all keys are still present on versioned remote after import of a tree
When importing from versioned remotes, fix tracking of the content of deleted files. Only S3 supports versioning so far, so only it was affected. But, the draft import/export interface for external remotes also seemed to need a change, so that versionedExport could be set.
This commit is contained in:
parent
e22c3b3d7c
commit
c2ad84b423
7 changed files with 35 additions and 9 deletions
|
@ -150,6 +150,13 @@ support a request, it can reply with `UNSUPPORTED-REQUEST`.
|
|||
Indicates that `IMPORTKEY` can be used.
|
||||
* `IMPORTKEYSUPPORTED-FAILURE`
|
||||
Indicates that `IMPORTKEY` cannot be used.
|
||||
* `VERSIONED`
|
||||
Used to check if the special remote is versioned.
|
||||
Note that this request may be made before or after `PREPARE`.
|
||||
* `ISVERSIONED`
|
||||
Indicates that the remote is versioned.
|
||||
* `NOTVERSIONED`
|
||||
Indicates that the remote is not versioned.
|
||||
* `LISTIMPORTABLECONTENTS`
|
||||
Used to get a list of all the files that are stored in the special
|
||||
remote. A block of responses
|
||||
|
@ -170,6 +177,8 @@ support a request, it can reply with `UNSUPPORTED-REQUEST`.
|
|||
be nested multiple levels deep.
|
||||
This should only be used when the remote supports using
|
||||
"TRANSFER RECEIVE Key" to retrieve historical versions of files.
|
||||
And, it should only be used when the remote replies `ISVERSIONED`
|
||||
to the `VERSIONED` message.
|
||||
* `END`
|
||||
Indicates the end of a block of responses.
|
||||
* `LOCATION Name`
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue