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

[Samuel Masham]

On 13/12/05, Chris Mason <mason at suse.com> wrote:
> I'm not against the qtag command,

me nether *grin*

> but I do want the flexibility of merging hg qpush -m -n foo

Now  I have to confess even looking at this again I still don't like this.

Here you are taking changes from one queue ( .hg/foo) and then putting
the changes into a completely separate queue (the default
.hg/patches).

If you save the queue I don't mind working on that

hg -Q .hg/foo qpush -m
  (made up syntax to match the hg -R)

but when doing this I want the results to end up in the .hg/foo queue
(repos) not jump into another one.

If you want to use the one queue twice just clone (take two copys
qsave -c etc) the queue before you set off.

When doing this kind of thing its easiest if the queue and main repos
can be updated to the the same point, and being able to update both to
the same point is greatly simplified by qtag (plug plug)

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

and the tags have nothing to say here, they completely agnostic about this :)

(other than giving you a tag to update too etc of cause).

None of this discussion has any thing directly to do with the status
file format, so including the second parent in this file is OK ?

The issue is that when I added this I also removed the qpush -m -n to
make the code simpler.

So in principle if I respin and preserve this (somehow *grin*) the
patch would be ok?

Samuel

ps I am not going to be able to do this untill next year (gulp)
however as for me at least xmas hits tonight...  and that means no
access to hg etc

>
> -chris
>