]> arthur.barton.de Git - bup.git/commitdiff
save/vfs: update comments wrt. tree/bupm ordering
authorJohannes Berg <johannes@sipsolutions.net>
Sat, 25 Jan 2020 23:17:38 +0000 (00:17 +0100)
committerRob Browning <rlb@defaultvalue.org>
Sat, 25 Apr 2020 19:25:37 +0000 (14:25 -0500)
After looking into this and thinking about it, the comments here
are a bit misleading - save states the entries must be in a given
order without a rationale, and vfs states that the order is wrong
but gives an explanation that's not quite right.

Update both comments to make this clearer, and to document that
there's no inherent reason, just happened to pick something when
the save code was written, which turned out to be not the best.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
(cherry picked from commit 273bc50ab1151e25f900521e26d9d7a6e0839d19)

cmd/save-cmd.py
lib/bup/vfs.py

index 43f41e7477ad4a609f32efd9b079a32c1c643b8a..366f031cab1011cbd3c520e9929d80e01f514485 100755 (executable)
@@ -115,8 +115,11 @@ def eatslash(dir):
 # Since the git tree elements are sorted according to
 # git.shalist_item_sort_key, the metalist items are accumulated as
 # (sort_key, metadata) tuples, and then sorted when the .bupm file is
-# created.  The sort_key must be computed using the element's real
-# name and mode rather than the git mode and (possibly mangled) name.
+# created.  The sort_key should have been computed using the element's
+# mangled name and git mode (after hashsplitting), but the code isn't
+# actually doing that but rather uses the element's real name and mode.
+# This makes things a bit more difficult when reading it back, see
+# vfs.ordered_tree_entries().
 
 # Maintain a stack of information representing the current location in
 # the archive being constructed.  The current path is recorded in
index 1105f79bd6ff8c0ad62bbbcc2a79ac30ea149cc4..f94eb29e3cb66c58ed712e85f4d154f908fadad0 100644 (file)
@@ -611,10 +611,12 @@ def ordered_tree_entries(tree_data, bupm=None):
 
     """
     # Sadly, the .bupm entries currently aren't in git tree order,
-    # i.e. they don't account for the fact that git sorts trees
-    # (including our chunked trees) as if their names ended with "/",
-    # so "fo" sorts after "fo." iff fo is a directory.  This makes
-    # streaming impossible when we need the metadata.
+    # but in unmangled name order. They _do_ account for the fact
+    # that git sorts trees (including chunked trees) as if their
+    # names ended with "/" (so "fo" sorts after "fo." iff fo is a
+    # directory), but we apply this on the unmangled names in save
+    # rather than on the mangled names.
+    # This makes streaming impossible when we need the metadata.
     def result_from_tree_entry(tree_entry):
         gitmode, mangled_name, oid = tree_entry
         name, kind = git.demangle_name(mangled_name, gitmode)