de-centralised version control with bazaar
DESCRIPTION
This was the presentation I gave on Bazaar version control at Yahoo!'s internal front-end engineering summitTRANSCRIPT
Bazaar Version ControlStuart Colville and Andrew Phillipo
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 baseX
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 - SubversionProject 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 BazaarEasy 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://[email protected]/~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://[email protected]/~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/