Commit extremely slow

[Kape]

Yes, it's bound to a remote repository on a remote server, not local network. 
And no, I'm not on dialup but on cable.  The slowdown doesn't seem to be
from uploading to the remote server.  I was looking at the network traffic
and it was only being used in bursts every 5 minutes or so.  When it was
using the network it was relatively fast, 800kB/s or so.

It did happen that it was the 10th commit, so that explains the repacking. 
I'm also using bzr over sftp so that further explains the slow down.  The
remote repo is actually hosted on Hostmonster, so I think my local computer
is probably faster anyway.  I set it up this way because I'm working on the
same code with someone else and it's simpler to have a single repo that is
accessible by both of us remotely.  I don't think I can use bzr+ssh with
Hostmonster but now that I've passed the 10th commit, I have another 90
commits until another 2 hour long commit.  I can live with that as long as
it's not every single time.  I did the first commit, which took long as
expected, but all other commits were done by the other person.  So when I
did one commit, which happened to be the 10th, I was afraid they would all
take this long.

Anyway, thanks for your help.


John Arbash Meinel wrote:
> 
> -----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-----
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Commit-extremely-slow-tp31689617p31707533.html
Sent from the Bazaar - General Discussion mailing list archive at Nabble.com.