update
authorJoey Hess <joeyh@joeyh.name>
Fri, 1 Dec 2023 19:01:45 +0000 (15:01 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 1 Dec 2023 19:01:45 +0000 (15:01 -0400)
doc/todo/distributed_migration.mdwn
doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment [new file with mode: 0644]

index ad11ada8f938cb27b0c9e39aaf9143fb55bd2f50..c605b474a13761eb8cf7b0c8b0d13c72655c7c4a 100644 (file)
@@ -29,9 +29,23 @@ and use a lot of bandwidth. Probably not a good idea.
 Alternatively, the old key could be left on a special remote, but update
 the location log for the special remote to say it has the new key,
 and have git-annex request the old key when it wants to get (or checkpresent)
-the content from the special remote. This would need the mapping to be
-cheap enough to query that it won't signficantly slow down accessing a
-special remote.
+the new key from the special remote. (Being careful to verify the content
+using the new key when downloading from the old key on the special remote.)
+This would need the mapping to be cheap enough to query that it won't
+signficantly slow down accessing a special remote.
+
+> A complication is that the special remote could end up containing both
+> old and new key. So it would need to fall back from one to the other for
+> get and checkpresent. Which will double the number of round trips to the
+> special remote if it tries the wrong one first.
+> 
+> And how to handle dropping from a special remote then? It would need to
+> update the location log for both old key and new key when dropping the
+> old key or the new key. But when the special remote stores both the old
+> and new key on it separately, dropping one should not change the location
+> log for the other. So it seems it would need to drop the key, then check
+> if the other key is stored there and if not, update the location log to
+> indicate it's not present.
 
 Rather than a dedicated command that users need to remember to run,
 distributed migration could be done automatically when merging a git-annex
diff --git a/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment b/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment
new file mode 100644 (file)
index 0000000..180e937
--- /dev/null
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-01T19:00:41Z"
+ content="""
+Even if the stuff with special remotes turned out to be too complicated to
+implement, `git-annex migrate --update` would be useful for some users.
+So it's worth implementing the mapping and then incrementally implementing
+these ideas.
+"""]]