← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: John Arbash Meinel
  • Date: 2008-10-28 22:19:31 UTC
  • mto: (3815.2.1 prepare-1.9)
  • mto: This revision was merged to the branch mainline in revision 3816.
  • Revision ID: john@arbash-meinel.com-20081028221931-uk9oan2xkocd0gis
Add repository 1.9 format, and update the documentation.

Help people generating new repository formats find all the locations
they need to update.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/development-repo.txt
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