4
..   These documents are formatted as ReStructuredText.  You can    ..
 
 
5
..   convert them to HTML, PDF, etc using the ``python-docutils``   ..
 
 
9
*Bazaar-NG* (``bzr``) is a project of `Canonical Ltd`__ to develop an
 
 
10
open source distributed version control system that is powerful,
 
 
11
friendly, and scalable.  The project is at an early stage of
 
 
14
__ http://canonical.com/
 
 
17
**Note:** These documents are in a very preliminary state, and so may
 
 
18
be internally or externally inconsistent or redundant.  Comments are
 
 
19
still very welcome.  Please send them to <mbp@sourcefrog.net>.
 
 
22
For more information, see the homepage at http://bazaar-ng.org/
 
 
29
* `Project overview/introduction <intro.html>`__
 
 
31
* `Command reference <cmdref.html>`__ -- intended to be user
 
 
32
  documentation, and gives the best overview at the moment of what the
 
 
33
  system will feel like to use.  Fairly complete.
 
 
36
Requirements and general design
 
 
37
-------------------------------
 
 
39
* `Various purposes of a VCS <purpose.html>`__ -- taking snapshots and
 
 
40
  helping with merges is not the whole story.
 
 
42
* `Requirements <requirements.html>`__
 
 
44
* `Costs <costs.html>`__ of various factors: time, disk, network, etc.
 
 
46
* `Deadly sins <deadly-sins.html>`__ that gcc maintainers suggest we avoid.
 
 
48
* `Overview of the whole design <design.html>`__ and miscellaneous
 
 
51
* `File formats <formats.html>`__
 
 
53
* `Random observations <random.html>`__ that don't fit anywhere else yet.
 
 
57
Design of particular features
 
 
58
-----------------------------
 
 
60
* `Automatic generation of ChangeLogs <changelogs.html>`__
 
 
62
* `Cherry picking <cherry-picking.html>`__ -- merge just selected non-contiguous changes  from a branch.
 
 
64
* `Common changeset format <common-format.html>`__ for  interchange
 
 
67
* `Compression <compression.html>`__ of file text for more efficient storage.
 
 
69
* `Config specs <config-specs.html>`__ assemble a tree from several places.
 
 
71
* `Conflicts <conflicts.html>`_ that can occur during merge-like
 
 
74
* `Ignored files <ignore.html>`__
 
 
76
* `Recovering from interrupted operations <interrupted.html>`__
 
 
78
* `Inventory command <inventory.html>`__
 
 
80
* `Branch joins <join-branches.html>`__ represent that all the changes
 
 
81
  from one branch are integrated into another.
 
 
83
* `Kill a version <kill-version.html>`__ to fix a broken commit or
 
 
85
  remove confidential information from the history.
 
 
87
* `Hash collisions <hashes.html>`__ and weaknesses, and the security
 
 
90
* `Layers <layers.html>`__ within the design
 
 
92
* `Library interface <library-interface.html>`__ for Python.
 
 
94
* `Merge <merge.html>`__
 
 
96
* `Mirroring <mirroring.html>`__
 
 
98
* `Optional edit command <optional-edit.html>`__: sometimes people
 
 
99
  want to make the  working copy read-only, or not present at all.
 
 
101
* `Partial commits <partial-commit.html>`__
 
 
103
* `Patch pools <pool.html>`__ to efficiently store related branches.
 
 
105
* `Revfiles <revfile.html>`__ store the text history of files.
 
 
107
* `Revfiles storing annotations <revfile-annotation.html>`__
 
 
109
* `Revision syntax <revision-syntax.html>`__ -- ``hello.c@12``, etc.
 
 
111
* `Roll-up commits <rollup.html>`__ -- a single revision incorporates
 
 
112
  the changes from several others.
 
 
114
* `Scalability <scalability.html>`__
 
 
116
* `Security <security.html>`__
 
 
118
* `Shared branches <shared-branches.html>`__ maintained by more than
 
 
121
* `Supportability <supportability.html>`__ -- how to handle any bugs
 
 
122
  or problems in the field.
 
 
124
* `Place tags on revisions for easy reference <tagging.html>`__
 
 
126
* `Detecting unchanged files <unchanged.html>`__
 
 
128
* `Merging previously-unrelated branches <unrelated-merge.html>`__
 
 
130
* `Usability principles <usability.html>`__ (very small at the moment)
 
 
132
* `<use-cases.html>`__
 
 
134
* `<web-interface.html>`__
 
 
136
* `<workflow.html>`__ Modelling/controlling flow of patches.
 
 
138
* `<yaml.html>`__ --  Discussion of using YAML_ as a storage or transmission format.
 
 
140
.. _YAML: http://www.yaml.org/
 
 
144
Comparisons to other systems
 
 
145
----------------------------
 
 
147
* `Taxonomy <taxonomy.html>`__: basic questions a VCS must answer.
 
 
149
* `Bitkeeper <bitkeeper.html>`__, the proprietary system used by some
 
 
152
* `Aegis <compared-aegis.html>`__, a tool focussed on enforcing
 
 
153
  process and workflow.
 
 
155
* `Codeville <compared-codeville.html>`__ has an intruiging but
 
 
156
  scarcely-documented merge algorithm.
 
 
158
* `CVSNT <compared-cvsnt.html>`__, with more Windows support and some
 
 
161
* `OpenCM <compared-opencm.html>`__, another hash-based tool with a
 
 
164
* `PRCS <compared-prcs.html>`__, a non-distributed inventory-based tool.
 
 
166
* `GNU Arch <todo-from-arch.html>`__, with many pros and cons.
 
 
168
* `Darcs <darcs.html>`__, a merge-focussed tool with good usability.
 
 
170
* `Quilt <quilt.html>`__ -- Andrew Morton's patch scripts, popular with kernel maintainers.
 
 
172
* `Monotone <monotone.html>`__, Graydon Hoare's hash-based distributed system.
 
 
174
* `SVK <svk.html>`__ --     distributed operation stacked on Subversion.
 
 
176
* `Sun Teamware <compared-teamware.html>`__
 
 
179
Project management and organization
 
 
180
-----------------------------------
 
 
182
* `Notes on how to get a VCS adopted <adoption.html>`__
 
 
184
* `Thanks <thanks.html>`__ to various people
 
 
186
* `Extra commands <extra-commands.html>`__ for
 
 
187
  internal/developer/debugger use.
 
 
189
* `Choice of Python as a development language <python.html>`__