Translations by Tarik Radončić

When logging a range of revisions using -rX..Y, log starts at revision Y and searches back in history through the primary ("left-hand") parents until it finds X. When logging just the top level (using -n1), an error is reported if X is not found along the way. If multi-level logging is used (-n0), X may be a nested merge revision and the log will be truncated accordingly.

When exploring non-mainline history on large projects with deep history, the performance of log can be greatly improved by installing the historycache plugin. This plugin buffers historical information trading disk space for faster speed.

When the default format has changed after a major new release of Bazaar, you may be informed during certain operations that you should upgrade. Upgrading to a newer format may improve performance or make new features available. It may however limit interoperability with older repositories or with older versions of Bazaar.

The source of the merge can be specified either in the form of a branch, or in the form of a path to a file containing a merge directive generated with bzr send. If neither is specified, the default is the upstream branch or the branch most recently merged using --remember. The source of the merge may also be specified in the form of a path to a file in another branch: in this case, only the modifications to that file are merged into the current working tree.

merge refuses to run if there are any uncommitted changes, unless --force is given. If --force is given, then the changes from the source will be merged with the current working tree, including any uncommitted changes in the tree. The --force option can also be used to create a merge revision which has more than two parents.

The working tree contains a list of revisions that have been merged but not yet committed. These revisions will be included as additional parents of the next commit. Normally, using revert clears that list as well as reverting the files. If any files are specified, revert leaves the list of uncommitted merges alone and reverts only the files. Use ``bzr revert .`` in the tree root to revert all files but keep the recorded merges, and ``bzr revert --forget-merges`` to clear the pending merge list without reverting any files.

Using "bzr revert --forget-merges", it is possible to apply all of the changes from a branch in a single revision. To do this, perform the merge as desired. Then doing revert with the "--forget-merges" option will keep the content of the tree as it was, but it will clear the list of pending merges. The next commit will then contain all of the changes that are present in the other branch, but without any other parent revisions. Because this technique forgets where these changes originated, it may cause additional conflicts on later merges involving the same source and target branches.

Shelve allows you to temporarily put changes you've made "on the shelf", ie. out of the way, until a later time when you can bring them back from the shelf with the 'unshelve' command. The changes are stored alongside your working tree, and so they aren't propagated along with your branch nor will they survive its deletion.

{0} commit by author {1} with key {2} now expired

{0} commits by author {1} with key {2} now expired

Unknown key {0} signed {1} commit

Unknown key {0} signed {1} commits

In addition, one branch may be bound to another one. Binding to another branch indicates that commits which happen in this branch must also happen in the other branch. Bazaar ensures consistency by not allowing commits when the two branches are out of date. In order for a commit to succeed, it may be necessary to update the current branch using ``bzr update``.

Checkouts are source trees that are connected to a branch, so that when you commit in the source tree, the commit goes into that branch. They allow you to use a simpler, more centralized workflow, ignoring some of Bazaar's decentralized features until you want them. Using checkouts with shared repositories is very similar to working with SVN or CVS, but doesn't have the same restrictions. And using checkouts still allows others working on the project to use whatever workflow they like.

A checkout is created with the bzr checkout command (see "help checkout"). You pass it a reference to another branch, and it will create a local copy for you that still contains a reference to the branch you created the checkout from (the master branch). Then if you make any commits they will be made on the other branch first. This creates an instant mirror of your work, or facilitates lockstep development, where each developer is working together, continuously integrating the changes of others.

However the checkout is still a first class branch in Bazaar terms, so that you have the full history locally. As you have a first class branch you can also commit locally if you want, for instance due to the temporary loss af a network connection. Use the --local option to commit to do this. All the local commits will then be made on the master branch the next time you do a non-local commit.

It is also possible to create a "lightweight" checkout by passing the --lightweight flag to checkout. A lightweight checkout is even closer to an SVN checkout in that it is not a first class branch, it mainly consists of the working tree. This means that any history operations must query the master branch, which could be slow if a network connection is involved. Also, as you don't have a local branch, then you cannot commit locally.

Lightweight checkouts work best when you have fast reliable access to the master branch. This means that if the master branch is on the same disk or LAN a lightweight checkout will be faster than a heavyweight one for any commands that modify the revision history (as only one copy of the branch needs to be updated). Heavyweight checkouts will generally be faster for any command that uses the history but does not change it, but if the master branch is on the same disk then there won't be a noticeable difference.

Obviously to commit on a checkout you need to be able to write to the master branch. This means that the master branch must be accessible over a writeable protocol , such as sftp://, and that you have write permissions at the other end. Checkouts also work on the local file system, so that all that matters is file permissions.

checkout Create a checkout. Pass --lightweight to get a lightweight checkout update Pull any changes in the master branch in to your checkout commit Make a commit that is sent to the master branch. If you have a heavy checkout then the --local option will commit to the checkout without sending the commit to the master switch Change the master branch that the commits in the checkout will be sent to bind Turn a standalone branch into a heavy checkout so that any commits will be sent to the master branch unbind Turn a heavy checkout into a standalone branch so that any commits are only made locally info Displays whether a branch is bound or unbound. If the branch is bound, then it will also display the location of the bound branch

The ``weave`` merge type is not affected by this problem because it uses line-origin detection instead of a basis revision to determine the cause of differences.

To ensure that older clients do not access data incorrectly, Bazaar's policy is to introduce a new storage format whenever new features requiring new metadata are added. New storage formats may also be introduced to improve performance and scalability.

Some of the older formats have two variants: a plain one and a rich-root one. The latter include an additional field about the root of the tree. There is no performance cost for using a rich-root format but you cannot easily merge changes from a rich-root format into a plain format. As a consequence, moving a project to a rich-root format takes some co-ordination in that all contributors need to upgrade their repositories around the same time. 2a and all future formats will be implicitly rich-root.

--version Print the version number. Must be supplied before the command. --no-aliases Do not process command aliases when running this command. --builtin Use the built-in version of a command, not the plugin version. This does not suppress other plugin effects. --no-plugins Do not process any plugins. --no-l10n Do not translate messages. --concurrency Number of processes that can be run concurrently (selftest).

--profile Profile execution using the hotshot profiler. --lsprof Profile execution using the lsprof profiler. --lsprof-file Profile execution using the lsprof profiler, and write the results to a specified file. If the filename ends with ".txt", text format will be used. If the filename either starts with "callgrind.out" or end with ".callgrind", the output will be formatted for use with KCacheGrind. Otherwise, the output will be a pickle. --coverage Generate line coverage report in the specified directory.

* The 'lp:' bug tracker alias can expand launchpad bug numbers to their URLs for use with 'bzr commit --fixes', e.g. 'bzr commit --fixes lp:12345' will record a revision property that marks that revision as fixing Launchpad bug 12345. When you push that branch to Launchpad it will automatically be linked to the bug report.

It is a good idea to create a repository whenever you might create more than one branch of a project. This is true for both working areas where you are doing the development, and any server areas that you use for hosting projects. In the latter case, it is common to want branches without working trees. Since the files in the branch will not be edited directly there is no need to use up disk space for a working tree. To create a repository in which the branches will not have working trees pass the '--no-trees' option to 'init-repository'.

When reconfiguring a checkout, tree or branch into a lightweight checkout, a local branch must be destroyed. (For checkouts, this is the local branch that serves primarily as a cache.) If the branch-to-be-destroyed does not have the same last revision as the new reference branch for the lightweight checkout, data could be lost, so Bazaar refuses.

When you push a branch to a remote system, a working tree will not be created. If one is already present the files will not be updated. The branch information will be updated and the working tree will be marked as out-of-date. Updating a working tree remotely is difficult, as there may be uncommitted changes or the update may cause content conflicts that are difficult to deal with remotely.

Bazaar knows about a few bug trackers that have many users. If you use one of these bug trackers then there is no setup required to use this feature, you just need to know the tracker identifier to use. These are the bugtrackers that are built in:

For the bug trackers not listed above configuration is required. Support for generating the URLs for any project using Bugzilla or Trac is built in, along with a template mechanism for other bugtrackers with simple URL schemes. If your bug tracker can't be described by one of the schemes described below then you can write a plugin to support it.

If you use Bugzilla or Trac, then you only need to set a configuration variable which contains the base URL of the bug tracker. These options can go into ``bazaar.conf``, ``branch.conf`` or into a branch-specific configuration section in ``locations.conf``. You can set up these values for each of the projects you work on.

If present, the location of the Bugzilla bug tracker referred to by <tracker>. This option can then be used together with ``bzr commit --fixes`` to mark bugs in that tracker as being fixed by that commit. For example::

If present, the location of the Trac instance referred to by <tracker>. This option can then be used together with ``bzr commit --fixes`` to mark bugs in that tracker as being fixed by that commit. For example::

If present, the location of a generic bug tracker instance referred to by <tracker>. The location must contain an ``{id}`` placeholder, which will be replaced by a specific bug ID. This option can then be used together with ``bzr commit --fixes`` to mark bugs in that tracker as being fixed by that commit. For example::

Override the progress display. Possible values are "none" or "text". If the value is "none" then no progress bar is displayed. The value "text" draws the ordinary command line progress bar.

Under special circumstances (mostly when trying to diagnose a bug), it's better to disable a plugin (or several) rather than uninstalling them completely. Such plugins can be specified in the ``BZR_DISABLE_PLUGINS`` environment variable.

When adding a new feature or working on a bug in a plugin, developers often need to use a specific version of a given plugin. Since python requires that the directory containing the code is named like the plugin itself this make it impossible to use arbitrary directory names (using a two-level directory scheme is inconvenient). ``BZR_PLUGINS_AT`` allows such directories even if they don't appear in ``BZR_PLUGIN_PATH`` .

Each branch can also contain a configuration file that sets values specific to that branch. This file is found at ``.bzr/branch/branch.conf`` within the branch. This file is visible to all users of a branch, if you wish to override one of the values for a branch with a setting that is specific to you then you can do so in ``locations.conf``.

The only valid section headers for bazaar.conf currently are [DEFAULT] and [ALIASES]. Section headers are case sensitive. The default section provides for setting options which can be overridden with the branch config file.

``locations.conf`` allows one to specify overriding settings for a specific branch. The format is almost identical to the default section in bazaar.conf with one significant change: The section header, instead of saying default, will be the path to a branch that you wish to override a value for. The '?' and '*' wildcards are supported::

The GnuPG user identity to use when signing commits. Can be an e-mail address, key fingerprint or full key ID. When unset or when set to "default" Bazaar will use the user e-mail set with ``whoami``.

If set to true, bzr will automatically break locks held by processes from the same machine and user that are no longer alive. Otherwise, it will print a message and you can break the lock manually, if you are satisfied the object is no longer in use.

The branch you intend to submit your current work to. This is automatically set by ``bzr send``, and is also used by the ``submit:`` revision spec. This should usually be set on a per-branch or per-location basis.

If set to "True" then revisions can only be appended to the log, not removed. A branch with this setting enabled can only pull from another branch if the other branch's log is a longer version of its own. This is normally set by ``bzr init --append-revisions-only``. If you set it manually, use either 'True' or 'False' (case-sensitive) to maintain compatibility with previous bzr versions (older than 2.2).

Defines the maximum file size the command line "add" operation will allow in recursive mode, with files larger than this value being skipped. You may specify this value as an integer (in which case it is interpreted as bytes), or you may specify the value using SI units, i.e. 10KB, 20MB, 1G. A value of 0 will disable skipping.

Defines an external merge tool called <name> with the given command-line. Arguments containing spaces should be quoted using single or double quotes. The executable may omit its path if it can be found on the PATH.

Resolving conflicts is sometimes not obvious. Either because the user that should resolve them is not the one responsible for their occurrence, as is the case when merging other people's work or because some conflicts are presented in a way that is not easy to understand.

Bazaar tries to avoid conflicts ; its aim is to ask you to resolve the conflict if and only if there's an actual conceptual conflict in the source tree. Because Bazaar doesn't understand the real meaning of the files being versioned, it can, when faced with ambiguities, fall short in either direction trying to resolve the conflict itself. Many kinds of changes can be combined programmatically, but sometimes only a human can determine the right thing to do.

These are produced when a text merge cannot completely reconcile two sets of text changes. Bazaar will emit files for each version with the extensions THIS, OTHER, and BASE. THIS is the version of the file from the target tree, i.e. the tree that you are merging changes into. OTHER is the version that you are merging into the target. BASE is an older version that is used as a basis for comparison.

Say the initial text is "The project leader released it.", and THIS modifies it to "Martin Pool released it.", while OTHER modifies it to "The project leader released Bazaar." A conflict would look like this::