Bzr merge problem

[Trent Johnson]

Max, Eli, thanks for your help!

Max, your solution worked. Now I have to do a bit of reading to find out why :)

Trent

-----Original Message-----
From: Max Bowsher [mailto:maxb at f2s.com] 
Sent: December 17, 2010 11:46 AM
To: Eli Zaretskii
Cc: Trent Johnson; bazaar at lists.canonical.com
Subject: Re: Bzr merge problem

On 17/12/10 15:36, Eli Zaretskii wrote:
>> From: Trent Johnson <Trent.Johnson at jasco.com>
>> Date: Thu, 16 Dec 2010 14:24:12 -0800
>>
>> About a week ago a developer decided to merge his (incomplete) work into trunk, first he merged trunk with his branch (bug678) to get it up-to-date (trunk revision 273). Then the developer merged his feature branch with trunk (to create trunk revision 274).
>>
>> As the product manager, after a review of the work, I decided to revert the trunk back to the previous revision (revision 273) to get revision 275.
>>
>> I used:
>> bzr revert -r273
>>
>> The developer continued working on his feature branch, trunk received commits from other developers (now up to revision 279).
>>
>> The developer is now truly ready to merge and commit his feature branch with trunk.
>> He performed a merge with trunk from within his feature branch:
>> bzr merge ../trunk
>>
>> And received tuns of changes and conflicts. Many more than the simply changes that occurred between his previous merge of trunk and the HEAD of trunk.
>>
>> How should he merge trunk back into his feature branch before merging his changes with trunk?

Hi Eli,

> I think he should first revert to the version before the second merge
> from the trunk, and then merge his branch into the trunk.

This will not have the intended effect. Trunk has already had the early
part of the branch reverted. A simple merge into trunk at this point
will try to apply the second part of the development without the first,
resulting in much the same mess of conflicts.

Max.