Why packs => knits messes up the revision ordering

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I finally figured out what is going on, which is causing fetching from packs =>
knits to get so messed up.

The specific issue is that packs => knits uses the GenericRepoFetcher, and the
fetch code looks like:

for rev in revs:
~  to_store.add_revision(self.from_repository.get_revision(rev), ...)


And how does the list of 'revs' get determined? In

_fetch_everything_for_search() we have the function:

revs = search.get_keys()

I have the feeling that the search object returns the revisions in whatever
order it finds them, rather than returning them in topological order. And *that*
causes the fetch into knits to be pretty much as out-of-order as you can get.

One thing I don't quite understand is why we are using InterSameDataRepository
instead of InterKnitRepository. Which does the copy using Knit.join(revs). Which
I *think* would transfer them in the correct order.

Another (IMO better) option would be to change search.keys() to either return
them in topological order, or to change the code to sort search.keys() result.


It seems we aren't using the InterKnit code because, although PackRepository
inherits from KnitRepository, RepositoryFormatPack inherits directly from
MetaDirRepositoryFormat, and not RepositoryFormatKnit.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgXmoEACgkQJdeBCYSNAAP1xgCgvlumKzc4x/nHEJEQOaiujhz2
tmsAoKDLojY5EjDXSQU9EraoGvSYPHD0
=nF+k
-----END PGP SIGNATURE-----