Usage discussion from the GNU Emacs project.

[Óscar Fuentes]

Jason Earl <jearl at notengoamigos.org> writes:

[snip]

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

Yes, I remember not too far ago when a `bzr branch' was *really*
slow. There is no doubt that bzr progressed a lot.

> These days downloading a tarball is not really that much of a time
> saver.

For my combination of connection/machine: 9 minutes (tarball) vs 23
minutes (bzr branch http). I think that 23 minutes is
acceptable. Requiring 30 minutes for cloning to a netbook from a sftp
server over the local network is acceptable too, if you are not in a
hurry, but annoying nevertheless. The lack of an informative progress
meter makes things appear worse than they really are. When you download
a tarball, you know how much time it will require.

I'm more concerned about speed of operations such as `log' etc. I tend
to dismiss git's propaganda about its millisecond-class speed but,
honestly, it really makes a difference when the dataset grows and/or the
CPU shrinks.

[snip]

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

git protocol.

[snip]

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

[snip]

Yes, tried it a moment ago and it is even more useless than bzr's.
Maybe a git master knows how to obtain some relevant progress
information from that, but it looks as garbage to me.

[snip]

-- 
Óscar