Merge branch 'master' of ssh://git-annex.branchable.com

9 files changed, 120 insertions, 0 deletions

diff --git a/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast.mdwn b/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast.mdwn
new file mode 100644
index 000000000..7e135e34b
--- /dev/null
+++ b/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast.mdwn
@@ -0,0 +1,28 @@
+###What steps will reproduce the problem?
+    $ git annex addurl 'file:///$HOME/space file' --fast
+    addurl _$HOME_space%20file 
+      unable to access url: file:///$HOME/space file
+    failed
+    git-annex: addurl: 1 failed
+
+    $ git annex addurl 'file:///home/arand/space\ file' --fast
+    addurl _home_arand_space%5C%20file 
+      unable to access url: file:///home/arand/space\ file
+    failed
+    git-annex: addurl: 1 failed
+
+###What is the expected output? What do you see instead?
+
+I guess it's semi-expected to fail since spaces aren't supposed to be in urls, but with file:// it would be nice if that restriction was lessened.
+
+###What version of git-annex are you using? On what operating system?
+
+Debian sid/experimental
+
+    git-annex version: 4.20130227
+    local repository version: 4
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+
diff --git a/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast/comment_1_eea9477ea1157cb88c8a07d8da5f0dba._comment b/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast/comment_1_eea9477ea1157cb88c8a07d8da5f0dba._comment
new file mode 100644
index 000000000..6e970322c
--- /dev/null
+++ b/doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast/comment_1_eea9477ea1157cb88c8a07d8da5f0dba._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 1"
+ date="2013-03-10T21:56:04Z"
+ content="""
+This seems to only occur with the \"--fast\" option.
+
+And the first example above is obviously failing due to '$HOME' as well
+"""]]
diff --git a/doc/bugs/get_fails_for_file:__47____47___web_remotes_if_the_file_is_empty.mdwn b/doc/bugs/get_fails_for_file:__47____47___web_remotes_if_the_file_is_empty.mdwn
new file mode 100644
index 000000000..84b107c31
--- /dev/null
+++ b/doc/bugs/get_fails_for_file:__47____47___web_remotes_if_the_file_is_empty.mdwn
@@ -0,0 +1,21 @@
+###What steps will reproduce the problem?
+    $ touch /home/arand/empty
+    $ git annex addurl 'file:///home/arand/empty'                                                                             
+    addurl _home_arand_empty (downloading file:///home/arand/empty ...) 
+    
+    git-annex: /home/arand/tmp/c/.git/annex/tmp/URL--file&c%%%home%arand%empty: getFileStatus: does not exist (No such file or directory)
+    failed
+    git-annex: addurl: 1 failed
+
+###What is the expected output? What do you see instead?
+If it is possible to distinguish between empty files and files that just fail to open, it would be nice if Annex were able to handle it, or at least give a more obvious error message.
+
+###What version of git-annex are you using? On what operating system?
+
+Debian sid/experimental
+
+    git-annex version: 4.20130227
+    local repository version: 4
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
diff --git a/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment
new file mode 100644
index 000000000..8c41b51f0
--- /dev/null
+++ b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="46.239.117.180"
+ subject="comment 2"
+ date="2013-03-10T03:06:55Z"
+ content="""
+From my tests, Rsync actually seems to honor the bandwidth limit that's in the sender's options. In particular, a dirty hard-coding of the limit in <tt>Utility.Rsync.rsyncServerParams</tt> (forwarding the option from <tt>git-annex-shell</tt> to the actuall rsync command, and) did the trick for me.
+
+I know Rsync merely tries to respect <tt>bwlimit</tt> on average, but for large files it's good enough I think. And for those like me who have a volume quota on their connection, it'd a plus to make <tt>git-annex-shell</tt> respect that limit. Well of course I could ask my users to use something like <tt>trickle</tt>, but external commands are more likely to be forgotten than a config option ;-)
+
+I couldn't see where in the code you whitelist the list of safe commands; Did you mean there is already such a thing, or is it empty right now? In any case, my wish doesn't seem to be hard to implement, and I'd be happy to try to provide a patch in the next few days.
+"""]]
diff --git a/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_3_d36045e2b466882108c5bf09580755fa._comment b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_3_d36045e2b466882108c5bf09580755fa._comment
new file mode 100644
index 000000000..2b39d4bfa
--- /dev/null
+++ b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_3_d36045e2b466882108c5bf09580755fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-10T16:58:44Z"
+ content="""
+There is not yet a white list, no. Patch would be appreciated.
+"""]]
diff --git a/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_11_0df2210c30dec6d88d7858d93eec19a3._comment b/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_11_0df2210c30dec6d88d7858d93eec19a3._comment
new file mode 100644
index 000000000..0ed43cc41
--- /dev/null
+++ b/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_11_0df2210c30dec6d88d7858d93eec19a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhjlfoU21OiXKH_MXw75Uq5EsX7LJW5p0"
+ nickname="Ian"
+ subject="comment 11"
+ date="2013-03-10T08:33:26Z"
+ content="""
+Thanks Joey! I'll hopefully manage to give the new version a try after my current batch of traveling.
+
+From the sounds of things I can expect it to just work now, rather than requiring some manual step to kick it out of its current state?
+"""]]
diff --git a/doc/bugs/webapp_hang/comment_2_2a21ac5657128a454f9deb77c4d18057._comment b/doc/bugs/webapp_hang/comment_2_2a21ac5657128a454f9deb77c4d18057._comment
new file mode 100644
index 000000000..ece1aa358
--- /dev/null
+++ b/doc/bugs/webapp_hang/comment_2_2a21ac5657128a454f9deb77c4d18057._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://crosstwine.com/dd/"
+ ip="88.65.128.43"
+ subject="chrome://net-internals/"
+ date="2013-03-09T20:10:54Z"
+ content="""
+Hi Joey,
+
+I see that you have found the cause and a workaround for this particular
+problem, but would like to point out that `chrome://net-internals/` can be
+very useful for diagnosing such issues.
+
+(I once hit the `SOCKET_POOL_STALLED_MAX_SOCKETS_PER_GROUP` problem
+mentioned in
+<https://code.google.com/p/chromium/issues/detail?id=27324>, which can
+cause Chromium to keep spinning while not issuing any new requests to a
+specific web server.)
+
+Cheers,  
+Damien Diederen
+"""]]
diff --git a/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn b/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn
new file mode 100644
index 000000000..135ec70ee
--- /dev/null
+++ b/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn
@@ -0,0 +1,3 @@
+Title says it all.
+
+It would be nice if I could tell git annex (assistant) which files (not) to annex (automatically).
diff --git a/doc/todo/wishlist:_recursive_directory_remote_setup__47__addurl.mdwn b/doc/todo/wishlist:_recursive_directory_remote_setup__47__addurl.mdwn
new file mode 100644
index 000000000..2bfb90b54
--- /dev/null
+++ b/doc/todo/wishlist:_recursive_directory_remote_setup__47__addurl.mdwn
@@ -0,0 +1,7 @@
+I think it would be interesting to have a way to recursively import a local directory without actually moving files around. And to be able to checksum these files as well (without moving them into the annex).
+
+This would work somewhat similar to looping over a directory and adding file:// remotes for each file.
+
+A use case is importing optical media (read-only), whilst keeping that media as a remote, and being able to calculate checksums directly without moving any files around.
+
+For single files, it would also be interesting if addurl had a "--localchecksum" option that would only work for file:// urls, and make it checksum files directly from their source location?)