Re: Tag locking change

[Greg A. Woods]

[ On Monday, October 7, 2002 at 12:38:21 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Greg A. Woods writes:
> > 
> > Is this really a good idea?  Do people who start a 'cvs co -r' or some
> > other command using the new tag too soon before an [r]tag is finished
> > deserve to lose (assuming by some strange quirk of concurrency that
> > their command catches up to the tag)?
> 
> Yes, I'd say they do.  And they always have in the past.  Locking the
> whole tree was a fairly recent change in response to a report of lost
> changes due to bugs in the previous directory-at-a-time locking method

Locking the whole tree  is the correct way to ensure checkouts, or
merges, of new tags don't fail, and to ensure that commits don't happen
concurrently deep somewhere in separate branches of the tree resulting
in only partial tagging of the new changes.

(the alternative of forcing use of modules exclusively for any commit or
merge or checkout really isn't a viable alternative)

> and lots of people complained about it because tagging large trees can
> take a long time and no one can even do checkouts or updates while the
> tag is in progress.

That's life.  Tell them to get a faster disk subsystem, or get over it!  :-)

(running such long-running commands on the server instead of remotely
from a client might help too)

Such complaints really have no significance in relation to correctness
and maintenance of repository integrity.  Obviously users could still
erroneously commit related changes with separate commands and still end
up with partially tagged changes, but that's a user error and not one
caused by poor locking strategies in the system.  If the users don't
make such errors then the system shouldn't screw up behind their backs.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>