Some unscientific timing results (on the Python source tree)

[Paul Moore]

On 24/03/2008, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:

> I understand the nuisance as a user, but I am not sure you can blame bzr
>  if nobody set it up for good performances. Maybe bzr server is harder to
>  set up than mercurial, at which point it is a bzr problem (I don't say
>  it is, I just don't have that experience).

That's possibly true, although I could argue that if it needs special
care to set up a reasonably-performing Bazaar server, then there's
something wrong in Bazaar (with the default settings, at least).

>  > I dispute "reasonable".
>
>  No need to dispute, that was just my broken English :) I meant expected.

Sorry, I get a bit obsessive about precise English, which is a
particularly obnoxious habit when I forget that people may not be
native speakers. It might be more acceptable if I could speak any
other language comprehensibly :-)

> I don't know about bzr team's directions, but some of the differences
>  you pointed are known (log, and blame (?) I think are significantly
>  slower than on mercurial) . Some other, I don't consider them as
>  important (0.5 vs 1s for example: if you don't like latency, you can use
>  bzr shell to avoid the overhead of bzr launch; that's what I am using
>  myself).

Oh, I agree absolutely. The individual figures don't matter much, it's
the pattern (always slower, and significantly so for key operations
like branching) that worries me. That and the fact that I have to
organise my working practices to stay fast (using a repository, which
limits my choice of disk location for where I work - I know I can bzr
branch in the repo, then bzr checkout, but that takes a total of over
3 minutes, as well as being a much more complex set of commands).

Ultimately, any VCS needs to be smooth enough and quick enough that
it's in practical terms no overhead to use it. Otherwise laziness sets
in (with me, anyway :-))

Oh, and just another point - all of this is only of issue with a big
repository. Shallow branches (where I can in effect pretend that any
history before Jan 2008, say, in the main repository, does not exist)
would make every repository "small", and completely bypass the issue.

Paul.