Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> On Thu, 2002-02-21 at 17:45, Greg A. Woods wrote:
>> > 
>> > Don't get stuck on this idea of trying to keep track of everything back
>> > to the beginning of time with one RCS file. 
>> 
>> So, you don't believe that history of those files are that important.

>Of course it's important -- it's your record of what happened to that
>code through its lifetime.  It can tell you how bugs were fixed in the
>past, and how new bugs were introduced, and all kinds of management
>level information such as how many lines of code changed, who changed
>them, etc., etc., etc.

>It just doesn't have to be all in the same RCS file.  The idea that it
>should is a very dangerous fallacy, esp. w.r.t. to CVS.

That last paragraph is utter crap.  Without having the entire history
of a file's lifetime in one container, it's much much harder to track
changes that are made before the last reorg.  And it's especially difficult
to track migrations through the reorg with respect to branches.  For
example, it's much harder to migrate bug fixes from old releases to new
development if the new stuff involves renaming files.

And going the other way, suppose a rename was done and a new file takes
the place of the old one in the filesystem.  Now you have a dangerous
situation in which a single RCS files contains partial version histories
of multiple files.  It's dangerous because it opens up the possibility of
someone merging inappropriate changes from one branch to another, from
one file to another.

Here is an illustration:

Create file x using "cvs add".
Commit new revisions to x.
Create a branch of x, say "a".
Commit revisions to x on the trunk and the branch.
On the trunk use "cvs remove" and "cvs add" to rename x to y.
Resurrect x for brand new purpose on the trunk.
Commit revisions to x on the trunk.
Join any revision of x on the "a" branch with the trunk.

Note that in practice, the last step involves an entire project, so
an empty join would typically be done on the trunk of file y with the
non-existent "a" branch.

The join is very dangerous because first of all it doesn't do what the
user wants (migrate a fix from branch "a" of x to the trunk of y), and
second of all because it can render the new x unusable on the trunk
(potentially with loss of data if the user didn't commit there first).

This is a real world scenario, but simplified in this example:  Branch
"a" is the maintenance branch of a past release, and the trunk is the
next release.  It's common to migrate bug fixes in this manner.  And if
the next release is a major one that involves significant architectural
changes to the project (which is common) then some kind of reorg is
expected.

The fact that CVS doesn't map RCS files uniquely to sources in the
context of reorganizations doesn't make the requirement to do so
a fallacy.  It makes CVS broken.

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