lfs-test: note a problem with unpushed lfs files and cloning/sharing
AFAIK, this isn't an issue with largefiles because it knows how to look in the
system-wide cache.
--- a/tests/test-lfs.t Thu Oct 26 00:13:38 2017 +0900
+++ b/tests/test-lfs.t Thu Nov 16 21:05:15 2017 -0500
@@ -566,6 +566,35 @@
repo: repo9
repo: repo10
+TODO: repo12 doesn't have any cached lfs files. Figure out how to get the
+unpushed files from repo12's source instead of the remote store, where they
+don't exist.
+
+ $ find $TESTTMP/repo12/.hg/store/lfs/objects -type f
+ find: */repo12/.hg/store/lfs/objects': $ENOENT$ (glob)
+ [1]
+
+ $ hg --config extensions.share= share repo12 repo13
+ updating working directory
+ abort: $TESTTMP/dummy-remote/09/66faba9a01f6c78082aa45899a4fef732002d0b26404e90093adf1e876ab8d: $ENOTDIR$ (glob)
+ [255]
+ $ hg clone repo12 repo14
+ updating to branch default
+ abort: $TESTTMP/dummy-remote/09/66faba9a01f6c78082aa45899a4fef732002d0b26404e90093adf1e876ab8d: $ENOTDIR$ (glob)
+ [255]
+
+TODO: If the source repo doesn't have the blob (maybe it was pulled or cloned
+with --noupdate), the blob should be accessible via the global cache to send to
+the remote store.
+
+ $ rm -rf $TESTTMP/repo14/.hg/store/lfs
+ $ hg init repo15
+ $ hg -R repo14 push repo15
+ pushing to repo15
+ searching for changes
+ abort: $TESTTMP/repo14/.hg/store/lfs/objects/1c/896a0adcf9262119f4a98216aaa5ca00a58b9a0ce848914a02f9cd876f65a3: $ENOTDIR$ (glob)
+ [255]
+
lfs -> normal -> lfs round trip conversions are possible. The threshold for the
lfs destination is specified here because it was originally listed in the local
.hgrc, and the global one is too high to trigger lfs usage. For lfs -> normal,