Bazaar still below the radar when evaluating VCS tools

[Parth Malwankar]

On Sat, Feb 27, 2010 at 2:06 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 26 February 2010 20:12, John Arbash Meinel <john at arbash-meinel.com> wrote:
>>> I'm curious to know if there are good reasons for the difference (that
>>> "40811 revisions" vs "5504 changesets with 25490 changes" is
>>> suspicious, and I guess Launchpad may still be on an old repo format)
>>
>> ^- Changesets vs revisions is pretty close to the same thing. So
>> Mercurial has 1/8th the history that the Bazaar branch has. Why? I don't
>> know, but that is certainly significant.
>
> I thought that might be how to interpret it. So that quite probably
> explains the time difference.
>
> The big problem is that for obvious reasons, there's no significantly
> sized project with relatively official repositories in more than one
> DVCS format - so comparing like with like is extremely difficult.
>
> Yet more proof that all benchmarks are lies, I guess...
> Paul.
>

Agreed. What I meant was, that bzr could have speed benchmarks
for medium and large projects on its page. At least in my case (I was
coming from SVN) I was trying to understand, (a) if bzr is 'fast enough'
for most common workflows (bzr check is not something I do much)
and (b) does bzr-core team care enough about performance.

When I was evaluating bzr, I found git to be very fast which was
cool, but I found bzr performance acceptable. I also found a bzr page
(maintained bzr dev team) that tracked bzr performance v0.7 vs 0.8
vs N+1. There was a good explanation of how these numbers were
being generated (a 'bzr benchmark' command IIRC). This told me that
bzr devs cared enough about performance and I got to see some
numbers on all ops giving me a feel for what I was getting into if I
moved to bzr. So while bzr was definitely "the slowest" among the
top three DVCSes, it was 'good enough' for my needs. Unfortunate,
this page seems to be lost in time (couldn't locate it on google) and
was going out of use when I started moving to bzr (1.13).

So, I think it may work out well for bzr to avoid going down the
'bzr vs X' path altogether. It can quickly turn into a discussion that
doesn't help a guy simply trying to decide (X uses hardlinks, Y has
smart server running, we dont use shared repo etc.)
For a lot of people, is this fast enough for me may be the question
(I think). So as someone mentioned in the list, its an advocacy
question. If I see bzr number for a well known project (say a
python or emacs mirror on lp) with the recommended workflow, looking
at it can quickly answer my question, is this fast enough for me.
That certainly won't tell me if X is faster, but I would probably say,
looks like bzr has good numbers for commonly used command for
say, python with NNNNN versions and I have just 2000 revs so it
would definitely work for me. Most of the people wanting to do the
move are probably going to be moving for svn so I suspect that would
help. Right now, we do see numbers for space benchmark in bzr
docs (and its really cool to see that ".bzr" is nearly as compact
as ".git") but if someone want to know how bzr performs, he has
no way of knowing this. There is access to old naive blog post
with much earlier bzr versions.

An svn user evaluating bzr  is probably not going to know enough
about DVCS workflows to do the right benchmarks, so he will
probably do something that really slow and say bzr is slow, _or_
go with the numbers presented in the old blog posts.

Anyway, the point being that it may be worthwhile having bzr
performance numbers (not bzr vs X) with the recommended
workflow, easily available to some svn user evaluating bzr.

Looks like my rant is becoming longer than I hoped so I
will just shut up now :-)

Regards,
Parth