At Resolver Systems, we practice Agile techniques such as Continuous Integration, Pair Programming, Iterations and more.

One fundamental rule of Agile Programming is that There should never be a broken trunk. This means that before checking in we must make sure that every test passes. This makes checking in a very expensive operation: 4 hours for a full test run in a single machine. In the meantime, you go on working on that tree, making things very difficult to keep track of, without some form of version control.

In this post I will investigate various Version Control Systems that can be run locally: Most of them are distributed, but I don't really care about it - I don't want to replace Subversion (yet). I just want to be able to check in every hour and have a local version history, before checking in to the central Subversion repository.

I repeat: I don't want to replace Subversion. (yet). A typical workflow that commonly occurs is:

1. Checkout a working copy from Subversion
2. Hack and slash, editing and adding files.
3. Promote a tree to check-in status
4. cp tree tree-build
5. tree-build/run_unit_tests
6. go on working in tree
7. if unit tests pass, check in tree-build
8. svn update tree - This is where we get conflicts, wailing and gnashing of teeth.

After reading up a bit on the general idea of DVCSs, the workflow I will be testing is:

1. Import trunk (complete with history) from subversion
2. Make a local branch (tree) to work on
3. Hack and slash, editing and adding files
4. Commit locally as needed
5. Branch tree-build off tree
6. Run unit tests in tree build
7. Continue to hack and slash in tree
8. Check in from tree-build to subversion
9. Merge tree and tree-build back together, with no subversion conflicts.
10. Repeat

There could be minor variations of the above, and I don't really need the complete history from subversion. Hopefully the general idea is clear.

The systems I will try out are Mercurial v1.0, SVK v2.0.2, Darcs v1.0.9, Arch v1.3.5, Git v1.5.4, and Bazaar v1.3.

Requirements:

1. Easy install on Windows XP and Vista, preferrably without Cygwin.
   
2. SVN integration - either by supporting empty .svn directories or understarding the SVN protocol so it can communicate directly.

At the end of the day, Subversion is what everyone else will be working on in the office, so everything must end up there.

To be continued...

This article has been on the backburner for a long time, due to the fact that I aimed to test everything and then post my findings. This could take months, as every system has its own intricacies and it takes time to be able to compare between them. I will post a new entry when I have the first results ready!