Re: cvs add <directory>

[Kaz Kylheku]

On Fri, 23 May 2003, Greg A. Woods wrote:

> [ On Friday, May 23, 2003 at 15:25:51 (-0700), Shankar Unni wrote: ]
> > Consider, for instance, a product script setup that's checked in to CVS.
> > If the product's directories are reorganized in the future such that
> > files move around, it's important to be able to keep the file's history
> > separate from that of its location in the tree, so that I can see a
> > unified history of the file across that move. Having to "delete" the
> > file from one location and "create" it another breaks the history chain.
> 
> You are very confused.  Nothing is broken or lost when files are removed
> from one location and added in another.

What is broken is the merge context.  I rename foo.c to bar.c. On
another branch, you are committing changes on the same file where it is
still called foo.c. When I merge your change, I want the patch to go to
bar.c! I don't want some conflict, and then have to figure out
the situation and hand-migrate the changes from the old object to the
new.

This use case works sanely in systems like Meta-CVS and ClearCase.
The Subversion people haven't quite figured it out yet, last time I
checked, but they eventually might.

It does not work if you *simulate* a move operation by removing one
object and then creating a new one that happens to have the same
contents as the removed one. The merge operation has no idea that the
new object is intended to represent a continuation of the old one.
The operation to retrieve history has no idea how to hunt down the
faked out renames and stitch it all together.

If you don't care about sane merging, or being able to retrieve a
single, continous history of an object's contents, then the simulated
rename is good enough. Otherwise it is not.

But merging is what parallel development is all about. If I have to
hand-migrate changes from one object to another, I'm not getting as
much value out of the tool as I could if it had the feature.

Managing the directory structure is not the job of a build system, when
the objects involved are not the result of a build, but are the primary
objects that go into the build!. It's the job of a version control system.

Anyway, CVS has already been extended to do this, so it's pointless
to continue ranting against it.