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

doc/Slow_transfer_for_a_lot_of_small_files..mdwn

@@ -0,0 +1,11 @@
+What steps will reproduce the problem?
+Sync a lot of small files.
+
+What is the expected output? What do you see instead?
+The expected output is hopefully a fast transfer.
+
+But currently it seems like git-annex is only using one thread to transfer(per host or total?)
+
+An option to select number of transfer threads to use(possibly per host) would be very nice.
+
+And maybe also an option to limit how long a queue the browser should show, it can become quite resource intensive with a long queue.

doc/bugs/ControlPath_too_long_for_Unix_domain_socket.mdwn

@@ -0,0 +1,44 @@
+What steps will reproduce the problem?
+Pairing an existing git annex repository with a fresh repository on another computer in the git-annex webapp
+
+
+What is the expected output? What do you see instead?
+Expected result is that the two machines sync correctly.
+
+What i see are some "ControlPath <data>  too long for unix domain socket" errors from ssh, but the computers do actually sync properly. 
+
+Even though the data is synced properly, either the sender(or both of the clients) don't actually realize this. And the queue circles, all the transfers are being redone constantly(On every start of git-annex webapp on the original repository at least).
+
+
+What version of git-annex are you using? On what operating system?
+Latest git master as of this post. Debian sid and Ubuntu 12.04
+
+
+Please provide any additional information below.
+
+
+stdout snippet from git-annex webapp:
+
+
+    ControlPath "/home/alansmithee/Desktop/annex/.git/annex/ssh/alansmithee@git-annex-debbook.local-alansmithee.dxpXHVCkLhsxvWaH" too long for Unix domain socket
+    SHA256-s51233--0b4c59b3ab03b1ca6d95d4084fa6ff7220cf26695b6e3dd575f78af3dec6b701
+           51233 100%    5.43MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+    sent 30 bytes  received 51385 bytes  102830.00 bytes/sec
+    total size is 51233  speedup is 1.00
+    ok
+    (Recording state in git...)
+
+    ControlPath "/home/alansmithee/Desktop/annex/.git/annex/ssh/alansmithee@git-annex-debbook.local-alansmithee.9ZQwEjraTxi20B6W" too long for Unix domain socket
+    SHA256-s47883982--4b7cbb49506dcdd223a9db7b400cc41fc2e3ebbf5b2b17b75c9334bb949b6754
+        47883982 100%    1.34MB/s    0:00:34 (xfer#1, to-check=0/1)
+
+    sent 30 bytes  received 47889978 bytes  1388116.17 bytes/sec
+    total size is 47883982  speedup is 1.00
+    ok
+    (Recording state in git...)
+
+
+This data appears on both the sending and receiving git-annex stdout. At least for the initial sync. For later syncs it only appears on the sender, though the client system is using a lot of resources.
+
+

doc/design/assistant/blog/day_49__first_run_experience/comment_4_549b07bb02c07a5b1b95445b01758db2._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="dhess"
+ ip="173.247.200.7"
+ subject="Choose a friendly/unintimidating name"
+ date="2012-09-13T00:32:15Z"
+ content="""
+You've already decided to accommodate mom by choosing ~/Desktop as the default location, so you should be consistent: choose a name that means something to people. \"Annex\" and \"GitAnnex\" are good branding, but not very user-friendly. (Contrast with \"Dropbox\", the default folder name for Dropbox -- good branding *and* reasonably meaningful.)
+
+\"Shared\" is friendly, but implies that you're sharing with other people, which isn't necessarily the case. (You should reserve the name \"Shared\" for a sub-directory of the default directory, anyway, if/when the time comes to implement sharing URLs to your g-a-a objects with other users.)
+
+I think that \"Synced\" is fine. Most English-speakers will know what it means, and it's a good description of what g-a-a does.
+
+Don't worry whether we like it or not. Nobody who comments here, nor, likely, anyone who votes, will use the default name anyway ;)
+"""]]

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 0 "Amazon S3" 0 "Box.com" 0 "My phone (or MP3 player)" 0 "Tahoe-LAFS" 0 "OpenStack SWIFT" 0 "Google Drive" 0 "Amazon Glacier"]]
+[[!poll open=yes 4 "Amazon S3" 5 "Box.com" 10 "My phone (or MP3 player)" 0 "Tahoe-LAFS" 1 "OpenStack SWIFT" 1 "Google Drive" 1 "Amazon Glacier"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they

doc/design/assistant/polls/prioritizing_special_remotes/comment_1_dd9280df27848a7ff132f5809dab0a79._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-09-13T08:39:59Z"
+ content="""
+I've been looking at ceph for various reasons in work, it supports a swift interface as well as it's own restful api. so +1 for swift (and any s3 compatible api).
+"""]]

doc/design/assistant/polls/prioritizing_special_remotes/comment_2_370e0b9c43486ee96c825f9155eebde4._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2012-09-13T09:07:02Z"
+ content="""
+Swift has its own API but offers a S3 compatibility layer. Last I tried that layer, it did not work.
+"""]]

doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_4_e514fe2d4d0ad6a10e281939e6ab4266._comment

@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 4"
+ date="2012-09-12T20:32:52Z"
+ content="""
+I see a migration to SHA256E currently outputs:
+
+migrate issue.txt (checksum...) (Recording state in git...)
+ok
+
+Is that verifying the existing checksum or re-computing it to re-name the file?  If the latter, couldn't the SHA256 to SHA256E migration just rename the file?
+
+I would be worried about this process hiding data corruption.. If it isn't using the old checksum but instead re-computing a new one then it would be easy to miss the fact that a files checksum changed during this process.
+"""]]