Re: Tag locking change

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
>> Subject: Re: Tag locking change
>>
>> Greg A. Woods wrote:
>> 
>> > If you really Really REALLY want to tag the head of a branch then just
>> > check out the branch (or do a "cvs update" in any existing working
>> > directory which has no un-committed changes) then then apply the tag to
>> > what you get as a result by running "cvs tag" in that working directory.
>> > That way you can know ahead of time exactly what you've got.  It's then
>> > up to the user whether or not they actually look to see what's there
>> > before they tag it.
>> 
>>      What I fail to understand is why anyone would want to tag the head of 
>> a branch in an instantaneous fashion.

>Me too!  :-)

There are lots of cases where someone demands "tag branch x as of time y".
It's used often enough when someone doesn't care what the specific version
numbers are, or they don't know or care what tags (if any) have been
applied to those versions.  But they know what features they want, and
they know when those features were committed to the branch, so the
branch/timestamp pair is their means of identifying specific configurations.
In some shops that apply tags infrequently, this may indeed be the only
means to identify a configuration.

I claim that "y" == "now" is a common special case.  Therein lies the
"tag the head of a branch" issue.

As for the instantaneous part:  It takes a while for CVS to apply tags
using the rtag command.  The proposed change to the locking system opens
a race condition between rtag and commit, where the head of the branch
can change while the tag is being applied.  Some of us think this is
bad and would consider it a bug, while others seem to think this is bad and
would consider it a feature.

However, assuming a timestamp of "now" during rtag is a low-overhead and
lock-free method to remove the race condition.  The same trick could be
used for checkout or update to improve throughput even when concurrent
commits are made to the same branch, provided commits continue to use
two-phase locking principles.

>--- End of forwarded message from address@hidden