noob - understanding branches diverged

[Mike Mattie]

On Fri, Apr 17, 2009 at 03:02:28PM +0900, Stephen J. Turnbull wrote:
> 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.

That does click. The merge did indeed work for me but it hosed the
assumptions that my Emacs interface was based on. I suspect that by
digging deeper into the revision ids, x.x.x.... I can get what I
need.

As long as the resolution of conflicts in a merge shows up as
commit/delta distinct from the changes pulled that caused a conflict
cherry picking from diverged branches will not be degraded from the
"not diverged" case.

However it shakes out I need to do some more experimenting on my own
at this point to burn some more knowledge in.

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

I really appreciate the detailed response. It does help quite
a bit actually.

I have read the bzr docs on the website a few times, but I am still
experimenting to get a handle on the features and concepts.

The RFC thread was very useful actually. I did not understand it
completely but it shed some light on some areas that were difficult
for me to grasp from the documentation.

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

Luckily I am experimenting on myself, or rather my own/isolated
repositories before I inflict my knowledge and skills on others.

Thank you again for taking the time to explain it to me.

Cheers,
Mike Mattie

-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090417/06e31646/attachment.pgp