faster "bzr export" versus stable ordering

John Arbash Meinel john at
Tue Dec 15 17:45:27 GMT 2009

Hash: SHA1

So as part of looking at bug #343218 ('bzr export' much slower than 'bzr
co --lightweight), I decided to approach it 2 fold. For a 2.0 release,
just do a small patch to just the dir exporter, and have it use
'iter_files_bytes' to get the bulk content.

This seems to work pretty well, as exporting bzr on my local network
from http:// is as much as 4x faster than before.

For a 2.1 fix, I was thinking to refactor that change into a helper
(similar to the helper export already has).

However, 'iter_files_bytes' intentionally leaves the order of the
results undefined. (It is whatever is fastest for the repository to

As such, if we used it to export tarballs, they would be randomly
ordered. I make sure to yield directories before files, so we know that
we have a place to put anything that comes out.

However, does the ordering in the tarball matter to people? Given that
people wanted 'bzr export foo.tar.gz' to give deterministic tarballs (to
use with debian packaging), it seems that this would break for them.

So for now, I'm just doing it for the dir_exporter code, but I was
wondering what people thought. Is export-to-tarball-from-remote a common
operation? (I wouldn't have thought export-to-directory was, but
apparently it is the primary way that Gentoo wants to work.)

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


More information about the bazaar mailing list