Understanding Reflective/Cyclic Merges

I am posting this for my own benefit, but also for the benefit of
anyone else that might not understand what is going on when they see
references to these terms.

Let's start with a simple real world example.

CMike has created a branch called "mergeinfoless-copies" that he has
been working on for a while. If you look at the history he has done
more than a dozen commits to this branch and three times has synched
the branch up with trunk.

Let's fast forward to when he is done and wants to merge to trunk. If
he wanted to use merge tracking he would have a WC from trunk and just
run:

svn merge ^/branches/mergeinfoless-copies

Merge tracking should be able to merge the changes that happened on
the branch and filter out the revisions that were merges from trunk to
the branch. This is what Kamesh and Karl have been working on in
Issue #2897. I think the current code tries to merge all the
revisions from the branch which is not correct.

Now, let me take a brief pause to say that there is a problem here
that is currently not fixable. Our merge algorithm is based on
including or excluding entire revisions. So while it would be an
improvement to filter out those merges from trunk that CMike made,
that also means that we will be filtering out the conflict resolution
work that he did as part of synching his branch with trunk. So that
work will have to be repeated when he merges back to trunk. See this
thread as a reference, particularly the post from DannyB.
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=587141
 It appears this problem cannot be solved for 1.5, or likely not even
without a new repository design. It is worth pointing out that there
is another way to do this merge that does not have these problems:

svn merge ^/trunk@LAST-SYNCED-REV ^/branches/mergeinfoless-copies

That is how merges would b done in 1.4 and still works fine for 1.5.
It just is not using merge tracking to do the merge.

OK, let's go back to this problem and this specific example as I have
some questions on alternate scenarios.

CMike has the branch described above, but Glasser has started a
somewhat related branch named sqlite-node-origins. Presumably over
the life of this branch he will be synching it with trunk. Let's
assume that instead of merging his branch back to trunk, he and CMike
decide to merge his changes into CMike's branch so that they can
stabilize the changes together and see how they interact. So from a
WC of the mergeinfoless-copies branch, one of them runs this command:

svn merge ^/branches/sqlite-node-origins

Question: will merge tracking be smart enough to skip the revisions
that were merges from trunk to the sqlite-node-origins branch? Maybe
it just skips any merges to this branch that came from the copy-source
of the mergeinfoless-copies branch?

Moving on, they finish this branch together and now want to merge this
combined branch to trunk. They would run this command from a trunk
WC:

svn merge ^/branches/mergeinfoless-copies

Question: can merge tracking be smart enough to skip the revisions
that were merges from trunk to the mergeinfoless-copies branch but be
smart enough to not skip the revision that was a merge from the
sqlite-node-origins branch?

This seems like a hard problem, but I think if we are always filtering
out revisions that were the result of merges from the copy-source of
the target, then it is always the same algorithm and would work and
hold up. I am not sure if this is what Kamesh and Karl are doing or
not.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org