The order of PersistedDiffFileInfo items in the diff_infos connection of PersistedDiffManager is incorrect.
It should order items in insertion order. However it orders by path and not according to the order the parts were generated using the unique integer identifier as the sort is alphabetical.
Previously I resisted using a Vec-like type as earlier diff purging implementations lacked serial number relation metadata and used unclear and error prone Vec indexing, and I wanted an ordered "set" type whereas Vec is neither ordered nor a set.
However, the BTreeMap ordering is not insertion order, and the current version of the code indexes into it only by path, lookup by serial number requires a search as using a Vec would require, while a Vec would be order by insertion.
So perhaps it is best to switch to a Vec-like type.
The order of
PersistedDiffFileInfoitems in thediff_infosconnection ofPersistedDiffManageris incorrect.It should order items in insertion order. However it orders by path and not according to the order the parts were generated using the unique integer identifier as the sort is alphabetical.
Previously I resisted using a
Vec-like type as earlier diff purging implementations lacked serial number relation metadata and used unclear and error proneVecindexing, and I wanted an ordered "set" type whereasVecis neither ordered nor a set.However, the
BTreeMapordering is not insertion order, and the current version of the code indexes into it only by path, lookup by serial number requires a search as using aVecwould require, while aVecwould be order by insertion.So perhaps it is best to switch to a
Vec-like type.