>--- Forwarded mail from [EMAIL PROTECTED] >[ 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). Believe it or not, I actually agree with Greg on this one. However, there are possible implementations that can eliminate the risk. For example, locking tags in the same what directories are locked and performing the same kinds of waits prevent users from using tags in incompatible ways, such as fetching by tag while updating a tag. Features such as rtag that don't identify in advance the revisions they act upon can also rely on branch/timestamp pairs to prevent multiple update problems when users sneak in a commit while rtag processes a different directory of the same module. Version tags could also be reimplemented not as symbolic names of specific revisions but as branch/timestamp pairs. Branch tags apply to their sprout points, which can be identified similarly. It's perhaps too much to ask to reimplement tags as in the last paragraph, but the first two items are relatively easy to implement. There has been a lot of research over the years on topics such as "degrees of isolation" and "lock free algorithms," and CVS could benefit from some of it. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs