MQ and push/pull

[Peter Arrenbrecht]

Paul,

Firstly, take a look at "hg help qclone".

Secondly, when working on patches in mulitple locations (more
typically multiple contributors in my case), we try to avoid working
on the same patch so that we don't have to merge diverging patches in
the mq repo.

Instead, we just add another patch after the one we want to revise.
When consolidating the work, we just qfold the revising patch onto the
base patch again.

So:

  hg qcommit -m "Taking home..."
  hg qclone repo /usb/repo

At home

  cd repo
  hg qgoto base.patch
  hg qnew base-home.patch
  <edit>
  hg qref
  hg qcommit -m "Revised at home"

At work again

  cd repo
  hg qcommit -m "Whatever happened at work"
  hg -R .hg/patches pull /usb/repo/.hg/patches
  hg -R .hg/patches merge
  <likely need to fix conflicts in series>
  hg qcommit -m "Merged"
  hg gqoto base.patch
  hg qfold base-home.patch

If anyone has a better workflow, I'd be interested too!
-peo


On Jan 12, 2008 11:46 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> I am trying to do some work on a repository, using MQ. I have a clone
> of the mainline, and I have done the normal hg qinit, hg qnew
> my-changes, edit, hg qrefresh sequence.
>
> However, I now want to do some work on this code at home. I can copy
> the repo to a USB drive, and take it home to continue work, but if I
> then forget to take it back in to work, I'm in trouble.
>
> If I wasn't using MQ, I would just hg clone the repo to the USB drive,
> hg clone at home, and merge the 2 independent copies back, when I
> finally remember to bring the home copy in. However, with MQ I can't
> do this - if I clone a repo with patches applied, the changes come
> over, but the patch series doesn't. And I get in a mess if I change,
> pull back and merge:
>
> >hg  qrefresh
> abort: working directory revision is not qtip
>
> Could anyone help? What is the recommended workflow here?
>
> Just to summarise what I want to do:
>
> 1. Work on a MQ patch in repo1
> 2. Take a copy of repo1, and work on the patch elsewhere
> 3. Work on the same patch in repo1 (I may not be able to merge back at
> this point)
> 4. Finally get simultaneous access to the 2 repos at once, again
> 5. Get the 2 copies back in sync, with the patch containing all changes
>
> I'd rather that the sequence of commands in (5) were reasonably simple
> and intuitive - I'm likely to do this a lot, and a complex process
> would hamper things a lot.
>
> Thanks,
> Paul.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>