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:
parent
a4328b49d2
commit
28e2cad849
14 changed files with 69 additions and 29 deletions
|
@ -17,12 +17,9 @@ there need to be a new interface in supported remotes?
|
|||
|
||||
Work is in progress. Todo list:
|
||||
|
||||
* Only export to remotes that were initialized to support it.
|
||||
* Prevent using export remotes for key/value storage.
|
||||
* Use retrieveExport when getting from export remotes.
|
||||
(Needs a map from key to ExportLocation)
|
||||
* Efficient handling of renames.
|
||||
* Support export to aditional special remotes (S3 etc)
|
||||
* Support export to external special remotes.
|
||||
* If the same content is present in two different files, export
|
||||
location tracking can be messed up.
|
||||
|
||||
|
@ -33,3 +30,5 @@ Work is in progress. Todo list:
|
|||
And, once one of the files is uploaded, the location log will
|
||||
say the content is present, so the pass over the tree won't try to
|
||||
upload the other file. (See design for a fix for this.)
|
||||
* Support export to aditional special remotes (S3 etc)
|
||||
* Support export to external special remotes.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue