On Dec 14, 2004, at 6:40 PM, Julian Foad wrote:
>
> Isn't the real purpose of "svn:needs-lock" to indicate that a file
> _should_ be locked before _editing_ it?
Absoultely. This paper needs to be tweaked.
A locking system has two goals:
1. serialize access to a file, so merges never have to happen.
2. prevent people from wasting time on unmergeable changes.
If we simply implemented 'lock' and 'unlock' and called it day, we'd
only be satisfying the first goal, not the second goal. Heck, we're
already at that point now.
The whole point of this 'needs-lock' property isn't to force people to
do extra work. It's to *prevent* wasted work from happening; the
read-only state is the critical communication system. In an ideal
world, everyone would remember to 'lock' unmergeable files before they
ever started working on them. But that never happens. The read-only
feature is the "swift kick to the head" that reminds someone to lock
before editing.
> 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?
>
I think spec is misworded. It should read: "Create a new
"svn:needs-lock" property to indicate that a file must be locked
_before being edited_." The act of locking it changes the working
file from read-only to read-write.
> 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 don't think the property has anything to do with the ability to
commit changes to a file: that is, if a file has this property in the
repository, but nobody has it locked, then heck, sure, someone can do
an 'svn mv URL URL' on it. The property only affects working copy
permissions; it doesn't act like a lock by itself.
(Conversely, the property isn't required to lock something: any file
can be locked.)
>
> I think we should _not_ require a lock in order to commit, either from
> WC or server side.
Agreed. But in the case of WC, the only way the file can change from
read-only to read-write by locking it first, so files that have this
property generally *will* be locked already when committed.
>
>
>> 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?
I think this whole section needs to be changed; as I said, I think I'm
with you. The presence of the property shouldn't *require* a lock to
make changes. The property should just affect working copy
permissions, that's it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 06:50:02 2004