Bazaar-NG

Bazaar-NG (bzr) is a project of Canonical Ltd to develop an open source distributed version control system that is powerful, friendly, and scalable. The project is at an early stage of development.

Note: These documents describe the initial design and are out of date in parts. For more up-to-date information see the wiki at http://bazaar.canonical.com/

For more information, see the homepage at http://bazaar-ng.org/

User documentation

Project overview/introduction
Command reference -- intended to be user documentation, and gives the best overview at the moment of what the system will feel like to use. Fairly complete.

Requirements and general design

Various purposes of a VCS -- taking snapshots and helping with merges is not the whole story.
Requirements
Costs of various factors: time, disk, network, etc.
Deadly sins that gcc maintainers suggest we avoid.
Overview of the whole design and miscellaneous small design points.
File formats
Random observations that don't fit anywhere else yet.

Design of particular features

Automatic generation of ChangeLogs
Cherry picking -- merge just selected non-contiguous changes from a branch.
Common changeset format for interchange format between VCS.
Compression of file text for more efficient storage.
Config specs assemble a tree from several places.
Conflicts that can occur during merge-like operations.
Ignored files
Recovering from interrupted operations
Inventory command
Branch joins represent that all the changes from one branch are integrated into another.
Kill a version to fix a broken commit or wrong message, or to remove confidential information from the history.
Hash collisions and weaknesses, and the security implications thereof.
Layers within the design
Library interface for Python.
Merge
Mirroring
Optional edit command: sometimes people want to make the working copy read-only, or not present at all.
Partial commits
Patch pools to efficiently store related branches.
Revfiles store the text history of files.
Revfiles storing annotations
Revision syntax -- hello.c@12, etc.
Roll-up commits -- a single revision incorporates the changes from several others.
Scalability
Security
Shared branches maintained by more than one person
Supportability -- how to handle any bugs or problems in the field.
Place tags on revisions for easy reference
Detecting unchanged files
Merging previously-unrelated branches
Usability principles (very small at the moment)
use-cases.html
web-interface.html
workflow.html Modelling/controlling flow of patches.
yaml.html -- Discussion of using YAML as a storage or transmission format.

Comparisons to other systems

Taxonomy: basic questions a VCS must answer.
Bitkeeper, the proprietary system used by some kernel developers.
Aegis, a tool focussed on enforcing process and workflow.
Codeville has an intruiging but scarcely-documented merge algorithm.
CVSNT, with more Windows support and some merge enhancements.
OpenCM, another hash-based tool with a good whitepaper.
PRCS, a non-distributed inventory-based tool.
GNU Arch, with many pros and cons.
Darcs, a merge-focussed tool with good usability.
Quilt -- Andrew Morton's patch scripts, popular with kernel maintainers.
Monotone, Graydon Hoare's hash-based distributed system.
SVK -- distributed operation stacked on Subversion.
Sun Teamware

Project management and organization

Notes on how to get a VCS adopted
Thanks to various people
Extra commands for internal/developer/debugger use.
Choice of Python as a development language