Greg Hudson wrote:
>(Apologies to everyone for the length. Many points of disagreement
>here.)
>
>
(Which is good, we'll at least have a good chance of getting it right
the first time.)
>>I've explained this before. Both ACLs and locks need a path-based lookup
>>table that supports tree-based inheritance. The idea is to use _one_
>>table for both, and a single lookup overhead for both, not reinvent the
>>wheel yet a third time.
>>
>>
>
>(1) Well, if we don't do directory locks, we certainly don't need
>tree-based inheritance for locking.
>
>(2) If we do directory locks, we still don't really need tree-based
>inheritance for locking. We just have to look up the changed
>directories as well as the changed files in the lock table.
>
>(3) We need to maintain history on ACLs, but not on locks. In some ACL
>designs, an ACL change might constitute a commit, whereas a lock or
>unlock pretty much necessarily does not constitute a commit.
>
>(4) ACLs are potentially more numerous and need to be checked in more
>places than locks, but do not change as often.
>
>
I'll start an ACL design thread soonish, and I'll explain my reasons for
wanting to have a common infrastructure in another thread, too.
>(I've asked what happens if a file is deleted when a lock is held on it,
>and got the answer from several people, "well, you can't delete a file
>if you don't hold the lock." Which doesn't really answer my question;
>what happens if you delete the file while you do hold the lock?)
>
>
That depends on whether you restrict locks to apply only to existing
objects or not. For example, most byte-range locking implementations I
know will let you lock a range of bytes beyond the physical end of the
file. This is useful for some forms of IPC, but the main reason to do so
is because it makes the range-lock implementation simpler and much faster.
In the same way, you could decide to allow the SVN user to lock a path
that's not been added to the repository yet, for example, to "reserve" a
file name they're about to add (never mind about the WC-side
implementation problems for now). Let's call this a B-type lock, and the
strictly targeted kind an A-type lock.
Now to your question. For the sake of argument, let's assume that locks
are implemented in libsvn_repos, not libsvn_fs -- it makes the range of
possibilities more interesting.
In this scenario, there are three distinct ways to delete a file: 1.
directly through libsvn_fs, 2. through implicit commit ("svn rm URL"),
or 3. with the help of the working copy ("svn rm path; svn commit").
1. Since libsvn_fs doesn't know about locks, the deletion will succeed.
* with A-type locks: The repository's lock table becomes
inconsistent (ouch!). The WC that owns the lock is confused and
has to treat this as a lock steal.
* with B-type locks: Nothing changes, the lock lives on.
2. Not having a working copy, you can't attach a lock token to "svn rm
URL". Therefore the delete fails.
3. This scenario has two subcases:
3.1 Using a normal commit, the lock is destroyed as part of the commit.
3.2 Using "svn commit --keep-locks"
* with A-type locks: What happens depends on the exact semantics of
the "--keep-locks" switch. Again, there are two choices:
o The commit always destroys the lock, and "--keep-locks"
forces an atomic "commit+lock". Since the file on longer
exists after the commit, the "lock" part will fail,
therefore the whole commit will fail.
o The commit itself doesn't touch the locks table if
--keep-locks is set. The commit will succeed, but the locks
table won't get updated. The result is the same sort of
inconsistency as in case 1.
* with B-type locks: Nothing changes, the lock lives on
If we use A-type locks -- note the "if" because this discussion hasn't
touched on these alternatives yet -- then based on this analysis, two
things become apparent:
* If locking is in libsvn_repos, case 3. implies that this layer has
to play a part in ensuring repository consistency on failed
commits. The maintenance of the filesystem's transactional
guarantees starts creeping from libsvn_fs to libsvn_repos. Hm.
* If locking is in libsvn_fs, case 1. never happens.
If we use B-type locks, locking can be handled by libsvn_repos just
fine, at the cost of complicating working-copy maintenance.
>>I've spent the last three months modifying ACLs instead of using locks
>>to block access to the release branch where locks would serve better,
>>
>>
>
>Why would locks have served better?
>
>
This particular tool (name omitted to protect the guilty, initials are
V.S.S.) doesn't have the concept of a wildcard user ID ("everyone"), so
to lock a directory, I had to modify the ACL for _every_ user of the
system, except the build manager. It would have been so much easier, not
to mention more logical (semantics do matter, IMHO), if the build
manager could have just locked the tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 14:18:49 2004