Some unscientific timing results (on the Python source tree)

John Arbash Meinel john at
Thu Mar 27 14:57:35 GMT 2008

Hash: SHA1

Paul Moore wrote:


| bzr - 262Mb
| hg - 140Mb
| Subversion checkout - 333Mb

Something seems fishy here. Specifically, if the SVN checkout is 333Mb, that
sounds like the size of your working tree is 333/2 = 160MB. (SVN creates 2
copies of every file so it has a pristine copy to 'diff' against.)

I don't see how hg could have your working tree in less space than the raw files
on disk take.

I'm also a little surprised that we are that much larger than hg, since usually
our on-disk tests show packs as taking up less space. (hg has 1 or 2 files per
versioned file, which usually causes a lot of 'wasted' space because of block

I'm wondering if you don't have a lot of stuff in .bzr/repository/obsolete_packs
which will be cleaned up over time. (When we generate new packs we leave the old
ones around a bit to make sure that you can recover even if the OS decides to
process deletes before writes and crashes in the middle.)

I'm also curious about your bandwidth/latency to both machines.

I would also be interested to know the load on both machines. Hg's cgi script
does (effectively) a zcat | bzip2 to stream out the data. Which is nice for
bandwidth, but puts a rather heavy load on the server. I'm not sure what happens
when you have 10 people branching at the same time. (Which *might* be an issue
for a project like, probably isn't for others.)

I know we've considered doing that for bzr+http:// but we haven't decided if it
is worth the server load yet. (We could probably make it configurable, but there
is always the 'you should work the best you can "out of the box"' problem.)

I'm currently on vacation in an area with very limited internet connectivity. If
I ever get a chance, I'd like to figure out why these numbers are so different.

Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list