Re: Symmetric Merge

On Mon, Mar 26, 2012 at 1:52 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Mark Phippard wrote:
>
>> I have been doing some simple playing around merging back and forth
>> between a simulated branch and trunk.  Overall, it seems to work
>> pretty nicely.
>
> Thanks for trying it and reporting back, Mark!
>
>> One thing I noticed (not sure if I would call this a problem but maybe
>> it is something you can improve).
>>
>> *  Merge a branch back to trunk and commit.
>>
>> *  Continue doing some work on both branch and trunk.  No merges.
>>
>> *  Merge the branch to trunk again.
>>
>> This second merge tries to merge some of the same changes from the
>> first merge.
>
> Sounds like a bug; it's supposed to avoid doing that.  Can you post the transcript?

I wasn't able to replicate anything like this, at least in the simple
cases involving no cherry picks, no subtree merges, and no subtree
mergeinfo. Without those restraints it is easy, see below.

>>  It all works really nicely if you do a merge from trunk
>> back to the branch before you do this.  But if you do repeated merges
>> from the branch back to trunk it seems to calculate the same base
>> revision and therefore tries to merge the same changes again.
>
> Did you see it printing out the same base revision(s) in its debug prints?
>
>> Another question. Your document talks about cherry picks, but I assume
>> it is always talking about them in the context of cherry picking an
>> entire revision from the root of a branch.
>
> Your assumption is correct: I use the phrase 'cherry-pick' only with reference to revision numbers, not sub-trees.  I'd like to stick to the phrase 'subtree merges' for when a subtree's mergeinfo differs (substantively) from its parent's.
>
>>  Does your changes support subtree merges at all?
>
> Yes it does.  Having determined the location of the base for the initial (root) merge, it then runs the same code that is run by a 1.7 'sync' or 'reintegrate' merge.  That code handles subtrees according to their own mergeinfo, in some manner.  So, the short answer is that I expect it to handle subtrees in the same way that 1.7 'sync' and 'reintegrate' merges do, with the only difference being that the high-level code chooses which of those two it runs regardless of whether you specify the '--reintegrate' flag.
>
> I'm still far from clear what the subtree-handling code does in theoretical/algebraic terms.  That's one thing I need to analyze, so I can state more definitely what I think it should do and what it does do, and your question prompts me to get on with that.
>
>>  I have not tried it yet, but I am assuming
>> this is a case where the sort of checks that reintegrate does would be
>> important to still have in the code.  I know we have talked about
>> disallowing subtree merges, but this is something we have seen to do
>> ourselves in our own tree a few times.  Considering how infrequently
>> we use branches, the fact that when we did, people have felt the need
>> to cherry pick some of those changes back to trunk before the branch
>> was done does not bode well for removing that as a feature in the
>> future.  Maybe your new code could just detect the reintegrate
>> scenario is happening and do the additional safety checks before
>> running the merge.  [...]
>
> I intend to support subtree merges.
>
> I'm unsure what you're saying here.  Maybe: "Given that the existing 'reintegrate' code can't (or isn't guaranteed to) handle switched subtrees, I need to ensure that when the automatic 'symmetric' merge code chooses the base-on-target-branch (that is, 'reintegrate-type') merge code path, then it performs the check for no switched subtrees, even if the user didn't specify the '--reintegrate' flag."  That may be so; I need to investigate.
>
> Or are you talking about disallowing some kinds of subtree mergeinfo scenarios?

I notice that symmetric merges completely ignore subtree mergeinfo, is
this a known limitation at this point in the development?

For example, starting with the basic Greek tree "trunk and branch"
setup we frequently use in the test suite (see
merge_tests.py:set_up_branch):

### We start with no previous merges:
> svn up -q

>svn pl -vR

### Cherry pick a change to a subtree of the 'A_COPY' branch a.k.a. a
subtree merge that creates subtree mergeinfo. FWIW we could do a sync
merge here (symmetric or not) and the problem I am describing still
stands.
>svn merge ^^/A/D/H A_COPY/D/H -c3
--- Merging r3 into 'A_COPY\D\H':
U A_COPY\D\H\psi
--- Recording mergeinfo for merge of r3 into 'A_COPY\D\H':
 U A_COPY\D\H

### Note the subtree mergeinfo before we commit, nothing unusual:
C:\SVN\src-trunk-3\Debug\subversion\tests\cmdline\svn-test-work\working_copies\merge_tests-128>svn
pl -vR
Properties on 'A_COPY\D\H':
  svn:mergeinfo
    /A/D/H:3

>svn ci -m "Subtree merge"
Sending A_COPY\D\H
Sending A_COPY\D\H\psi
Transmitting file data .
Committed revision 7.

### Make an edit to the branch file that was modified by the subtree
cherry pick of r3:
>echo branch edit> A_COPY\D\H\psi

>svn ci -m "branch edit"
Sending A_COPY\D\H\psi
Transmitting file data .
Committed revision 8.

### Considering the subtree mergeinfo (hence the -R) what revs are
eligible for syncing from A to A_COPY?
>svn mergeinfo --show-revs=eligible -R ^^/A A_COPY
r4
r5
r6

### Note that r4-6 *don't* touch psi:
>svn diff --summarize A -r3:6
M A\B\E\beta
M A\D\G\rho
M A\D\H\omega

### Now sync merge, with the --symmetric option. The subtree
mergeinfo on A_COPY/D/H is ignored and r3 is merged again, causing a
spurious conflict:
>svn up -q

>svn merge ^^/A A_COPY --symmetric
DBG: merge.c:11188: base on source:
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_1
DBG: merge.c:11190: base on target:
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_1
DBG: merge.c:11303: yca
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_1
DBG: merge.c:11304: base
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_1
DBG: merge.c:11306: mid
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_8
DBG: merge.c:11307: right
file:///C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-128/A_at_8
--- Merging differences between repository URLs into 'A_COPY':
U A_COPY\B\E\beta
U A_COPY\D\G\rho
U A_COPY\D\H\omega
Conflict discovered in
'C:/SVN/src-trunk-3/Debug/subversion/tests/cmdline/svn-test-work/working_copies/merge_tests-128/A_COPY/D/H/psi'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: p
C A_COPY\D\H\psi
--- Recording mergeinfo for merge between repository URLs into 'A_COPY':
 U A_COPY
 U A_COPY\D\H
Summary of conflicts:
  Text conflicts: 1

### Also, the mergeinfo on A_COPY/D/H should elide to A_COPY, buy doesn't:
>svn pl -vR
Properties on 'A_COPY':
  svn:mergeinfo
    /A:2-8
Properties on 'A_COPY\D\H':
  svn:mergeinfo
    /A/D/H:2-8

### What I'd expect to see is something like this:
>svn revert -R .
Reverted 'A_COPY'
Reverted 'A_COPY\B\E\beta'
Reverted 'A_COPY\D\G\rho'
Reverted 'A_COPY\D\H'
Reverted 'A_COPY\D\H\psi'
Reverted 'A_COPY\D\H\omega'

### r3 isn't merged again:
>svn merge ^^/A A_COPY
--- Merging r4 through r8 into 'A_COPY\D\H':
U A_COPY\D\H\omega
--- Merging r3 through r8 into 'A_COPY':
U A_COPY\D\G\rho
U A_COPY\B\E\beta
--- Recording mergeinfo for merge of r2 through r8 into 'A_COPY':
 U A_COPY
--- Recording mergeinfo for merge of r2 through r8 into 'A_COPY\D\H':
 U A_COPY\D\H
--- Eliding mergeinfo from 'A_COPY\D\H':
 U A_COPY\D\H

>svn st
 M A_COPY
M A_COPY\B\E\beta
M A_COPY\D\G\rho
 M A_COPY\D\H
M A_COPY\D\H\omega

### The subtree mergeinfo elides:
>svn pl -vR
Properties on 'A_COPY':
  svn:mergeinfo
    /A:2-8
Received on 2012-03-28 22:45:04 CEST