On 4/28/06, Edward Harvey <eharvey@chilsemi.com> wrote:
> The lock method is misleading. As evidenced by the fact that so many
> users have been misled.
>
The lock method seems to be the same as other lock methods I've seen,
how is it misleading? The lock prevents anyone from modifying the file
in the repository. It's only purpose is for the person obtaining the
lock to say they don't want to have to merge others changes. There's
nothing to stop someone who doesn't mind having to do such merging
from modifying the file without a lock. Even with needs-lock all it
does is set the read-only attribute. Anyone who wants to could remove
this and start modifying the file.
svn:needs-lock purpose is meant mostly for binary files that are never
mergeable. You seem to be thinking that anytime anyone locks a file
that all other users aren't going to want to touch that file. They
could quite easily not care about the lock and just know they may have
to wait and likely merge their changes. If the original person locked
it because they are going go be making some severely drastic changes
that would be a pain to merge with anyone else's changes then they
should really be communicating better with the team about this. A lock
may be a good idea for this, but is certainly not the correct means of
communication.
> If a person locks a file, the lock is not communicated to other users.
> Unless the user manually checks for it, which as you said, costs more
> time and even you yourself don't bother to do it.
>
With your proposed method, users would still have to actively do
something for it to have any benefit. They would have to do an update
to get the needs-lock property. If a user cares about whether someone
else locked a file, I don't understand why they can't just use the
Check for Modifications instead of having to run an Update every time.
They'd have to do this anyways if for some reason they didn't want to
get an update currently.
If you really want to communicate locks you should just look into a
post-lock script that sends an e-mail.
- Jody
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Apr 28 23:29:39 2006