Comment 1 for bug 680763

I'm timing to Chinstrap rather than Devpad because I can't get Paramiko to do the chinstrap song-and-dance to create an nc tunnel. However, the data center stuff should be the same.

$ time bzr log bzr+ssh://<email address hidden>/~bzr-pqm/bzr/bzr.dev -r -1
...
HPSS calls: 16 (9 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
real 0m9.203s

$ time bzr log bzr+ssh://<email address hidden>/home/jameinel/dev/bzr/bzr.dev -r -1
...
HPSS calls: 19 (9 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
real 0m9.471s

So at least that part is quite comparable from Chicago. Though chinstrap probably has more pack files.

'info' is also pretty comparable:
$ time bzr info bzr+ssh://<email address hidden>/~bzr-pqm/bzr/bzr.dev
HPSS calls: 12 (0 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
real 0m7.704s

$ time bzr info bzr+ssh://<email address hidden>/home/jameinel/dev/bzr/bzr.dev
HPSS calls: 15 (0 vfs) SmartSSHClientMedium(bzr+ssh://<email address hidden>/)
real 0m6.081s

A bit slower, but nothing like the 13s vs 5.8s we see in the initial report.

My initial guess is that stacked branches may have a specific impact here, and it may depend on the specific pack layout. Pushing up a stacked branch does at least some amount of data correctness check, which can be impacted by repo layout. So if devpad was more packed than Launchpad, that might impact this timing.

I think relevant to the discussion would be the time to push a new branch into a shared repository, since I think that is what the git code is doing.