~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2008-03-16 16:58:03 UTC
  • mfrom: (3224.3.1 news-typo)
  • Revision ID: pqm@pqm.ubuntu.com-20080316165803-tisoc9mpob9z544o
(Matt Nordhoff) Trivial NEWS typo fix

Show diffs side-by-side

added added

removed removed

Lines of Context:
28
28
 
29
29
When a release of bzr is done, all the older numbered development
30
30
formats will be removed from 'bzr.dev', so we will not be carrying the
31
 
code for them around indefinately.
 
31
code for them around indefinately. 
32
32
 
33
33
Support for upgrade and migration
34
34
---------------------------------
40
40
 - users of a given development format can always get back onto regular
41
41
   formats by switching to the next bzr released version which is
42
42
   guaranteed to be able to upgrade from that development format.
43
 
 - users that routinely use bzr.dev should upgrade to the most recent
 
43
 - users that routinely use bzr.dev should upgrade to the most recent 
44
44
   development version available before pulling in bzr.dev changes
45
45
   around release time, as that is when old format cleanups will occur.
46
46
 
171
171
 
172
172
If you need any help or encounter any problems, please contact the developers
173
173
via the usual ways, i.e. chat to us on IRC or send a message to our mailing
174
 
list. See http://wiki.bazaar.canonical.com/BzrSupport for contact details.
 
174
list. See http://bazaar-vcs.org/BzrSupport for contact details.
175
175
 
176
176
 
177
177
Technical notes
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
 
   current development format for an example.
 
192
   ``development0`` 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. 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
 
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
244
226
development
245
227
-----------
246
228
 
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
 
229
Currently an alias for Development0
254
230
 
255
231
development-subtree
256
232
-------------------
257
233
 
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.
 
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.
274
243
 
275
244
 
276
245
..