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
>implement.
>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,
>too!)
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.
>-K
-Billy
---------------------------------------------------------------------
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