bzr pull vs. bzr update

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > So my questions are more about Bazaar docs: why does BzrForEmacsDevs
 > recommends pull for a checkout, while the docs seem to uniformly
 > suggest that update is the right command?

I can't really speak for why the docs do things the way they do.
Although I'm coming to appreciate the features offered by the Bazaar
UI, I still think in terms of git's underlying model of the VC problem.

 > At which point of BzrForEmacsDevs something in the Emacs workflow
 > makes pull preferable to update?

It's not really appropriate to ask that.  It's not something about the
Emacs workflow.  The workflow in BzrForEmacsContent is simply a rather
generic workflow whose various components Karl or I are confident
(a) will work, (b) will leave a reasonably readable history, and (c)
are a good foundation for developing personal best practices.  Not to
belittle (d) something either of us can explain and/or debug in our
sleep.

The common Emacs workflow can be fitted to any number of personal
workflows, and there is no particular need for those workflows to be
the same, as long as the individual developers are willing to work
things out for themselves, with a *little* help from their friends.
Experience shows that (except in very centralized, very well-connected
projects, where the optimum often seems to be lightweight checkouts
for all committers) developers will have varying preferences.  The
recommendations of BzrForEmacsDevs, on the other hand, are a
compromise, one-size-fits-all, intended to generate easily answerable
FAQs rather than one-of-a-kind wedged branches.

 > And where in the Bazaar docs there is a clear explanation of pull
 > vs. update, so a newbie can understand the trade-offs?

:-( I haven't found one.  Until John mentioned it just now, I wasn't
aware of the subtle difference that a checkout doesn't set the parent
pointer, while binding a branch does.  Thus pull and update determine
the default source of new revisions in different ways, and neither can
be defined in terms of the other.

And in fact I got this wrong (and it's still wrong :-(), when I wrote
the original version of the table of commands in
http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
-- I defined update in terms of pull and the parent, which update
doesn't use according to John.  *sigh*