- Development repository formats
- Using development repository formats
- Format names
- Support for upgrade and migration
- Before converting to a development format
- Creating a new development format branch
- Creating a new development format repository
- Upgrading an existing branch or repository to development
- Starting a new development format branch from one in an older format
- Develoment formats for bzr-svn users
- Reporting problems
- Technical notes
- Format Details
- Using development repository formats
We believe that we can continue to gain substantial performance benefits by altering the repository storage in bzr. The more feedback we can get on the changes during the development process the better.
To make it possible to get more feedback we are going to expose the current development formats to the users of our development trunk ‘bzr.dev’. The technical details of the individual formats are at the end of this document.
The current development format will be called ‘development’. Each time the development format changes, the prior development format will be renamed to e.g. ‘development0’, ‘development1’ etc.
When a release of bzr is done, all the older numbered development formats will be removed from ‘bzr.dev’, so we will not be carrying the code for them around indefinately.
The preservation and renaming policy makes it quite safe for users to test out development formats (though we cannot guarantee bugs of course - it is development code):
- users of a given development format can always get back onto regular formats by switching to the next bzr released version which is guaranteed to be able to upgrade from that development format.
- users that routinely use bzr.dev should upgrade to the most recent development version available before pulling in bzr.dev changes around release time, as that is when old format cleanups will occur.
We cannot guarantee backwards compatability though, because some of the planned work may be ‘upgrade only’. Please see bzr help formats for the text of the ‘development’ format which will indicate its compatability with other formats if you need to interoperate with users or services that do not have bzr.dev.
Run a bzr check with the version of bzr that you will be using. bzr check gets updated as we find new things that are inconsistent with existing repositories. While only a small number of repositories are likely to have any given error, it is best to check just in case.
If bzr check reports a problem, run this command:
Note that reconcile can take many hours, particularly if you are reconciling one of the ‘knit’ or ‘dirstate’ format repositories. If you have such a repository, consider upgrading it to ‘pack-0.92’ first, which will perform reconcile significantly faster.
If you’re starting a project from scratch, it’s easy to make it a development one. Here’s how:
cd my-stuff bzr init --development bzr add bzr commit -m "initial import"
In other words, use the normal sequence of commands but add the --development option to the init command.
If you’re starting a project from scratch and wish to use a shared repository for branches, you can make it a development repository like this:
cd my-repo bzr init-repo --development . cd my-stuff bzr init bzr add bzr commit -m "initial import"
In other words, use the normal sequence of commands but add the --development option to the init-repo command.
If you have an existing branch and wish to migrate it to a development format, use the upgrade command like this:
bzr upgrade --development path-to-my-branch
If you are using a shared repository, run:
bzr upgrade --development ROOT_OF_REPOSITORY
to upgrade the history database. Note that this will not alter the branch format of each branch, so you will need to also upgrade each branch individually if you are upgrading from an old (e.g. < 0.17) bzr. More modern bzr’s will already have the branch format at our latest branch format which adds support for tags.
This can be done in one of several ways:
- Create a new branch and pull into it
- Create a standalone branch and upgrade its format
- Create a knitpack shared repository and branch into it
Here are the commands for using the pull approach:
bzr init --development my-new-branch cd my-new-branch bzr pull my-source-branch
Here are the commands for using the upgrade approach:
bzr branch my-source-branch my-new-branch cd my-new-branch bzr upgrade --development .
Here are the commands for the shared repository approach:
cd my-repo bzr init-repo --development . bzr branch my-source-branch my-new-branch cd my-new-branch
As a reminder, any of the above approaches can fail if the source branch has inconsistent data within it and hasn’t been reconciled yet. Please be sure to check that before reporting problems.
If you are using bzr-svn or are testing the prototype subtree support, you can still use and assist in testing the development formats. The commands to use are identical to the ones given above except that the name of the format to use is development-subtree.
WARNING: Note that bzr only supports one-way conversion to the subtree format development-subtree. Once you are using development-subtree you cannot pull or merge back into a regular format such as pack-0.92, development etc.
The development-subtree format is required for the bzr-svn plug-in but should otherwise not be used until the subtree feature is complete within bzr.
Whenever a code change will result in incorrect behaviour with existing development repositories. Changes in push/pull/init/commit/merge have all been known to do this in the past.
Register two new formats with the next available sequence number. e.g. development1 and development1-subtree. (You can see the current development format for an example. These should:
- Use your new development repository/branch/tree classes
- Have really bare bones help - something like ‘changes X to be Y see ...developers/development-repo.html’
- Be hidden and experimental.
Change the repository class (or branch or tree) in the development and development-subtree formats to point to the new class you are creating.
Add a new development format (and tests!). Repository formats are in bzrlib.repofmt. You probably want to reproduce the current development format from bzrlib.repofmt.pack_repo with just new disk format strings, _get_matching_bzrdir and help.
Register your development format with the various registries. At the moment you need to update:
- bzrlib/bzrdir.py to register the WT/Branch/Repository collection.
- bzrlib/workingtree.py, bzrlib/branch.py, bzrlib/repository.py, each one maintains a direct list of their respective formats.
- For repositories, you also need to update the InterKnit1and2 class. This is responsible for converting between rich-root and non-rich-root repositories.
- For repositories based on KnitPackRepository, you need to update bzrlib/tests/test_pack_repository.py to add the class to the tested permutations.
Alter any other things that do class based tests. The easiest way to find these is a grep for Development in bzrlib - and please refactor as you find these to reduce the relevance this step has, as it should not need to exist.
Now subclass/create from scratch/whatever the live object code you need to change to introduce your new format. Keep in mind that eventually it will become the default format, so please don’t keep subclassing the last releases code, rather consider making the last releases code a subclass of your new code (if there is a lot in common) so that we can eventually remove that format once it becomes ancient (or relegate it to a plugin).
Once you have made the changes that required a new disk format, you should submit the resulting branch to be merged. Other changes - to take advantage of whatever new feature you have added - should be sent in separately, because the disk level changes are a contention point between multiple developers.
Not currently available, as our development formats are all rich root or subtrees now.
Currently an alias for Development6Subtree
Currently an alias for Development6Subtree
These formats use the new groupcompress delta compress and a CHK(Content Hash Key) based inventory store which is much faster at incremental operations than the prior XML based store. Note Converting from a non-rich-root to a rich-root format is a one-way upgrade, and you cannot merge back afterwards: using this format for everyday use is likely to cause all developers of a project to upgrade to a rich-root format themselves. This is fine, as bzr is moving to make rich-root formats the default and to get all users to upgrade, but we have not finalised the migration process, and until we do do not recomment that casual users upgrade. Users of bzr-svn are already using rich-root formats and can test with this with impunity.