Re: Official Git mirror?

[Óscar Fuentes]

Tim X <timx@nospam.dev.null> writes:

>> 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.
>
> Such comparisons are meaingless. There are two many variables not
> accounted for, such as network, server load, client/server versions and
> even differences in repositories. 

Okay, let's repeat the experiment on a controlled environment.

LAN 100 Mb/s, idle.

A quad-core 2.4GHz Q6600 machine with 8 GB RAM, Kubuntu 10.10 64 bits (let's
call this machine `qcore')

A single-core single-thread Pentium M 2.0GHz with 2 GB RAM, Kubuntu
10.10 32 bits (let's name this one `single')

git version 1.7.1
bzr version 2.2.1

                                        real  /  user  /  sys
git ssh://qcore (from single)           5m34s    4m28s    0m27s
bzr nosmart+bzr://qcore (from single)   9m54s    9m21s    0m9s
bzr bzr://qcore (from single)           7m37s    6m15s    0m8s
git ssh://single (from qcore)           2m50s    2m23s    0m7s
bzr nosmart+bzr://single (from qcore)   6m47s    6m27s    0m3s
bzr bzr://single (from qcore)           6m24s    4m17s    0m3s

On all cases the operation seems CPU-bound on the *client*. Git shows a
CPU spike on the server at the beginning, on the "counting objects"
phase. The Bzr server shows no significant CPU usage when connected with
the "nosmart" option. Else it pegs one CPU core for a large part of the
phase where revisions are sent, and uses up to 1.5 GB of RAM for a short
moment, although most of the time it is about 400 MB (on the 64bit
machine). Neither bzr nor git clients seems to exploit the multiple
cores while cloning. The bzr client uses a lot of memory (almost 600 MB
on the 64 bit machine, almost 400 on the 32 bits machine.)

It seems that "nosmart" is used for compensating for servers with busy
CPUs at the cost of more data sent to the client and more work offloaded
to it.

> However, what really matters is the updates rather than a fresh full
> branching/cloning as you only do the long initial copy once. 

We are discussing protocol efficiency. It is reasonable to expect that
any shortcoming on the cloning process will show in the update
operation. Moreover, on the timings I used an special case for bzr
(nosmart) that may tilt the results to its favor if we extrapolate the
results to update operations.

My experience updating emacs bzr from Launchpad (with the smart
protocol) is that it is noticeably slower than updating emacs git from
repo.or.cz. (To address just one factor, network latency is important on
short operations, but pinging to repo.or.cz is 50% slower than pinging
to launchpad.net from here.)

> Personally, I prefer git, but use bzr just as much as a number of
> projects I work on use bzr. I've found the initial checkouts to be
> fairly close and later updates to also be about the same.

I guess that your anecdotal experience is as good as mine.

[snip]

> The real point to note, as mentioned by Eli, is that the git repositories
> are frequently hours behind bzr.

That's a different issue. No discussion about that.

[snip]