← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/development-repo.txt

https://launchpad.net/bugs/524184
NEWS section template into a separate file

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/development-repo.txt
189
189
 
190
190
1. Register two new formats with the next available sequence number.
191
191
   e.g. ``development1`` and ``development1-subtree``. (You can see the
192
 
   ``development0`` format for an example.
 
192
   current development format for an example.
193
193
   These should:
194
194
 
195
195
   * Use your new development repository/branch/tree classes
203
203
   ``bzrlib.repofmt``. You probably want to reproduce the current
204
204
   development format from ``bzrlib.repofmt.pack_repo`` with just new
205
205
   disk format strings, ``_get_matching_bzrdir`` and help.
206
 
4. Alter any other things that do class based tests. The easiest way
 
206
4. Register your development format with the various registries. At the
 
207
   moment you need to update:
 
208
 
 
209
    1. ``bzrlib/bzrdir.py`` to register the WT/Branch/Repository
 
210
       collection.
 
211
 
 
212
    2. ``bzrlib/workingtree.py``, ``bzrlib/branch.py``,
 
213
       ``bzrlib/repository.py``, each one maintains a direct list of
 
214
       their respective formats.
 
215
 
 
216
    3. For repositories, you also need to update the InterKnit1and2
 
217
       class. This is responsible for converting between rich-root and
 
218
       non-rich-root repositories.
 
219
 
 
220
    4. For repositories based on KnitPackRepository, you need to update
 
221
       ``bzrlib/tests/test_pack_repository.py`` to add the class to the
 
222
       tested permutations.
 
223
 
 
224
5. Alter any other things that do class based tests. The easiest way
207
225
   to find these is a grep for Development in bzrlib - and please
208
226
   refactor as you find these to reduce the relevance this step has,
209
227
   as it should not need to exist.
210
 
5. Now subclass/create from scratch/whatever the live object code you
 
228
6. Now subclass/create from scratch/whatever the live object code you
211
229
   need to change to introduce your new format. Keep in mind that
212
230
   eventually it will become the default format, so please don't keep
213
231
   subclassing the last releases code, rather consider making the last
214
232
   releases code a subclass of your new code (if there is a lot in
215
233
   common) so that we can eventually remove that format once it becomes
216
234
   ancient (or relegate it to a plugin).
217
 
6. Once you have made the changes that required a new disk format, you
 
235
7. Once you have made the changes that required a new disk format, you
218
236
   should submit the resulting branch to be merged. Other changes - to
219
237
   take advantage of whatever new feature you have added - should be
220
238
   sent in separately, because the disk level changes are a contention
226
244
development
227
245
-----------
228
246
 
229
 
Currently an alias for Development0
 
247
Not currently available, as our development formats are all rich root or
 
248
subtrees now.
 
249
 
 
250
development-rich-root
 
251
---------------------
 
252
 
 
253
Currently an alias for Development6Subtree
230
254
 
231
255
development-subtree
232
256
-------------------
233
257
 
234
 
Currently an alias for Development0Subtree
235
 
 
236
 
Development0[Subtree]
237
 
---------------------
238
 
 
239
 
These formats exists solely to provide an actual new format for the
240
 
feature of 'development formats' to be introduced. They are regular
241
 
pack-0.92 style formats with no changes to the disk storage other than
242
 
the version marker.
 
258
Currently an alias for Development6Subtree
 
259
 
 
260
Development6RichRoot[Subtree]
 
261
-----------------------------
 
262
 
 
263
These formats use the new groupcompress delta compress and a CHK(Content
 
264
Hash Key) based inventory store which is much faster at incremental
 
265
operations than the prior XML based store.
 
266
*Note* Converting from a non-rich-root to a rich-root format is a
 
267
one-way upgrade, and you cannot merge back afterwards: using this format
 
268
for everyday use is likely to cause all developers of a project to
 
269
upgrade to a rich-root format themselves. This is fine, as bzr is moving
 
270
to make rich-root formats the default and to get all users to upgrade,
 
271
but we have not finalised the migration process, and until we do do not
 
272
recomment that casual users upgrade. Users of bzr-svn are already using
 
273
rich-root formats and can test with this with impunity.
243
274
 
244
275
 
245
276
..