Comment 0 for bug 120697

This is actually debian bug 396227:

From: Roland Mas <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: bzr: Very network-unfriendly
Date: Mon, 30 Oct 2006 18:20:02 +0100
Package: bzr
Version: 0.11-1
Severity: normal

bzr seems to deliberately eat my bandwidth. The following two
invocations of bzr have been run in a row, after the $http_proxy and
$HTTP_PROXY environment variables have been set up to point to a
(working) squid proxy/cache. As you can see, there's no gain in using
a cache:

,----
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m28.351s
| user 0m31.538s
| sys 0m1.880s
| roland@mirexpress:/tmp$ mv bzr.dev/ bzr.dev.bak
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m58.854s
| user 0m32.130s
| sys 0m1.740s
| roland@mirexpress:/tmp$
`----

The Squid logs lots of TCP_MISS and TCP_CLIENT_REFRESH_MISS entries.
According to the Squid documentation, this means that "The client
issued a "no-cache" pragma, or some analogous cache control command
along with the request. Thus, the cache has to refetch the object."

  Bzr is slow enough already, bypassing proxy-caches is not good. One
could, with lots of goodwill, argue the case for initial branching,
but re-fetching more than a megabyte afterwards for each bzr pull (one
in each branch) is stretching it.