The recent release of 3.4.1 gave me some more practical experience with using Mercurial for cherrypicking bugfixes, and I've found I want to do things slightly different than we do today.

Cherrypicking changesets is done with the transplant extension. I've never been 100% comfortable with this, as I feel it circumvents Mercurial's fine merging capabilites. It gives me slightly the same feeling as merging bugfixes with Subversion did, the only improvement being that each changeset is transplanted separately instead of being mashed together in one big changeset.

With transplanted changesets in the series-branches, we cannot easily compare the contents of the series-branches with the default branch, using commands such as 'hg in' or 'hg out'.

Really, the only reason I have to do cherrypicking is because we fix bugs on the unstable default branch. I can't very well pull the default branch into any of the series-repositories, as they're supposed to be stable, so I have to pick single bugfix changesets from the default branch and transplant them.

If we look at things the other way around, anything that goes into the stable series-branches should also go into the default branch (except for version bumping and tags, see my side note below).

If bugfixes are committed to the latest series-branch instead of the default branch, the series-branch can easily be pulled and merged into the default branch, and no transplants need to take place.

Conclusion ---------- Starting from series/3.5.x (whenever it is branched from default), I would like everyone to commit bugfixes for stable code directly to this branch. I'm the only one with push access to these branches on MetaNAV, since I'm the only one working as a release technician at the moment, so I will need to know when and where to pull your bugfixes from.

The series/3.4.x branch is already a mix of directly committed bugfixes and transplanted bugfixes, which complicates committing bugfixes to this branch (you need to checkout the latest bugfix revision and commit your changes as a child node to that changeset, then merge the whole thing with the last head). This is why I won't start requiring this method of bugfixing until 3.5.x is on its way and this can be done more consistently.

Side note --------- For those of you who haven't looked at the series-repositories, please be aware of the specifics of how I tag a new release version on these. I'll use the 3.4.x branch as my example.

When I'm satisified that the latest changeset (A) on the 3.4.x branch is ready to become the 3.4.1 release, I change the version number in the file VERSION to 3.4.1 and commit it (changeset B). I then tag changeset B as "3.4.1". The tag changeset itself becomes changeset C.

When committing bugfixes and other changes for a later 3.4.2 version, I check out changeset A again, and base my changes on this. This is because I don't want the VERSION file in the following changesets to say "3.4.1", but rather "3.4.x_devel", as it did in changeset A. Also, I don't want to pull the changesets that changed the VERSION file into the default branch at a later time.

This may seem a bit contrived, and it leads to having multiple heads in any series-branch, but so far I haven't thought of a more useful way of updating the VERSION file without changing it back and forth all the time.