[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Implicit keep-alive after reintegrate merge

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 18 Jan 2012 22:37:39 +0000 (GMT)

Branko Čibej wrote:

> On 18.01.2012 14:45, Julian Foad wrote:
>>> A_at_1---r4---r5---r6---r7----------------r11----------->
>>>   |\                                    ^          |
>>>   | \                                   |          |
>>>   |  \                              reintegrate    |
>>>   |  V                                  |          |
>>>   |  A_COPY_2-----------------r9---r10---          |
>>>   |                            ^                sync merge
>>>   |                          /                     |
>>>   |                  cherry-pick merge of r8       |
>>>   V                        /                       V
>>>   A_COPY-------------------r8------------------------->
>>
>> Thanks for this good example of a more complex use case.  I've included
>> it in <http://wiki.apache.org/subversion/KeepingReintegratedBranchAlive>
>> and written up a discussion of the options there.
>>
>> What do we want in this case?  The options are basically:

(To be sure we're talking about the same thing, here I'm talking about how Subversion decides whether to merge the change "r11" from A onto A_COPY.)

>>   (1) try to merge (as we do now), despite knowing it will conflict;
>
> Actually, you know that it will not conflict, unless r9 or r10
> introduced changes in the same place as r8. Otherwise the code is the
> same and diff3 should skip that part, yes?

No; I mean in general it will conflict.  Yes there are certain simple changes that the three-way text merge function will detect as "looks like that change has already been made here" and auto-resolve it as a no-op, but that's beside the point.

[sorry, can't reply to the rest just now]

- Julian
Received on 2012-01-18 23:38:18 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.