largefiles: walk history in ascending order while downloading all lfiles
I don't think the order matters. Maybe it's purely because of the use of
walkchangerevs(), which was originally designed for "hg log" command.
Surprisingly, the number of objects fetched in test-largefiles.t has changed.
According to the --verbose output, the order of the following fetches flipped
and the latter got deduplicated.
getting large3:
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
found
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
getting sub/large4:
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
found
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
Address commentary in manifest.excludedmanifestrevlog.add -
specifically we should improve the collaboration with core so that
add() never gets called on an excluded directory and we can improve
the stand-in to raise a ProgrammingError.
Reason more completely about rename-filtering logic in
narrowfilelog. There could be some surprises lurking there.
Formally document the narrowspec format. For bonus points, unify with the
server-specified narrowspec format.
narrowrepo.setnarrowpats() or narrowspec.save() need to make sure
they're holding the wlock.
The follinwg places do an unrestricted dirstate walk (including files outside the
narrowspec). Some of them should perhaps not do that.
* debugfileset
* perfwalk
* sparse (but restricted to sparse config)
* largefiles