[IPython-dev] Bazaar on OS X

[David Cournapeau]

On Sun, 2008-06-29 at 00:43 +0200, Stéfan van der Walt wrote:
> 2008/6/26 Fernando Perez <fperez.net at gmail.com>:
> > I think that we only have a small issue, and it's one I'm willing to
> > ignore from now on: Launchpad (*not* bzr, since bzr viz/log is
> > faithful to the full history) ignores all but one branch when showing
> > history, and what it actually shows can change with each commit.  When
> > they improve their display, great, but until then let's just ignore
> > that point (we're all too busy here to spend time fixing lp).
> >
> > But the fact that sometimes one *must* merge is unavoidable with
> > distributed development: even using a special branch for communicating
> > with upstream, merges sometimes are unavoidable.  Else I'm really
> > missing something here.
> 
> The above two paragraphs give a good summary of the "problem" and the
> solution, which corresponds with my understanding of the situation.

I think the problem is kind of different, actually. At first, I got the
same understanding of the issue as you, but I realized later that that's
not the problem at all. The 'ugly' history is inherent to bzr way of
doing things; as Villo noted, it more a trade off than a weakness of
bzr.

bzr emphasizes the current branch (mainline) as special. That's the
fundamental difference between bzr and hg/git here. In git and hg, what
happens when you merge a branch is that you 'append' the new revisions
to the DAG. It means you have a flat log, and you can see every commit
at the same level:

   /------B ----- C ------\
A -                        -----> merge -> F
   \------D ------ E -----/

Here is what you get with git (and hg, too, I think; I am more into git
ATM, for an alternative to hg):

commit a1effecf343bb69e931670eedf3e68c1b6e135b6
Merge: be91f09... 0745401...
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:27 2008 +0900

    Merge branch 'b1' into b2

commit be91f099bb570f381bb79d6091f7453cac05c857
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:13 2008 +0900

    Commit E.

commit 0745401f2601c0595e294f3cb29f58c94b57292f
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:00 2008 +0900

    Commit C.

commit da6b022593196cf15b9491b23efad3003f6a60fe
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:34:36 2008 +0900

    commit D

commit 1a1b17e4b48861b3d29b184d9ea65736a8a4ed30
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:33:44 2008 +0900

    Commit B

commit 66bfd488a0848e10e677eba2c26a56e02413b686
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:32:47 2008 +0900

    Commit A

With bzr, you have something quite different:

------------------------------------------------------------
revno: 4
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:39:49 +0900
message:
  Merge b2.
    ------------------------------------------------------------
    revno: 1.1.2
    committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
    branch nick: b2
    timestamp: Mon 2008-06-30 10:39:27 +0900
    message:
      Commit E.
    ------------------------------------------------------------
    revno: 1.1.1
    committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
    branch nick: b2
    timestamp: Mon 2008-06-30 10:38:57 +0900
    message:
      Commit D.
------------------------------------------------------------
revno: 3
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:39:13 +0900
message:
  Commit C.
------------------------------------------------------------
revno: 2
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:38:30 +0900
message:
  Commit B.
------------------------------------------------------------
revno: 1
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: trunk
timestamp: Mon 2008-06-30 10:37:56 +0900
message:
  Commit A.

The 'ugly' history, to use Fernando's words. The difference:
	- the log does look confusing if you are used to git/hg
	- you can *not* have a flat log ala git/hg, contrary to what I thought
previously. I was confused by the description of some bzr developers,
when they mentioned merge --pull. It is actually not really useful, and
does not do what git/hg do at all when you merge. Better forget it, I
think.
	- but this has a nice property: at any revision of the mainline, the
tree is in a workable state. In bzr development itself, the merge to the
mainline are not done manually, but through a gatekeeper: in particular,
the merge will be refused if it does not pass the test suite. You cannot
do that with git/hg I think (at least not as naturally). bzr developers
call this the merge-review-commit workflow.

Honestly, I don't really see the problem with the code browsing on
launchpad: I just never use it and don't see a big use for it. Since now
you have the whole history, what's the point (as a regular developer, at
least, that is if you have the branch on your computer) ? Having the DAG
displayed would be much better, yes. But since again, you can do it
locally (bzr visualize)... The problem is more the availability of those
tools on non free OS (windows and mac os X).

Concerning history folding, it can become really ugly when you work on
several branches at the same time and need to merge one from the other
(typically, I encountered this in the following quite usual scenario:
start a feature branch, then see a bug in this branch, fix the bug in
another branch, and then merge the fix into mainline and merge mainline
into feature branch). You can do with rebase, but it does not work that
well with bzr (I think this is because contrary to git, which
essentially guesses everything, bzr uses a lot of meta-data; again, this
has advantages and disadvantages); and rebase has its own problem, too.
There is no win-win scenario that I am aware of.

I think what Brian said is really important (you never the nice things
of the tools you are using, you never see the bad things of the tools
you are not using). The only way is to use the tools on a daily basis.

cheers,

David