Conflict resolution workflow (was Re: Recipes vs. Looms vs. pipelines)

Barry Warsaw barry at canonical.com
Thu Dec 17 16:53:25 GMT 2009


BTW, this thread reminds me of a workflow wart that I'd like to get some advice on.

Let's say I have a branch or loom or whatever, and I merge in all updates on the trunk that have happened since I started my branch.  I get conflicts.  I have to resolve these conflicts, but doing so may entail not insignificant amount of work.  I'm sitting in a branch with lots of uncommitted changes due to the merge.  I can't commit that until I've resolved the conflicts, but once I do, I have no way to know what part of that work came from the trunk merge and what part of the work came from my resolution of the conflicts.

I would like to split this task into two parts.  I want a revision that is the results of the merge of trunk, and a separate revision that includes just my changes to resolve the conflict.  With that it would be much easier to identify, diff, review, and modify just the changes I had to make to resolve the conflict.  It's entirely possible that I didn't resolve the conflict correctly the first time.

Does bzr have tools to help me with this?

-Barry




More information about the ubuntu-distributed-devel mailing list