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
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
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
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
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.
(c) Robert Widhopf-Fenk
Last modified: Tue Feb 12 23:11:24 CET 2008