How to pull/merge selective changesets

[Bruce Frederiksen]

On Thu, Aug 20, 2009 at 3:18 AM, Martin Geisler <mg at lazybytes.net> wrote:

>
> If the bugfix was made as changeset X in release_1, then instead of step
> 3-5 you could switch to a dev clone and use 'hg pull -r X ../release_1'
> to bring it over (and then merge). That will give the same result.
>
> I like that your technique allows allows both clones to contain
> changesets not present in the other, while still being flexible enough
> to allow new common changesets to be introduced.
>
> You are in a sense implementing the scheme suggested by Abderrahim
> Kitouni, except that you keep the 'common' repository implicit. Such a
> repository is by its nature redundant since all its changesets will also
> be present in the two main clones, so nothing is lost by not storing it
> explicitly (except that one has to search a bit to find the common
> ancestor point).
>

This sounds like a winner!

And then I suppose you could use named branches to track these common
changesets?

To test my hg knowledge, if you had a branch named "common", it would appear
in both release_1 and dev.  Then you could start in either release_1 or dev,
update to common, do your change, commit, merge to the default branch,
commit, then push the common branch to the other repo and merge/commit there
to default.  Doing this would automatically track what the latest common
changeset is in both repos.  Is this correct?

Can you then use the branch name in the pull (hg pull -r common
../release_1)?  (If so, this is not documented in 'hg help revisions', but I
think it works for hg update).

Then I guess as you add more releases, you could play it by ear in terms of
creating new named branches to represent the various possibilities if and
when they become necessary.  Having multiple named branches would mean
multiple merges, but I guess these could be delayed and done as needed.  For
example, with release_1, release_2 and dev, you have a "common" branch in
all 3 repos.  When you create a "common_1_2" branch that excludes dev, you
would have to merge new changesets in common from then on to both common_1_2
and default.  But you could let the changesets in common accumulate and only
merge to common_1_2 when needed; i.e., just before making a new common_1_2
changeset.  So I should develop the habit to always merge from common first
before starting new work on common_1_2.

And I guess after creating the 3 repos (without common_1_2), creating a
common_1_2 named branch in release_1 and then pulling it to release_2 will
automatically create the common_1_2 branch in release_2 as well?

-Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090820/b1bd9263/attachment.htm