[Courses] [Tools] An introduction to our three VCSs: CVS,
Subversion and Bazaar (version 2)
mary-linuxchix at puzzling.org
Sat Oct 22 10:01:18 EST 2005
This post is the seventh 'lesson' in the Participating in Free Software
LinuxChix course. You can find previous lessons at
http://www.linuxchix.org/content/courses/tools/ . Questions and
discussion are welcome, please make sure the string "[Tools]" is in the
subject of your mail.
I'll be on IRC to discuss this lesson at two times:
- Sun Oct 23 2005, 00:00 (midnight) UTC/GMT, see
http://tinyurl.com/d86sa for local times
- Wed Oct 26 2005, 10:00 UTC/GMT, see http://tinyurl.com/d9zwp for
The channel is #tools-course on server irc.linuxchix.org
In this lesson we'll review the three version control systems we're
going to look at in this courseL CVS, Subversion and Bazaar (version 2).
I'll give an overview of their maturity and of how to install them or
test that you've installed them on Linux. (All three systems have
versions for other operating systems which I can point you to, but can't
teach you to operate or test.) For each version control system I'll also
point to some extra resources: this course is an overview and if you
want references you will want to consult a more complete source.
-- CVS --
The letters "CVS" stand for Concurrent Versions System, but the full name
is rarely used outside of books that document it, and its not always
used then. Since the acronym is nearly universal, I'll refer to the
system just as "CVS" throughout the course.
CVS is by far the most widely used version control system among Free
Software projects. It is also by far the oldest of the commonly used
Free version control systems. Up until about the year 2000, when
development of Subversion and several other competing systems began to
pick up pace in earnest, CVS had more or less an open field: there were
other version control systems, but they were proprietry and commonly not
available for Linux or other free UNIX-like systems.
CVS had the field to itself for a while, and has been very stable: few
new features or major releases are made. However, some of its
limitations have led people to develop alternatives:
1. CVS has no way to rename files or move them from the client
command line while keeping the full history of the file.
2. CVS makes branching very difficult, to the point where a lot of CVS
users just don't branch.
3. CVS has no way to track files that are committed together (it
doesn't have what are called "atomic commits": each file is
committed in its own commit operation). This poses problems for
automated testing. Some projects like to have a automated process
that runs tests over the latest versions of the files (eg, it tests
that they compile, or it runs some unit tests). CVS does not provide
an easy way to say "give me a complete version of the files as of
the last complete commit"
4. It is not easy to version your own changes to a project unless you
have write access to the main repository.
However, it is still likely that any given Free Software project will be
To check if CVS is installed on your system, type "cvs --version" at the
command line. You should get something like this:
$ cvs --version
Concurrent Versions System (CVS) 1.12.9 (client/server)
Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public
License, a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS
You don't need to have any particular version installed for this course.
Almost all Linux distributions package CVS and you can install it from
their packages. Please ask for help if you don't think you have it
installed and can't figure out how to.
There is a graphical version of CVS that works under Microsoft Windows
and which integrates with Windows Explorer: TortoiseCVS, available from
http://www.tortoisecvs.org/ . I won't be covering this or any other
graphical interfaces in this course, but it is useful if you want to use
CVS with people who prefer this kind of interface. There seem to be
several for Linux too, but I don't know if there is a known "best of
Resources for CVS
For a more complete guide to CVS, see the following resources:
1. O'Reilly's "Open Source Development with CVS", 3rd edition, is
available freely online at http://cvsbook.red-bean.com/
(under the GPL) and in book form:
2. LinuxChix's own Jenn Vesperman wrote O'Reilly's "Essential CVS", see
--- Subversion ---
Subversion (also known as "SVN" or "svn" after its command-line tool) is
CVS's main competitor now among Free Software projects using version
control. When asked why Subversion exists, the Subversion developers
have replied "[This project exists] to take over the CVS user base.
Specifically, we're writing a new version control system that is very
similar to CVS, but fixes many things that are broken." 
Essentially, you can regard Subversion as CVS with a different name and
some extra features. They list these on their front page at
http://subversion.tigris.org/ , but the two most commonly cited are:
1. Atomic commits: if a group of files are committed together, this is
recorded, and rather than being able to access versions of individual
files, you can access a version of the whole project.
2. Versioning of file meta-data. This means that things like moving
files, renaming files, adding directories, renaming directories are
versioned too. (So are symbolic links.)
After CVS, it is most likely now that a Free Software project will be
To check if Subversion is installed on your system, type "svn --version"
at the command line. You should get something like this:
$ svn --version
svn, version 1.2.0 (r14790)
compiled Jun 29 2005, 12:46:42
Copyright (C) 2000-2005 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV)
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn
* network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
You'll want to have at least version 1 installed. Make sure that you
have the "ra_svn" and "ra_dav" modules.
Almost all Linux distributions package Subversion and you can install it
from their packages. Please ask for help if you don't think you have it
installed and can't figure out how to.
There is a Tortoise Subversion called TortoiseSVN. Like Tortoise CVS, it
integrates with Windows Explorer. You can get it from
Resources for Subversion
For a more complete guide to Subversion, see the following resource:
1. O'Reilly's "Version Control With Subversion" is
available freely online at http://svnbook.red-bean.com/
(under Creative Commons Attribution 2.0) and in book form:
--- Bzr ---
This section describes a version control system called Bazaar version 2
(named for Eric S. Raymond's essay evangelising Open Source as a
development methodology, see ). Because Bazaar version 1 is quite
different and still in relatively wide use, I will refer to Bazaar
version 2 as Bzr, which is its command-line tool (doing this is fairly
common, quite a lot of people call Subversion "svn" after its
Bzr differs from CVS and Subversion in a number of ways: it's both newer
and less well-used. I'm including it in this course as an example of a
distributed (also known as "decentralised") version control system, one
of a newer breed of version control systems, none of which is yet
notable for its take-up among many projects. My choice of Bzr was
motivated mainly by it being the distributed version control system
which I'm personally most interested in using. It's also been developed
specifically based on the best and most useful ideas from other version
control systems, and compared to some of the others it is very easy to
get started with it.
In the previous lesson I reviewed some of the limitations of having a
central repository which stores all the revisions of the code, both the
trunk or main set of files and the branches which aren't ready for
merging. Two of the biggest limitations are that you can't take
advantage of version control when you're not able to access the central
repository (for example, when you're not connected to the 'net), and
that if you don't have write access to the central repository it is
difficult to maintain a copy of it and work on your own changes locally.
Distributed version control systems solve these two problems. Unlike
centralised systems, which store files in one place and which merge
between branches stored in that one place, distributed version control
systems allow you to copy, branch and merge entire repositories. A
typical sequence of use is something like this (keep in mind that most
of these are done via commands in the version control system):
1. You want to make a change to foo project.
2. You make a distributed branch (a copy of the repository) on the
machine you're going to be working on.
3. You work on your changes, committing them to your local repository.
You can check out, edit and commit as usual to these repositories.
4. You either merge your work to the upstream, or, if you don't have
permission to, you make your own repository public and ask someone with
permission to review your changes and merge them.
Multiple levels of upstream are possible here too. For example, you and
your friends might want to work on foo together. One friend copies the
foo repository, and makes some changes. You then copy her repository and
make some changes. You can then either ask your friend to merge them
into hers, ask foo to merge your changes directly, or both.
Distributed version control systems are, as a rule, very focussed on
merging and have very sophisticated merging algorithms: they're much
better at working out which changes have already been merged and which
are new. Having worked with, and butted my head against, CVS and
Subversion branching a merging a lot, I find this aspect of using Bzr
very refreshing. It's not something you will encounter upstream projects
using much yet, but you may consider using it for your own projects,
especially if you work offline (eg, on a laptop) much.
Bzr itself is still in a comparitively early stage. It won't be
officially released until early 2006. The development is sponsored by
Canonical Ltd (who also sponsor most of the development of Ubuntu
Linux) and they're moving their internal development (Launchpad) to it
As noted in a previous mail, you will need to have Python 2.4 installed
to use bzr. If you're having trouble with this, post and we will help
out where we can.
To find out what version of Python you're running, run the following:
"python" (once you have the information you need, type Ctrl+d to exit
back to a normal command-line).
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
The number I've marked with ^ needs to be >= 2.4. Fedora Core 4 and
Ubuntu 5.04 and 5.10 have Python 2.4. Fedora Core 3 and earlier do not,
and Debian stable does not. You can install Python 2.4 for Linux from
source here: http://www.python.org/2.4.2/ or in RPM form here:
You can download Bzr itself from here:
Once it's installed, you can test the install by typing "bzr --version":
$ bzr --version
bzr (bazaar-ng) 0.6pre
Copyright 2005 Canonical Development Ltd.
bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.
Resources for Bzr
Bzr is still fairly early on in its development, so there are no books
yet. You will find these resources most useful:
1. The homepage at http://www.bazaar-ng.org/
2. The tutorial at http://bazaar.canonical.com/IntroductionToBzr
3. The wiki at http://bazaar.canonical.com/Bzr
If you're interested in actual Bzr design and development, you can find
some discussion of it at http://sourcefrog.net/weblog/software/vc/bzr
More information about the Courses