mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2023-12-01 15:01:45 -04:00
parent 5c4ce1353e
commit edf31a2ebc
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 27 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/distributed_migration.mdwn
View 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 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, 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) 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 the new key from the special remote. (Being careful to verify the content
cheap enough to query that it won't signficantly slow down accessing a using the new key when downloading from the old key on the special remote.)
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, Rather than a dedicated command that users need to remember to run,
distributed migration could be done automatically when merging a git-annex distributed migration could be done automatically when merging a git-annex

10
doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment Normal file
View file

@ -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.
"""]]