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.
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:
209
1. ``bzrlib/bzrdir.py`` to register the WT/Branch/Repository
212
2. ``bzrlib/workingtree.py``, ``bzrlib/branch.py``,
213
``bzrlib/repository.py``, each one maintains a direct list of
214
their respective formats.
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.
220
4. For repositories based on KnitPackRepository, you need to update
221
``bzrlib/tests/test_pack_repository.py`` to add the class to the
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
229
Currently an alias for Development0
247
Currently an alias for Development2
231
249
development-subtree
232
250
-------------------
234
Currently an alias for Development0Subtree
252
Currently an alias for Development2Subtree
236
Development0[Subtree]
254
Development2[Subtree]
237
255
---------------------
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
257
These formats use B+Tree indices which are considerably faster than
258
the earlier indices in bzr.
added
removed
doc/developers/development-repo.txt
