Re: CVS Update Behaviour

[Arcin Bozkurt - Archie]

On Thu, 2002-02-21 at 21:03, Paul Sander wrote:
> >--- 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.

In the problem I am facing, we are not, at the moment, thinking of
assigning new purposes to existing files and we are not planning any
renamings...

> 
> 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.
> 

A question on merge behaviour of cvs: Will CVS be able to follow a file
disappearing in one module, appearing in another one? I would say no.
And therefore a merge would not be able to propogate bugfixes on that
file even though the file is not deleted, and resurrected for another,
etc.


Am I right?

> Here is an illustration:
> 
[... : illustration understood and taken out for clarity ]
> 
> 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
>