Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ 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 address@hidden