Slow "bzr branch" on Savannah

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/18/2011 12:03 PM, Eli Zaretskii wrote:
>> Date: Thu, 10 Feb 2011 21:04:04 +0200
>> From: Eli Zaretskii <eliz at gnu.org>
>> Cc: bazaar at lists.canonical.com
>>
>>> Date: Tue, 08 Feb 2011 15:22:12 -0600
>>> From: John Arbash Meinel <john at arbash-meinel.com>
>>> CC: Eric Siegerman <lists08-bzr at davor.org>, bazaar at lists.canonical.com
>>
>> I did some more measurements using the advice given.  To summarize:
> 
> No responses?  At least two people said they would be interested in
> seeing these results.
> 
> Anyway, any conclusions from this, except that Savannah admins should
> be urged to upgrade to bzr 2.2+?
> 
> Thanks.
> 

I read it, and was thinking about it. I still have it marked "unread" in
my folder (the last one, in fact). I just haven't had time to really dig
into it and determine the implications.

The immediate take away was just that using the smarts on the client
side seems to work a lot better than taxing the Savannah server for
computing what to send. And I can sort of see that being true for "fetch
everything". If the server is loaded, then offloading all the
computation to the client works well for CPU. And if you are fetching
everything anyway, there isn't a loss on the client side for fetching
more than it needs (because it needs everything).

I would imagine that all future updates would be worse without smart
server support. (I've certainly seem emacs "bzr up" over raw http take
approx as much bandwidth for a 1000 rev update as re-downloading the
whole history.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1fCQEACgkQJdeBCYSNAAMPFgCfbChqDw6wRW0hQla1vXdk4TbH
Y+sAoKcYDAtgiejhH4h9F32OaQ7ZQVOl
=aK3o
-----END PGP SIGNATURE-----