[Python-Dev] We should be using a tool for code reviews

[Martin Geisler]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Barry Warsaw writes:
>
>  > You can have "co-located" branches[1] which essentially switch
>  > in-place, so if a branch is changing some .c files, you won't have
>  > to rebuild the whole world just to try out a patch.
>
> In Mercurial these are called "named branches", and they are
> repo-local (by which I mean they must be part of the DAG).

Think of it this way: you can have several clones and when you make
different commits in each, they naturally begin to diverge:

  clone 1: ... [X] --- [A] --- [B]

  clone 2: ... [X] --- [R]

  clone 3: ... [X] --- [U] --- [V]

Though you cannot see it yet, you have created branches in the history.
If you pull one clone 2 into clone 1, then the branch suddenly becomes
visible in that clone -- you have two "heads" (B and R):

  clone 1: ... [X] --- [A] --- [B]
                  \
                   [R]

You can of course pull in clone 3 as well:

  clone 1: ... [X] --- [A] --- [B]
                | \
                |  [R]
                 \
                  [U] --- [V]

You can now use 'hg update' to switch between these three anonymous
branches. You can find the three heads by using 'hg heads' or you can
use the bookmarks extension to assign labels to them. These labels will
move forward when you commit, just like you move a bookmark forward in a
book when you read through it.

Btw, you can separate such a repository again with 'hg clone -r' which
lets you ask for a clone containing just a subset of another repository.
You can of course also split off named branches (see below) in this way.

> Named branches used to have some inconvenient aspects relevant to
> standalone branches (they could be fairly confusing to other users if
> pushed before being merge to mainline).

Now, "named branches" is sort of an extension of the above scenario.
Along with the commit message, date, username, etc..., each changeset in
Mercurial contains a label that tells us which "named branch" it belongs
to. By default, changesets are on the branch called, well, "default".

Named branches allow you to group or namespace your changesets. For
Mercurial itself, we use two named branches: default and stable.
Bugfixes go on the stable branch and we do our development on the
default branch.

Though a named branch is a collection of changesets, you often refer to
a named branch in a context where you need just a single changeset. It
is then interpreted as the tip-most changeset with that branch name. So

  $ hg update stable

will checkout the latest (tip-most) changeset on the stable branch. If
you now commit a bugfix, then that changeset will also be on the stable
branch since the branch name is inherited from the parent changeset.

In Mercurial we then merge the stable branch back into the default
branch:

  # fix bug
  $ hg commit -m 'Fixed issue 123'
  $ hg update default
  $ hg merge stable
  $ hg commit -m 'Merged in fix for issue123'

I've written a guide to such a workflow here:

  http://mercurial.aragost.com/kick-start/tasks.html

> It's not obvious to me that Mercurial style named branches would work
> well here ... it would take a little thought to design an appropriate
> workflow, anyway.

Yeah, you guys should try it out first -- it's easy to introduce named
branches later if you want.

-- 
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/20100930/3495ffbf/attachment.pgp>