Re: Official Git mirror?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think 11 min are significantly better than 17.  Seems like a
> good price to pay for being always in sync with the repository.  And
> this is just the initial checkout, the differences get even smaller
> for routine day-to-day operation.
>
> Yours is just one example, I get almost the same times, and sometimes
> slightly faster times for bzr than for git.  Here's one example where
> I got the same times:
>
>   bzr:
>   real    0m14.437s
>   user    0m2.516s
>   sys     0m0.308s
>
>   git:
>   real    13m59.655s
>   user    7m55.702s
>   sys     0m18.321s

The times quoted above seems wrong (0m14s for bzr?)

> Btw, what is your bzr version?  You could get faster downloads with
> the latest versions (2.2+).

2.2.1

>> Please note that git downloads all 51 branches that exists or existed on
>> Savannah while bzr gets just `trunk'.
>
> Most people don't need the other branches, so it's just ballast.

I have no issues with your recommendation of using bzr. I'm discussing
your assertion about bzr protocol's efficiency compared to git.

>> Git keeps the pipe downloading data at full speed all the time, while
>> bzr fluctuates a lot, including several long pauses, possibly because
>> the server is doing some CPU-intensive work for preparing the data.
>
> The nosmart+ option prevents the server from wasting CPU cycles when
> everything is needed to be downloaded anyway.

Then the question is: why is it not enabled by default when bzr clones a
branch from scratch?

>> Maybe the differences are not big enough to notice by most people that
>> update their Emacs mirrors from time to time, but it is not accurate to
>> say that bzr's network protocol is no less efficient than git.
>
> I did testing on several machines, and the average is almost the same,
> in terms of elapsed time.  On some machines, git is slightly faster,
> on others it's the other way around.

Bzr is quite CPU- and memory-intensive, to the point of being almost
unbearable when cloning a large branch (i.e. Emacs) on a netbook. Maybe
the machines that work faster for you are the more powerful ones?

> And I doubt that many people care about the trade-off between CPU,
> file I/O, and network I/O.  The OP was talking about the network
> protocol, but I'm quite sure he actually cares about the elapsed time
> of the initial download.

Agreed.

> Bottom line: I'd advise using bzr, because the advantages of using the
> same tool as the Emacs developers (same revision IDs etc.) outweigh
> the disadvantages of a slightly slower operation, even on GNU/Linux.

Agreed too, except for the case where the user is already familiar with
git and wants to keep local changes or do experimental hacking. Apart
from differences on workflow and performance, whose value may be
subjetive, developing with emacs+git is a very pleasant experience
thanks to packages like magit.el and others. Bzr still has a long path
to walk on terms of Emacs integration.