Why packs => knits messes up the revision ordering

[John Arbash Meinel]

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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> I finally figured out what is going on, which is causing fetching from
>> packs =>
>> knits to get so messed up.
> 
>> 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.
> 
> That turned out to be one of the big issues with the non-rich-root to
> rich-root conversion, and is fixed in my patch:
> 
> http://bundlebuggy.aaronbentley.com/request/%3C48174A66.8030508@aaronbentley.com%3E
> 
> 
>> 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.
> 
> It would transfer them in the correct order, but it would mess up all
> the file texts, which are annotated for knits and not for packs.
> Knit.join() is too low-level to handle that, AIUI.
> 
> Aaron

Actually Knit.join() has code to check if the source is annotated but
the target is not, and it adds an "strip_annotations" adapter.

Anyway, if you are fixing it, I don't need to worry about it as much.

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

iD8DBQFIF6kzJdeBCYSNAAMRAnBPAJ0RSMzpamof3i08nmjSqpBG7Ma88ACggPAy
s5V157wA/iYdHjmzuhDiPyg=
=KFRq
-----END PGP SIGNATURE-----