[Python-Dev] Mercurial migration readiness

Martin Geisler mg at lazybytes.net
Sun Jul 4 16:32:59 CEST 2010


Éric Araujo <merwok at netwok.org> writes:

>> I'm not sure if I misunderstand Martin's intent, but in principle, if
>> you want to merge one changes (not changesets!) branch into another,
>> all you need to do would be "hg merge <otherbranch>". Subsequently
>> committing the merge (after fixing conflicts) creates a new changeset
>> "on" the current branch.
>
> Indeed, merges are branch-wise operations, not changeset-wise. You
> need tricks to copy one changeset from a named branch into another
> one.

You basically need to replay the changes -- the transplant extension can
do this for you. This is more or less a wrapper around 'hg export'
(gives you a diff) and 'hg import' (applies the diff).

> Copying changesets between a stable branch and a devel branch is easy
> if the devel history is a strict superset of the stable history. Every
> changesets landing into stable can then just be pulled into devel.
> This means no different named branches for stable and devel. Not sure
> I’m clear enough, I hope Mercurial experts can chime in.

It sounds like you are describing how Mercurial itself was developed
before we began using named branches. This part of the graph is typical
for us then:

  http://selenic.com/repo/hg/graph/52c5be55af82

Notice the three merges wtih 'crew-stable', which was what we called the
clone representing the next stable release. Whenever a bugfix is made,
it is immediatedly merged into the 'crew' clone, where normal
development takes place. This gives a characteristic flow with two
tracks (branches), where one is continuously merged into the other.

The two with commit message "Fix typeerror when specifying both --rebase
and --pull" (dd1b47e17d7e and aee8455ee8ec) are a typical example of a
transplanted changeset: the bug was first fixed in 'crew', but it was
then realized that it should also be in the 'crew-stable' repository so
that it could be part of the next point release.

Today we use a 'stable' branch in addition to the 'default' branch and
the graph looks much the same:

  http://selenic.com/repo/hg/graph/4d3288197717

You'll notice the small labels saying 'stable' on the changesets from
that branch -- that is the whole difference. A named branch is made up
by the changesets that same the branch name, but the graph itself works
the same.

The nice thing about our current setup is that I can do

  hg update stable

and the name 'stable' is then interpreted as the tip-most changeset on
the stable branch.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100704/98593904/attachment-0001.pgp>


More information about the Python-Dev mailing list