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

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

Browse source
This commit is contained in:
Joey Hess 2013-03-10 19:16:59 -04:00
commit 0633a33643
9 changed files with 120 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast.mdwn Normal file
View file

@ -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

10
doc/bugs/addurl_file_doesn__39__t_work_with_spaces_in_filenames_and_--fast/comment_1_eea9477ea1157cb88c8a07d8da5f0dba._comment Normal file
View file

@ -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
"""]]

21
doc/bugs/get_fails_for_file:__47____47___web_remotes_if_the_file_is_empty.mdwn Normal file
View file

@ -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

12
doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment Normal file
View file

@ -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.
"""]]

8
doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_3_d36045e2b466882108c5bf09580755fa._comment Normal file
View file

@ -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.
"""]]

10
doc/bugs/three_way_sync_via_S3_and_Jabber/comment_11_0df2210c30dec6d88d7858d93eec19a3._comment Normal file
View file

@ -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?
"""]]

21
doc/bugs/webapp_hang/comment_2_2a21ac5657128a454f9deb77c4d18057._comment Normal file
View file

@ -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
"""]]

3
doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn Normal file
View file

@ -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).

7
doc/todo/wishlist:_recursive_directory_remote_setup__47__addurl.mdwn Normal file
View file

@ -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?)