>--- Forwarded mail from [EMAIL PROTECTED] >[ On Thursday, February 21, 2002 at 18:03:20 (-0800), Paul Sander wrote: ] >> Subject: Re: CVS Update Behaviour >> >> 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.
>No, you're full crap, to be blunt about it. It's hardly even noticably >more difficult to track the history across multiple files. You've been >harping on this subject for literally years yet you've never contributed >one line of code to make it easier and I'll bet you're so scared of this >particular way of using CVS that you don't even try to do it yourself so >how the hell would you know how hard it is to do!?!?!?!?!? >Quit being an idiot Paul and either shut up or talk only about the >things you actually have real live current experience with. I've done it the "CVS way", actually I've done it in several of the "CVS ways" as documented in the manual. And I have modified CVS to try to make one or two of them easier. It can't be done with sufficient robustness to be worthwhile to submit to Larry and company, at least not without making incompatible changes to the format of the repository. And that's the way it sits as long as CVS uses the filesystem to map the locations of revision containers to sandboxes. I've also used systems do maintain a single revision history of a file throughout its lifetime. They are way more usable than CVS under these conditions, and some of them support concurrent development. The mapping can be done with text files (transparently to the user as an implementation detail), and the merge algorithms are virtually identical to what CVS already has built-in. All that the mappings do is add a level of indirection. There are secondary issues that can be complex, such as how one efficiently locks the revision containers during commits. But that's only an issue if CVS is used in local mode; the client/server modes can funnel the locking in such a way that the necessary coordination can be implemented well. This system would be more scalable if there were a way to permit concurrent modifications to the revision containers on different branches, but that's a lesser requirement than just getting the mapping at all. Rather than argue for the sake of arguing, I suggest that you try a system that has such a mechanism. Apply it to a non-trivial project, and try making fundamental changes to the layout of the sources. A Unix kernel with its drivers might be a good sample. Then try merging changes across branches. Because CVS doesn't have this feature, its users become accustomed to working around its absence. And they don't recognize the value of the feature until they've actually tried it in a real world situation using a different system. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
