How to pull/merge selective changesets

[Martin Geisler]

Bruce Frederiksen <dangyogi at gmail.com> writes:

> On Wed, Aug 19, 2009 at 3:01 PM, Martin Geisler <mg at lazybytes.net> wrote:
>
>> 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).
>>
>> 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.
>
> OK, a couple of questions to be sure I understand this correctly:
>
> 1. I only do the above procedure on dev for changesets that are
> release_1 only. Then after that the changesets targeting both repos go
> to release_1 first (the subset repo), and are then pulled/merged into
> dev normally (Mercurial thinking it already has the first
> release_1-only changeset in dev when the second pull into dev is
> done). Is this correct?

Yes -- after the dummy merge, the release_1-only changeset is included
in the dev repo. Think of a merge like this: you take two changesets and
create a third changeset that show how you want the first two to be
combined. The third changeset can be anything, it can in particular be
one of the first two:


        dev: --- A ----- M
                       /
  release_1: --- X ---

Here you make all files in D equal to how they were in A. The X change
wont bother you again when you merge normally the next time:

        dev: --- A ----- M --- B --- M'
                       /           /
  release_1: --- X -------- Y --- Z

The new changesets in release_1 are Y and Z, so Mercurial will look at
the changes in Y and Z and merge them with the changes in B.

> 2. The HGMERGE=true causes the merge to not do anything. So I'm a
> little confused on the need for the revert (though suppose it can't
> hurt)?

It tells Mercurial to consider all conflicts as resolved. When a
conflict occurs, Mercurial finds the files for a tree-way merge (your
version, the common ancestor version, the new version). It then calls
the merge program, which should edit the 'your version' file and exit
succesfully. The true program will just exit.

The revert is necessary to un-add files introduced in the commit you
don't want. These new files wont trigger the conflict machinery, but
revert will un-add them.

> Does the merge end up with the files just pulled from release_1 in the
> working dir, rather than what was in the dev working dir before the
> merge?

Files in both branches will have the content from the dev commit you
revert back to. New files are probably left behind by the revert, I'm
not entirely sure.

> 3. I only need one commit at the end for the above procedure?

Yes, that is how you "bind" two branches together. It's all a matter of
preparing a working directory in the right state (the old state of dev)
and telling Mercurial to store this snapsnot as the merge.

-- 
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/20090820/df0887a5/attachment.pgp