[Svnmerge] Patch for non-reflected bidirectional merging support

[Raman Gupta]

Archie Cobbs wrote:
> Raman Gupta wrote:
> 
>> Jim Fulton wrote:
>>
>>> Raman Gupta wrote:
>>>
>>>> Jim Fulton wrote:
>>>>
>>>>> Raman Gupta wrote:
> 
> Great discussion! I'm glad to have some help figuring this out :-)

Thanks :-)

> Let me throw out a completely different idea, just to add more
> confusion...
> 
> Suppose before each merge, we do something like this:
> 
>   svn log --xml . \
>    | grep revision= \
>    | sed s/^.*revision="\([[:digit:]]*\)".*$/\1/g'
> 
> Here "." is the branch (i.e., target) directory for the merged changes.
> This just tells us which revisions actually changed the target branch,
> as opposed to revisions which made changes outside of the target branch.
> 
> Then, we simply omit these changes from whatever revisions we're going to
> merge in. Voila, "reflected" changes are never merged in.

Hmm, I'm not sure I understand this. Excluding revisions from the target
is meaningless because svn merge automatically excludes those. Its the
merge-points on the source that need to be excluded. Or have I
misunderstood your intent?

Just so that we are working with an example, lets say we have the simple
scenario (and testrepo.zip) I gave in:

http://www.orcaware.com/pipermail/svnmerge/2005-August/000000.html

So you don't have to reproduce it, here is a complete log up to just
before the point of the merge from the trunk to the branch that will
produce a reflected spurious conflict:

------------------------------------------------------------------------
r7 | raman | 2005-08-26 14:35:33 -0400 (Fri, 26 Aug 2005) | 1 line

Change B on trunk applied to Change A on branch
------------------------------------------------------------------------
r6 | raman | 2005-08-26 14:34:50 -0400 (Fri, 26 Aug 2005) | 3 lines

Merged revisions 3-5 via svnmerge from
/branch

------------------------------------------------------------------------
r5 | raman | 2005-08-21 02:02:02 -0400 (Sun, 21 Aug 2005) | 1 line

Change A on branch
------------------------------------------------------------------------
r4 | raman | 2005-08-20 13:58:17 -0400 (Sat, 20 Aug 2005) | 3 lines

Initialized merge tracking via svnmerge with revisions 1 from
file:///home/raman/testrepo/trunk

------------------------------------------------------------------------
r3 | raman | 2005-08-20 13:57:26 -0400 (Sat, 20 Aug 2005) | 3 lines

Initialized merge tracking via svnmerge with revisions 1-2 from
file:///home/raman/testrepo/branch

------------------------------------------------------------------------
r2 | raman | 2005-08-20 13:43:01 -0400 (Sat, 20 Aug 2005) | 1 line

Create branch
------------------------------------------------------------------------
r1 | raman | 2005-08-20 13:41:20 -0400 (Sat, 20 Aug 2005) | 1 line

Initial import
------------------------------------------------------------------------

The next thing I want to do is to merge to the branch from the trunk.
Here is some relevant info (using the original svnmerge, not my patched
version):

[raman testsrc]$ svnmerge avail -S $REPO/trunk branch
2-7

[raman testsrc]$ svn log --xml branch | grep revision= \
| sed 's/^.*revision="\([[:digit:]]*\)".*$/\1/g'
5
4
2
1

Revision 6 is the commit on the trunk that contains the merges from the
branch that we do not want to reflect back.

The available revisions are 2-7. The revisions on the target ("branch"
in my example) from the above command, are 1, 2, 4, and 5. If I
understand correctly, then you would exclude those and merge in
revisions 3 and 6-7. What am I missing? Revision 6, from the trunk, is
still going to cause a spurious conflict...

To simulate it manually, we can exclude rev 3 (just init merge tracking):

[raman testsrc]$ svn merge -r 5:7 trunk branch
C    branch/foo
 U   branch

> Now this would work great, except in the pathological case where someone
> made a change to TWO branches at the same time, then tried to merge
> the change from one to the other. However, we can always add an obscure
> flag  "--include-reflected-changes" for those situations.

Isn't this just a normal (and valid) conflict case?

Cheers,
Raman