RE: cvs add <directory>

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Friday, May 23, 2003 at 15:25:51 (-0700), Shankar Unni wrote: ]
>> Subject: RE: cvs add <directory>
>>
>> I know that the CVS aficionados like to think of directories as just
>> artifacts of some arbitrary file arrangement, but the actual directory
>> organization is important in many (most) cases. 

>Indeed, but all of this "organization" is automatically and
>transparently handled by CVS.  Directories exist when they need to, and
>not otherwise.  Files come and they go as content is commited to them
>and as they are marked dead.

This is all true, if your requirement is simply to be able to check in
new changes and reproduce those changes.  However, the story is incomplete
because that is not all that a version control system is called upon to
do.  It is in these other requirements that you do not list where the
CVS mechanism breaks.

>> 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.  When you rename files you
>simply commit the necessary changes to the scripts which know the names
>& locations of these files at the same time as you commit the adds and
>removes and all is as it should be.  (i.e. always commit _only_ when
>everything is working togther)

What is lost is the ability to merge between branches.  You can merge
adds and removals, but you can't merge changes to content that occur
on one branch while a rename occurs on another.

The CVS mechanism breaks in other ways, too.  The add/remove workaround
means that CVS requires users to combine version histories among files
whose only commonality is that they happen to share a spot in the
filesystem at some point in time.  This is broken because merging content
that have distinctly different semantics is the wrong thing to do.

>--- End of forwarded message from address@hidden