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

todo

Browse source 
kind of a bug, but I'm not sure if it can be fixed
This commit is contained in:
Joey Hess 2025-01-13 13:04:38 -04:00
parent 8d4da46273
commit 580c11cf19
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 57 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

57
doc/todo/avoid_sync_unncessary_transfers.mdwn Normal file
View file

@ -0,0 +1,57 @@
`git-annex sync --content` can sometimes do unncessary transfers
when syncing with multiple remotes at the same time. Here is an example:
git-annex sync --content r2 r3
...
copy foo (to r2...)
ok
copy foo (to r3...)
ok
drop foo (from r2...) ok
git-annex wanted r3
anything
git-annex wanted r2
not copies=foo:1
git-annex group r3
foo
At the time sync decides to copy to the first repository, it legitimately
wants the content. But once the content is also copied to the second
repository, the first no longer wants it.
Perhaps this could be improved by sync simulating that the second copy
has already happened, and seeing if the first repository still wants the
content then.
But, bear in mind that the second repository may not be accessible
currently. And indeed it may currently be located somewhere such that content
can only reach it via the first repository. So if it decides to send to the
second repository but not then to the first, it should still send to the
first repository if it is unable to send to the second.
So essentially, this would reorder the list of repositories to work on from
"r2 r3" to "r3 r2".
But, it's also possible to have this situation:
git-annex wanted r3
not copies=foo:1
git-annex wanted r2
not copies=foo:1
git-annex group r3
foo
git-annex group r2
foo
In that situation, `git-annex sync --content r2 r3` will currently send
content to r2 when it's accessible. Then r3 doesn't get a copy, and the
copy remains on r2. If the list of repositories were reordered, that would
change which repository ends up with the file. Which would be surprising
since that configuration and order of repositories passed to sync
is clear in its desired effect.
With the config above, there would be no need to reorder the list of
repositories since it does not avoid excess work. Are there
configs where reordering would avoid excess work, but would also change
desired behavior (for the same file)? --[[Joey]]