DVC rules

Centralized VCS (version control systems) have ruled for a long time, but they have severe draw backs.

Distributed Version Control (DVC) fixes them!

Centralize version control is wrong due to:

The central repository is the single point of failure. No one can work if it is not available, broken or blocked by someone else.
You must be online to commit, i.e. you must have a network connection. Hoops, just lost the WLAN conncetion during commit. Hoops a network failure ...
Networks are really slow compared to local disk accesses. This affects all operations requiring network access, e.g. diff, status, log, blame. Caching data locally will avoid this to some extent, but if you do it you just made the first step towards DVC.
You need commit access. There is no way to just start fixing and hacking. You want to keep development private for a while and still have version control, but there is no way to do it. Well you could check in the code into another VCS, but then you will not be able to merge the commits back to the source branch and getting updates in terms of commits to the source branch.
The repository is polluted with test code as feature branches are not used or not possible. This is wrong as it should be easy to create feature branches and to test new features and throw the branches away if they are not needed anymore or have been merged.
People tend to commit only once in a while to avoid impact on others or/and commit only when the code is finished. This is wrong as one should commit often to keep the change sets small and track development on a fine grained resolution. If you ever used bisection on the history of a project to find the source of a bug, then you know what it is worth to have a change set of a few lines instead of hundreds of lines.

Things done right in BZR (beside the problems above and basic operations):

Merging just works. Merges are tracked and you will not accidently merge a change twice. You can also ask for the missing changes between branches and branches can converge to each others again.
Renames just work. They are not an alias to copy+delete. Renames are common when refactoring code and merging these changes works.
Backups are just branches you push to. Each branch is a backup of the branch it was created from.
Track other branches. Just pull them in a cron/batch job and inspect them from your local disk, this is so much faster than going over network. Others branching and pulling from your are doing the backups for you!

CVS has (kind of) branches, but it lacks proper merge support. It is essential that merges are tracked by the VCS, not the user or custom scripts. CVS has no support for renames. It is just too annoying to wait for CVS to complete simple commands like diff and status with a repository somewhere on the other side of the network. With BZR I push commits in background jobs and thus I am not bothered if it does not work or takes long. No need to wait for the commands I use most often: log, status, diff and commit.

SVN has cheap branching, but it is nothing worth without proper merge support. Well, it is worth a bit to tag a certain revision. It (1.4.*) lacks merge tracking and cannot handle merges for renamed files. If they would have done CVS right, they should have done this right first. There is a rename command, but it is just a fake, it is only an alias for copy+delete. The SVN developers are working on this, but SVN is still not distributed and thus sucks! In the meanwhile it is a PITA.

You do not like DVC? You think there has to be a central repository! Well, just name one branch the trunk, make it the central repository where only the few selected people may commit to. It will become more stable then it would have ever been with CVCS, as developers will push if things have been tested, but not when they feel the urge to commit.

You fear that people can just easily take away all the code and history. If you fear this, you should not give them access to the code or central repository at all.

Version control can be fun, just go for DVC. Commit often, branch and merge frequently. Disk space is cheap, keep as many branches as you want or use a local repository and light weighted branches / checkouts. Branch to your USB-stick hack somewhere else and merge back the changes. Host your repositories and branches on a dump server, i.e. some free web or ftp space. Merge revisions instead of patches, no need to write comments, credits etc. and no need for others to commit to your repository. Let others create the backups for you.

You call yourself an agile programmer, but you are still using a centralizes VCS ... you should switch to DVC or stop calling yourself agile.

If you do not like BZR then checkout HG, DARCS, MTN, GIT, ARCH, ... any DVC it better than a centralized VCS like CVS, SVN or any commercial ones.

Another word on DVC, in fact most of the time I use DVC inside Emacs instead of the command line as it is simply much nicer when reviewing changes, undoing debug stuff and selection files to commit. A nice command line is a must, but browsing history and changes is much easier outside of the command line in a GUI -- hey it is called browsing. While Launchpad.net really has a nice GUI to browse history, I also want to have it on my desktop.

Last modified: Tue Feb 12 23:11:24 CET 2008