From notes/locking/locking-ui.txt:
> B. The "svn:needs-lock" property
>
> Create a new "svn:needs-lock" property to indicate that a file
> must be locked before committing.
I still don't see the logic in defining the property in this way. If the file
is up to date, the user can satisfy this condition by replacing "commit" with
"lock; commit", giving himself extra work for no benefit that I can see. If
the file is not up to date, then either the "lock" or the "commit" command is
going to say so; does it matter which?
If we made the svn client "commit" command behave like "lock; commit", that
would automatically satisfy that condition so that it no longer needs to be
stated. I think this thought experiment shows the above definition to be
redundant. Have I overlooked anything?
Isn't the real purpose of "svn:needs-lock" to indicate that a file _should_ be
locked before _editing_ it? Isn't the idea of checking that the file is locked
before committing really just an idea for an implementation detail that could
help to teach people not to bypass its real meaning?
Was this definition intended to apply to server-side commit operations such as
"move URL URL" or "propedit URL"? It would seem ugly if so, since they are
atomic anyway and therefore don't need a lock, but somewhat inconsistent if not.
I think we should _not_ require a lock in order to commit, either from WC or
server side.
> Just like "svn:executable",
> the value of the property is irrelevant and the property can be
> created (or deleted) by any user or administrator.
>
> 1. Property as enforcement system
>
> The presence of the "svn:needs-lock" property on a file means
> that concurrency is disabled for the file and a user *must*
> obtain a lock on that file before committing changes to it.
> The server rejects any commit which modifies this file unless
> the user has a lock on the file. Note: a user can delete a
> file with this property, providing that the file is not
> locked.
Why this exception for deleting? I'd think it would be logical for this
property to require a lock for exactly the same operations that a lock
protects. With this exception, user A schedules the file F for deletion, then
user B locks, changes, commits so this copy is out of date, then user A tries
to commit, and gets an "out of date" error. Isn't that what this property was
trying to avoid?
>
> 2. Property as communication system
>
> When the Subversion client encounters the "svn:needs-lock"
> property on a path (on checkout or update), it sets the
Change to something like "(on commands like 'checkout' or 'update' that modify
the WC)" because other commands like "copy" would also do this.
> working-copy path to a read-only state by default.
Add "unless it is locked by this user".
The phrase "by default" needs qualifying. Is it alluding to the possibility of
a local configuration option that can specify other behaviour, or the exception
if locked by this user, or something else?
> This
> serves as a reminder to the user that she should lock this
> path before editing it. When a user locks the path, the
> Subversion client makes the working-copy path read-write.
> When the user releases the lock, or if the lock is found to
> be defunct (see next section), the Subversion client makes
> the path read-only again.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 01:42:10 2004