Usage discussion from the GNU Emacs project.

[Jason Earl]

Óscar Fuentes <ofv at wanadoo.es> writes:

> 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.

It is hard to argue with that.

I was the guy that originally suggested making premade repositories for
Emacs developers.

However, that was a year ago when bzr branch on the Emacs repository of
the day took several hours.  These days downloading a tarball is not
really that much of a time saver.  Yes, bzr (without a smart server) is
slower than git with a smart server.  If you have a very powerful
machine git might save you a whole ten minutes.  Once.

That's assuming that we could talk the savannah hackers into allowing
the git protocol.

>> 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?

GNU/Linux Ubuntu 9.10.  I would bet that your machine is simply a *lot*
more powerful than mine.

>> 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).

Was that with the http url or the git one?  When I used the git url my
experience matched yours.  For me the http url was far more
pathological.

>> 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.

git's progress indicator (if it can be called that) when using http is
completely different than when using the git protocol.

It looks something like this:

Initialized empty Git repository in /home/jearl/tmp/emacs/.git/
Getting alternates list for http://repo.or.cz/r/emacs.git
Getting pack list for http://repo.or.cz/r/emacs.git
Getting index for pack e68ad9b728a83cfcb0a95b00fb7783d57ca502cc
Getting index for pack 2c775595dbd0660f1acd526403bce5c899760105
Getting pack 2c775595dbd0660f1acd526403bce5c899760105
 which contains 29aa2320d2ba702a006681f872042d7fb1e32f41
walk 29aa2320d2ba702a006681f872042d7fb1e32f41
Getting pack e68ad9b728a83cfcb0a95b00fb7783d57ca502cc
 which contains f02dfd5040843b550600a01b4a85a7ca6dc53f39

except by the time you are done it has filled up several pages.

>>> 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?

I thought it did, but that doesn't appear to be the case.  The progress
bar has changed so much since I have started using bzr that I am sure I
simply got confused.

Jason