noob - understanding branches diverged

[Stephen J. Turnbull]

Mike Mattie writes:
 > On Wed, Apr 15, 2009 at 01:08:02PM +0900, Stephen J. Turnbull wrote:
 > > Mike Mattie writes:
 > > 
 > >  > 5. home box: pull - "branches have diverged"
 > >  > 6. home box: merge .... works.
 > > 
 > > AFAICS "bzr pull" is almost never what you want.  It definitely has
 > > very different semantics from all other VCSes that use that name for a
 > > command.  Specifically, since bzr doesn't have colocated branches, all
 > > branches other than the current one are "remote", and thus "bzr merge"
 > > must "go get" the new revisions, then merge them into the current
 > > branch.
 > > 
 > > Ie, "bzr merge" is analogous to "git pull" or "hg pull -u", not to the
 > > corresponding "merge" commands.
 > > 
 > > "bzr pull" is closer to "cvs update" than anything else.  It is
 > > looking for a fast-forward merge, and otherwise isn't very useful.
 > > 
 > 
 > Hmmmm
 > 
 > After much experimentation with my workflow I decided to use unbound
 > branches. I assumed that for unbound branches that the push/pull
 > commands were the appropriate way to send/receive changes between
 > unbound branches. That assumption came from git.
 > 
 > So what your are saying is that I should use merge instead ?

You said that after a pull you merged and it "works", so I assumed
that was OK with you.  And from there I assumed a git-style concurrent
hacking workflow where merges are not uncommon (or perhaps even
frenetic :-).  If so, yes, you should use bzr merge instead of bzr
pull, because bzr simply doesn't care where in the world the other
branch is, it happily fetches and merges, similar to what git does.
The difference in terminology is due to the fact that bzr assumes that
all other branches have a separate repo and meta data, while to git
there are "fetchable" branches, stored elsewhere, and "mergable
branches", stored in the same repo.

 > From my limited experience with GIT I think I do want a fast-forward
 > merge, but you think otherwise ?

I'm not sure exactly how recent git does this anymore, but AIUI what
happens on the master branch (or any other branch that is working as a
mirror of a foreign branch)

# what git pull actually does
git fetch master:remotes/origin/master    # always a fast-forward
git merge remotes/origin/master           # fast-forward if in sync

So if you're generally in the habit of hack here, commit, push; hack
there, commit, push; get telephone from Joe, pull from there, hack,
push; and so on, most of the time you'll be seeing fast-forwards.  (In
fact push is not the inverse of pull, it's the inverse of fetch, so it
must be a fast-forward in a generalized sense.)

Now, in bzr you'd have to manage this explicitly.  If you want to get
fast-forwards *all* the time, you could have an explicit local mirror
which you always use as follows:

bzr update
bzr merge local-work
bzr push

and even then if somebody happens to update the remote repo
concurrently, you're going to have to revert the merge, pull, redo the
merge, and push.  You never do any hacking in the local mirror, or if
you do you commit and push asap.

In fact, this makes little sense in bzr.  What you may want is a
checkout, which has a central "official" repository, an (optional)
local "mirror"[1] repository, a local branch, and a local workspace.
See Ian's initial post in the "[MERGE/RFC] Userdoc Driven Design on
the Bazaar 2.0 UI", especially the tutorial, as well as (for example)
Neil Martinsen-Burrell's replies.  I'm not sure I agree with all his
ideas about "data integrity" but his viewpoint may be very close to
your requirements.

I'm not sure if this really answers your question, though.


Footnotes: 
[1]  I prefer "mirror" to "cache" as some others have called it
because (up to losses since the last sync) it is a fully functional
replacement for the official mirror.  Firebomb the original repo's
machine, OK, now everybody has to update one URL in their ws/.bazaar
and you're up and running again!