[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: Michael Brouwer <michael_at_tlaloc.net>
Date: 2004-10-14 17:17:01 CEST

Of course that particular problem would be better solved by a better
diff3 type algorithm that can deal with indentation changes rather than
file locking. After all locking doesn't solve the problem of wanting
to merge branches or even patches applied in the past.

something like svn merge --ignore-indentation-changes would be a better
way to go here.


On Oct 14, 2004, at 1:46 AM, Simon Large wrote:

> "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

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