diff options
| -rw-r--r-- | doc/design/assistant/polls/prioritizing_special_remotes.mdwn | 2 | ||||
| -rw-r--r-- | doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment | 32 |
2 files changed, 33 insertions, 1 deletions
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn index 6b37b68aa..31d189045 100644 --- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn +++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn @@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync. Help me prioritize my work: What special remote would you most like to use with the git-annex assistant? -[[!poll open=yes 15 "Amazon S3 (done)" 9 "Amazon Glacier" 7 "Box.com" 55 "My phone (or MP3 player)" 13 "Tahoe-LAFS" 4 "OpenStack SWIFT" 16 "Google Drive"]] +[[!poll open=yes 15 "Amazon S3 (done)" 9 "Amazon Glacier" 7 "Box.com" 57 "My phone (or MP3 player)" 13 "Tahoe-LAFS" 4 "OpenStack SWIFT" 16 "Google Drive"]] This poll is ordered with the options I consider easiest to build listed first. Mostly because git-annex already supports them and they diff --git a/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment new file mode 100644 index 000000000..2163ba76d --- /dev/null +++ b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment @@ -0,0 +1,32 @@ +[[!comment format=mdwn + username="helmut" + ip="89.0.176.236" + subject="Asynchronous hooks?" + date="2012-10-13T09:46:14Z" + content=""" +Is there a way to use asynchronous remotes? Interaction with git annex would have to +split the part of initiating some action from completing it. + +I imagine I could `git annex copy` a file to an asynchronous remote and the command +would almost immediately complete. Later I would learn that the transfer is +completed, so the hook must be able to record that information in the `git-annex` +branch. An additional plumbing command seems required here as well as a way to +indicate that even though the store-hook completed, the file is not transferred. + +Similarly `git annex get` would immediately return without actually fetching the +file. This should already be possible by returning non-zero from the retrieve-hook. +Later the hook could use plumbing level commands to actually stick the received file +into the repository. + +The remove-hook should need no changes, but the checkpresent-hook would be more like +a trigger without any actual result. The extension of the plumbing required for the +extension to the receive-hook could update the location log. A downside here is that +you never know when a fsck has completed. + +My proposal does not include a way to track the completion of actions, but relies on +the hook to always complete them reliably. It is not clear that this is the best road +for asynchronous hooks. + +One use case for this would be a remote that is only accessible via uucp. Are there +other use cases? Is the drafted interface useful? +"""]] |