mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update proposed external special remote protocol

Browse source
This commit is contained in:
Joey Hess 2017-08-28 15:34:26 -04:00
parent 792e582a60
commit ed5d8ee9ea
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 43 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
doc/design/exporting_trees_to_special_remotes.mdwn
View file

@ -108,28 +108,36 @@ would be overkill if it's only used to support resuming partial uploads.
This needs some additional methods added to special remotes, and to
the [[external_special_remote_protocol]].
* `TRANSFEREXPORT STORE|RETRIEVE Key File Name`
Requests the transfer of a File on local disk to or from a given
Name on the special remote.
The Name will be in the form of a relative path, and may contain
path separators, whitespace, and other special characters.
Here's the changes to the latter:
* `EXPORT Name`
Comes immediately before each of the following requests,
specifying the name of the exported file. It will be in the form
of a relative path, and may contain path separators, whitespace,
and other special characters.
* `TRANSFEREXPORT STORE|RETRIEVE Key File`
Requests the transfer of a File on local disk to or from the previously
provided Name on the special remote.
The Key is provided in case the special remote wants to use eg
`SETURIPRESENT`.
The remote responds with either `TRANSFER-SUCCESS` or
`TRANSFER-FAILURE`, and a remote where exports do not make sense
may always fail.
* `CHECKPRESENTEXPORT Key Name`
Requests the remote to check if a Name is present in it.
* `CHECKPRESENTEXPORT Key`
Requests the remote to check if the previously provided Name is present
in it.
The remote responds with `CHECKPRESENT-SUCCESS`, `CHECKPRESENT-FAILURE`,
or `CHECKPRESENT-UNKNOWN`.
* `REMOVEEXPORT Key Name`
Requests the remote to remove content stored by `TRANSFEREXPORT`.
* `REMOVEEXPORT Key`
Requests the remote to remove content stored by `TRANSFEREXPORT`
with the previously provided Name.
The Key is provided in case the remote wants to use eg
`SETURIMISSING`.
The remote responds with either `REMOVE-SUCCESS` or
`REMOVE-FAILURE`.
* `RENAMEEXPORT Key OldName NewName`
Requests the remote rename a file stored on it from OldName to NewName.
* `RENAMEEXPORT Key NewName`
Requests the remote rename a file stored on it from the previously
provided Name to the NewName.
The Key is provided in case the remote wants to use eg
`SETURIMISSING` and `SETURIPRESENT`.
The remote responds with `RENAMEEXPORT-SUCCESS`,

13
doc/design/exporting_trees_to_special_remotes/comment_15_3fc518cee1a11b28da769c0915d33e3b._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="joey"
subject="""comment 15"""
date="2017-08-28T19:00:10Z"
content="""
Since [[bugs/external_special_remote_protocol_broken_by_key_with_spaces]]
was fixed, the Key can't contain spaces any longer.
The File could still contain spaces, eg when exporting from a direct mode
repository where the worktree filename contains spaces.
In `RENAMEEXPORT`, both OldName and NewName could contain spaces.
"""]]

11
doc/design/exporting_trees_to_special_remotes/comment_16_29f598eda413c0d5e17536d8f9438d31._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 16"""
date="2017-08-28T19:32:06Z"
content="""
I've updated the proposed external special remote protocol to avoid the
whitespace concerns. Not wild about needing a separate EXPORT request,
which will probably get shoved into a global variable in most
implementations. But it does avoid needing to use some kind of encoding,
which would complicate implementations more, I feel.
"""]]