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

Re: Locking functional spec: read-only WC

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2004-10-14 10:46:21 CEST

"Ben Collins-Sussman" wrote
> It's not important that locking communication be "good" in the case of
> mergeable files. Why? Because the file is mergable. Suppose you
> foo.c and I'm unaware of this. Then I edit foo.c and my commit fails.
> My work isn't 'wasted'. I run 'svn up', merge things, then eventually
> commit after you release the lock.

Please excuse my butting in on this thread, but I would like to point
out that text files which are normally mergeable can sometimes be
modified in hard-to-merge ways. I can give you a case in point from a
couple of days ago:

The TSVN documentation is in XML and normally changes can be merged
efficiently and easily. However, over a period of time the indentation
had become completely messed up, and some of the text required
re-wrapping to fit a sensible width.

This makes changes to a large number of lines in the file, and it also
means that any changes by someone else in the same area (and this did
happen) generate huge numbers of conflicts which can only be merged by
careful hand editing. It's still mergeable, it's just *much* harder than

Of course, locking the file when locking is normally not required does
not solve the problem. No-one else has read-only copies, so they could
have started editing before I acquired the lock. Or, after the lock is
released, they might start editing an older version of the file without
updating. Good old-fashioned talking works better here ("don't edit this
file yet, and update after I commit my changes").

Sorry, no solutions, only problems. Just pointing out that mergeable
files ain't necessarily so.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 11:08:01 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.