Paul Burba wrote:
> On Mon, Feb 18, 2013 at 11:54 AM, Mark Phippard <markphip_at_gmail.com>
> wrote:
>
>> BTW, how are you managing your branch? I tried merging it back to
>> trunk to get an idea on the diff and there were a lot of text and tree
>> conflicts. I thought I had seen you doing synch merges from trunk in
>> the past so I assumed it would merge back.
>
> On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com> wrote:
>
>> Hm. I split fsfs.c and .h into multiple files on the
>> branch and the first merge from /trunk required
>> significant manual intervention. Since that, merges
>> have been clean because fsfs.* wasn't touched
>> on /trunk.
>>
>> If I understand Julian's merge changes in 1.8,
>> reintegrating should work because there has been
>> no cherry picking etc.
>
> On Thu, Feb 21, 2013 at 11:04 AM, Mark Phippard <markphip_at_gmail.com>
> wrote:
>
>> I see this when using 1.8:
>>
>> $ svn mergeinfo ^/subversion/branches/fsfs-format7
>> youngest common ancestor
>> | last full merge
>> | | tip of branch
>> | | | repository path
>>
>> 1414755 1448697
>> | |
>> --| |------------ subversion/branches/fsfs-format7
>> /
>> /
>> -------| |------------ subversion/trunk
>> |
>> 1447423
>>
>> It seems to imply that it does not think you have ever synched with
>> trunk. So maybe it is trying to replay every revision from your
>> branch when I merge back and that is why it gets so many conflicts?
>
> I found the cause of the conflict filled reintegrate merge. The
> automatic merge code seems to be doing the right thing re Mark's
> automatic merge above, the problem arises earlier.
Paul, thanks for investigating. While I'm glad to hear the automatic merge was not the main root cause of the problem, it would make sense for it to detect that merges in the opposite direction have been done and at least warn the user. It really doesn't make sense to proceed with the merging in a case like this.
- Julian
Received on 2013-02-27 23:05:32 CET