~bzr-pqm/bzr/bzr.dev : contents of doc/intro.txt at revision 496

~bzr-pqm/bzr/bzr.dev : (revision 496)

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.



6 by mbp at sourcefrog import all docs from arch	1	Introduction to Bazaar
	2	======================
	3
	4	Bazaar's goal is *to make a distributed version control system that
	5	open source developers will love to use*. Using Bazaar should feel
	6	good.
	7
	8	.. epigraph::
	9
	10	Language designers want to design the perfect language. They want to
	11	be able to say, "My language is perfect. It can do everything." But
	12	it's just plain impossible to design a perfect language, because
	13	there are two ways to look at a language. One way is by looking at
	14	what can be done with that language. The other is by looking at how
	15	we feel using that language -- how we feel while programming.
	16
	17	Because of the Turing completeness theory, everything one
	18	Turing-complete language can do can theoretically be done by another
	19	Turing-complete language, but at a different cost. You can do
	20	everything in assembler, but no one wants to program in assembler
	21	anymore. From the viewpoint of what you can do, therefore, languages
	22	do differ -- but the differences are limited. For example, Python
	23	and Ruby provide almost the same power to the programmer.
	24
	25	Instead of emphasizing the what, I want to emphasize the how part: how
	26	we feel while programming.
	27
	28	-- `Yukihiro Matsumoto`__
	29
	30	__ http://www.artima.com/intv/ruby.html
	31
	32	Bazaar tries to make simple things simple, and complex things
	33	possible. In particular:
	34
	35	* Distributed operation is easy: you can work while disconnected; you
	36	can fork any other project; you can contribute changes back
	37	easily.
	38
	39	* The system is designed to scale to supporting very large trees with
	40	a lot of history. No operations require downloading the entire
	41	history of the project.
	42
	43	* Changes can be "cherry-picked" out of branches as needed. Because
	44	of dependencies between
	45
	46
	47
	48	History-sensitive merging
	49	=========================
	50
	51	Baz keeps track of what changes have been merged into a branch. You
	52	can repeatedly merge from one branch into another and Baz will pull
	53	across only the new changes since you last merged.
	54
	55
	56	Speed
	57	=====
	58
	59	For most users, the most important factor for performance is to avoid
	60	unnecessary network round trips. Baz tries hard to avoid ever
	61	downloading the same data twice.
	62
	63	Remote archives are automatically cached on your local machine by
	64	default. If you have ever accessed a remote revision you should be
65	able to get it again without going to the network. The cache policy
66	may be tuned.
67
68
69
70	Code history
71	============
72
73	One important function of a revision control system is to maintain a
74	record of when, why, how and by whom changes were made.
75
76	Baz requires that branches and archives be named.
77
78	Unlike most other systems, Baz keeps a record for each changeset of
79	which branches and archives it passed through on its way to its
80	eventual destination. This allows people to go back later and see the
81	context in which the patch was written or merged.
82
83
84
85	Scalability
86	===========
87
88	We regularly test Baz on projects with tens of thousands of commits,
89	and tens of thousands of files.
90
91
92
93	Merging
94	=======
95
96	The basic method of integration is a three-way merge. Baz selects an
97	appropriate basis version
98
99
100
101	File renaming
102	=============
103
104	Baz allows files and directories to be renamed in a project. Unlike
105	Subversion, Baz will correctly merge changes spanning file renames.
106	This is done by automatically assigning a unique ID to each file,
107	which is persistent across renames.
108
109