From 759e5a9903820523e00b2d1a33b83aaa44c4b03a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 31 May 2021 10:50:22 -0400 Subject: [PATCH] todo --- ...copies_check_other_files_using_same_key.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/todo/numcopies_check_other_files_using_same_key.mdwn diff --git a/doc/todo/numcopies_check_other_files_using_same_key.mdwn b/doc/todo/numcopies_check_other_files_using_same_key.mdwn new file mode 100644 index 0000000000..19b365b962 --- /dev/null +++ b/doc/todo/numcopies_check_other_files_using_same_key.mdwn @@ -0,0 +1,17 @@ +Like was recently done for preferred content, when checking numcopies for a +drop, it could check if other files are using the same key, and if so check +that their numcopies (and mincopies) is satisfied as well. + +There would be an efficiency tradeoff of course, since it would have to +query the keys db. The question I suppose is, if someone sets different +numcopies for different files via .gitattributes, and they use the same +key, will the user think it's a problem that numcopies can be violated in +some circumstances. And I think that users would maybe consider that to be +a problem, if they happened to encounter the behavior. + +It may also be worth considering making --all (etc) also check numcopies of +associated files. Although then, in a bare repo, it would behave +differently than in a non-bare repo. (Also if this is done, the preferred +content checking should also behave the same way.) The docs for --all +do say that it bypasses checking .gitattributes numcopies. +--[[Joey]]