Edward Harvey <eharvey <at> chilsemi.com> writes:
>
> > > 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.
No. Please don't misrepresent what we have been saying to you. You told us that
you want to use locking as a way of communicating to other developers that you
require sole access to a file, and to prevent them working on it. We recommended
you to use the svn:needs-lock property because it was designed for that purpose.
You told us that you wanted to use it as a means of avoiding merges because you
distrust automatic merging. If you lock a file without svn:needs-lock, you avoid
merging other peoples changes, but they still have to merge yours when they
update. The only way to avoid merging completely is to use the
lock-modify-unlock model version control model, which in Subversion means using
svn:needs-lock in conjunction with locking.
> 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.
That's not TortoiseSVN behaviour, it's Subversion behaviour.
> 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.)
You asked us to cache the remote locks, which we can't do because it's not
supported in Subversion. You asked us to add an option to query the repository
for remote locks automatically every N minutes, which we won't do because a) it
doesn't fit with the disconnected client model that we use, b) the information
displayed would be stale (and therefore misleading) if the interval is long, or
would cripple the server if the interval is short.
> 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.
If that information were cached, we might consider showing it on the icons
(subject to Windows limited number of icon overlays). But it isn't, so we can't.
Please don't try to paint us as being uncooperative in this respect.
--
Simon
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 3 00:40:28 2006