On Wed, Feb 27, 2013 at 5:04 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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.
Hi Julian,
What are we going to warn them to do exactly? To explicitly use
--reintegrate option? Because that would work in Stefan's case, so we
should just do it rather than warn...unless you mean something else.
I filed an issue for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4329 and added a
test which demonstrates a very simple version of the problem. I set
issue #4329 a 1.8 blocker. While I think what Stefan is doing is
somewhat atypical[1], if we are deprecating --reintegrate, then
automatic merges should handle cases like this. After all, if we
explicitly use the --reintegrate option the merge works fine. What do
others think?
[1] Doing *cherrypick* merges to effectively keep a branch in sync
with trunk and then using an *automatic* merge to "reintegrate" the
branch back to trunk.
> It really doesn't make sense to proceed with the merging in a case like this.
>
> - Julian
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Received on 2013-03-04 23:22:04 CET