"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
lock
> 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
usual.
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.
Simon
---------------------------------------------------------------------
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