diff tests/test-largefiles.t @ 45455:b0d45612c552

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

--- a/tests/test-largefiles.t	Sun Sep 13 17:43:19 2020 +0900
+++ b/tests/test-largefiles.t	Sun Sep 13 17:46:48 2020 +0900
@@ -1005,7 +1005,7 @@
   getting changed largefiles
   3 largefiles updated, 0 removed
   5 files updated, 0 files merged, 0 files removed, 0 files unresolved
-  8 additional largefiles cached
+  7 additional largefiles cached
 
   $ rm "${USERCACHE}"/*
   $ hg clone --all-largefiles -u 0 a a-clone0
@@ -1013,7 +1013,7 @@
   getting changed largefiles
   2 largefiles updated, 0 removed
   4 files updated, 0 files merged, 0 files removed, 0 files unresolved
-  9 additional largefiles cached
+  8 additional largefiles cached
   $ hg -R a-clone0 sum
   parent: 0:30d30fe6a5be 
    add files
@@ -1047,7 +1047,7 @@
 
   $ rm "${USERCACHE}"/*
   $ hg clone --all-largefiles -U a a-clone-u
-  11 additional largefiles cached
+  10 additional largefiles cached
   $ hg -R a-clone-u sum
   parent: -1:000000000000  (no revision checked out)
   branch: default