Migrate to Mercurial VCS

This article proposes that PARPG migrate its codebase from Codesion's SVN hosting to a mercurial host.

Hosting Options
An acceptable mercurial host must meet the following criteria:
 * Supports Mercurial;
 * Free, and supports an unlimited number of developers;
 * Has a reasonable repository size limit (1~2 GB minimum);
 * Integrated tools for:
 * Bug tracking;
 * Milestone/progress reporting;

Assembla
So far, Assembla (www.assembla.com) is the only host we've found that meets all of our requirements. Assembla uses a modular framework with 20+ tools which can be added and removed from a workspace as needed, and many of these tools are specifically designed for agile development. Specifically, Assembla provides:
 * Free hosting for open-source projects;
 * Support for an unlimited number of svn, mercurial and git repositories all with integrated support with other Assembla tools;
 * An in-house bug tracker with an optional Trac frontend;
 * StandUp, which is an asynchronous messaging system designed to replace real-time SCRUM meetings;
 * Milestone tracking with integrated SCRUM backlog;
 * Continuous integration/build server hooks;

Assembla guarantees 1 year of free hosting no matter if they drop or change their free services, so worst case scenario we have only 1 year of free hosting with them. Given the limited number of free DVCS hosts that meet our requirements, I think this is reasonable. Most other hosts don't even guarantee their free service.

Branching
Mercurial treats branching quite differently than most other VCS's, and in fact provides no less than 4 different kinds of branching. For an good overview of the various methods of branching in Mercurial I highly recommend Steve Losh's blog post on the subject.

In particular, it is important to note that unlike git and svn where you can choose which local branch should be pushed to the server Mercurial's default behavior is to push ALL branches to the server! This means that any branches you make locally (e.g. to work on new features) will be committed to the server and clutter up the main repository's history. It is thus very important that we carefully evaluate the different branching mechanisms that Mercurial offers.

The four methods of branching differ in whether and how the history of a branch is stored a) locally and b) when pushed to the main server. In summary, the types of branches in Mercurial are:
 * Named Branches
 * Created using hg branch . Named branches split the revision history and keep track of every revision committed under the branch. Although it might be tempting to compare named branches to svn's branches, unlike svn Mercurial's named branches are permanently stored in history even after merging those changes back into the default branch (equivalent to svn's trunk).


 * Anonymous Branches or Heads
 * Created whenever a change (via a commit on an older revision, changes pulled from the server etc.) implicitly causes the history to branch. Heads are comparable to git's branching mechanism, except without the explicit naming (but see bookmarks below). Mercurial will warn you if you try to push changes that would result in creation of one or more new heads in the server's repository, as creation of new heads should generally be avoided on the server unless you have a really good reason for it.


 * Bookmarks
 * Created using hg bookmarks . Essentially, Mercurial bookmarks just add a convenient tag to an anonymous branch which you can use to refer to the head instead of its hash value or revision number. Bookmarked anonymous branches are essentially equivalent to git's branches.


 * Clones
 * The simplest and leave intrusive method of branching is to simply clone the repository. The clone's history is completely independent of any other clone's history, and is the branching method most similar to svn's branching.

Workflow
A DVCS is quite different from a centralized VCS like SVN, and requires a different workflow. Mercurial can support a wide variety of workflows so we will need to decide upon how we want to work with it.

Repository Structure
Although Mercurial does not require an explicit repository structure, it is a good idea to decide how we want the repository to look.

Steve Losh addressed the issue of repository structure in a series of articles on his blog. In summary, Losh identified and evaluated the following repository structures:
 * Branch As Needed
 * In this scheme, essentially the repository structure is not managed at all. Parallel changes are merged into the default branch as they appear, and named branches are created as needed. The problem with this approach is that it can quickly become difficult to tell when and where bugs were fixed, which versions are stable versus bleeding edge, etc.


 * Stable and Default