Translations by Maida

Additionally for directories, symlinks and files with a changed executable bit, Bazaar indicates their type using a trailing character: '/', '@' or '*' respectively. These decorations can be disabled using the '--no-classify' option.

Note that --short or -S gives status flags for each item, similar to Subversion's status command. To get output similar to svn -q, use bzr status -SV.

Before merges are committed, the pending merge tip revisions are shown. To see all pending merge revisions, use the -v option. To skip the display of pending merge information altogether, use the no-pending option or specify a file/directory.

To see which files have changed in a specific revision, or between two revisions, pass a revision range to the revision argument. This will produce the same results as calling 'bzr diff --summarize'.

In non-recursive mode, all the named items are added, regardless of whether they were previously ignored. A warning is given if any of the named files are already versioned.

In recursive mode (the default), files are treated the same way but the behaviour for directories is different. Directories that are already versioned do not give a warning. All directories, whether already versioned or not, are searched for files or subdirectories that are neither versioned or ignored, and these are added. This search proceeds recursively into versioned directories. If no names are given '.' is assumed.

Adding a file whose parent directory is not versioned will implicitly add the parent, and so on up to the root. This means you should never need to explicitly add a directory, they'll just get added when you add a file in the directory.

--file-ids-from will try to use the file ids from the supplied path. It looks up ids trying to find a matching parent directory with the same filename, and then by pure path. This option is rarely needed but can be useful when adding the same logical file into two branches that will be merged later (without showing the two different adds as a conflict). It is also useful when merging another project into a subdirectory of this one.

If the last argument is a versioned directory, all the other names are moved into it. Otherwise, there must be exactly two arguments and the file is changed to a new name.

If OLDNAME does not exist on the filesystem but is versioned and NEWNAME does exist on the filesystem but is not versioned, mv assumes that the file has been manually moved and only updates its internal inventory to reflect that change. The same is valid when moving many SOURCE files to a DESTINATION.

By default, this command only works on branches that have not diverged. Branches are considered diverged if the destination branch's most recent commit is one that has not been merged (directly or indirectly) into the parent.

If there is no default location set, the first pull will set it (use --no-remember to avoid setting it). After that, you can omit the location to use the default. To change the default, use --remember. The value will only be saved if the remote location can be accessed.

The --verbose option will display the revisions pulled using the log_format configuration option. You can use a different format by overriding it with -Olog_format=<other_format>.

Perform a local pull in a bound branch. Local pulls are not applied to the master branch.

This command only works on branches that have not diverged. Branches are considered diverged if the destination branch's most recent commit is one that has not been merged (directly or indirectly) by the source branch.

If you want to ensure you have the different changes in the other branch, do a merge (see bzr help merge) from the other branch, and commit that. After that you will be able to do a push without '--overwrite'.

The --verbose option will display the revisions pushed using the log_format configuration option. You can use a different format by overriding it with -Olog_format=<other_format>.

Create a stacked branch referring to the source branch. The new branch will depend on the availability of the source branch for all operations.

If BRANCH_LOCATION is omitted, checkout will reconstitute a working tree for the branch found in '.'. This is useful if you have removed the working tree or if it was never created - i.e. if you pushed the branch to its current location using SFTP.

If the TO_LOCATION is omitted, the last component of the BRANCH_LOCATION will be used. In other words, "checkout ../foo/bar" will attempt to create ./bar. If the BRANCH_LOCATION has no / or path separator embedded, the TO_LOCATION is derived from the BRANCH_LOCATION by stripping a leading scheme or drive identifier, if any. For example, "checkout lp:foo-bar" will attempt to create ./foo-bar.

To retrieve the branch as of a particular revision, supply the --revision parameter, as in "checkout foo/bar -r 5". Note that this will be immediately out of date [so you cannot commit] but it may be useful (i.e. to examine old code.)

Perform a lightweight checkout. Lightweight checkouts depend on access to the branch for every operation. Normal checkouts can perform common operations like diff and status without such access, and also support local commits.

This will perform a merge of the destination revision (the tip of the branch, or the specified revision) into the working tree, and then make that revision the basis revision for the working tree.

If there are any uncommitted changes in the tree, they will be carried across and remain as uncommitted changes after the update. To discard these changes, use 'bzr revert'. The uncommitted changes may conflict with the changes brought in by the change in basis revision.

You cannot update just a single file or directory, because each Bazaar working tree has just a single basis revision. If you want to restore a file that has been removed locally, use 'bzr revert' instead of 'bzr update'. If you want to restore a file to its state in a previous revision, use 'bzr revert' with a '-r' option, or use 'bzr cat' to write out the old content of that file to a new location.

The 'dir' argument, if given, must be the location of the root of a working tree to update. By default, the working tree that contains the current working directory is used.

Your local commits will now show as pending merges with 'bzr status', and can be committed with 'bzr commit'.

In verbose mode, statistical information is included with each report. To see extended statistic information, use a verbosity level of 2 or higher by specifying the verbose option multiple times, e.g. -vv.

Display the above together with extended format information and basic statistics (like the number of files in the working tree and number of revisions in the branch and repository):

This makes Bazaar stop tracking changes to the specified files. Bazaar will delete them if they can easily be recovered using revert otherwise they will be backed up (adding an extension of the form .~#~). If no options or parameters are given Bazaar will scan for files that are being tracked by Bazaar but missing in your tree and stop tracking them for you.

This can correct data mismatches that may have been caused by previous ghost operations or bzr upgrades. You should only need to run this command if 'bzr check' or a bzr developer advises you to run it.

If a second branch is provided, cross-branch reconciliation is also attempted, which will check that data like the tree root id which was not present in very early bzr versions is represented correctly in both branches.

At the same time it is run it may recompress data resulting in a potential saving in disk space or performance gain.

Pack-based format used in 1.x series. Introduced in 0.92. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92.

If there is a repository in a parent directory of the location, then the history of the branch will be stored in the repository. Otherwise init creates a standalone branch which carries its own history in the .bzr directory.

New branches created under the repository directory will store their revisions in the repository, not in the branch directory. For branches with shared history, this reduces the amount of storage needed and speeds up the creation of new branches.

If the --no-trees option is given then the branches in the repository will not have working trees by default. They will still exist as directories on disk, but they will not have separate copies of the files at a certain revision. This can be useful for repositories that store branches which are interacted with through checkouts or remote branches, such as on a server.