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