RE: Understanding Reflective/Cyclic Merges

Nice summary Mark!.

>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.

No the current code does not merge all the revisions, rather it does a faulty negation on the requested range.
i.e
WC_OF_MERGEINFOLESS_COPIES$svn merge -r10:19 ^/trunk
WC_OF_MERGEINFOLESS_COPIES$svn ci -m 'log' #results in r20
WC_OF_TRUNK$svn merge -r10:20 ^/branches/mergeinfoless-copies Here it does a merge of r20 alone from mergeinfo-less-copies, leaving out the potential *mergeinfoless-copies only* changes and remerging the trunk to itself via r20.
 

>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?

No it is not smart here. Assuming it is the first merge, it can potentially repeat merges the trunk changes to mergeinfoless-copies branch. issue 2897 does not take care of it. *Probably we need to do diff-summarize equivalent on the merge source to see if at all the source is a result of some merge by looking for 'svn:mergeinfo' changes and drive our merge accordingly.*.

>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?

Fix to 2897 would 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.

I am not able to understand this.

With regards
Kamesh Jayachandran
Received on Fri Nov 16 20:29:25 2007