ansaurus

Question

mercurial: how to synchronize mq patches from a master repo as mq patches to a set of clone repos

Answer 1

+3 A:

patches can be maintained in their own repository provided you passed the "-c" switch to qinit like so

hg qinit -c

You may still be able to create a patch repo after the fact via

cd .hg/patches
hg init
hg addremove
hg commit -m "my patches"

But I haven't ever tried that personally.

then .hg/patches can be treated like any other mercurial repository. so I think you could probably roll some shell scripting. to get into the .hg dir of your cloned repos and do a

hg clone http://centralrepo.com/patch_repo ./patches

Tom Willis 2010-04-13 12:20:05

Thanks Tom. Unfortunately, I was already considering an approach based on this idea (that's why I'm wondering in question "Do I need to have versioned mq patches for that?") but looks little bit too complex. I'll post tested details as a self answer. Really --mq option should be also available for clone. Anybody see something easier? or other way to achieve my above usecase? +1 for now.

dim 2010-04-13 14:15:13

even if partial and qinit become obsolete, this is the idea. thanks for answer...

dim 2010-04-20 18:37:27

no problem hope it works it all works out. I will most likely have to do something similar very soon.

Tom Willis 2010-04-20 20:56:25

I suggest you default `qinit` with `-c` as soon as you start to use MQ, because it's too easy to lose change history with `qrefresh`. As all tutorials would tell you that you should commit often to mark the progress, with MQ you need to `qcommit` often. It's the best of both worlds: keep your regular changeset history clean while having work-in-progress history to reference and fall back.

Geoffrey Zheng 2010-09-16 03:03:45

Answer 2

+1 A:

Here is the solution that I've implemented. Few notes:

all patches guarded with ready_for_testing AND those unguarded are applied for testing.
using versioned repos is better because we can make abstraction of queue repository implementation
I use mercurial 1.5.1
master repo is in master dir
clone repos are in clone-x dirs

Here are the steps (some could be optional):

once: put patches in master repository under versioning using mercurial:
a. hg -R master init --mq #no commit happen here, can be done later
b. hg -R master commit --mq --addremove --message 'initial patch queue' #make them visible to clone repos
for each clone, once after clone creation finishes: assuming no patches created yet on clones, initialize mq sub-repository:
a. hg clone master\.hg\patches clone-x\.hg\patches
b. hg -R clone-x qselect ready_for_testing
for each change ready in master (patch created/imported in mq repo): do this before launching tests for it:
a. review/update guards of mq patches: those included for testing should be unguarded or with +ready_for_testing
b. hg -R master commit --mq -A #make them visible to clone repos
for each clone, for each [test] iteration for each clone: do this preparation sequence before running the actual test:
a. hg -R clone-x qpop --all --force
b. hg -R clone-x pull
c. hg -R clone-x update --clean
d. hg -R clone-x purge --all
e. hg -R clone-x pull --mq
f. hg -R clone-x update --mq
g. hg -R clone-x qpush --all

dim 2010-04-13 15:19:52

just found some qclone mercurial command. maybe step 2a can be avoided...

dim 2010-04-14 14:45:08

ansaurus

tags:

views:

answers:

mercurial: how to synchronize mq patches from a master repo as mq patches to a set of clone repos

related questions