You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2004/10/12 23:59:21 UTC
Locking functional spec comments
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 resource.
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?
+
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.
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.
+
+ The restriction on moving a locked node includes the effect of
+ moving any of its parent directories.
+
+ 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.
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.
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.
+ is necessary; ideally, it would prevent a user from beginning
+ work in the first place. At least it must allow a user to
+ discover whether locking is advised for a particular path. If
+ 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. 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.
+
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 choice
+ of the client. Any indirect locks inherited from parent
+ paths that are not offered for committing are retained.
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.
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 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.
D. Configurable Mechanisms
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Garrett Rooney wrote:
> I suppose the svn:lock property doesn't make a whole lot of sense unless
> it's enforcing 'lock this before you can edit it' by setting the file to
> read-only or something, like perforce does.
Of course the spec does say we do that, so it's a moot point...
I'm going to refrain from commenting again until I've read over the
whole thing while I'm fully awake and not running only on caffeine...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Julian Foad wrote:
> Garrett Rooney wrote:
>
>> Julian Foad wrote:
>>
>>> 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.
>>
>>
>> It's not totally pointless. Requiring a lock to be taken out also
>> requires the pre-lock hook script to fire, which means that the
>> administrator has the ability to say "you can't lock this file". That
>> might be useful in some situations.
>
>
> But in the unenforced scenario, the administrator would just put that
> same restriction in the pre-commit hook instead, wouldn't he?
True, I guess he would be able to do that.
I suppose the svn:lock property doesn't make a whole lot of sense unless
it's enforcing 'lock this before you can edit it' by setting the file to
read-only or something, like perforce does.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Julian Foad <ju...@btopenworld.com>.
Garrett Rooney wrote:
> Julian Foad wrote:
>> 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.
>
> It's not totally pointless. Requiring a lock to be taken out also
> requires the pre-lock hook script to fire, which means that the
> administrator has the ability to say "you can't lock this file". That
> might be useful in some situations.
But in the unenforced scenario, the administrator would just put that
same restriction in the pre-commit hook instead, wouldn't he?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 9:17 AM, Garrett Rooney wrote:
>
> It's not totally pointless. Requiring a lock to be taken out also
> requires the pre-lock hook script to fire, which means that the
> administrator has the ability to say "you can't lock this file". That
> might be useful in some situations.
>
Another reason it's not pointless is that it's inherently part of the
UI to prevent people from wasting time.
The model is: somebody wants to change a file, then notices it's
read-only. "Oh", he thinks, "that's right, I guess I should lock this
thing first." The reward for running 'svn lock' is that the file
becomes read-write.
Sure, you could argue that there's nothing *techincally* gained by
requiring a lock before commit (since the server is ultimately
enforcing locks, not the client), but it's a fundamental part of the
"don't-waste-time-editing" system. The theory is that an administrator
would activate this read-only/must-lock-first behavior on all files
that are inherently unmergable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Julian Foad wrote:
>>> 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.
It's not totally pointless. Requiring a lock to be taken out also
requires the pre-lock hook script to fire, which means that the
administrator has the ability to say "you can't lock this file". That
might be useful in some situations.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Julian Foad <ju...@btopenworld.com>.
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
Re: Locking functional spec comments
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
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
> resource.
>
> 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
> of
> + 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
> 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?
> 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
> beginning
> + work in the first place. At least it must allow a user to
> + discover whether locking is advised for a particular path.
> If
> + a lock already exists, a user should be able to see who
> + created it, when, and why.
OK.
> 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
> 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?
> 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
> 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.
> 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
> 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 (and the last paragraph repeats the
"During a commit...out-of-dateness" bit too.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> + The working copy must store representations not only of its
>> + own locks but of all other locks that affect it.
>
> I think "must" is a bit strong here. Actually I don't see it's useful at
> all; that information is stale almost by definition, and would
> complicate the update process.
[...]
OK. I accept that.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec comments
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> + The working copy must store representations not only of its
> + own locks but of all other locks that affect it.
I think "must" is a bit strong here. Actually I don't see it's useful at
all; that information is stale almost by definition, and would
complicate the update process. How? Well, the state of locks on files
can change _without_ a bump to the global revision number, so what is
today an empty update would still have to pull all lock info frrom the
server. For example:
A> svn update
A> svn lock foo
B> svn update (notes that foo is locked elsewhere)
A> svn unlock foo (changes her mind, no change in the repo)
B> svn update
At this point, the server notices that the client's working copy is
already up-to-date. But in order to maintain the lock status in the WC,
the server would _still_ have to send info about all locks in the
subtree. Yuck.
Storing knowledge about other people's locks in the WC will gain you
nothing, because any lock-affected operation would _still_ have to make
a round trip to the server to update stale info.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org