Re: Tag locking change

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> There are lots of cases where someone demands "tag branch x as of time y".

>What the heck does that have to do with tagging the head of a branch?!?!?!?

Gosh, Greg, if you'd finished reading that paragraph and the next, you
would have the answer.  Let me recap here:

-->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.

Let me be more explicit:  The last version committed to a branch before
now is the head of the branch.  In other words, "branch x as of time now"
is the head of branch x.  Hence, the demand to "tag branch x as of time now"
is exactly the same as "tag the head of branch x".

>>  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.

>The point is you shouldn't be tagging the head of the branch without
>doing so from within a working directory which is up-to-date to the head
>of the branch in the first place.  It really doesn't matter whether "cvs
>rtag" makes it a safe "atomic" operation or not.

The only reason to have the working directory is to produce an inventory
of revision numbers of each version to which the tag is applied.
I claim that a branch/timestamp pair is equivalent to a revision number
in that it is another means to specifically identify versions.  The
reason this is true is because the version checked in on "branch x at
time y" has at most one revision number.

Determining the proper timestamp can be tricky, but so can be determining
the proper revision numbers.  Either way, the configuration needs to
be tested for correctness.  How that is done is beyond the scope of this
forum, but there are lots of ways to do it regardless of the method used
to identify the configuration.

>> However, assuming a timestamp of "now" during rtag is a low-overhead and
>> lock-free method to remove the race condition.

>Well, yes, in the implementation "now" hopefully gets converted to the
>time at the start of the command and doesn't change as the procedure
>progresses, and so it's a silly cheap trick to still get undefined
>results with the tag....

Yes, that's how I recommended the implementation be done.

However, keep in mind that your notion of "undefined" means that you don't
know the specific revision numbers of each version that gets the tag.
But the following streams of commands are exactly equivalent (assuming
rtag were modified to accept both -D and -r options):

cvs checkout -r branch module         cvs rtag -D now -r branch module
cvs tag label

No doubt you'll cry "foul" here because the checked-out working copy was
never validated.  In this case it doesn't matter because the desired
revisions are defined to be whatever's on the head of the branch at the
time the process is initiated.

Now let's try something else:

cvs checkout -r branch module        stamp=`date`
test away                            cvs export -D $stamp -r branch module
cvs tag label                        test away
                                     cvs rtag -D $stamp -r branch module

I think that you will agree that these are equivalent, with the following
deviation:  One workspace contains CVS meta-data and the other does not.

Now consider that someone else checks out and tests a series of
configurations and produces a list that identifies "good" configurations.  
Such a list could contain existing workspaces that contain CVS meta-data,
it could identify an inventory of version numbers (e.g. the output of
"cvs status" reduced to some usable format), or it could supply
branch/timestamp pairs collected when the test environments were assembled.
All of these are equivalent and produce identical results.  What's more,
if all of the timestamps are identical, then a single branch/timestamp
pair can specify the entire configuration.

Now here's where the branch/timestamp method breaks down:

cvs checkout -r branch module
test away/failure
cvs update -r branch submodule
test away/good
cvs tag label

Under these conditions, there is no single branch/timetamp pair that can
identify the correct revisions of the entire module.  I believe that
Greg's argument is based on the notion that this is a common scenario.

But there are ways to solve this problem, too.  One common one is to spin
another build and update the timestamp.  Another is to keep a list of
branch/timestamp/submodule triples to apply corrections that match the
updates.  Again, these branch/timestamp methods produce identical results,
in terms of correctness, to methods that rely on revision numbers.

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