Brian W. Fitzpatrick wrote:
>
> On Oct 12, 2004, at 6:59 PM, Julian Foad wrote:
[...]
>> 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
>> resource.
>> 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.
Well, the second paragraph of I.B. implies that configurability by the
administrator is a major goal, and so it should be listed under "Goals".
>> 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.
OK - it is not pointless to have a communication system. We just need
to be clear about what its purpose is, as it _is_ pointless to enforce
that a path must be locked (just) before committing. Here's why (as
summarised in my introductory paragraph at the beginning of the e-mail).
If a user wasn't going to lock the file before committing, and then we
force them to lock it before committing, no benefit results from doing
so. They try to lock it before committing; if that succeeds, then they
can commit it but also they would (in the unenforced scenario) have been
able to commit it anyway. If they fail to get a lock, then they would
not have been able to commit it in the unenforced scenario. So what's
gained?
The only thing I can see that would be useful is if we could try to
ensure that a lock is taken out before the user starts to modify the
file. If that's what this sentence is aiming at, then it should say so.
>> + 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 from
>> + 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?
Yes. I'm proposing this as one possible specification. Not necessarily
the one that we want.
>> @@ -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 any
>> + 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?
Did you mis-read my text? I said "may not include" meaning "need not
include", because I recognise that trying to identify a WC to other
users would be tricky and not necessarily very useful. I certainly
don't think it is necessary.
>> @@ -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 choice
>> + of the client. Any indirect locks inherited from parent
>> + 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.
In principle, yes, though the server could cache information for each
directory that reflects whether locks exist beneath it, to make this
efficient. As per Greg Hudson's e-mail, recursive locks may well be too
complicated for us to do at this stage.
>> @@ -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 makes
>> + 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 for
>> + locks as each changed path arrives. If a path violates a lock,
>> + the entire commit is rejected immediately.
>
> I find this rephrasing less clear
That might be because I don't know how the server checks for
out-of-dateness. I was trying to change it from implying that the
checks as each changed path arrives are the essential and checks during
finalisation secondary, to the other way around, and make it clear (as
this is a functional spec) that the checks during arrival are not essential.
> (and the last paragraph repeats the
> "During a commit...out-of-dateness" bit too.
Huh? Where? I can't see that.
- Julian
>
> -Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 15:07:23 2004