[MERGE] Better progress reporting in commit

[Ian Clatworthy]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> A few comments...
>> You again sent a bundle which cannot be applied without more context. So I'm
>> unable to just "bzr merge bundle". I did apply the patch directly (patch -p0 <
>> bundle). And I can say I like the reporter.
> 
> Ian,
> 
> I can kinda see where you're coming from, and I kinda can't.  You know
> what happened last time, so you should know that bundles aren't supposed
> to be used the way you're using them.
> 
> - preferably, make your changes in a branch that has freshly branched
>   from or merged bzr.dev.  That way, your changes are mergeable, either
>   from your branch, or from a bundle generated the normal way.

Aaron/John,

Sorry, sorry, sorry. This was not intentional. I *did* branch off my
local bzr.dev which 99% of the time is a straight mirror of the main
bzr.dev trunk.

In this case, I've stuffed something up as part of releasing 0.17? My
bzr.dev had the merge of the 0.17rc1 -> 0.17 fixes ready for submission
to PQM. That stuff is now truly in bzr.dev but I must have branched
before I had re-pulled from PQM.

If someone can ping me on IRC, I'd like to walk through this a bit more
to better understand exactly what I did wrong and how to fix it from here.

> - if you can't do that, please send a diff and indicate where your
>   branch is, and what revnos to merge from.  There is no point sending a
>   bundle, because a bundle's extra metadata is unusable.
> 
> But on the other hand, I can see that it would be nice if you could
> easily request a partial merge.  Here's my thought:
> 
> Let's give merge directives an additional "base_revision".  You'd then
> be able to specify "bzr merge-directive -r6..7", and that would generate
> a request to merge "6..7" precisely.  The diff shown in the merge
> directive would be the diff from 6..7.  The bundle could contain all the
> revisions that were necessary to construct 6 and 7, e.g. 5 and 4.
> Whatever's not an ancestor of the target branch's last-revision.
> 
> Does that sound like a good approach?

Given I don't fully understand what I did wrong yet, I'm not sure I know
enough to say how it ought to work. Bazaar does such a good job sorting
out merges and the tracking of their history that I guess I'm coming to
expect it to work magic in this area that simply isn't possible.

Having said that, I'd like to get a good workflow sorted for partial
submissions and dependency of unaccepted changes going for me. I like
using one branch per change but a hold-up of an early change (like the
kcachegrind stuff) breaks how I expect/hope to operate for changes
downstream. Whether the downstream changes are logically related or only
physically related, it's something I don't have clear yet while many of
you obviously do.

As I said, ping me on IRC and guide my though this please. I hate doing
the wrong thing, particularly a second time. :-(

Ian C.