Commit extremely slow

[John Arbash Meinel]

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

On 05/26/2011 08:44 AM, Martin Pool wrote:
> Can you tell us more about the configuration you have here?  When you
> say "the repo is bound": bound to what?  A remote repository?  What
> does "bzr info" in the local repository show?
> 

'bzr info' should give enough information, but how remote is the remote
repository? (local network, 600ms latency with dialup internet speeds?, etc)

Repacking happens to maintain efficiency. Any given content is only
touched on an exponential backoff. So the first commit is repacked at
commit 10, then 100, then 1000, then 10000, etc.

It happens that your project is currently very new, and commit 1 has
*lots* of data. If you had the history of the project, the 1GB was built
up over time, and thus we wouldn't be touching all 1GB very often (you'd
be in then only-once-every 10,000 commits part of the cycle, rather than
the once-in-every 10 commits.)


As for remote connections, if you are using bzr over something like
sftp, we have no choice but to do the work locally. (There is no process
on the remote machine that knows how to repack the repository.) Which
means downloading the remote content to determine exactly what is there,
recompressing it, and then uploading it again. If you have 1GB of
content and a slow link, that can take a while.

If you can use "bzr+ssh://" to access the remote content, then repacking
will be done by the remote bzr process. It may still take a while, but
it will be bound by the remote machine's cpu rather than your network link.

It would be nice if we had a better way to avoid repacking the initial
content. But at the moment we don't really have any knobs to tweak to do so.

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

iEYEARECAAYFAk3eDJwACgkQJdeBCYSNAANSSACdEJJ7VtJBSYZ389QVQcNoz0XZ
SL4An2ZgHwAXAiUoJDEaC51aswUCe5lC
=gd2E
-----END PGP SIGNATURE-----