bzr pull vs. bzr update

[Stephen J. Turnbull]

Matthew D. Fuller writes:

 > If you want to update a checkout to catch up changes in the branch,
 > you want 'update'.  That 'pull', with an appropriate parent location,
 > in a heavy checkout, also seems to do the same thing is sheer
 > coincidence and a terribly ugly break of the model.

If you think about it as a workspace checkout which can be updated
without full synchronization, yes.  If you think about it as a local
mirror of the parent branch (which is what the workflow is intended to
be), it's not clear that it's a break of the model at all.  In fact,
the help for pull says:

    Purpose: Turn this branch into a mirror of another 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) into the parent.

That is exactly what we want (we = "the authors of BzrForEmacsDevs"[1];
Juanma may have something different in mind, or he may not yet be sure
what he wants but it's probably different, or maybe he even agrees
with me).  In particular, we do not want to automatically merge
upstream into the local mirror if there are unpushed changes, but
update will do that.

BTW, this workflow is based on the scenario "Repeated Contributions"[2]
on the wiki.  There binding the branch is described as a "belt and
suspenders" approach to preventing divergence (specifically, an
attempt to commit a merge from the local workspace will fail if the
mirror is not up-to-date).

 > So, yes, if you want to update the _BRANCH_, you absolutely want to
 > use 'pull' in a checkout [of that branch].  If you want to update the
 > _CHECKOUT_, you want to use 'update', and do your best to forget that
 > if certain stars are aligned right, 'pull' seems to do the same thing.

But we don't want to "update" anything -- that implies we know about
*and accept* lags *and other differences* between the parent and the
local branch.  Rather, we want to ensure synchronization of two
branches; the user should not see any lags.  In theory,
synchronization should happen in the background.[3]  In practice, pull
*does* DTRT, although it may not have been designed for that.

Footnotes: 
[1]  http://www.emacswiki.org/cgi-bin/emacs/BzrForEmacsDevs

[2]  http://wiki.bazaar.canonical.com/Scenarios/RepeatedContributions

[3]  In our case, I think we would like bzr merge to realize that the
branch is bound and do a pull before trying to merge, or perhaps do
the update and stop, telling the user that there were new changes that
they should merge into their working tree and test before merging.