~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/index.txt

  • Committer: mbp at sourcefrog
  • Date: 2005-03-09 04:51:05 UTC
  • Revision ID: mbp@sourcefrog.net-20050309045105-d02cd410a115da2c
import all docs from arch

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
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
 
 
22
Summary status
 
23
--------------
 
24
 
 
25
(as of 2005-02-23)
 
26
 
 
27
* Bazaar-NG can track the history of a single local branch, similar to
 
28
  RCS.  The storage format should be reasonably close to what will be
 
29
  used for 1.0.
 
30
 
 
31
* The following commands work: ``add``, ``remove``, ``commit``,
 
32
  ``log``, ``diff`` (whole tree against basis revision), ``status``, ``help``,
 
33
  ``export`` (any revision).
 
34
 
 
35
* Subdirectories and files within them are now supported.
 
36
 
 
37
 
 
38
 
 
39
User documentation
 
40
------------------
 
41
 
 
42
* `Project overview/introduction <intro.html>`__
 
43
 
 
44
* `Command reference <cmdref.html>`__ -- intended to be user
 
45
  documentation, and gives the best overview at the moment of what the
 
46
  system will feel like to use.  Fairly complete.
 
47
 
 
48
* `Quick reference <quickref.html>`__ -- single page description of
 
49
  how to use, intended to check it's adequately simple.  Incomplete.
 
50
 
 
51
* `FAQ <faq.html>`__ -- mostly user-oriented FAQ.
 
52
 
 
53
* `Demonstration/tutorial <short-demo.html>`__
 
54
 
 
55
 
 
56
Requirements and general design
 
57
-------------------------------
 
58
 
 
59
* `Various purposes of a VCS <purpose.html>`__ -- taking snapshots and
 
60
  helping with merges is not the whole story.
 
61
 
 
62
* `Requirements <requirements.html>`__
 
63
 
 
64
* `Costs <costs.html>`__ of various factors: time, disk, network, etc.
 
65
 
 
66
* `Deadly sins <deadly-sins.html>`__ that gcc maintainers suggest we avoid.
 
67
 
 
68
* `Overview of the whole design <design.html>`__ and miscellaneous
 
69
  small design points.
 
70
 
 
71
* `File formats <formats.html>`__
 
72
 
 
73
* `Random observations <random.html>`__ that don't fit anywhere else yet.
 
74
 
 
75
 
 
76
 
 
77
Design of particular features
 
78
-----------------------------
 
79
 
 
80
* `Automatic generation of ChangeLogs <changelogs.html>`__
 
81
 
 
82
* `Cherry picking <cherry-picking.html>`__ -- merge just selected non-contiguous changes  from a branch.
 
83
 
 
84
* `Common changeset format <common-format.html>`__ for  interchange
 
85
  format between VCS.
 
86
 
 
87
* `Compression <compression.html>`__ of file text for more efficient storage.
 
88
 
 
89
* `Config specs <config-specs.html>`__ assemble a tree from several places.
 
90
 
 
91
* `Conflicts <conflicts.html>`_ that can occur during merge-like operations.
 
92
 
 
93
* `Recovering from interrupted operations <interrupted.html>`__
 
94
 
 
95
* `Inventory command <inventory.html>`__
 
96
 
 
97
* `Branch joins <join-branches.html>`__ represent that all the changes
 
98
  from one branch are integrated into another.
 
99
 
 
100
* `Kill a version <kill-version.html>`__ to fix a broken commit or
 
101
  wrong message, or to
 
102
  remove confidential information from the history.
 
103
 
 
104
* `Hash collisions <hashes.html>`__ and weaknesses, and the security
 
105
  implications thereof.
 
106
 
 
107
* `Layers <layers.html>`__ within the design
 
108
 
 
109
* `Library interface <library-interface.html>`__ for Python.
 
110
 
 
111
* `Merge <merge.html>`__
 
112
 
 
113
* `Mirroring <mirroring.html>`__
 
114
 
 
115
* `Optional edit command <optional-edit.html>`__: sometimes people
 
116
  want to make the  working copy read-only, or not present at all.
 
117
 
 
118
* `Partial commits <partial-commit.html>`__
 
119
 
 
120
* `Patch pools <pool.html>`__ to efficiently store related branches.
 
121
 
 
122
* `Revision syntax <revision-syntax.html>`__ -- ``hello.c@12``, etc.
 
123
 
 
124
* `Roll-up commits <rollup.html>`__ -- a single revision incorporates
 
125
  the changes from several others.
 
126
 
 
127
* `Scalability <scalability.html>`__
 
128
 
 
129
* `Security <security.html>`__
 
130
 
 
131
* `Shared branches <shared-branches.html>`__ maintained by more than
 
132
  one person
 
133
 
 
134
* `Supportability <supportability.html>`__ -- how to handle any bugs
 
135
  or problems in the field.
 
136
 
 
137
* `Place tags on revisions for easy reference <tagging.html>`__
 
138
 
 
139
* `Detecting unchanged files <unchanged.html>`__
 
140
   
 
141
* `Merging previously-unrelated branches <unrelated-merge.html>`__
 
142
 
 
143
* `Usability principles <usability.html>`__ (very small at the moment)
 
144
 
 
145
* `<use-cases.html>`__
 
146
 
 
147
* `<web-interface.html>`__
 
148
 
 
149
* `<workflow.html>`__ Modelling/controlling flow of patches.
 
150
 
 
151
* `<yaml.html>`__ --  Discussion of using YAML_ as a storage or transmission format.
 
152
 
 
153
.. _YAML: http://www.yaml.org/
 
154
 
 
155
 
 
156
 
 
157
Comparisons to other systems
 
158
----------------------------
 
159
 
 
160
* `Taxonomy <taxonomy.html>`__: basic questions a VCS must answer.
 
161
 
 
162
* `Bitkeeper <bitkeeper.html>`__, the proprietary system used by some
 
163
  kernel developers.
 
164
 
 
165
* `Aegis <compared-aegis.html>`__, a tool focussed on enforcing
 
166
  process and workflow.
 
167
 
 
168
* `Codeville <compared-codeville.html>`__ has an intruiging but
 
169
  scarcely-documented merge algorithm.
 
170
 
 
171
* `CVSNT <compared-cvsnt.html>`__, with more Windows support and some
 
172
  merge enhancements.
 
173
 
 
174
* `OpenCM <compared-opencm.html>`__, another hash-based tool with a
 
175
  good whitepaper.
 
176
 
 
177
* `PRCS <compared-prcs.html>`__, a non-distributed inventory-based tool.
 
178
 
 
179
* `GNU Arch <todo-from-arch.html>`__, with many pros and cons.
 
180
 
 
181
* `Darcs <darcs.html>`__, a merge-focussed tool with good usability.
 
182
 
 
183
* `Quilt <quilt.html>`__ -- Andrew Morton's patch scripts, popular with kernel maintainers.
 
184
 
 
185
* `Monotone <monotone.html>`__, Graydon Hoare's hash-based distributed system.
 
186
 
 
187
* `SVK <svk.html>`__ --     distributed operation stacked on Subversion.
 
188
 
 
189
* `Sun Teamware <compared-teamware.html>`__
 
190
 
 
191
 
 
192
Project management and organization
 
193
-----------------------------------
 
194
 
 
195
* `Development news <news.html>`__
 
196
 
 
197
* `Notes on how to get a VCS adopted <adoption.html>`__
 
198
 
 
199
* `Testing plan <testing.html>`__ -- very sketchy.
 
200
 
 
201
* `Thanks <thanks.html>`__ to various people
 
202
 
 
203
* `Roadmap <roadmap.html>`__: High-level order for implementing features.
 
204
 
 
205
* `<work-order.html>`__: current tasks.
 
206
 
 
207
* `Extra commands <extra-commands.html>`__ for
 
208
  internal/developer/debugger use.
 
209
 
 
210
* `Choice of Python as a development language <python.html>`__
 
211
 
 
212
 
 
213
Download
 
214
--------
 
215
 
 
216
There are no releases yet.
 
217
 
 
218
The Bazaar-NG development code may be downloaded using GNU Arch by the
 
219
following steps::
 
220
 
 
221
   tla register-archive http://sourcefrog.net/arch/mbp@sourcefrog.net--2004
 
222
   tla get mbp@sourcefrog.net--2004/bazaar-ng--0  bazaar-ng
 
223
 
 
224
(By contrast, when Bazaar-NG network operations are complete, a single
 
225
much shorter command will do.)
 
226
 
 
227
Note that the current code is under heavy development and so is not
 
228
guaranteed to do anything useful whatsoever.
 
229