Branko ÄŒibej <brane@xbc.nu> writes:
> If we implemented this proposal now, we'd just have to rip it out
> later. Right now, our repeated-merge problem is no worse than CVS's,
> and is a bit better in places -- the possible exception is our use of
> diff3 instead of an (the?) integrated diff library. It think that is
> sufficient for 1.0.
Agree in general, but we should also keep an open mind about an
incremental solution here. For example, an initial implementation of
merge history preservation might record the stated
revision-range/paths of the merge (i.e., the ones given by the user),
and not know anything about the diff-hunk level. This gives us a very
close approximation of the true merge history, modulo any local mods
made to the merge before the commit.
I guess what I'm saying is: I don't think we're going to solve this
whole problem at once. But if we're careful, we can make sure that
each step we take contributes to the steps we take later.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 17:53:33 2002