distributed migration for pull and sync --content

pull, sync: When operating on content, automatically hard link objects
that have been migrated.

Added annex.syncmigrations config that can be set to false to prevent
pull and sync from migrating object content.

I think that true is a good default for this config, because it avoids
users having to re-download migrated content or learning about migration.
But, some users will surely not like it, whether because it does take some
time (especially for the first git-annex branch scan when there is a long
history), or because they want to deal with it manually, or because their
filesystem doesn't support hard links and they don't want it to copy
objects.

Sponsored-by: k0ld on Patreon
This commit is contained in:
Joey Hess 2023-12-08 14:18:18 -04:00
parent 4ed71b34de
commit 257f01729c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 43 additions and 8 deletions

View file

@ -59,9 +59,7 @@ seek o
| updateOption o || applyOption o = do
unless (null (migrateThese o)) $
error "Cannot combine --update or --apply with files to migrate."
streamNewDistributedMigrations (not (applyOption o)) $
\oldkey newkey ->
commandAction $ update oldkey newkey
seekDistributedMigrations (not (applyOption o))
| otherwise = do
withFilesInGitAnnex ww seeker =<< workTreeItems ww (migrateThese o)
commitMigration
@ -73,6 +71,14 @@ seek o
, usesLocationLog = False
}
seekDistributedMigrations :: Bool -> CommandSeek
seekDistributedMigrations incremental =
streamNewDistributedMigrations incremental $ \oldkey newkey ->
-- Not using commandAction because this is not necessarily
-- concurrency safe, and also is unlikely to be sped up
-- by multiple jobs.
void $ includeCommandAction $ update oldkey newkey
start :: MigrateOptions -> Maybe KeySha -> SeekInput -> RawFilePath -> Key -> CommandStart
start o ksha si file key = do
forced <- Annex.getRead Annex.force