Usage discussion from the GNU Emacs project.

[Óscar Fuentes]

Jason Earl <jearl at notengoamigos.org> writes:

> Óscar Fuentes <ofv at wanadoo.es> writes:
>
>> Perfomance sucks. Having to distribute a tarball with the repository
>> because bzr takes so long to clone "trunk" is a shame. It requires 23
>> minutes with the http protocol over ADSL 6Mb, on a fast machine (bzr
>> version 2.0). Besides, I discovered with much despair that cloning is
>> a CPU-bound process for bzr, as cloning the same branch to a 1.6 GHz
>> netbook over the local network with the sftp protocol took half an
>> hour, with the CPU almost always at 100% (bzr version 2.1-b3).
>
> Over the past year I have gotten a little bit tired of hearing about
> bzr's poor performance.  This is especially true when I believe that
> git's supposed speed advantage is only imagined, and not actually
> measured.  I've checked out the Emacs repository using git on a regular
> basis for the last year or so, and I did not remember this feat ever
> taking less than 20 minutes.
>
> So, just for fun, I checked out the git repository that the bzr
> repository is created from.

First things first: I don't care about how much time git requires to
fetch the repository. My point is that if you need to resort to creating
tarballs for distributing your branch, `bzr branch' is not up to the
task.

> time git clone git://repo.or.cz/emacs.git emacs-git-andreas
>
> real    25m21.055s
> user    13m17.734s
> sys     1m8.396s

Just tried it and it took

real    11m16.224s
user    5m25.540s 
sys     0m8.660s

Are you using git on Windows, by chance?

> Then to be especially perverse I used a straight http url instead of the
> special git server.  This test was surprisingly bad.
>
> time git clone http://repo.or.cz/r/emacs.git  emacs-git-andreas2
>
> real    117m28.122s
> user    91m37.752s
> sys     4m58.323s
>
> Interestingly enough, the process was CPU bound almost the entire time.

For me it was CPU bound on the "Resolving deltas" phase. The "Receiving
objects" phase was net-bound (over a 6 Mb/s ADSL connection).

[snip]

> And if you think bzr's progress indicator is bad you should see what
> git's http progress indicator looks like.  It was so bad that I actually
> checked out the newest copy of git from the git repository so that I
> could see if they had fixed it.  I assumed that the output I got was due
> to some sort of bug.

git's progress indicator allows to figure out how much work is left (at
least while accessing through the `git' protocol, haven't checked
http). It shows an object count indicator (in the form of n/N), download
rate and a percentage.

>> While cloning, the progress bar is worse than useless. It gives no clue
>> about how much remains to be done, so after 15 minutes of looking at it
>> it turns from boring to annoying. Actually, it exacerbates the
>> impression of bazaar's slowness.
>
> I certainly agree that bzr's progress bar on http clones is sub par.  It
> is not as bad as git's http clone output.

My experience is that the progress bar over sftp is the same as
http. Maybe the smart server allows bzr to show more a more informative
progress indicator?

[snip]

> And either way bzr is much better than cvs.

:-)

-- 
Óscar