diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2017-04-07 17:06:12 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-04-07 17:06:12 -0400 |
| commit | ef62e7f068669097f2ef4b42eaa88b2cb46afeab (patch) | |
| tree | c39b90c9f2bcd05f54fe3c45bee58df6d3fe1c3e | |
| parent | 01e7733f3b62c2340d72c83fdd7ffe0a775f0b49 (diff) | |
| parent | 2ce5a6e590f182b388d391cfbed7d82edcd3c592 (diff) | |
Merge branch 'master' of ssh://git-annex.branchable.com
| -rw-r--r-- | doc/bugs/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment new file mode 100644 index 000000000..c60ba6d4a --- /dev/null +++ b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="yarikoptic" + avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" + subject="may be?" + date="2017-04-07T21:01:56Z" + content=""" +well, it kinda depends at either at which level parallelization is happening or how parallel jobs handling is done, or may be ... + +level of parallelization: +I guess ATM annex just parallelizes at the level of \"get --key KEY\" jobs. +But if central process decided to try to \"get --from=remote --key KEY\" -- call which it submits to parallel work pull -- then it could first check if remote is an ssh remote and connection caching is established, and if not -- establish it and then submit this and/or any subsequent get call. +This would though over-complicate the design I guess considerably, so probably shouldn't be approached. + +jobs handling: +if parallel jobs could 'yield' back to the original process (e.g. if there was some protocoled exchange between them and master process... somewhat similar to git annex special remotes in a way) demanding some action (e.g. - authenticate me to the host) and then proceed back with its dues, could work out I guess. +But I guess that is also not current implementation + + +may be...: +since I guess (didn't check) GIT_SSH_COMMAND is used (or not yet but could be?) for ssh transfers, such activity as establishing shared ssh connection could be deferred to it (with some proper locking/waiting for parallel invocations)... or am I wrong? +"""]] |