faster "bzr export" versus stable ordering
John Arbash Meinel
john at arbash-meinel.com
Tue Dec 15 17:45:27 GMT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the bazaar