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.
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.
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.
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
Not currently available, as our development formats are all rich root or
250
development-rich-root
251
---------------------
253
Currently an alias for Development6Subtree
229
Currently an alias for Development0
255
231
development-subtree
256
232
-------------------
258
Currently an alias for Development6Subtree
260
Development6RichRoot[Subtree]
261
-----------------------------
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
236
Development0[Subtree]
237
---------------------
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