fastimport and the scope of the hottest 100 effort

[Ian Clatworthy]

Jelmer Vernooij wrote:

>> For each of these, fastimport may be the best option, given
>> fastimport-generated branches are often much smaller than those created
>> via Jelmer's plugins.
> Is this still true after packing? I'm a bit surprised as to what could
> be causing this. We have the same data, after all.

Bazaar's compression and therefore repo sizes are quite sensitive to the
file-id and rev-id schemes used. When jam suggested I change file-id
generation from path-based to basename-based, Samba shrank dramatically!

In my experience, even changing the prefix from xxx-revN: to xN: can
shrink things a heap. I think we need to experiment more. It may even be
possible for bzr-xxx to get *better* sizes than fastimport (which uses
the default bzr scheme).

My concern is that large repo sizes on highly visible projects will lead
to slower performance and higher disk space usage. Rightly or wrongly,
users will grab imported branches from LP and then say "bzr is 2-3 times
less efficient than git". If the import of project X was done
differently, those same users could be saying "bzr is in the same
ballpark as git wrt disk efficiency".

Ian C.