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
current development format for an example.
192
``development0`` 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. 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
206
4. Alter any other things that do class based tests. The easiest way
225
207
to find these is a grep for Development in bzrlib - and please
226
208
refactor as you find these to reduce the relevance this step has,
227
209
as it should not need to exist.
228
6. Now subclass/create from scratch/whatever the live object code you
210
5. Now subclass/create from scratch/whatever the live object code you
229
211
need to change to introduce your new format. Keep in mind that
230
212
eventually it will become the default format, so please don't keep
231
213
subclassing the last releases code, rather consider making the last
232
214
releases code a subclass of your new code (if there is a lot in
233
215
common) so that we can eventually remove that format once it becomes
234
216
ancient (or relegate it to a plugin).
235
7. Once you have made the changes that required a new disk format, you
217
6. Once you have made the changes that required a new disk format, you
236
218
should submit the resulting branch to be merged. Other changes - to
237
219
take advantage of whatever new feature you have added - should be
238
220
sent in separately, because the disk level changes are a contention
247
Currently an alias for Development2
229
Currently an alias for Development0
249
231
development-subtree
250
232
-------------------
252
Currently an alias for Development2Subtree
234
Currently an alias for Development0Subtree
254
Development2[Subtree]
236
Development0[Subtree]
255
237
---------------------
257
These formats use B+Tree indices which are considerably faster than
258
the earlier indices in bzr.
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
added
removed
doc/developers/development-repo.txt
