What's next for pbranch?

[Peter Arrenbrecht]

On Wed, Nov 25, 2009 at 3:05 PM, Christian Boos <cboos at neuf.fr> wrote:
> 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.
>>
>
> Note that with Mercurial 1.4, you can now safely use 'hg rebase' for
> rebasing your MQ patch queue.
> This *will* use regular hg merges for updating the patches against changes
> in upstream.
>
> e.g. assuming you have your patch queue applied:
>
> $ hg pull
> $ hg rebase -b qtip -d tip

Welcome news. Nevertheless, pbranch keeps full history of the merges,
whereas mq's rebase will lose it. And pbranch records which version of
patches were supposed to apply to which version of upstream. This, not
even versioned mq will tell you without ad-hoc measures like encoding
current qbase into the commit msgs of your .hg/patches repo. And
versioned mq is not something for the faint of heart, anyway.

-parren