What's next for pbranch?

[Peter Arrenbrecht]

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.

Where mq is far superior, though, is when the set of active patches
needs to change at will (qguard). And pbranch is basically useless
when you want to reorder patches. MQ is also better for quick edits to
csets (qimport, qref, qfinish).

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).

>> It's more cumbersome than maintaining
>> separate branches with merging between them all the time.
>>>
>>> now. I still think they differ sufficiently in their approaches and
>>> aims.
>
> And why is that a problem?  Use MQ for those jobs that suit its paradigm and
> pbranch for those that suit its.  This is not a contest where there can only
> be one winner.

I agree, but given that mpm so far has vetoed endorsing pbranch as a
regular hg extension because there already is mq, there is - while not
actually a contest - a conflict of sorts.
-parren