From edf31a2ebcb31ed1f85cde1df0749886f6d58d7c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 1 Dec 2023 15:01:45 -0400 Subject: [PATCH] update --- doc/todo/distributed_migration.mdwn | 20 ++++++++++++++++--- ..._8734d30aa0c1cb27dce81a0277d24948._comment | 10 ++++++++++ 2 files changed, 27 insertions(+), 3 deletions(-) create mode 100644 doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment diff --git a/doc/todo/distributed_migration.mdwn b/doc/todo/distributed_migration.mdwn index ad11ada8f9..c605b474a1 100644 --- a/doc/todo/distributed_migration.mdwn +++ b/doc/todo/distributed_migration.mdwn @@ -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 index 0000000000..180e937c2d --- /dev/null +++ b/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment @@ -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. +"""]]