Multiple patch queues

[Bela Babik]

That's why I prefer to use Mercurial to manage my changes and not mq.
If your changes are part of the repository this problem would not
exist (you are basically talking about branches and merging).

On Fri, May 2, 2008 at 1:40 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 01/05/2008, Paul Moore <p.f.moore at gmail.com> wrote:
>  > 2008/4/30 Bela Babik <teki321 at gmail.com>:
>  > > qpush and qpop both have a queue name parameter (-n). I would give that a try.
>  >
>  > Ah, is *that* what that's about? I'll give it a go.
>
>  I had a little look, and I'm not sure how it helps.
>
>  What I want to do is:
>
>  1. hg clone crew my-crew; cd my-crew
>  2. hg qinit -c
>  3. hg pull -R .hg/patches windows-test-patches
>  4. hg qpush -a
>  5. ---> now start a new queue - no idea how to do this!
>  6. hg qnew my.first.patch
>  7. edit, qrefresh, qnew, etc etc.
>  8. ---> now I want to update the windows patches:
>     hg qpop -a (this should be just my stuff)
>     switch back to windows test patches
>     hg pull -R .hg/patches windows-test-patches
>     hg qpush -a
>     switch back to my stuff
>     hg qpush -a
>
>  and when I want to post my patches, hg email -r qbase:qtip without
>  needing to worry that I post many win-test patches.
>
>  The next problem is for me to copy my patch series to a clean crew
>  clone, without the windows testing patches applied.
>
>  If someone can give me some ideas on simplifying these scenarios, that
>  would be really helpful.
>
>  (Hmm, maybe just pushing a dummy patch called something like myparent
>  would do - then I could qpop myparent, or hg diff myparent:qtip, or
>  whatever. Is that plausible?)
>
>  Paul.
>