On Oct 12, 2004, at 6:59 PM, Julian Foad wrote:
> Here are my initial comments on the functional spec, in the form of a
> tentative patch.
> The one issue that I don't explain below is the idea of requiring that
> a path is locked before committing to it. I marked this with "###"
> and "Pointless". If we simply require that, and a user isn't
> interested in complying with the spirit of the requirement, she will
> simply use a "commit" script that performs "lock; commit". So what is
> the spirit of this requirement? The only thing I can think of is to
> try to enforce, or at least encourage, locking before modifying the
> Other comments presented as part of the patch.
> - Julian
> Index: notes/locking/locking-functional-spec.txt
> --- notes/locking/locking-functional-spec.txt (revision 11340)
> +++ notes/locking/locking-functional-spec.txt (working copy)
> @@ -18,6 +18,10 @@
> 2. Provide a communication mechanism to decrease the chances of
> a user wasting time working on a file locked by someone else.
> + 3. Perhaps provide a mechanism for users to configure (to the
> + extent allowed by the repository administrator) which paths
> + must/may/cannot be locked. ### But what does this mean?
This is covered in section I.B.
> B. Summary
> We recommend implementing a lightweight locking mechanism.
> @@ -26,7 +30,7 @@
> and enforce locking policies. Provide a series of client
> commands for creating, removing, breaking, and stealing locks.
> Lastly, create a new property to communicate that a path must be
> - locked before committing.
> + locked before committing. ### Pointless.
How is it pointless? See section II.B.2.
> Note that Subversion is still an inherently concurrent system.
> The ability to lock paths is optional, and can even be prevented
> @@ -52,7 +56,21 @@
> exclusive right to change the directory's list of entries and
> properties, to delete the directory, and to move the
> directory. This lock applies recursively to all files and
> - directories under the locked directory.
> + directories under the locked directory, regardless of whether
> + they existed at the time when the lock was created. A
> + directory lock is a single entity; it cannot be decomposed by
> + unlocking some of its children, grandchildren, etc.
This is a good clarification.
> + The restriction on moving a locked node includes the effect
> + moving any of its parent directories.
Ah! That makes sense.
> + A given path can never be the direct target of more than one
> + active lock, whether by the same or different users, in the
> + same or different working copies. However, a path may be
> + subject indirectly to any number of active locks inherited
> + from parent directories, as well as perhaps a direct lock.
> + All of the locks applicable to a path will necessarily be
> + the same user and the same working copy.
So you're saying that multiple locks *can* apply to the same path (via
recursion) iff they're owned by the same user, right?
> B. Client requirements for locking
> @@ -60,13 +78,16 @@
> It must be possible to declare that certain files or
> directories absolutely require locks before committing.
> + ### Pointless.
Again, I disagree. See Section I.B.
> 2. Communication system
> There must be a system in place that tells users when locking
> - is necessary; ideally, it would prevent a user from
> - beginning work in the first place. If a lock already exists,
> - a user should be able to who created it, when, and why.
s/able to/able to discover/
> + is necessary; ideally, it would prevent a user from
> + work in the first place. At least it must allow a user to
> + discover whether locking is advised for a particular path.
> + a lock already exists, a user should be able to see who
> + created it, when, and why.
> C. Lock manipulation via client
> @@ -77,6 +98,12 @@
> and occasionally synchronize this with the repository's
> master list of locks.
> + The working copy must store representations not only of its
> + own locks but of all other locks that affect it.
This is likely going to be necessary.
> These will
> + obviously not include the lock tokens, and may not include
> + information about the whereabouts of the working copy that
> + owns each lock.
I don't know about this--we never assumed that the server would track
working copies in the lock table. Do you really think it's necessary?
And if so, how do you see it happening? By IP address? What if a user
has multiple working copies on the same machine?
> Because locks can be broken or stolen, it is possible for a
> working copy's lock representation to become "defunct". A
> defunct lock cannot be used or released--it is useless and is
> @@ -111,9 +138,12 @@
> 1. Using a lock to Commit
> - Upon successful commit, a locked path is released by
> - default. The Subversion client provides an option to
> - retain the lock after commit.
> + Upon successful commit, the direct lock on each path
> + offered for committing (regardless of whether the
> + content of the path has changed and so is actually
> + committed) is either released or retained, at the
> + of the client. Any indirect locks inherited from
> + paths that are not offered for committing are retained.
Again, providing that the parent locks are owned by the same user.
This brings up an interesting point WRT recursive locks--they'll have
to be search through all their children [An O(n) operation] before
allowing a lock.
> 2. Releasing a lock
> @@ -135,20 +165,9 @@
> d. Stealing a lock
> - "Stealing" a lock is a means of creating a lock when:
> - - The path is locked by you, but you don't have a
> - representation of the lock in your current working
> - copy, or
> - - The path is locked by someone else.
> - In order to steal a lock, a user must be authenticated to
> - the server.
> - (e.g. Harry locks path foo and goes on vacation. Sally
> - needs to make changes to path foo and obtains a lock on
> - path foo by stealing Harry's lock, without using Harry's
> - username or lock representation.)
> + "Stealing" a lock is exactly equivalent to breaking and
> + then creating the lock. It may be useful to provide this
> + as an atomic operation.
I prefer the explicit description that we had as it's consistent with
a., b., and c.
> e. Discovering/examining locks
> @@ -205,14 +224,14 @@
> During a commit, the server checks for locks the same way that
> it checks for out-of-dateness.
> - As each changed path arrives, the server checks to see if the
> - path is locked. If the path is locked, the server makes certain
> - that the correct username and lock representation have been
> - presented by the client. If not, the entire commit is rejected
> - immediately.
> - In addition, the server re-checks and enforces locks during
> - commit finalization.
> + During commit finalization, if a path is locked, the server
> + certain that the correct username and lock representation have
> + been presented by the client. If not, the entire commit is
> + rejected.
> + In addition, for efficiency, the server should probably check
> + locks as each changed path arrives. If a path violates a lock,
> + the entire commit is rejected immediately.
I find this rephrasing less clear (and the last paragraph repeats the
"During a commit...out-of-dateness" bit too.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Oct 13 06:11:03 2004