A great advantage of all DVCS is that they completely cover use cases for RCS
or SCCS too, i.e. totally local usage.  If you ever want to start sharing the
repository more widely, it's easy to do so.
Another great advantage is that the metadata and database are not spewed all
through the work area subdirectories but reside only under .bzr of the top dir.
Hence the switch "--no-trees" to mean no working files/dirs.
I guess one could call the work directories for a single branch the "work tree".

BRANCH SWITCHING IS CLEARLY INFERIOR TO Git.

DVCS = Decentralized...
Centralized = Non-DVCS.

"bzr help *" does not page automatically.  You have to use shell to pipe:
     bzr help checkout | more
"bzr help topics" for less command-specific help.

Generally, wrt remembering default associated branches, the first other
repository used for that purpose will be used unless you give switch
"--remember" which means to update the default with this one.

Repository directory is an optional parent dir of branches.  Purpose is to share
metadata files for efficiency.  "bzr info" of branches shows whether in a
repository.
Initialize central repo with:
    bzr init-repo --no-trees
to skip work files.
I guess you should not push from treeless branches, since you can't get the
 trees from that.  ("pulling" checkouts and branches do make work areas).

User global settings in $HOME/.bazaar/*.
bazaar.conf stores your "whoami" information, and you can set
mail_client = thunderbird

IGNORES
Nice:  "bzr ignored"
Per-branch file is .bzrignore.  THIS IS NOT PER-DIRECTORY, BUT PER-BRANCH
 and resides at top dir of branch!
Just like svn, the .bzrignore itself may be CMd or not, and you may still CM
 ignored files.
Global @ $HOME/.bazaar/ignore

Branching is completely different.  With the exception of work areas below a
"--no-trees" repository, work areas correspond 1:1 with branches, so I'll use
the terms interchangeably.

Snapshotting is completely different.
Bar commits commit the file contents at the time of commit.
No "snapshotting" occurs at add time like with Git.

Your work area "is" a branch, with possible relationships to other branches.
"Switching" is not general like in svn, but is limited to Centralized workflow
and just changes which other branches this branch is associated with.

IMPORTANT!
"bzr pull" and "bzr push" mean that you want to mirror the other side.
Therefore if you want to get updates from more than one source, use merge
instead.
"bzr clone" is very different from Git's clone, and is much more limited.

MERGING  (merging fetches updates from another branch with some common ancestry)
(This is conceptually a "pull", but don't confuse this with the "bzr pull"
command which additionally enforces exact mirroring).
A branch may "bzr merge" from the 'parent branch' (if this branch was created
via "bzr branch x y"), or from any other 'submit branch'.
"bzr info" shows 'parent' and 'submit' branches.
"--remember" switches can change the default associated branches.

PUSHING/publishing is for direct mirroring, not for just contributing to
another branch.
"bzr info" shows the default 'push branch', though you can specify any dest.
The default 'push branch' can be changed with --remember switch.
The pushee branches show no association to pusher with "bzr info".
The "--create-prefix" option just means to mkdir the new dest directory.

bzr send    To merge updates from a branch to a parent, must use "bzr send".
    If the branch is accessible to the parent repository, then
     ?use "--no-bundle".
    Must have a destination, by default email.  Either:
        Give -o file.name  to send to file instead of emailing
        OR
        --mail-to=dest@addr     (or other ways of specifying dest addr)
        --plain to only produce the directive (don't work for file branches)
OR
bzr merge-directive    Requests a merge
    Also has --mail-to=
    How in hell would you use this to request a merge of a remotely-hosted
     branch?
After the merge on the source side, I don't know how to pull down and take care
of the resulting conflicts.

BINDING is a more direct association between work areas, where a local
commit (by default) also applies the commit to the remote repository.
Accomplished via "bzr checkout" or "bzr bind".

CENTRALIZED WORKFLOW  (traditional SCM)
(These work areas are at least sometimes not called "branches" in the docs).
"bzr info" shows the branch checked out from.
You "checkout" instead of "branch" from the central repository.
"bzr switch" = "bzr bind" + "bzr update" can change the source repository.
 (Says need, after this, to either "bzr revert" or "bzr commit" to say what to
 do with local committed and uncommitted changes).
Traditional Heavyweight vs. (new) Lightweight
    Heavyweight work areas are "bound".
    "bzr checkout --lightweight..." just does not get history info.
      CAN NOT --local WITH LIGHTWEIGHT
      BUT YOU DEFINITELY CAN "bzr switch".
Commits will commit to the parent branch's DB, but not to the work area until
 the parent branch "updates".  Usually you will have a --no-trees parent, so
 this will have no effect.
Use "update" to get changes from other side and/or to apply DB changes to your
 work tree.
LOCAL-ONLY CHANGES
    Either unbind then bind; or "bzr commit --local..." for every commit.
    To get your changes into the central repos, run a normal (bound) commit.

Useful:
    bzr commit --fixes BUGSYSTEMSID:BUGID
IMPORTANT GOTCHA!
    By default ALL CHANGES IN BRANCH ARE COMMITTED, even from parent dirs.
    If you specify dir path(s), then only from there downward commit.

GOTCHA
    "bzr remove" does not remove a file, but makes it untracked.


Nice way to merge "uncommitted" work changes between branches:
    bzr merge --uncommitted OLDDIR