6
by mbp at sourcefrog
import all docs from arch |
1 |
Bazaar-NG |
2 |
********* |
|
3 |
||
4 |
.. These documents are formatted as ReStructuredText. You can .. |
|
5 |
.. convert them to HTML, PDF, etc using the ``python-docutils`` .. |
|
6 |
.. package. .. |
|
7 |
||
8 |
||
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 |
|
12 |
development. |
|
13 |
||
14 |
__ http://canonical.com/ |
|
15 |
||
16 |
||
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>. |
|
20 |
||
21 |
||
39
by Martin Pool
make doc index consistent with new web page |
22 |
For more information, see the homepage at http://bazaar-ng.org/ |
6
by mbp at sourcefrog
import all docs from arch |
23 |
|
24 |
||
25 |
||
26 |
User documentation |
|
27 |
------------------ |
|
28 |
||
29 |
* `Project overview/introduction <intro.html>`__ |
|
30 |
||
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. |
|
34 |
||
35 |
* `Quick reference <quickref.html>`__ -- single page description of |
|
36 |
how to use, intended to check it's adequately simple. Incomplete. |
|
37 |
||
38 |
* `FAQ <faq.html>`__ -- mostly user-oriented FAQ. |
|
39 |
||
40 |
||
41 |
Requirements and general design |
|
42 |
------------------------------- |
|
43 |
||
44 |
* `Various purposes of a VCS <purpose.html>`__ -- taking snapshots and |
|
45 |
helping with merges is not the whole story. |
|
46 |
||
47 |
* `Requirements <requirements.html>`__ |
|
48 |
||
49 |
* `Costs <costs.html>`__ of various factors: time, disk, network, etc. |
|
50 |
||
51 |
* `Deadly sins <deadly-sins.html>`__ that gcc maintainers suggest we avoid. |
|
52 |
||
53 |
* `Overview of the whole design <design.html>`__ and miscellaneous |
|
54 |
small design points. |
|
55 |
||
56 |
* `File formats <formats.html>`__ |
|
57 |
||
58 |
* `Random observations <random.html>`__ that don't fit anywhere else yet. |
|
59 |
||
60 |
||
61 |
||
62 |
Design of particular features |
|
63 |
----------------------------- |
|
64 |
||
65 |
* `Automatic generation of ChangeLogs <changelogs.html>`__ |
|
66 |
||
67 |
* `Cherry picking <cherry-picking.html>`__ -- merge just selected non-contiguous changes from a branch. |
|
68 |
||
69 |
* `Common changeset format <common-format.html>`__ for interchange |
|
70 |
format between VCS. |
|
71 |
||
72 |
* `Compression <compression.html>`__ of file text for more efficient storage. |
|
73 |
||
74 |
* `Config specs <config-specs.html>`__ assemble a tree from several places. |
|
75 |
||
76 |
* `Conflicts <conflicts.html>`_ that can occur during merge-like operations. |
|
77 |
||
78 |
* `Recovering from interrupted operations <interrupted.html>`__ |
|
79 |
||
80 |
* `Inventory command <inventory.html>`__ |
|
81 |
||
82 |
* `Branch joins <join-branches.html>`__ represent that all the changes |
|
83 |
from one branch are integrated into another. |
|
84 |
||
85 |
* `Kill a version <kill-version.html>`__ to fix a broken commit or |
|
86 |
wrong message, or to |
|
87 |
remove confidential information from the history. |
|
88 |
||
89 |
* `Hash collisions <hashes.html>`__ and weaknesses, and the security |
|
90 |
implications thereof. |
|
91 |
||
92 |
* `Layers <layers.html>`__ within the design |
|
93 |
||
94 |
* `Library interface <library-interface.html>`__ for Python. |
|
95 |
||
96 |
* `Merge <merge.html>`__ |
|
97 |
||
98 |
* `Mirroring <mirroring.html>`__ |
|
99 |
||
100 |
* `Optional edit command <optional-edit.html>`__: sometimes people |
|
101 |
want to make the working copy read-only, or not present at all. |
|
102 |
||
103 |
* `Partial commits <partial-commit.html>`__ |
|
104 |
||
105 |
* `Patch pools <pool.html>`__ to efficiently store related branches. |
|
106 |
||
107 |
* `Revision syntax <revision-syntax.html>`__ -- ``hello.c@12``, etc. |
|
108 |
||
109 |
* `Roll-up commits <rollup.html>`__ -- a single revision incorporates |
|
110 |
the changes from several others. |
|
111 |
||
112 |
* `Scalability <scalability.html>`__ |
|
113 |
||
114 |
* `Security <security.html>`__ |
|
115 |
||
116 |
* `Shared branches <shared-branches.html>`__ maintained by more than |
|
117 |
one person |
|
118 |
||
119 |
* `Supportability <supportability.html>`__ -- how to handle any bugs |
|
120 |
or problems in the field. |
|
121 |
||
122 |
* `Place tags on revisions for easy reference <tagging.html>`__ |
|
123 |
||
124 |
* `Detecting unchanged files <unchanged.html>`__ |
|
125 |
||
126 |
* `Merging previously-unrelated branches <unrelated-merge.html>`__ |
|
127 |
||
128 |
* `Usability principles <usability.html>`__ (very small at the moment) |
|
129 |
||
130 |
* `<use-cases.html>`__ |
|
131 |
||
132 |
* `<web-interface.html>`__ |
|
133 |
||
134 |
* `<workflow.html>`__ Modelling/controlling flow of patches. |
|
135 |
||
136 |
* `<yaml.html>`__ -- Discussion of using YAML_ as a storage or transmission format. |
|
137 |
||
138 |
.. _YAML: http://www.yaml.org/ |
|
139 |
||
140 |
||
141 |
||
142 |
Comparisons to other systems |
|
143 |
---------------------------- |
|
144 |
||
145 |
* `Taxonomy <taxonomy.html>`__: basic questions a VCS must answer. |
|
146 |
||
147 |
* `Bitkeeper <bitkeeper.html>`__, the proprietary system used by some |
|
148 |
kernel developers. |
|
149 |
||
150 |
* `Aegis <compared-aegis.html>`__, a tool focussed on enforcing |
|
151 |
process and workflow. |
|
152 |
||
153 |
* `Codeville <compared-codeville.html>`__ has an intruiging but |
|
154 |
scarcely-documented merge algorithm. |
|
155 |
||
156 |
* `CVSNT <compared-cvsnt.html>`__, with more Windows support and some |
|
157 |
merge enhancements. |
|
158 |
||
159 |
* `OpenCM <compared-opencm.html>`__, another hash-based tool with a |
|
160 |
good whitepaper. |
|
161 |
||
162 |
* `PRCS <compared-prcs.html>`__, a non-distributed inventory-based tool. |
|
163 |
||
164 |
* `GNU Arch <todo-from-arch.html>`__, with many pros and cons. |
|
165 |
||
166 |
* `Darcs <darcs.html>`__, a merge-focussed tool with good usability. |
|
167 |
||
168 |
* `Quilt <quilt.html>`__ -- Andrew Morton's patch scripts, popular with kernel maintainers. |
|
169 |
||
170 |
* `Monotone <monotone.html>`__, Graydon Hoare's hash-based distributed system. |
|
171 |
||
172 |
* `SVK <svk.html>`__ -- distributed operation stacked on Subversion. |
|
173 |
||
174 |
* `Sun Teamware <compared-teamware.html>`__ |
|
175 |
||
176 |
||
177 |
Project management and organization |
|
178 |
----------------------------------- |
|
179 |
||
180 |
* `Development news <news.html>`__ |
|
181 |
||
182 |
* `Notes on how to get a VCS adopted <adoption.html>`__ |
|
183 |
||
184 |
* `Testing plan <testing.html>`__ -- very sketchy. |
|
185 |
||
186 |
* `Thanks <thanks.html>`__ to various people |
|
187 |
||
188 |
* `Roadmap <roadmap.html>`__: High-level order for implementing features. |
|
189 |
||
190 |
* `<work-order.html>`__: current tasks. |
|
191 |
||
192 |
* `Extra commands <extra-commands.html>`__ for |
|
193 |
internal/developer/debugger use. |
|
194 |
||
195 |
* `Choice of Python as a development language <python.html>`__ |