Separation of lock and needs-lock (was Atomicity of locks and needs-lock)

> Also, because we don't necessarily agree that you shouldn't
> be able to edit a file someone has locked.

This is primary goal #2 of locking-functional-spec.txt: "decrease the
chances of a user wasting time working on a file locked by someone
else."

The presence of a lock implies temporarily that any merge attempt would
be difficult or impossible. (Until the next commit; hence the commit
automatically removes the lock.)

The presence of the needs-lock property implies persistently that any
merge attempt would be difficult or impossible, hence a lock is required
for any changes to commit.

---
Whether a file is locked by some other user, or has the needs-lock
property, it means that any changes are likely to be wasted time, and in
either case it should be suggested to wait or obtain lock.  In either
case, the file should be read-only and the gui should display a gray
icon.  
Only if you are willing to accept the fact that your changes are
probably not commitable, should you then override the read-only bit,
ignore the lock, and work on a file which is locked by someone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org