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:
svn log -r1445479
------------------------------------------------------------------------
r1445479 | stefan2 | 2013-02-13 01:37:54 -0500 (Wed, 13 Feb 2013) | 2 lines
On the fsfs-format7: ketchup merge from /trunk up to and including r1445080.
No conflicts to revolve.
------------------------------------------------------------------------
$ svn diff --depth=empty -c1445479 ^/subversion/branches/fsfs-format7
Index: .
===================================================================
--- . (revision 1445478)
+++ . (revision 1445479)
Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
Merged /subversion/trunk:r1442090-1445080
(and lots of other changes were made in that revision, too, as expected).
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.
- Julian
Received on 2013-02-21 17:54:45 CET