Bazaar Version Control
Stuart Colville and Andrew Phillipo

X
Version Control Software
A way to keep a multiple revisions of a single
resource without creating copies
Undo either short or long term
Audit-trail of who did what and when
Access to details of why a change was made
Tools to help teams of developers work on a single
code base

History of Version Control Systems
“Those who cannot remember the past are
condemned to repeat it.” - George Santanya

SCCS - Source Code Control System
The first Version Control System, built during the
70s
Was dominant until RCS was released
SCCS had no concept of branching
Internal file format is still used today by Bitkeeper
and TeamWare
Tools still available to access the SCCS format

RCS - Revision Control System
Built During the 80s as “a better SCCS”
Only knows about revisions of single files
Supports branching, badly
“RCS automates the storing, retrieval, logging,
identification, and merging of revisions.”
- GNU RCS homepage

CVS - Concurrent Versioning System
Originally based upon RCS (for managing sets of files/projects) in
the late 80s, by Dick Grune and later rewritten by Brian Berliner
Only files are versioned, no symlinks or directories
No direct moving/renaming capability
Branching and merging can be a world of pain
Allows control over who can commit
Stable, well supported infrastructure and tools

HTTP://FLICKR.COM/PHOTOS/EECUE/91518838/

SVN - Subversion
Project start by collab.net in 2000
Built to improve on CVS
Atomic commits
Allows renaming/moving of assets
Language bindings for all common programming
languages

What do you look for in a
revision control system?
Stability
Easy to use
Doesn’t get in the way of me developing my stuff
Flexibility
Extensible

Introduction to Bazaar
Easy to branch and smarter merging
First-class renaming capabilities
No server software needed - “Batteries included”
Designed with usability, ease of use in mind
Cross platform: Linux, BSD, OSX, Windows
Flexible and extensible, with a full plug-in system

BAZAAR DOESN’T
GET IN THE WAY

Bazaar Workflows

Workflows: Solo
As simple as pick a directory and tell bazaar to
start versioning it
No server/database setup
Sharing with other developers is easy, should it be
needed
Let’s look at an example...

Set-up a versioned dir
$ cd ~/bazaar/demo
$ bzr init
~/bazaar/demo is now set-up to be
versioned

Let’s add a file
$ vim test.css
$ bzr add

Let’s add a file
$ vim test.css
$ bzr add
added test.css

First commit
$ bzr commit -m “my first
commit”

First commit
$ bzr commit -m “my first
commit”
added test.css
Committed revision 1.

Workflows: Partner

Workflows: Centralised

Workflows: Local Commit

Workflows: Shared

Workflows: Gatekeeper

Workflows: PQM

Why use Distributed VCS in tandem
with Centralised Version Control?
Company policy requires the use of a centralised
system
Development with centralised VCS is harder
A modern VCS brings more advanced merging
Reduction in developer suicide rate

Using Distributed VCS in tandem
with Centralised Version Control
Keeping history:
Tailor is a tool that can convert between many
different rcs http://progetti.arstecnica.it/tailor
CVSPSImport converts directly from CVS
http://bazaar-vcs.org/CVSPSImport
Ignore history and take current set of files
Faster but obviously you lose access to older
history

Launchpad.net
Similar to sourceforge with 100% less CVS
Tightly integrated with Bazaar - though import
from other VCS is possible
Removes the barriers to contributing open-
source development
Bug tracking, FAQ, Documentation and
translation management

Launchpad Example
Bazaar-email is a simple plug-in that uses the
post-commit hooks in bazaar to mail diffs
To contribute back to the project I raised bugs
for trivial issues found using the plug-in
A developer fixed one of these issues and
submitted a branch linked to the bug
To add this to trunk the maintainer can simply
carry out a merge

Launchpad Bug fix process
Branch the trunk/main branch
Make + test the fix
Push the fix back to launchpad and associate it
with the bug number
bzr push sftp://user@bazaar.launchpad.net/~user/project/branch
The maintainer can then merge the fix into the
trunk

Adding a feature to a project
Branch the trunk/main branch
Merged pending bugfixes
Develop the feature
Push to launchpad
bzr push sftp://user@bazaar.launchpad.net/~user/project/branch
Raise merge request

Let’s hack on something

Conclusion
Version control has come a long way
De-centralisation is the future!
First-class merging makes this all possible
Development should never be constrained by
the version control system you use

Questions?
That’s all folks!
http://bazaar-vcs.org/