Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Introduction: Bazaar for CVS Users

This tutorial is for people that are experienced with CVS. Its generally better to start off with the normal tutorials if you do not have experience with CVS.

This tutorial is broken up into two sections; concepts and behaviour. The concept section is concerned with giving you the understanding to run Bazaar effectively. The second section eschews all of the details about what and why things are and jumps straight into the usage of Bazaar.

If you learn better with a hands on approach, then skip straight ahead to section 2. If, on the other hand, you are the sort of person that likes to think a bit about things before you do them, then section 1 is for you.

Section 1 - Explanation of Bazaar

Whats that hype about?

So, by this point you've probably gotten it from all sides about how you need to give decentralized revision control systems like Bazaar a try. "Bazaar does this! It does that too! It can merge this, allows for independent development that, tracks history the other, and generally makes hacking fun again". For all the hype that you hear, Bazaar probably finds lost socks as well.

So can Bazaar really do _all_ of these things? Nope. Its a lie. Bazaar will not find the sock that slipped behind your washing machine. The rest of it is true beyond a doubt.

What is DRCS all about?

Project management used to be highly centralized. People working together on a project would meet together in one place, work together on a project and release their work. If you didn't work in the same place, you were an outsider that at best could send in patches.

To say that the world has changed since the internet became ubiquitous is an understatement. Developers for free software projects are spread throughout the world. Wouldn't it make sense if our development tools worked the same way that we do?

How is a branch different from a CVS repository?

The purpose of decentralized revision control systems is to break the chain between the developer and the server. This is done by moving the RCS data from the central server down to the developer. This is done by making a Bzr branch something that is like both a repository and a working tree.

Logically combining the RCS data with the working tree means that when you branch from somebody else, you end up with a repository of your own. That means you can commit in your branch without needing to ask for permission from the person you branched from. Its almost as if you copied their CVS repository and made a CVS repository of your own.

How do repositories fit into the Bazaar model?

The catch to keeping RCS data and working trees logically related is that each time you make a branch, you copy a lot of RCS data. Some revision control systems, such as Bazaar, allow one to create a shared repository. A shared respository allows the user to store the RCS data for several branches in one place. That way, the RCS data common to several branches is only represented once on the filesystem.

How does merging work between branches?

Section 2 - Common CVS behaviours translated into Bazaar

This section explains how to perform common CVS behaviours in a Bazaar world. Unfortunately, this means that I won't be able to teach you many of the things that are unique to decentralized revision control systems.

This section covers how to use Bazaar in checkout mode. Reading section 3, which covers standard Bazaar methods, is highly encouraged.

Getting a checkout

In the CVS world, somebody has already setup a CVS repository and has told you to perform some rather arcane instructions on how to get a "checkout". Usually the instructions look something like:

 $ export CVSROOT=""
 $ cvs login
 $ cvs checkout codebase

In the Bazaar world, this is usually done with:

 $ bzr checkout

Updating a checkout

In the CVS world you may have done a checkout. From time to time you have to get new changes from the repository and apply them to your checkout. This usually looks something like this:

 $ cd codebase/
 $ cvs update

This looks very similiar in the Bazaar world:

 $ cd codebase/
 $ bzr update

In both the CVS and Bazaar case this will mean that the changes in the repository or branch that you do not yet have in the working tree will be applied. You might have to deal with conflicts.

Seeing how a working tree has changed since the last commit

In the CVS world we often want to check how we have changed things since we last committed. By checking how the code base has changed, we can see what we're about to commit before we actually perform the commit.

In the CVS world, we would check the changes this way:

 $ cvs -n update
 [see a list of files that have changed, or that need to be updated]
 $ cvs diff
 [see a diff of how files have changed]

This is very similar in Bazaar:

 $ bzr status
 [see a list of files that have changed]
 $ bzr missing
 [see a list of new revisions in the parent branch]
 $ bzr diff
 [see a diff of how files have changed]

In both of these cases, you'll get a diff that you can review prior to commit.

(cvs also has a status command, but it's less useful and rarely used.)

Comitting code in a checkout

In the CVS world you may have made changes to your checkout that need to be saved in the repository. One typically does so in this way:

 $ cvs commit -m'some description of whats being committed.'

Again, this looks very similiar in the Bazaar world:

 $ bzr commit -m'some description of whats being committed.'

In both of these cases, the new changes will be saved to either the repository (CVS) or branch (Bazaar).

Section 2 - Using Branches to perform CVS migration

Bazaar supports a variety of other development methodologies that are foreign to CVS developers. These methodologies typically work much better than the CVS method. They are, however, a bit different from the CVS way.

Section 3 - Development methodologies

Loose Cannon Style

General Rules

  • Each developer makes and maintains their own branches.
  • Developers merge each other ad-hoc
  • No coordination of merges between branches


  • Everyone gets their own itches scratched
  • Developers do not need to like each other
  • Highly competitive environment.


  • Branches will become highly diverged.
  • Users will be confused about which branches to follow
  • Branches will likely diverge into different projects

Shared Branch Style

General Rules

  • There is one proto-branch that all developers can push to and from
  • Developers may have local branches that individual features are worked on and then merged into the proto-branch


  • The branch for users to follow is clear and obvious
  • Development is not held up if one developer goes on vacation


  • Developers can put code into the proto-branch without test cases being run.
  • Contention for pushing into the proto-branch may become an issue if there is a large number of commit-happy developers.

The Lieutenant Style

General Rules

  • Needs to be combined with another style of development
  • Each developer is responsible for a section of the codebase
  • Developer collects merges and patches for their section of the codebase and puts it into a special branch


  • Developers can specialize on a particular type of code
  • Code is more likely to become peer reviewed


  • Coordination for code that needs the involvement between two or more Lieutenants becomes a bit more complicated
  • Development rate is slowed down a little.

The Patch Queue Manager Style

General Rules

  • Each developer makes their own branches
  • The merge requests are submitted via email to a bot
  • The bot merges the developers' changes into the proto-branch


  • Development is well coordinated
  • Tests can be run automatically.
  • Contention is reduced as changes are merged and not pushed


  • Depends upon a server that can accept mail and expose a branch publically
  • Can fall down under high loads
  • Is not well documented