Cool, such a feature would also be useful for backing up the repository. Do you
still have the diff file?
Noel
[EMAIL PROTECTED] on 2000.02.20 21:33:37
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Re: Multiple developers and code integration
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 18, 2000 at 18:43:32 (-0800), Michael Peck wrote: ]
>> Subject: Multiple developers and code integration
>>
>> You would get on the hat list with 'cvs hat -a <message>', and then when
>> it was your turn, you would grab the hat with 'cvs hat -g'. Then you
>> would check in, and 'cvs hat -f' to free the hat. This also sent email
>> to the next person on the hat list informing them that the hat was now
>> free for them to grab. 'cvs hat -l' showed all the people on the list
>> with their comments, and a counter of how long they've been waiting, or
>> how long the hat has been available to them. If nobody had the hat,
>> only the first person on the hat list could grab it for the first half
>> hour. If they didn't grab it, then the next person could grab it.
>> There were also commands to jump ahead of others in the list and drop
>> back behind others.
>Kinda cool, but I don't think it's necessarily a good thing to integrate
>directly into CVS.
I once made a local change to CVS in the v1.3 days to support such a feature.
I called it "cvs lock" and it locked an entire subtree so that a single user
would have permission to perform updates and commits within that tree, and
all other users were locked out. The subtree was a tree rooted in any
arbitrary directory within the repository. In practice it also had to
include all of its ancestor directories up to (but not including) the
root of the repository itself.
The requirement was to allow that user to merge several branches and commit
each file upon its completion. The locks were needed to prevent commits from
corrupting that user's state, and to prevent updates (and checkouts) from
getting inconsistent state (resulting from a partially committed merge).
That group of a dozen or so people was very happy with the addition of that
feature.
(No, Greg, I did not think up this feature; the users did. These mega-
merges were special cases and they really did want to shut off CVS'
concurrency features while they were occurring. They had their reasons
for minimizing the number of merges with the understanding that the
complexity of the merges increased with the length of the contributing
branches.)
>--- End of forwarded message from [EMAIL PROTECTED]
