[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking UI comments

From: Frank Compagner <frank_at_compagner.com>
Date: 2004-10-13 17:36:20 CEST

Justin Erenkrantz wrote:

> On Wed, Oct 13, 2004 at 10:06:27AM +0100, Ben Sewell wrote:
>>Just to add a potential comment from the Windows crowd; not preserving
>>extensions breaks the windows auto-launching behaviour for documents. In my
>>situation, locked files are liable to be MS Excel files, for example; if a
>>non-techie attempts a check-in, and it fails, and none of the remaining
> Subversion already renames the extension when there is a merge conflict to
> '.mine', '.rXXXX', and '.rYYYY' I view the case of a lock race (?) to be
> essentially the same as a merge conflict from a user's perspective. -- justin

Consisteny is alway nice, but there are definitely differences between a
lock conflict and a merge conflict. Assuming that subversion will never
attempt to merge a file with the svn:lock property, the current file
version in the WC has to be either the local copy or the newly received
server version.

If we further assume that the svn client makes sure that all svn:lock
files are read-only by default, and only become temporarily read-write
when a lock has been acquired, lock conflicts are only possible when the
user actively tries to work around it. I would therefore very much
prefer the default behaviour to be to replace the WC version of the file
with the the server version, while renaming the old (changed) local copy
to .mine. This means that the .rNEWREV copy is no longer necessary.
Also, the value of having the .rOLDREV is very questionable for
unmergeable files, and might be costly (network trafic and/or binary
diffs, I'm not sure how this is/would be implmented), especially as
these unmergeable files will often be rather large (compared to plain
text files). That would leave only the .mine version.

Finally, I agree that renaming the file by tagging on an extra extension
is an unfortunate decision, as it messes up windows file associations.
This isn't a problem for programmers, but when locking is implemented,
svn becomes attractive to a much broader group of users which are
guaranteed to be confused by this. I would very much like to get all our
managers and artists and such to use a lock-enabled subversion, but some
of them "wouldn't be able to recognize a file-extension if it painted
itself purple, stood on top of a harpsicord, singing 'file-extensions
are here again'". So I would definitely prefer something like
mine.filename.ext, or possibly filename.mine.ext.

Frank Compagner

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 22:41:11 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.