~bzr-pqm/bzr/bzr.dev

Introduction to Bazaar

======================

Bazaar's goal is *to make a distributed version control system that

open source developers will love to use*.  Using Bazaar should feel

good.

.. epigraph::

  Language designers want to design the perfect language. They want to

  be able to say, "My language is perfect. It can do everything." But

  it's just plain impossible to design a perfect language, because

  there are two ways to look at a language. One way is by looking at

  what can be done with that language. The other is by looking at how

  we feel using that language -- how we feel while programming.

  Because of the Turing completeness theory, everything one

  Turing-complete language can do can theoretically be done by another

  Turing-complete language, but at a different cost. You can do

  everything in assembler, but no one wants to program in assembler

  anymore. From the viewpoint of what you can do, therefore, languages

  do differ -- but the differences are limited. For example, Python

  and Ruby provide almost the same power to the programmer.

  Instead of emphasizing the what, I want to emphasize the how part: how

  we feel while programming.

  -- `Yukihiro Matsumoto`__

__ http://www.artima.com/intv/ruby.html

Bazaar tries to make simple things simple, and complex things

possible.  In particular:

 * Distributed operation is easy: you can work while disconnected; you

   can fork any other project; you can contribute changes back

   easily.  

 * The system is designed to scale to supporting very large trees with

   a lot of history.  No operations require downloading the entire

   history of the project.

 * Changes can be "cherry-picked" out of branches as needed.   Because

   of dependencies between 

History-sensitive merging

=========================

Baz keeps track of what changes have been merged into a branch.  You

can repeatedly merge from one branch into another and Baz will pull

across only the new changes since you last merged.

Speed

=====

For most users, the most important factor for performance is to avoid

unnecessary network round trips.  Baz tries hard to avoid ever

downloading the same data twice.  

Remote archives are automatically cached on your local machine by

default.  If you have ever accessed a remote revision you should be

able to get it again without going to the network.  The cache policy

may be tuned.

Code history

============

One important function of a revision control system is to maintain a

record of when, why, how and by whom changes were made. 

Baz requires that branches and archives be named.

Unlike most other systems, Baz keeps a record for each changeset of

which branches and archives it passed through on its way to its

eventual destination.  This allows people to go back later and see the

context in which the patch was written or merged.

Scalability

===========

We regularly test Baz on projects with tens of thousands of commits,

and tens of thousands of files.

Merging

=======

The basic method of integration is a three-way merge.  Baz selects an

appropriate basis version

File renaming

=============

Baz allows files and directories to be renamed in a project.  Unlike

Subversion, Baz will correctly merge changes spanning file renames.

This is done by automatically assigning a unique ID to each file,

which is persistent across renames.