implement exporttree=yes configuration

* Only export to remotes that were initialized to support it.
* Prevent storing key/value on export remotes.
* Prevent enabling exporttree=yes and encryption in the same remote.

SetupStage Enable was changed to take the old RemoteConfig.
This allowed only setting exporttree when initially setting up a
remote, and not configuring it later after stuff might already be stored
in the remote.

Went with =yes rather than =true for consistency with other parts of
git-annex. Changed docs accordingly.

This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
Joey Hess 2017-09-04 12:40:33 -04:00
parent a4328b49d2
commit 28e2cad849
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
14 changed files with 69 additions and 29 deletions

View file

@ -15,13 +15,13 @@ when they want to export a tree. (It would also be possible to drop all content
from an existing special remote and reuse it, but there does not seem much
benefit in doing so.)
Add a new `initremote` configuration `exporttree=true`, that cannot be
Add a new `initremote` configuration `exporttree=yes`, that cannot be
changed by `enableremote`:
git annex initremote myexport type=... exporttree=true
git annex initremote myexport type=... exporttree=yes
It does not make sense to encrypt an export, so exporttree=true requires
(and can even imply) encryption=false.
It does not make sense to encrypt an export, so exporttree=yes requires
encryption=none.
Note that the particular tree to export is not specified yet. This is
because the tree that is exported to a special remote may change.
@ -137,7 +137,7 @@ key/value stores. The content of a file can change, and if multiple
repositories can export a special remote, they can be out of sync about
what files are exported to it.
Possible solution: Make exporttree=true cause the special remote to
Possible solution: Make exporttree=yes cause the special remote to
be untrusted, and rely on annex.verify to catch cases where the content
of a file on a special remote has changed. This would work well enough
except for when the WORM or URL backend is used. So, prevent the user