On Wed, 25 Nov 2009 18:15:51 +0000, Mark Phippard wrote:
...
> The problem here is not with merge tracking. It does record
> everything that is needed. Merge tracking was implemented on top of
> Subversion's existing merge algorithms and that is where the
> deficiency lies, or really even in the repository itself. To do a
> proper bi-directional merge Subversion would have to know what part of
> a commit was from a merge and what part was from conflict resolution.
No, you don't. When you do a backmerge, you just need to do a
diff3 --merge with the heads of trunk and branch as leaves,
and the revision the last merge between branch and trunk
originated from. Like:
--A--B--C--D--E--F (trunk)
\ \
J--K--L--M--N (branch)
When you now go to merge trunk and branch you take F and N
as the leaves, and C as the base. Note that this is completely
symmetric: The files resulting from the merge do not depend
on whether they are going on the trunk or the branch.
Possibly the problem with svn is that it insists in the backmerge
case to merge a set of revisions from the branch, and does not
see the possibility that C--N is the proper diff to put on F.
That is what I meant with merge info being ancestry information;
the C-L link is just as important as the A-J link.
(There are cases with more than two branches where a single
diff3 merge does not suffice, but we are not that far yet.)
> The latter needs to be merged back on the bi-directional merge.
No, you also need to merge back what was done in J and K. But that
is, including the necessary conflict resolution, exactly the diff
between C and L.
...
> That said, what is the big deal with specifying --reintegrate?
It just as stupid as to require to specify a revision range...
> It
> turns out Subversion did have a merge algorithm that does work
> properly and specifying --reintegrate just lets it know to apply it.
...and needing to specify --reintegrate nowadays is the definition of
'does not work properly'. There are others out there that just do it.
...
> Obviously if we started from scratch and optimized for merge this
> could be better, but it would suck for the users that had to spend
> weeks converting their repositories and upgrading all their tools etc.
But new users really like to have working merges. We specifically waited
for 1.5 before switching from cvsnt and had a big WTF moment as we
stumbled over --reintegrate.
Andreas
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424500
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-26 07:28:35 CET