I think you may have missed my point. Let me try to restate.
You are right on the attribute svn:needs-lock scenario. It will always
be read only unless a lock is set. So lets forget that scenario.. I went
off on a tangent while trying to present the case.
The point is that lock data is available in Subversion. It is not
explicitly made visible to the user at points where it would be useful
(on update, checkout, etc.) Instead the user is forced to jump through
additional hoops when they shouldn't have to. Or in the case of the
commit failure message, its not a clear message. I can't tell you how
many users in the past have come to me saying "I got an error" and they
never even read the whole message.
>But the instant that update is complete, any lock data can be out of
>date. One should always check w/ the server (svn st -u) to learn the
>current lock situation for a file, not rely upon local WC info.
The converse to this is true as well. The moment the svn st -u is done,
any lock data can be out of date. The system should fail "safe" and if
it detects a lock on update (or checkout) then it should note it and
record that in the working copy (which would make it easier for clients
like Tortoise to then display the lock). If the working copy indicates
a lock, even though the lock has been released since the last update,
that's the "safe" failure as it alerts the user to a potential problem
before it occurs. The locked status in the working copy would tell the
user to do one of the following:
1) Go talk to the person who has the file locked.
2) Wait and later try a svn update or status -u on the file to see if
the lock has been released
3) Choose to break the lock.
I'm not advocating putting more restrictions on the file modification
process. I'm advocating enhancing the existing commands to provide data
that is already captured in a manner that is easily understood by the
end user.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 13 20:49:28 2007