>--- 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. 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
