Echoing a post: bzr vs. git

[David Cournapeau]

Gour wrote:
>
> Some of your annoyances like 'One branch per directory' is pleasure for
> me 'cause I liked the concept while using darcs and I'm not at all
> annoyed with revno-s - probably due to not being exposed to unhealthy
> svn-rays ;)

The revno point has nothing to do with svn. I have never liked svn, and
I always found it complicated (I think linus really has a point when he
says that svn infects your brain, in the sense that people don't realize
that DVCS are simpler when you have never used svn/cvs before; that
certainly my own experience at least).

The revno problem appears with branches: when you have several parallel
branches, you can't rely on the ordering of revno. And they are
confusing in that case (the example of commit 299.1.4 being after 300 in
one branch). Now, there is a perfect explanation for that, if you really
know how revno work. But I am arguing this is much more complicated than
just using sha-1 (or revid). Because git has no revno, they had
developed in the UI a lot of really cool features to name
branches/commits (show me the commits of the last two days, show me the
grand parent of this commit, etc...); OTOH, I feel like revno gave a
false sense of "good enough" (I don't think people use revid on an every
days basis), and  now, in the case of multiple branches, you have no
real UI alternative in bzr.

IOW, if you use parallel branches, revno idea breaks horribly IMHO, and
it does not worth the simplicity it brings otherwise. I would go as far
as saying that that's the only point of my post which is not subjective.

> Since the project will be multi-platform (in Haskell), and some devs are
> accustomed to work with Windoze and/or prefer GUI tools, bzr was, once
> again, clear winner.  :-)

In my experience, GUI tools are nowhere near ready for any open source
DVCS I have used, being git, hg or bzr. This is a really hard problem, I
think it will take years before people really understand how to do it
(and implement it).

I would argue that for those people, git and bzr are almost as
complicated, because they are different from svn anyway. Without a GUI,
they will never use the product. I am mainly interested for a DVCS for
developing, and I am not interested in collaborating with people who
can't use the command line when I am coding open source projects.

>
> The performance is not a problem for me and, imho, it's way too much
> overrated (for DVCS tool) in different comparisons.

It depends on the projects. I have tried to prepare a patch using the
bzr repository of python, I could not stand it. We are not talking about
0.4 vs 0.1 s, but about 0.1s vs 2 minutes. If it takes more than one
minute for any command, the tool can't be used. And if it is slower than
svn (and bzr is slower than svn for many operations on some projects I
have privately converted from svn), you will have a hard time pushing it
for projects which use svn today.

A lot of projects cannot go the bzr route because it is too slow; those
big projects are not the majority, of course, but having big projects
using the tool means that the tool gets a lot of traction. Git would not
be nowhere near it is today if it was not used for the kernel, I think.

But again, speed is not my main problem with bzr. I think it is
certainly hurting bzr, but bzr developers are aware of it, so I don't
think it was worth being discussed much.

> Heh, in my case when I was using darcs I kept ALL the stuff under it -
> it's the same with bzr now. That's one BIG advantage for me, i.e. having
> one DVCS tool which fulfills all my needs - that's maybe why I switched
> From Vim to Emacs ;) 

I think this point won't matter much soon, at least in the open source
space, because you will have to know about git anyway, like you have to
know about svn today.

cheers,

David