Re: numpy 1.2.1, switching to git?
On Sun, Dec 21, 2008 at 12:08:18AM +0100, Ondrej Certik wrote:
> On Sat, Dec 20, 2008 at 7:49 PM, Steve Langasek <vorlon@debian.org> wrote:
> >> as it is really ugly to use
> > Ugly how?
> Well, it's just slow ---- once you get used to git and how fast it is,
> it really sucks to wait for basic operations like "bzr di". See e.g.
> my comparison here:
> http://www.selenic.com/pipermail/mercurial/2008-August/021009.html
Well, there are a few things I would point out about this:
- This compares a single operation. Broader comparisons of the tools have
shown that bzr is faster at some operations, git is faster at others.
- The performance profiles of the tools have changed over time; indeed, the
"diff" operation in particular is one where git is not an absolute winner.
<http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/>
shows that git used to be slower than bzr at a diff of a tree with
changes, now it's faster; git has always been faster than bzr at diffing a
tree with no changes, but bzr has been closing the gap.
- The bzr team continues to work on the performance of the tool, so <ahem>
"past performance is not a guarantee of future returns".
It may be true that users find bzr slower than git overall for their work;
the above comparison doesn't prove this, though, and I worry that this may
mostly be a self-perpetuating meme: if your expectation is that a tool is
slow, it's going to *feel* slower even if it's not slower overall.
I think there are other important metrics besides raw speed, such as whether
the learning curve is approachable by the community you're trying to reach,
and whether the tool's basic operations have a granularity that's optimized
for the common case; I think these are two areas where bzr wins over git,
but YMMV.
> But as Bernd said, let's not start a flamewar about this. But I think
> it's useful to see what all the debian-python developers think. As I
> told Matthias offlist, we should only switch to git if most of
> developers are fine with that.
I think we're managing to steer clear of flamewar territory so far; but
since I'm not a part of the DPMT and am only tangentially affected by the
team's decision, I shouldn't get a vote and you should feel free to tell me
to shut up about bzr at any time. :) I'm commenting because I'm genuinely
curious about the reasons people would consider bzr ugly, and because you
asked me a question in response to my post, not because I think there's any
reason you guys should listen to me when deciding what tools to use: the
point about Ubuntu being a downstream that makes heavy use of bzr has
already been made, and I don't really have anything to add to that.
> Yeah, but since we are talking about that --- Steve, do you really think
> that bzr has any future? I know that Ubuntu is using it a lot, and couple
> other projects (mostly hosted on Launchpad), but that's about it. Git, on
> the other hand, is used a lot in Debian, and in a lot of other projects.
> Also you have many places on the internet to store your repository
> (github, gitorious, git.debian.org, ...).
Well, the "couple other projects" include things like MySQL, which isn't
small potatoes.
http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
There is also a bzr.debian.org in addition to the git.debian.org, so it's
not that Launchpad is the only place to host bzr branches, and of course you
can generally host a bzr branch anywhere via http, so we're not
single-vendor in terms of hosting. (I use bzr.debian.org myself for a
couple of packages that I maintain, because there are substantial benefits
to me to being able to use the same VCS for Debian and Ubuntu branches.)
So overall, yes, I think bzr does have a future. Even if we only consider
Ubuntu, that's a large project with a lot of momentum related to its use of
bzr (c.f.: Linux/X and git, or Mozilla and hg), which will cause it to be
relevant for some time regardless - and I think it will certainly be
relevant long enough for us to see a bzr-git bidirectional implementation,
at which point users will have the option of choosing the tools they like
anyway, instead of having to choose the tools that work with the repo they
need to contribute to.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
33
Reply to: