> You have a good point.
> It's not obvious to users that they cannot lock files if it
> does not have "needs-lock" set.
Actually, you can lock files even if they don't have needs-lock.
This is what I'm suggesting -- As long as a file has a lock, even
without needs-lock, it implies that for now the file needs a lock.
As long as *either* the lock or the needs-lock is present, it implies
the need for lock, and the behavior of the client should have some
similarities -- If the file is locked by some other user, locally make
the file read-only and gray the icon. There's no conceivable reason why
a person should edit a file that's locked by someone else. All the
tools are in place to protect a user from this mistake, it's just a
matter of getting the developers to agree this is good behavior.
This is, after all, the behavior that new users expect. It's logical.
One person locks a file so other people won't edit it. And to lock a
file implies for now that the file needs a lock.
At present, the needs-lock is well communicated. It grays the icon, and
makes the file read-only. The same behavior should be present if the
file is locked by someone else.
There is only one reason, at present, that the client is unable to gray
the icon and make read-only, on a locked file. The client has no way to
know that the file is remotely locked, because there is no information
about remote locks in the entries file.
As always, the working copy is only as accurate as the most recent
update. Everyone can accept the fact that their icons will not update
unless they have clicked "update," and everyone can accept that they
should click update before they begin work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 29 19:00:50 2006