mq: addressing the broken version history (qpush/qpop/qpush cycle)

[Chris Mason]

On Tuesday 13 December 2005 02:38, Samuel Masham wrote:
> On 13/12/05, Chris Mason <mason at suse.com> wrote:
> > On Monday 12 December 2005 10:13, Samuel Masham wrote:
> > > How/when would this be of use?
> >
> > Think about the applications of cloning the .hg/patches repo instead of
> > forcing everything through tags.  It's of use in the same general way
> > that clones are of use.  hg qpush -m is just one user.
>
> The bit that I am wondering about is that for you to use the saved (&
> applied) patch queue you merge from that point (version) every time,
> is that practical?

You can merge from any queue.  So, if you merge patches from 2.6.14 into 
2.6.15, you can then merge from 2.6.15 into 2.6.16.  The queue clones don't 
dictate how it works, but they do keep the general hg model of having as many 
heads as you like.

I'm not against the qtag command, but I do want the flexibility of merging hg 
qpush -m -n foo

[ snip ]

> humm... is that realistic usage pattens for both methods?

I think so....perhaps we need to try it for a while to be sure ;)

>
> Any sign of which is more flexible / intuitive (winning *grin*)?
>
> The qtag based version rather relies on visioning the patch queue, but
> not convinced that that is a bad thing...
>
> Whats your take?

I think that versioning the patch queue works well with both models.  With the 
qsave model, if you have versioned patch queues you can simple hg pull from 
one saved queue to another and do a normal merge.

-chris