MQ merging

[Peter Arrenbrecht]

On Mon, Mar 3, 2008 at 12:38 AM, Peer Sommerlund
<peer.sommerlund at gmail.com> wrote:
> Steve Borho has an mq-repo (http://hg.borho.org/mq-tortoisehg/) that builds
> an installer on top of the mercurial repository. If I want to contribute to
> his mq-repo, I have to pull it AND to locate the correct repository (in this
> case hg-main) and changeset to use as qbase. The latter two steps is not
> automated by Mercurial today. However, I can do it with
>
>   hg qclone -p http://hg.borho.org/mq-tortoisehg/ http:/selenic.com/repo/hg
> my-work
>   hg up -R my-work -r <qbase> # qbase is unknown - so just pray that it is
> tip
>
> If the series file also stored the default path (in addition to qbase), and
> qclone was extended to support this, then I could simply write
>   hg qclone http://hg.borho.org/mq-tortoisehg/ my-work
>  and mercurial would automatically do
>   hg qclone -p http://hg.borho.org/mq-tortoisehg/ http:/selenic.com/repo/hg
> my-work
>   hg up -R my-work -r <qbase> # qbase is the same as used by borho

As of two recent commits, qclone can properly clone a remote
repo+queue if the queue is published within its base repo. The commits
are:

  http://hg.intevation.org/mercurial/crew/rev/f857eac30cd5
  http://hg.intevation.org/mercurial/crew/rev/0c2b443fb3c3

I realize this does not help if people do not want to host a full hg
repo just to be able to host a (much smaller) patch queue on top of
it. So your suggestion is still a good one, I think.

-peo