What's next for pbranch?

[Peter Arrenbrecht]

On Thu, Nov 26, 2009 at 1:16 AM, Peter Williams <pwil3058 at bigpond.net.au> wrote:
> On 25/11/09 22:48, Peter Arrenbrecht wrote:
>>
>> On Wed, Nov 25, 2009 at 6:56 AM, Peter Williams<pwil3058 at bigpond.net.au>
>>  wrote:
>> [snip]
>>>
>>> That doesn't mean that MQ doesn't have its uses.  For its intended
>>> purpose,
>>> keeping a set of local patches against an externally managed source tree
>>> (e.g. the Linux kernel), it is superior to pbranch.
>>>
>>> And I'm sure that for some purposes pbranch is superior to MQ.
>>
>> Actually, for the specific case you mention I personally find pbranch
>> to be superior. I use it to maintain a set of local patches against hg
>> crew, for instance. Unlike mq pbranch uses regular hg merges for
>> updating the patches against changes in upstream.
>
> It may be that I haven't got my head around how pbranch operates (in spite
> of adding GUI support for it to gwsmhg) that prevents me from agreeing.
>  Basically, I just don't see what it's offering and I especially worry that
> it seems to permanently pollute the repository where as MQ keeps the patches
> separate (except when they're applied).

It offers a clean history of what happened when. Try to forget for a
moment about the idea of a patch. Think instead about branches. I
personally have a bunch of tweaks to my Hg install. I maintain these
as a set of independent branches off of crew. When crew updates, I
simply merge it into each of these branches. And I merge the heads of
all these branches together again for my installed version. So this is
my pgraph:

@    rel
|\
| \
| |\
| | \
| | |\
o | | |  bashcomp-meld
| | | |
| o | |  hgrc-defaults-in-parentdirs
|/ / /
| o |  transplant-merge-all
| | |
+---o  graphlog-collapse-runs
| |
| o  transplant-unless
| |
| o  transplant-merges
| |
| o  transplant-nochange
|/
o  default

I never think in terms of patches here, except when reviewing what a
particular branch does (I want to see its cumulative effect against
crew). But I keep the changes in separate branches so I can fix stuff
in isolation when crew changes incompatibly, without possible
side-effects from others of my changes. Incidentally, this is one
reason why one might one to use qguard with mq - to test patches in
isolation.

So this is pbranch in "merge flow orchestration" mode. At any time, I
know exactly what my installed version of hg looked like, can revert
to it, can get meaningful diffs, etc. All with basically standard hg
operations on my main repo. No need for versioned patch files and
interdiff.

Should I really want to get rid of the pbranch cruft again, I would
simply reclone crew, apply my pdiffs to it, and drop the pbranch-repo.
(Or, once it's done, use the proposed pfinish.) But so far, I saw no
need for that. Some of my local patches were accepted upstream, so I
simply merge them, resulting in an empty pdiff, and then close them. I
keep my personal history.

>> Where mq is far superior, though, is when the set of active patches
>> needs to change at will (qguard).
>
> I never use this feature and struggle to imagine cases where it would be
> useful.  That's why (at the moment) both gquilt and gwsmhg ignore them and
> probably will continue to do so unless I receive requests to add support for
> them.

See above.

>> On the other hand, pbranch maintains a true graph of patch
>> dependencies, whereas mq is linear (unless you count judicious use of
>> qguard as a sort of graph management).
>
> I (mostly) only use linear patch series as I'm usually breaking up some
> large change (e.g. adding plug in CPU schedulers to the Linux kernel) into
> easily digestible (for a reviewer) chunks in an order that is (hopefully)
> logical for the reviewer (and, at least, for myself).

I have switched to pbranch for this, too. The reason here is: Imagine
I make a change to one of the later patches. While doing so, I realize
some of the changes should really go into an earlier patch, or a later
patch, or even a new intermediate patch. With mq, this takes some
judicious shuffling with qref -X/-I, qrecord, qpush/pop -f, etc. I
more than once lost some of my changes due to mishandling mq while the
changes were in transit to other patches. I hate that.

With pbranch, I first commit what I did to my current patch. Only then
do I shuffle parts of the changes around, knowing I have a safe base
to return to. I guess there is a workable way to do this with mq too,
like qref on the current patch for the safe base, then import
--no-commit of the patch into earlier patches and revert all that's
unneeded there, then qref, then update back to the first patch and
qref again, resolving the resulting conflicts (ugh), etc.

Same when upstream changes. I have a clearly defined safe base to
return to if anything gets borked on the merge.

For me, it boils down to pbranch doing things the hg way, using
merge's and update's built-in merge logic when shuffling things
around, whereas mq always has these patch rejects and stuff, that
totally fall out of the normal workflow, don't get merge tool support,
and can lead to loss of data.

Maybe even deeper integration of mq with rebase could alleviate this.
Or maybe moving away from the idea of patch files entirely and using
rebase with multiple in-flight versions of csets. Shall think about
this in a separate email.

Anyhow, as you said before, mq has use cases where it's an excellent
choice. I believe so has pbranch.

[snip]

> PS Have you had a chance to play with the pbranch interface in gwsmhg yet?
>  If so do you have any suggestions for improvement (other than adding a
> decent graphical display of the dependency graph which is on my list albeit
> at the end)?

Yes. Although I do miss the graphical view. And I'm really more of a
hgtk (TortoiseHg) guy, so since Peer is building pbranch support for
that, I guess I'll stay with hgtk. Note, too, that startup time for
gwsmhg for my local hg is hugely slower than for hgtk stat. You might
want to look into that.

-parren