← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/intro.txt

  • Committer: Martin Pool
  • Date: 2005-08-30 04:47:42 UTC
  • Revision ID: mbp@sourcefrog.net-20050830044742-0437d5b674f9ccaf
- change conflict markers to suit smerge, etc

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/intro.txt
 
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