Non-linear patch queues

[Pierre-Yves David]

On 07/28/2014 02:14 PM, Sebastian Unger wrote:
> Interesting. I can't pick how qqueue is related to my problem, but
> evolve does look like a worthy successor (pun intended) to MQ. However,
> from reading through the manual I can pick out a few issues that I have
> with it:
>
>  1. Evolve requires the extension to be installed on all servers hosting
>     repos and the mercurial there to be recent while MQ can be run just
>     locally and the queues hosted in a standard repo. This is of course
>     *our* problem in that we should get that server that is hosting our
>     repos updated.
>  2. I find that the publishing setting granularity is too coarse. I
>     would really like to be able to have a single central repo and have
>     some parts of the history in that repo in draft state and stay in
>     that state until explicitly changed to public while pushes to other
>     parts get promoted to public automatically. I wonder whether you
>     couldn't add publishing markers similar to how obsolescence markers
>     work. Like a draft-phase-is-persistent-marker that causes the marked
>     changesets to stay in draft phase even when pushed to a publishing
>     repo or something like that.

Youc an configure server to be non-publishing. So that draft chagneset 
pushed to them stays draft.

> Other than that it looks VERY interesting indeed (and yes, it obsoletes
> (;-) my original question). Are you planning on integrating that into
> stock mercurial at some point in the future?

Inclusion in core mercurial is planned. a good share of the logic is 
actually already in code but disabled by default. The extension is here 
to allow quick experiment before freezing final state into core.

-- 
Pierre-Yves David