BikeAlive goes Mercurial

Not only am I working on different projects at the same time but i am also working at different tasks within these projects and, to make it more complex, at different locations at different computers also.
This requires a different way of working.

Up to now I have been using a mixture of Subversion and Portable File Systems (USB memory stick) to keep track of all these changes. I like Subversion in that I have a centralized archive on the internet in which I can store all my work, I like PFS because that allows me to play around with a changeset before committing it into the centralized archive.
The USB stick has one big disadvantage: it does not allow me to track the changes I have made so if I am working on two different tasks (e.g. getting my FatFS to work and trying to solve implement a new feature to monitor the battery voltage) I need to manually merge these changes.

I had heard of Mercurial before but did not want to pull in yet another configuration management system. If I only had looked further I would have discovered earlier that Mercurial is a distributed CMS allowing me to create both a central (master) archive and multiple local archives. Each local archive can contain its own, local, changes. Multiple local archives can be merged to one archive that contains a merge of the changes of both local archives.
The same procedure can be used to merge changes in the networked archive.

Advantages of Mercurial

For me Mercurial has a number of advantages above the current systems I use:

• Always working from a local archive
  There is always a local archive where all the changes are committed locally.
• Multiple local archives can be used
  This allows me to work on different tasks in different (local) archives.
• Archives can be copied (cloned) when needed without impacting other archives
  Any user can clone an existing archive and start working on this archive. Any set of changes made to a local archive can be pulled into another archive or even pushed (uploaded) to a network archive when allowed.
• Any archive can be used to create a new networked/master archive
  This allows for the creation of a new archive (e.g. for a new project or product) that is based upon an existing one, keeping track of all the original changes.
• Merging archives is easy(er)
  Changes from one archive can be pulled into another archive, these changes can then be merged with the changes made in the local archive.
• Submit changes to a master archive when ready
  Multiple local changesets can be created to track changes in more detail without breaking the master archive. It is the user's decision when to upload (push) his/her changesets to the master archive, allowing to track changes on a more detailed level without breaking the master archive.
• Merging in changes from a base archive
  If we have something like a common base to start with (an OS with drivers and some standard libraries we use) we can use this archive as a starting point for a new archive (the new master archive of a new project). If we later fix bugs in the common base, these can be merged into our new project at will. All changes made to the common base are then visible as changesets in the new project.