comment
This commit is contained in:
parent
522d032016
commit
18faf9fb5b
1 changed files with 26 additions and 0 deletions
|
@ -0,0 +1,26 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""Re: numcopies question"""
|
||||
date="2023-07-05T21:22:10Z"
|
||||
content="""
|
||||
It won't send content that is otherwise not wanted just to satisfy
|
||||
numcopies. Of course, like all commands, it refuses to drop a file if
|
||||
numcopies is not satisfied.
|
||||
|
||||
Comsider a remote foo that only wants `include=foo/*`. And another remote
|
||||
bar that wants `include=bar/*`. And numcopies=2. If `git-annex satisfy`
|
||||
was only able to access foo, and worked to satisfy numcopies, foo would end
|
||||
up with files in bar/* that it doesn't want. But there's a better
|
||||
place for those files to go, namly bar, which wants them. So over time it
|
||||
would do a large amount of unncessary work, sending files to foo, only
|
||||
to later drop those same files from foo once it was able to populate bar.
|
||||
|
||||
If the user wants to, they can configure foo to want
|
||||
`include=foo/* or lackingcopies=1` and then `git-annex satisfy` will know
|
||||
this is a repository that wants any files that don't have enough copies,
|
||||
and when bar is not accessible, it will send its files to foo.
|
||||
|
||||
I think this could stand to be better documented. Especially since
|
||||
things like `git-annex copy --auto` *do* work to satisfy numcopies in
|
||||
addition to preferred content.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue