On Thu, Feb 21, 2013 at 11:54 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Mark Phippard wrote:
>
>> On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann
>> <stefan.fuhrmann_at_wandisco.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.
>>>
>>>
>>> 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.
>>
>> 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?
>
> That graph is wrong or at least misleading. There have been catch-up merges, for example this one:
> I don't yet know what's going wrong, but likely something to do with subtree mergeinfo is causing the mergeinfo
> graph to think that was not a complete merge.
I assumed the mergeinfo graph was wrong, because I recalled him doing
those sort of commits. What I was getting at, was if the merge graph
is wrong, then maybe merge itself is having the same issue and not
trying to do a reintegrate merge.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-02-21 19:05:24 CET