<div class="gmail_quote">On 2 July 2010 08:07, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br></div></div>
Other than that, while I sometimes review patches in email, I do not think<br>
patches in a tracker are the best way to manage these. A dvcs's biggest<br>
strength is in branches, so we should use those as much as possible.<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div> </div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>7. Merged default branch was pushed to the central repo, which triggered a continuous build.</div><div><br></div><div>This approach is quite contrary to that favoured by the Mercurial developers, but we found it had the following advantages:</div>
<div><br></div><div>a. Central team repo made backup and continuous build simple.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>d. Similarly, switching to someone else's named branch is just as easy (for review, pair programming, etc).</div><div><br></div><div>e. Named branches make it very obvious what needs to be merged for any particular task.</div>
<div><br></div><div>f. Easier to follow in the log/graphical log as everything was "tagged" with what task it was against.</div><div><br></div><div>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.</div>
<div><br></div><div>Tim Delaney</div></div>