This is consistent with my experience. Bzr has some issues with large (medium?) projects which some other vcs systems have solved. I believe the core devs will solve this. Meanwhile I find that breaking projects into modules...like bzr and its pluggins...does help a lot. Good luck! <div class="gmail_quote">On May 26, 2011 5:37 AM, "Kape" <<a href="mailto:erlend.sobec@gmail.com">erlend.sobec@gmail.com</a>> wrote: > > 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 - <a href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a> >> >> iEYEARECAAYFAk3eDJwACgkQJdeBCYSNAANSSACdEJJ7VtJBSYZ389QVQcNoz0XZ >> SL4An2ZgHwAXAiUoJDEaC51aswUCe5lC >> =gd2E >> -----END PGP SIGNATURE----- >> >> >> > > -- > View this message in context: <a href="http://old.nabble.com/Commit-extremely-slow-tp31689617p31707533.html">http://old.nabble.com/Commit-extremely-slow-tp31689617p31707533.html</a> > Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. > > </div>