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

RE: "svn diff" and "svn merge" sittin' in a tree

From: Billy Tanksley <btanksley_at_hifn.com>
Date: 2002-02-15 22:12:35 CET

From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>Yes, completely agree. Really perfect merging is much more
>sophisticated than either diff+patch or diff3, and is non-trivial to

>From what I've seen so far, I'd have to agree with this. I do wonder,
though, what the Synerga guys at IBM are going to come up with -- they claim
to have exhaustively analysed the problem. I wonder if a general 'merge'
tool will be among the results of their efforts (or if it's even possible).

>Giving clients plug-in options is part of it (we'll have
>to supply that fourth file -- the true common ancestor -- for them,

Ignorance warning: the following statement is an expression of ignorance,
not of knowledge.

If we're going to have more than three files, then I can't see any upper
bound. If we're going to provide an upper bound, I don't see any way to
choose any number other than three. Three certainly seems like a good lower
bound (with "empty file" serving as one of the files when we just want a
diff), but I suppose I see your point about partial merges.

It just seems to me that if someone's done a partial merge, they still did a
merge (discarding data), and as a result if you want the rest of the data
back you'll *have* to merge (3-way) more than once. Taking more than 3
files as input *seems* equivalent to doing a sequence of 3-way merges, and I
don't see how it could be generally handled automatically.

>I don't think we're aiming for perfect merging right now. We just
>need to be as good as CVS, and that means diff3 with three files, no
>one of which is necessarily a common ancestor.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006

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.