Re: CVS should die

Tom Lane wrote:

> AFAICS the only nondestructive way to do this is to cvs delete and cvs
> add, with a commit comment saying where the files were moved from. Then
> when you are looking at them in CVS, you'd have to navigate over to the
> previous location (by hand, probably; the commit comment isn't going to
> automate this for you) and look in the Attic to read the prior CVS history.
> It's not impossible, certainly, but it discourages moving files for less
> than the very best of reasons.

You can also do a repository-side copy of the ,v file to the new
location, remove old tags & branches from that new copy, and 'cvs
delete' the old copy. That preserves history but the file should still
show up in the old location (and not also in the new location) when
older versions are checked out. In theory. It's all very hairy..

> (I'm rather interested to know whether any other SCMs have a better
> solution to this problem, and if so what it is. It's not obvious how
> to do better.)

Subversion deals with this reasonably well. The main difference to CVS
is that it does not try to track multiple lines of development in a
particular file; instead, you make (internally cheap) copies *within*
the repository tree when you branch or tag.

Once you have that, it's much easier to track file copies and deletions,
as each path in the repository effectively has a linear history. A
rename is just a copy and delete.

See http://svnbook.red-bean.com/svnbook-1.0/ch04s02.html for some more
detail.

-O