> > I know by all accounts, it makes no sense to ever lock a file that
> > doesn't needslock.
>
> What leads you to this conclusion? needs-lock forces users
What leads me to this conclusion is actually tortoisesvn, and the
insistence of the tortoisesvn developers, that it makes no sense to lock
a file unless it needs-lock.
Personally I disagree with them - I agree with you, that the
"needs-lock" property should indicate that a file is unmergeable and
should never be edited without a lock - but I can't convince the
tortoisesvn group of that. They insist that it makes no sense to lock a
file unless it needs-lock, and I can learn to live with it if only
there's some solution that adequately communicates the presence of a
lock on a file.
In tortoisesvn behavior, the needs-lock property is communicated during
updates. But tortoisesvn does not communicate someone else's lock,
because someone else's lock is not locally cached in the entries file.
In my opinion, whether a file is remotely locked or has the needs-lock
property, the client behavior should be the same - Make the file
read-only and change the icon, except for the individual who has the
lock. But instead, the file is still writable and has the same icon as
a writeable file, unless the needs-lock property is set.
Try how I might, I just can't convince them to change this behavior, or
even to allow me to change it. Stefan is well-prepared to reject my
patch, if I try to submit one. (Plus I'm no good at writing patches,
which doesn't help me any.)
I would be happy if either -- Subversion can cache in the entries file,
the fact that some other user has locked a file. Or there is a way to
atomically set the lock and needs-lock property together. Either way,
when one user locks a file, the file will become read-only for other
users, and they will have an updated icon.
Well -- That is assuming the tortoisesvn guys are willing to make a file
read-only and change icon based on the presence of a remote lock in the
local entries cache.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 29 00:27:49 2006