[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Tim Delaney]

On 2 July 2010 08:07, Barry Warsaw <barry at python.org> wrote:

>
> Other than that, while I sometimes review patches in email, I do not think
> patches in a tracker are the best way to manage these.  A dvcs's biggest
> strength is in branches, so we should use those as much as possible.
>
>
I changed my team over from ClearCase to Mercurial in the last 3 months
(just before we were made redundant ... :) Obviously our usage was coloured
by our previous use of ClearCase, but the workflow I found that worked best
was along the lines of the following.

1. Central server for the team, with a repository for each version (e.g.
2.6, 2.7, 3.2) where the default branch is the "trunk". Later versions get
cloned from a previous version at a particular tag, and merges between
versions are always forwards (if there's a need to merge backwards, we
cherry-pick the change by doing an hg export of the appropriate versions).

2. Developer made at least one clone of the appropriate repo, but could have
as many as they liked. Generally would have one local repo for production
work, and others for prototyping, exploratory work, etc - stuff that you may
not want in the central repo.

3. Each change is developed in its own named branch, named for the task
number. Local commits are performed as often as possible - no requirement
that any particular commit was compilable so long as it was on the task's
named branch.

4. Changesets are pushed to the central repository (requires forcing, as Hg
doesn't like you pushing new named branches). The named branch should be
compilable, pass unit tests, etc at this point. Generally preferred not to
edit the history or anything, but if there was something egregious

5. Other developers pulled from the central repository and reviewed
(integration with ReviewBoard or Reitveld was planned, but ran out of
time). This often led to a pair programming session on the reviewers machine
where comments were addressed directly.

6. Named branch was closed and merged to the main/trunk branch (in our case,
default). In our case this was usually done by the author - for Python this
would be done by a committer.

7. Merged default branch was pushed to the central repo, which triggered a
continuous build.

This approach is quite contrary to that favoured by the Mercurial
developers, but we found it had the following advantages:

a. Central team repo made backup and continuous build simple.

b. Named branches for tasks made the whole "what do I do with these
unfinished changes?" question moot - you commit them to your named branch.

c. Switching between tasks is incredibly simple - you already have your
workspace set up (e.g. Eclipse) and just update to the appropriate named
branch. No need to set up multiple workspaces.

d. Similarly, switching to someone else's named branch is just as easy (for
review, pair programming, etc).

e. Named branches make it very obvious what needs to be merged for any
particular task.

f. Easier to follow in the log/graphical log as everything was "tagged" with
what task it was against.

The only issue was that if a branch was abandoned, it would show up in "hg
branches" unless it was closed - but closing wasn't a problem since you can
always reopen if necessary.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100702/dd6e99cf/attachment.html>