On Thu, 2002-02-21 at 21:03, Paul Sander wrote: > >--- Forwarded mail from [EMAIL PROTECTED] > > >[ 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 [EMAIL PROTECTED] > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
