Re: locking entire tree for write

[Greg A. Woods]

[ On Tuesday, October 14, 2003 at 13:05:58 (-0400), Derek Robert Price wrote: ]
> Subject: Re: locking entire tree for write
>
> If nobody has any comments on this, I'm going to check in the correction
> on feature soon.
>
> | Correct me if I am wrong, but there is no good reason for the
> | lock_tree_for_write calls in admin.c, edit.c, and watch.c.  The three
> | files contain four calls and all are of the form:
> |
> | ~    lock_tree_for_write
> | ~    start_recursion(...CVS_LOCK_NONE...)
> | ~    Lock_Cleanup
> |
> | with no intervening calls.  I believe that in all four locations this
> | could be replaced with the single call to:
> |
> | ~    start_recursion(...CVS_LOCK_WRITE...)
> |
> | as cvs tag and rtag do and that this would be more efficient, allowing
> | only a directory at a time to be locked rather than locking an entire
> | tree for the duration of the entire operations.

Yes, more efficient, but also more dangerous.

I don't know (and don't care) about anything to do with 'edit' and
'watch'.  However in theory even 'tag' and 'rtag' should always first
lock-for-write the whole module they're oerating on, even for the simple
case of adding a new tag (some other concurrent user can easily
encounter problems when trying to use the new tag, or the old tag in the
case of a rename or delete, or even an existing tag in the case of a
move).

For "cvs admin" there are many operations which won't leave the module
in an inconsistent state (w.r.t. other CVS readers) while they are still
processing, however it's very difficult to reliably predict which
operations are safe and which are not so 

Without locking the whole module we're relying on the fact that users
will recognize when they get an inconsistent tree and be able to "fix"
their working directory.

If I remember correctly previous discussions on this issue revolved
around the fact that tagging is often a frequent operation and tagging
of large trees should not need to halt all other operations since users
are generally experienced enough to recognize any problems that might
arise.  However "cvs admin" operations are normally quite uncommon and
given the range of possible things 'admin' can do it is generally better
to be safe than sorry and to always lock the whole module for write
before beginning any operation.

I.e.  "we" as a community have in the past agreed that for 'tag' and
'rtag' the benefits of per-directory locking outweigh the risks, but
that is not necessarily the case with 'admin'.

-- 
                                                Greg A. Woods

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