Use an integer to specify a revision in the history of the branch. Optionally a branch can be specified. The 'revno:' prefix is optional. A negative number will count from the end of the branch (-1 is the last revision, -2 the previous one). If the negative number is larger than the branch's history, the first revision is returned. Examples:

revno:1                   -> return the first revision
revno:3:/path/to/branch   -> return the 3rd revision of
                             the branch '/path/to/branch'
revno:-1                  -> The last revision in a branch.
-2:http://other/branch    -> The second to last revision in the
                             remote branch.
-1000000                  -> Most likely the first revision, unless
                             your history is very long.

Supply a specific revision id, that can be used to specify any revision id in the ancestry of the branch. Including merges, and pending merges. Examples:

revid:aaaa@bbbb-123456789 -> Select revision 'aaaa@bbbb-123456789'

Supply a positive number to get the nth revision from the end. This is the same as supplying negative numbers to the 'revno:' spec. Examples:

last:1        -> return the last revision
last:3        -> return the revision 2 before the end.

Supply any revision spec to return the parent of that revision. It is an error to request the parent of the null revision (before:0). This is mostly useful when inspecting revisions that are not in the revision history of a branch.

Examples:

before:1913    -> Return the parent of revno 1913 (revno 1912)
before:revid:aaaa@bbbb-1234567890  -> return the parent of revision
                                      aaaa@bbbb-1234567890
bzr diff -r before:revid:aaaa..revid:aaaa
      -> Find the changes between revision 'aaaa' and its parent.
         (what changes did 'aaaa' introduce)

Tags are stored in the branch and created by the 'tag' command.

Supply a datestamp to select the first revision that matches the date. Date can be 'yesterday', 'today', 'tomorrow' or a YYYY-MM-DD string. Matches the first entry after a given date (either at midnight or at a specified time).

One way to display all the changes since yesterday would be:

bzr log -r date:yesterday..-1

Examples:

date:yesterday            -> select the first revision since yesterday
date:2006-08-14,17:10:14  -> select the first revision after
                             August 14th, 2006 at 5:10pm.

Supply the path to a branch to select the common ancestor.

The common ancestor is the last revision that existed in both branches. Usually this is the branch point, but it could also be a revision that was merged.

This is frequently used with 'diff' to return all of the changes that your branch introduces, while excluding the changes that you have not merged from the remote branch.

Examples:

ancestor:/path/to/branch
$ bzr diff -r ancestor:../../mainline/branch

Supply the path to a branch to select its last revision.

Examples:

branch:/path/to/branch

Diffing against this shows all the changes that were made in this branch, and is a good predictor of what merge will do. The submit branch is used by the bundle and merge directive comands. If no submit branch is specified, the parent branch is used instead.

The common ancestor is the last revision that existed in both branches. Usually this is the branch point, but it could also be a revision that was merged.

Examples:

$ bzr diff -r submit:

Add specified files or directories.

bzr add [FILE...]

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.

Therefore simply saying 'bzr add' will version all files that are currently unknown.

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.

--dry-run will show which files would be added, but not actually add them.

--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.

remove

Show the origin of each line in a file.

bzr annotate FILENAME

This prints out the given file with an annotation on the left side indicating which revision, author and date introduced the change.

If the origin is the same for a run of consecutive lines, it is shown only at the top, unless the --all option is given.

ann, blame, praise

Convert the current branch into a checkout of the supplied branch.

bzr bind [LOCATION]

Once converted into a checkout, commits must succeed on the master branch before they will be applied to the local branch.

checkouts, unbind

Create a new copy of a branch.

bzr branch FROM_LOCATION [TO_LOCATION]

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

To retrieve the branch as of a particular revision, supply the --revision parameter, as in "branch foo/bar -r 5".

get, clone

checkout

Break a dead lock on a repository, branch or working directory.

bzr break-lock [LOCATION]

CAUTION: Locks should only be broken when you are sure that the process holding the lock has been stopped.

You can get information on what locks are open via the 'bzr info' command.

bzr break-lock

Write the contents of a file as of a given revision to standard output.

bzr cat FILENAME

If no revision is nominated, the last revision is used.

Note: Take care to redirect standard output when using this command on a binary file.

ls

Validate consistency of branch history.

bzr check [BRANCH]

This command checks various invariants about the branch storage to detect data corruption or bzr bugs.

Output fields:

revisions: This is just the number of revisions checked. It doesn't

indicate a problem.

versionedfiles: This is just the number of versionedfiles checked. It

doesn't indicate a problem.

unreferenced ancestors: Texts that are ancestors of other texts, but

are not properly referenced by the revision ancestry. This is a subtle problem that Bazaar can work around.

unique file texts: This is the total number of unique file contents

seen in the checked revisions. It does not indicate a problem.

repeated file texts: This is the total number of repeated texts seen

in the checked revisions. Texts can be repeated when their file entries are modified, but the file contents are not. It does not indicate a problem.

reconcile

Create a new checkout of an existing branch.

bzr checkout [BRANCH_LOCATION] [TO_LOCATION]

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.)

co

branch, checkouts

Commit changes into a new revision.

bzr commit [SELECTED...]

If no arguments are given, the entire tree is committed.

If selected files are specified, only changes to those files are committed. If a directory is specified then the directory and everything within it is committed.

If author of the change is not the same person as the committer, you can specify the author's name using the --author option. The name should be in the same format as a committer-id, e.g. "John Doe <jdoe@example.com>".

A selected-file commit may fail in some cases where the committed tree would be invalid. Consider:

bzr init foo
mkdir foo/bar
bzr add foo/bar
bzr commit foo -m "committing foo"
bzr mv foo/bar foo/baz
mkdir foo/bar
bzr add foo/bar
bzr commit foo/bar -m "committing bar but not baz"

In the example above, the last commit will fail by design. This gives the user the opportunity to decide whether they want to commit the rename at the same time, separately first, or not at all. (As a general rule, when in doubt, Bazaar has a policy of Doing the Safe Thing.)

Note: A selected-file commit after a merge is not yet supported.

ci, checkin

bugs, uncommit

List files with conflicts.

bzr conflicts

Merge will do its best to combine the changes in two branches, but there are some kinds of problems only a human can fix. When it encounters those, it will mark a conflict. A conflict means that you need to fix something, before you should commit.

Conflicts normally are listed as short, human-readable messages. If --text is supplied, the pathnames of files with text conflicts are listed, instead. (This is useful for editing all files with text conflicts.)

Use bzr resolve when you have fixed a problem.

See also bzr resolve.

List files deleted in the working tree.

bzr deleted

ls, status

Show differences in the working tree, between revisions or branches.

bzr diff [FILE...]

If no arguments are given, all changes for the current tree are listed. If files are given, only the changes in those files are listed. Remote and multiple branches can be compared by using the --old and --new options. If not provided, the default for both is derived from the first argument, if any, or the current tree if no arguments are given.

"bzr diff -p1" is equivalent to "bzr diff --prefix old/:new/", and produces patches suitable for "patch -p1".

Shows the difference in the working tree versus the last commit:

bzr diff

Difference between the working tree and revision 1:

bzr diff -r1

Difference between revision 2 and revision 1:

bzr diff -r1..2

Difference between revision 2 and revision 1 for branch xxx:

bzr diff -r1..2 xxx

Show just the differences for file NEWS:

bzr diff NEWS

Show the differences in working tree xxx for file NEWS:

bzr diff xxx/NEWS

Show the differences from branch xxx to this working tree:

bzr diff --old xxx

Show the differences between two branches for file NEWS:

bzr diff --old xxx --new yyy NEWS

Same as 'bzr diff' but prefix paths with old/ and new/:

bzr diff --prefix old/:new/

1 - changed 2 - unrepresentable changes 3 - error 0 - no change

di, dif

status

Export current or past revision to a destination directory or archive.

bzr export DEST [BRANCH]

If no revision is specified this exports the last committed revision.

Format may be an "exporter" name, such as tar, tgz, tbz2. If none is given, try to find the format with the extension. If no extension is found exports to a directory (equivalent to --format=dir).

If root is supplied, it will be used as the root directory inside container formats (tar, zip, etc). If it is not supplied it will default to the exported filename. The root option has no effect for 'dir' format.

If branch is omitted then the branch containing the current working directory will be used.

Note: Export of tree with non-ASCII filenames to zip is not supported.

Supported formats	Autodetected by extension
dir	(none)
tar	.tar
tbz2	.tar.bz2, .tbz2
tgz	.tar.gz, .tgz
zip	.zip

Show help on a command or other topic.

bzr help [TOPIC]

?, --help, -?, -h

topics

Ignore specified files or patterns.

bzr ignore [NAME_PATTERN...]

To remove patterns from the ignore list, edit the .bzrignore file.

Trailing slashes on patterns are ignored. If the pattern contains a slash or is a regular expression, it is compared to the whole path from the branch root. Otherwise, it is compared to only the last component of the path. To match a file only in the root directory, prepend './'.

Ignore patterns specifying absolute paths are not allowed.

Ignore patterns may include globbing wildcards such as:

? - Matches any single character except '/'
* - Matches 0 or more characters except '/'
/**/ - Matches 0 or more directories in a path
[a-z] - Matches a single character from within a group of characters

Ignore patterns may also be Python regular expressions. Regular expression ignore patterns are identified by a 'RE:' prefix followed by the regular expression. Regular expression ignore patterns may not include named or numbered groups.

Note: ignore patterns containing shell wildcards must be quoted from the shell on Unix.

Ignore the top level Makefile:

bzr ignore ./Makefile

Ignore class files in all directories:

bzr ignore "*.class"

Ignore .o files under the lib directory:

bzr ignore "lib/**/*.o"

Ignore .o files under the lib directory:

bzr ignore "RE:lib/.*\.o"

Ignore everything but the "debian" toplevel directory:

bzr ignore "RE:(?!debian/).*"

ignored, status

List ignored files and the patterns that matched them.

bzr ignored

ignore

Show information about a working tree, branch or repository.

bzr info [LOCATION]

This command will show all known locations and formats associated to the tree, branch or repository. Statistical information is included with each report.

Branches and working trees will also report any missing revisions.

repositories, revno, working-trees

Make a directory into a versioned branch.

bzr init [LOCATION]

Branch Format:

--format=ARG	Specify a format for this branch. See "help formats".
--default	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--development	Current development format. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar-vcs.org/latest/developers /development-repo.html before use.
--development-subtree
	Current development format, subtree variant. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar- vcs.org/latest/developers/development-repo.html before use.
--dirstate	New in 0.15: Fast local operations. Compatible with bzr 0.8 and above when accessed over the network.
--dirstate-tags
	New in 0.15: Fast local operations and improved scaling for network operations. Additionally adds support for tags. Incompatible with bzr < 0.15.
--knit	Format using knits. Recommended for interoperation with bzr <= 0.14.
--metaweave	Transitional format in 0.8. Slower than knit.
--pack-0.92	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--rich-root	New in 1.0. Better handling of tree roots. Incompatible with bzr < 1.0
--rich-root-pack
	New in 1.0: Pack-based format with data compatible with rich-root format repositories. Incompatible with bzr < 1.0
--weave	Pre-0.8 format. Slower than knit and does not support checkouts or shared repositories.

Use this to create an empty branch, or before importing an existing project.

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.

If there is already a branch at the location but it has no working tree, the tree can be populated with 'bzr checkout'.

Recipe for importing a tree of files:

cd ~/project
bzr init
bzr add .
bzr status
bzr commit -m "imported project"

branch, checkout, init-repository

Create a shared repository to hold branches.

bzr init-repository LOCATION

Repository format:

--format=ARG	Specify a format for this repository. See "bzr help formats" for details.
--default	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--development	Current development format. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar-vcs.org/latest/developers /development-repo.html before use.
--development-subtree
	Current development format, subtree variant. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar- vcs.org/latest/developers/development-repo.html before use.
--dirstate	New in 0.15: Fast local operations. Compatible with bzr 0.8 and above when accessed over the network.
--dirstate-tags
	New in 0.15: Fast local operations and improved scaling for network operations. Additionally adds support for tags. Incompatible with bzr < 0.15.
--knit	Format using knits. Recommended for interoperation with bzr <= 0.14.
--metaweave	Transitional format in 0.8. Slower than knit.
--pack-0.92	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--rich-root	New in 1.0. Better handling of tree roots. Incompatible with bzr < 1.0
--rich-root-pack
	New in 1.0: Pack-based format with data compatible with rich-root format repositories. Incompatible with bzr < 1.0
--weave	Pre-0.8 format. Slower than knit and does not support checkouts or shared repositories.

New branches created under the repository directory will store their revisions in the repository, not in the branch directory.

If the --no-trees option is used then the branches in the repository will not have working trees by default.

Create a shared repositories holding just branches:

bzr init-repo --no-trees repo
bzr init repo/trunk

Make a lightweight checkout elsewhere:

bzr checkout --lightweight repo/trunk trunk-checkout
cd trunk-checkout
(add files here)

init-repo

branch, checkout, init, repositories

Show log of a branch, file, or directory.

bzr log [LOCATION]

Log format:

--log-format=ARG
	Use specified log format.
--line	Log format with one line per revision
--long	Detailed log format
--short	Moderately short log format

By default show the log of the branch containing the working directory.

To request a range of logs, you can use the command -r begin..end -r revision requests a specific revision, -r ..end or -r begin.. are also valid.

Log the current branch:

bzr log

Log a file:

bzr log foo.c

Log the last 10 revisions of a branch:

bzr log -r -10.. http://server/branch

List files in a tree.

bzr ls [PATH]

cat, status

Perform a three-way merge.

bzr merge [LOCATION]

Merge algorithm:

--merge-type=ARG
	Select a particular merge algorithm.
--diff3	Merge using external diff3
--lca	LCA-newness merge
--merge3	Native diff3-style merge
--weave	Weave-based merge

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.

When merging a branch, by default the tip will be merged. To pick a different revision, pass --revision. If you specify two values, the first will be used as BASE and the second one as OTHER. Merging individual revisions, or a subset of available revisions, like this is commonly referred to as "cherrypicking".

Revision numbers are always relative to the branch being merged.

By default, bzr will try to merge in all new work from the other branch, automatically determining an appropriate base. If this fails, you may need to give an explicit base.

Merge will do its best to combine the changes in two branches, but there are some kinds of problems only a human can fix. When it encounters those, it will mark a conflict. A conflict means that you need to fix something, before you should commit.

Use bzr resolve when you have fixed a problem. See also bzr conflicts.

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

The results of the merge are placed into the destination working directory, where they can be reviewed (with bzr diff), tested, and then committed to record the result of the merge.

merge refuses to run if there are any uncommitted changes, unless --force is given.

To merge the latest revision from bzr.dev:

bzr merge ../bzr.dev

To merge changes up to and including revision 82 from bzr.dev:

bzr merge -r 82 ../bzr.dev

To merge the changes introduced by 82, without previous changes:

bzr merge -r 81..82 ../bzr.dev

To apply a merge directive contained in in /tmp/merge:

bzr merge /tmp/merge

remerge, status-flags, update

Show unmerged/unpulled revisions between two branches.

bzr missing [OTHER_BRANCH]

Log format:

--log-format=ARG
	Use specified log format.
--line	Log format with one line per revision
--long	Detailed log format
--short	Moderately short log format

OTHER_BRANCH may be local or remote.

merge, pull

Create a new versioned directory.

bzr mkdir DIR...

This is equivalent to creating the directory and then adding it.

Move or rename a file.

bzr mv OLDNAME NEWNAME

bzr mv SOURCE... DESTINATION

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.

Files cannot be moved between branches.

move, rename

Print or set the branch nickname.

bzr nick [NICKNAME]

If unset, the tree root directory name is used as the nickname To print the current nickname, execute with no argument.

info

Compress the data within a repository.

bzr pack [BRANCH_OR_REPO]

repositories

List the installed plugins.

bzr plugins

This command displays the list of installed plugins including version of plugin and a short description of each.

--verbose shows the path where each plugin is located.

A plugin is an external component for Bazaar that extends the revision control system, by adding or replacing code in Bazaar. Plugins can do a variety of things, including overriding commands, adding new commands, providing additional network transports and customizing log output.

See the Bazaar web site, http://bazaar-vcs.org, for further information on plugins including where to find them and how to install them. Instructions are also provided there on how to write new plugins using the Python programming language.

Turn this branch into a mirror of another branch.

bzr pull [LOCATION]

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 branches have diverged, you can use 'bzr merge' to integrate the changes from one into the other. Once one branch has merged, the other should be able to pull it again.

If you want to forget your local changes and just update your branch to match the remote one, use pull --overwrite.

If there is no default location set, the first pull will set 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.

Note: The location 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.

push, status-flags, update

Update a mirror of this branch.

bzr push [LOCATION]

The target branch will not have its working tree populated because this is both expensive, and is not supported on remote file systems.

Some smart servers or protocols may put the working tree in place in the future.

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 branches have diverged, you can use 'bzr push --overwrite' to replace the other branch completely, discarding its unmerged changes.

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'.

If there is no default push location set, the first push will set 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.

pull, update, working-trees

Reconcile bzr metadata in a branch.

bzr reconcile [BRANCH]

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.

The branch MUST be on a listable system such as local disk or sftp.

check

Reconfigure the type of a bzr directory.

bzr reconfigure [LOCATION]

Target type:

--branch	Reconfigure to a branch.
--checkout	Reconfigure to a checkout.
--lightweight-checkout
	Reconfigure to a lightweight checkout.
--tree	Reconfigure to a tree.

A target configuration must be specified.

For checkouts, the bind-to location will be auto-detected if not specified. The order of preference is 1. For a lightweight checkout, the current bound location. 2. For branches that used to be checkouts, the previously-bound location. 3. The push location. 4. The parent location. If none of these is available, --bind-to must be specified.

Redo a merge.

bzr remerge [FILE...]

Merge algorithm:

--merge-type=ARG
	Select a particular merge algorithm.
--diff3	Merge using external diff3
--lca	LCA-newness merge
--merge3	Native diff3-style merge
--weave	Weave-based merge

Use this if you want to try a different merge technique while resolving conflicts. Some merge techniques are better than others, and remerge lets you try different ones on different files.

The options for remerge have the same meaning and defaults as the ones for merge. The difference is that remerge can (only) be run when there is a pending merge, and it lets you specify particular files.

Re-do the merge of all conflicted files, and show the base text in conflict regions, in addition to the usual THIS and OTHER texts:

bzr remerge --show-base

Re-do the merge of "foobar", using the weave merge algorithm, with additional processing to reduce the size of conflict regions:

bzr remerge --merge-type weave --reprocess foobar

Remove files or directories.

bzr remove [FILE...]

Deletion Strategy:

--force	Delete all the specified files, even if they can not be recovered and even if they are non-empty directories.
--keep	Don't delete any files.
--safe	Only delete files if they can be safely recovered (default).

This makes bzr stop tracking changes to the specified files and delete them if they can easily be recovered using revert.

You can specify one or more files, and/or --new. If you specify --new, only 'added' files will be removed. If you specify both, then new files in the specified directories will be removed. If the directories are also new, they will also be removed.

rm

Remove the working tree from a given branch/checkout.

bzr remove-tree [LOCATION]

Since a lightweight checkout is little more than a working tree this will refuse to run against one.

To re-create the working tree, use "bzr checkout".

checkout, working-trees

Show list of renamed files.

bzr renames [DIR]

status

Mark a conflict as resolved.

bzr resolve [FILE...]

Merge will do its best to combine the changes in two branches, but there are some kinds of problems only a human can fix. When it encounters those, it will mark a conflict. A conflict means that you need to fix something, before you should commit.

Once you have fixed a problem, use "bzr resolve" to automatically mark text conflicts as fixed, resolve FILE to mark a specific conflict as resolved, or "bzr resolve --all" to mark all conflicts as resolved.

See also bzr conflicts.

resolved

Revert files to a previous revision.

bzr revert [FILE...]

Giving a list of files will revert only those files. Otherwise, all files will be reverted. If the revision is not specified with '--revision', the last committed revision is used.

To remove only some changes, without reverting to a prior version, use merge instead. For example, "merge . --revision -2..-3" will remove the changes introduced by -2, without affecting the changes introduced by -1. Or to remove certain changes on a hunk-by-hunk basis, see the Shelf plugin.

By default, any files that have been manually changed will be backed up first. (Files changed only by merge are not backed up.) Backup files have '.~#~' appended to their name, where # is a number.

When you provide files, you can use their current pathname or the pathname from the target revision. So you can use revert to "undelete" a file by name. If you name a directory, all the contents of that directory will be reverted.

Any files that have been newly added since that revision will be deleted, with a backup kept if appropriate. Directories containing unknown files will not be deleted.

The working tree contains a list of pending merged revisions, which will be included as parents in the next commit. Normally, revert clears that list as well as reverting the files. If any files are specified, revert leaves the pending merge list alone and reverts only the files. Use "bzr revert ." in the tree root to revert all files but keep the merge record, and "bzr revert --forget-merges" to clear the pending merge list without reverting any files.

cat, export

Show current revision number.

bzr revno [LOCATION]

This is equal to the number of revisions on this branch.

info

Show the tree root directory.

bzr root [FILENAME]

The root is the nearest enclosing directory with a .bzr control directory.

Mail or create a merge-directive for submiting changes.

bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]

A merge directive provides many things needed for requesting merges:

• A machine-readable description of the merge to perform
• An optional patch that is a preview of the changes requested
• An optional bundle of revision data, so that the changes can be applied directly from the merge directive, without retrieving data from a branch.

If --no-bundle is specified, then public_branch is needed (and must be up-to-date), so that the receiver can perform the merge using the public_branch. The public_branch is always included if known, so that people can check it later.

The submit branch defaults to the parent, but can be overridden. Both submit branch and public branch will be remembered if supplied.

If a public_branch is known for the submit_branch, that public submit branch is used in the merge instructions. This means that a local mirror can be used as your actual submit branch, once you have set public_branch for that mirror.

Mail is sent using your preferred mail program. This should be transparent on Windows (it uses MAPI). On Linux, it requires the xdg-email utility. If the preferred client can't be found (or used), your editor will be used.

To use a specific mail program, set the mail_client configuration option. (For Thunderbird 1.5, this works around some bugs.) Supported values for specific clients are "evolution", "kmail", "mutt", and "thunderbird"; generic options are "default", "editor", "mapi", and "xdg-email".

If mail is being sent, a to address is required. This can be supplied either on the commandline, by setting the submit_to configuration option in the branch itself or the child_submit_to configuration option in the submit branch.

Two formats are currently supported: "4" uses revision bundle format 4 and merge directive format 2. It is significantly faster and smaller than older formats. It is compatible with Bazaar 0.19 and later. It is the default. "0.9" uses revision bundle format 0.9 and merge directive format 1. It is compatible with Bazaar 0.12 - 0.18.

Merge directives are applied using the merge command or the pull command.

merge, pull

Run the bzr server.

bzr serve

server

Sign all commits by a given committer.

bzr sign-my-commits [LOCATION] [COMMITTER]

If location is not specified the local tree is used. If committer is not specified the default committer is used.

This does not sign commits that already have signatures.

Split a subdirectory of a tree into a separate tree.

bzr split TREE

This command will produce a target tree in a format that supports rich roots, like 'rich-root' or 'rich-root-pack'. These formats cannot be converted into earlier formats like 'dirstate-tags'.

The TREE argument should be a subdirectory of a working tree. That subdirectory will be converted into an independent tree, with its own branch. Commits in the top-level tree will not apply to the new subtree.

Display status summary.

bzr status [FILE...]

This reports on versioned and unknown files, reporting them grouped by state. Possible states are:

added

Versioned in the working copy but not in the previous revision.

removed

Versioned in the previous revision but removed or deleted in the working copy.

renamed

Path of this file changed from the previous revision; the text may also have changed. This includes files whose parent directory was renamed.

modified

Text has changed since the previous revision.

kind changed

File kind has been changed (e.g. from file to directory).

unknown

Not versioned and not matching an ignore pattern.

To see ignored files use 'bzr ignored'. For details on the changes to file texts, use 'bzr diff'.

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 -SV.

If no arguments are specified, the status of the entire working directory is shown. Otherwise, only the status of the specified files or directories is reported. If a directory is given, status is reported for everything inside that directory.

If a revision argument is given, the status is calculated against that revision, or between two revisions if two are provided.

st, stat

diff, revert, status-flags

Set the branch of a checkout and update.

bzr switch TO_LOCATION

For lightweight checkouts, this changes the branch being referenced. For heavyweight checkouts, this checks that there are no local commits versus the current bound branch, then it makes the local branch a mirror of the new location and binds to it.

In both cases, the working tree is updated and uncommitted changes are merged. The user can commit or revert these as they desire.

Pending merges need to be committed or reverted before using switch.

The path to the branch to switch to can be specified relative to the parent directory of the current branch. For example, if you are currently in a checkout of /path/to/branch, specifying 'newbranch' will find a branch at /path/to/newbranch.

Create, remove or modify a tag naming a revision.

bzr tag TAG_NAME

Tags give human-meaningful names to revisions. Commands that take a -r (--revision) option can be given -rtag:X, where X is any previously created tag.

Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge.

It is an error to give a tag name that already exists unless you pass --force, in which case the tag is moved to point to the new revision.

commit, tags

List tags.

bzr tags

This command shows a table of tag names and the revisions they reference.

tag

Show testament (signing-form) of a revision.

bzr testament [BRANCH]

Convert the current checkout into a regular branch.

bzr unbind

After unbinding, the local branch is considered independent and subsequent commits will be local only.

bind, checkouts

Remove the last committed revision.

bzr uncommit [LOCATION]

--verbose will print out what is being removed. --dry-run will go through all the motions, but not actually remove anything.

If --revision is specified, uncommit revisions to leave the branch at the specified revision. For example, "bzr uncommit -r 15" will leave the branch at revision 15.

In the future, uncommit will create a revision bundle, which can then be re-applied.

commit

Update a tree to have the latest code committed to its branch.

bzr update [DIR]

This will perform a merge into the working tree, and may generate conflicts. If you have any local changes, you will still need to commit them after the update for the update to be complete.

If you want to discard your local changes, you can just do a 'bzr revert' instead of 'bzr commit' after the update.

up

pull, status-flags, working-trees

Upgrade branch storage to current format.

bzr upgrade [URL]

Branch format:

--format=ARG	Upgrade to a specific format. See "bzr help formats" for details.
--default	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--development	Current development format. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar-vcs.org/latest/developers /development-repo.html before use.
--development-subtree
	Current development format, subtree variant. Can convert data to and from pack-0.92 (and anything compatible with pack-0.92) format repositories. Repositories in this format can only be read by bzr.dev. Please read http://doc.bazaar- vcs.org/latest/developers/development-repo.html before use.
--dirstate	New in 0.15: Fast local operations. Compatible with bzr 0.8 and above when accessed over the network.
--dirstate-tags
	New in 0.15: Fast local operations and improved scaling for network operations. Additionally adds support for tags. Incompatible with bzr < 0.15.
--knit	Format using knits. Recommended for interoperation with bzr <= 0.14.
--metaweave	Transitional format in 0.8. Slower than knit.
--pack-0.92	New in 0.92: Pack-based format with data compatible with dirstate-tags format repositories. Interoperates with bzr repositories before 0.92 but cannot be read by bzr < 0.92. Previously called knitpack- experimental. For more information, see http://doc .bazaar-vcs.org/latest/developers/packrepo.html.
--rich-root	New in 1.0. Better handling of tree roots. Incompatible with bzr < 1.0
--rich-root-pack
	New in 1.0: Pack-based format with data compatible with rich-root format repositories. Incompatible with bzr < 1.0
--weave	Pre-0.8 format. Slower than knit and does not support checkouts or shared repositories.

The check command or bzr developers may sometimes advise you to run this command. When the default format has changed you may also be warned during other operations to upgrade.

check

Show version of bzr.

bzr version

Show version information about this tree.

bzr version-info [LOCATION]

format:

--format=ARG	Select the output format.
--custom	Version info in Custom template-based format.
--python	Version info in Python format.
--rio	Version info in RIO (simple text) format (default).

You can use this command to add information about version into source code of an application. The output can be in one of the supported formats or in a custom format based on a template.

For example:

bzr version-info --custom \
  --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n"

will produce a C header file with formatted string containing the current revision number. Other supported variables in templates are:

• {date} - date of the last revision

• {build_date} - current date

• {revno} - revision number

• {revision_id} - revision id

• {branch_nick} - branch nickname

• {clean} - 0 if the source tree contains uncommitted changes,

  otherwise 1

Show or set bzr user id.

bzr whoami [NAME]

Show the email of the current user:

bzr whoami --email

Set the current user:

bzr whoami "Frank Chu <fchu@example.com>"