How to pull/merge selective changesets

[Martin Geisler]

Bruce Frederiksen <dangyogi at gmail.com> writes:

> I would like to set up two shared hg repos for the same project:
> release_1 and dev.
>
> Then after the following sequence of events:
>
>    1. Push a changeset to release_1 that should only ever be seen in
>    release_1.
>    2. Push a changeset to dev that should only ever be seen in dev.
>
> Now I want to push a changeset to both repos.
>
> My understanding is that if I start with either repo (say release_1)
> and simply clone, commit and push back to that repo, and then
> push/pull, merge from that repo to the other repo (dev), that *all* of
> the prior changesets from the first repo are copied over and merged
> into the second repo (including those from step 1).

Yes, when you pull a changeset into a repository, you must also pull all
its ancestors. This implies that you can only maintain a subset-relation
between two repositories: you can for instance let release_1 contain
fewer changesets than dev.

This is what we do for Mercurial itself: there is a 'hg' and a
'hg-stable' repository and 'hg-stable' is always a subset of 'hg'.
Bugfixes are applies to 'hg-stable', then pulled into 'hg' and finally
merged with the old 'hg' tip. New features are put in 'hg' and remain
there until the time of the next release.

This works nicely as long as everything that going into release_1 should
also be in dev. You say that you have changes in release_1 that you want
to keep there -- that is not really possible.

You should instead pull them into dev and merge the resulting heads
while *ignoring* everything from release_1. So you make a dummy-merge
and keep the invariant that dev is always a superset of release_1.

You do a dummy merge like this:

  $ HGMERGE=true hg merge
  $ hg revert --all old-dev-head

The first command will merge everything and let Mercurial believe that
it was done succesfully -- the second command resets all files to their
state in the dev head you want to preserve. Now commit and you're done.

If you happen to make a commit dev and release that it should also be in
release_1, then use the transplant extension. Transplan is basically a
nicer interface for "hg export | hg import", so this will re-apply the
change as another changeset. In my experience, this causes, the
duplicated change cause no harm when merging.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090819/eaa28202/attachment.pgp