how do I continue a merge after resolving conflicts?

[Jamie Wilkinson]

This one time, at band camp, Martin Pool wrote:
>On 18 Nov 2005, Jamie Wilkinson <jaq at spacepants.org> wrote:
>> This one time, at band camp, Martin Pool wrote:
>> >For those following along at home: bzr merge always merges all files,
>> >leaving conflicts in those where they occur.  There's no need to do
>> >another merge from the same source after you resolve the conflicts --
>> >just fix them up and commit.
>> 
>> So, bzr aggregates all the changesets coming in the merge, and applies it
>> once?
>
>The merge isn't really done by applying the changesets one at a time.  A
>better way to think of it is that it merges the two trees taking their
>history into account.
>
>> Or is it possible that two incoming changesets can conflict with a
>> local changeset, and make a mess of the << == >> ?
>
>I don't understand the question, can you expand?

Well, I think you answered it :)

I was trying to differentiate the case where merge iterates over the
changesets being merged, applying them one at a time, versus aggregating all
the changesets into one, and then applying that aggregate once.

I think now, the latter takes place.  I was concerned in the case of the
former, it might be possible to construct a conflict such that after the
first merge, the <<< === >>> markers are placed in the file, and then a
second changeset could also conflict with that part of the file, potentially
making a big mess.

Thanks for the clarification.