On Sat, 2005-06-25 at 08:39 -0500, Ben Collins-Sussman wrote:
> Aha, well I did add a footnote to the document right after the IRC
> conversation, take a look.
Ah, sorry I didn't read carefully enough.
> The algorithm above suggests that because the two starting values
> (A and C) are unequal, we should flag a conflict. But our current
> diff3 algorithm on lines-of-text may actually not care about the
> target base; it might produce a smooth merge because the *results*
> are the same.
One possible justification for this behavior is that the text-base of
the working copy can be seen as an arbitrary intermediate point in time.
It's not necessarily the repository head revision, even; it's just what
you happened to have checked out. (Although you'll get an out-of-date
error on checkin if it's not the head, I suppose.)
Even if we were going to make Subversion do four-way text merges using
variance-adjusted patching, I'm not sure that the working copy text base
would be part of any merges. I think the fourth point would come from
merge-tracking information.
As long as we're talking about this aspect of merging, people should be
aware at some level of Bram Cohen's work described in
http://lists.zooko.com/pipermail/revctrl/ (it's a low-traffic list; look
for stuff about the new Codeville merge algorithm starting in May).
He's working on a merge algorithm which doesn't assume anything about
common ancestors, because one of the goals is to address the
"criss-cross merge" corner case described at
http://www.gelato.unsw.edu.au/archives/git/0504/2279.html . The
criss-crose merge case is apparently pretty common with cooperative
distributed development; the reason it doesn't come up so much in
Subversion and CVS is that you have to do a local merge with the head
before commit, and the repository doesn't bother to store what you had
before that merge. Bram is also providing "implicit rollback", meaning
that you don't have to tell the revision control system that you're
rejecting or rolling back a patch in order to make the merge algorithm
do the right thing. This seems to conflict with another desirable
property called "patch convergence", though. I'm also not sure whether
Bram's algorithm requires different inputs to the merge than Subversion
can provide, and whether it can be implemented with the required
performance characteristics.
darcs has also put substantial work into the text merge problem, as I
understand it. And then there's this variance-adjusted patching which
Sander put into libsvn_diff but which we don't use yet; perhaps that is
another way to address the criss-cross merge case. Merging makes my
head hurt, so I'm not sure how all these pieces fit together.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 25 16:26:42 2005