[Svnmerge] [PATCH] Eliminate spurious svnmerge-integrated property conflicts

[Raman Gupta]

Auke Jilderda wrote:
> On Wednesday 14 February 2007 09:56, Raman Gupta wrote:
>> What do you mean exactly by "across more than two branches"?
> 
> I mean the way as in the use case  as I described in a recent post [1]: When 
> you copy a change set from branch A to B and then from B to C, the latter 
> copy will generate a conflict on the property used for merge tracking. This 
> is because svnmerge.py uses the same key for that versioned property on every 
> branch.

For this use case, my patch should resolve the issue you are having
with property conflicts, without any loss of information:

http://article.gmane.org/gmane.comp.version-control.subversion.svnmerge.devel/309/match=svnmerge+spurious

(The post doesn't seem to be in the orcaware archives for some reason).

>> Option d) should really be implemented in addition to the existing
>> option a) and this could maybe somewhat support transitive merging (at
>> least better than currently). I don't even think it would be that
>> complicated to merge the property manually with a little bit of
>> python-fu i.e. svnmerge.py would use the information on both branches
>> to explicitly set the property after the merge, whilst ignoring any
>> merges/conflicts produced by svn's merge algorithm by reverting the
>> property merge.
> 
> Yes, that would solve the issue.

My patch is a MUCH simpler solution that I'm pretty sure also resolves
your issue. See below for my description of the use case for which we
would need to implement the above option.

>> Though I'd still like to see a good use case for transitive merging --
>> I looked through the PDF you sent and I don't think the scenario it
>> describes is a transitive merging use case -- in fact I think its
>> pretty vanilla uni-directional merging from older branches to newer
>> branches. Your summary was this:
>>>     Summarising, this is a strictly linear merging model of forward
>>>     propagating fixes.  The transitive merge information is needed to be
>>>     able to verify that fixes have been propagated to all subsequent
>>>     releases.
> 
> Um, how do you define "transitive merging"?

I think I see the confusion. My definition of transitive merging
supports this use case:

- There exists branch A, B, and C, and functionality F1, F2, F3
- A merge of F1 and F2 occurs from branch A to B
- A merge of F1 and F2 occurs from branch A to C
- A merge of F1, F2, and F3 occurs from branch B to C
    - F1 and F2 are ignored, and F3 is merged

I think you are defining transitive merging this way:

- There exists branch A, B, and C, and functionality F1, F2
- A merge of F1 and F2 occurs from A to B
- A merge of F1 and F2 occurs from B to C

To me, the above is certainly "transitive", but it reduces to simple
uni-directional merging for each branch pair -- branch C does not have
to be aware of the existence of branch A in any way. The patch I
submitted should allow the above case without any property conflicts,
and without losing any information relating to each branch pair. It
will NOT, however, allow the situation I defined as transitive merging
without further work to implement what you described as option d).

Does that clear things up?

> To be able to use svnmerge.py, we need to be able to merge from A to B, from B 
> to C, and so on.  Transitive merge information would be nice to have but not 
> essential.
> 
>> I would set up a script that executes svnmerge.py avail on each branch
>> going forward in time with the prior older branch as the -S (source)
>> argument, and aggregates the result into some sort of consolidated
>> report of available revisions to be forward propagated. This would
>> give you your verification in one command, without any transitive
>> support in svnmerge.py.
>>
>> Since svnmerge.py also supports bidirectional merging, you could even
>> support both forward and backwards propagating fixes simultaneously.
>>
>> However, transitive support might be useful in your scenario if you
>> wanted to support the occasional "skipping" of a branch with later
>> application of that skipped revision. In this case, it would be needed
>> so that when the skipped revision was applied later, svnmerge.py would
>> understand that it had already been merged into the next branch
>> forward in time.
>>
>> If you just want to merge across multiple branches without the
>> transitive information, svnmerge.py does this already. If my patch is
>> applied (the one that kicked off this round of discussion about
>> transitive merging), then it will even do so without conflicts in the
>> svnmerge-integrated property.
> 
> Ah ok, I got slightly lost in the technical details earlier in this thread: to 
> the best of my understanding, your patch would avoid the conflict on the 
> versioned property but flushes transitive merge information.  But does this 
> mean that the value it is set to is still correct?  (That is, need not be 
> transitive but at least define exactly what revisions from what branch have 
> been merged on this branch.)

Yes correct. The value it keeps will be correct. The "transitive"
information that is flushed will be unrelated to the branch pair being
merged. It is kind of bogus information in my opinion, since in the
A,B,C case above, branch C was never initialized for merging with A,
and so therefore any merge information from A to C doesn't really mean
anything (without proper implementation of Option d).

My patch, in the course of eliminating the property conflict, does
remove the merge information from C on A. However, in your use case,
it is enough to know which revs from B have been merged into C
(regardless of whether they originally came from A or not), and my
patch does not remove that.

> Also, has the patch been accepted into svnmerge.py or is there a place where I 
> can get svnmerge.py with your patch to take this out for a spin?

No it has not yet been accepted. This thread is the discussion thread
for the patch, which started last October :-)  You can get the patch
from the URL above.

Cheers,
Raman