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

5 files changed, 68 insertions, 0 deletions

diff --git a/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_1_27fc71cadcbe6d5f146ffdb72b64689a._comment b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_1_27fc71cadcbe6d5f146ffdb72b64689a._comment
new file mode 100644
index 000000000..8e87e86db
--- /dev/null
+++ b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_1_27fc71cadcbe6d5f146ffdb72b64689a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-05T18:26:10Z"
+ content="""
+It's not clear to me that the accept message has anything to do with dbus.
+
+Does the accept message continue being logged past this point? Does the log contain \"unable to bind to local socket\"?
+
+Are you able to open the webapp? That's the part of git-annex that would use `accept()`..
+"""]]
diff --git a/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_2_0fb01ff463e7da6df2864186dc28f8e4._comment b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_2_0fb01ff463e7da6df2864186dc28f8e4._comment
new file mode 100644
index 000000000..dd46672a0
--- /dev/null
+++ b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_2_0fb01ff463e7da6df2864186dc28f8e4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="comment 2"
+ date="2014-01-05T22:50:32Z"
+ content="""
+The accept lines just keep coming and coming and coming and coming. About 58 of them between \"lost dbus connection...\" logs. There's interspersed \"Everything up-to-date\" and such.
+
+grep'ing for \"unable\" across all daemon log files gives me nothing.
+
+I haven't futzed with opening the webapp on the NAS yet. Correction: I just did try futzing and I fear there's something in the NAS software I need to figure out before I can do it successfully.
+"""]]
diff --git a/doc/bugs/USB_drive_not_syncing/comment_1_de76bd6b9f8eb2489d4854a4c8ddd308._comment b/doc/bugs/USB_drive_not_syncing/comment_1_de76bd6b9f8eb2489d4854a4c8ddd308._comment
new file mode 100644
index 000000000..afa3b3b6c
--- /dev/null
+++ b/doc/bugs/USB_drive_not_syncing/comment_1_de76bd6b9f8eb2489d4854a4c8ddd308._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-05T18:52:08Z"
+ content="""
+You seem to have already had a regular bare git repository on the drive at `/media/A-DATA UFD/annex`, and then used the webapp or command line to make an encrypted gcrypt repository in the same location. This is the only way I can explain you being able to run \"git annex get in `/media/A-DATA UFD/annex` and it do anything at all, and it also explains the \"warning: no common commits\" and the failure to sync.
+
+So, you have some unholy mix of two different types of repositories in one location. The best way to untangle this is probably to go into the webapp and 
+in the settings menu next to that repository, choose Delete. This will get back the files that were stored in the gcrypt repository. (Or stop the assistant, and in `~/annex/` run `git annex get` to hopefully retrieve the files that it stored in the gcrypt repository, and then remove the gcrypt repository from .git/config).
+
+You may then need to edit `/media/A-DATA UFD/annex/config` to remove the gcrypt-id setting. At that point, it should be possible to use the webapp to add the removable drive, which will see the git repository on there and use it.
+
+I have re-tested that the webapp does not allow creating a gcrypt repository when a regular bare git repository already exists on a removable drive. IIRC there were some bugs in this area initially, but they've all been fixed for a while. It *is* possible to manually use `git annex initremote` at the command line to turn a regular bare git repository into a gcrypt repository. 
+"""]]
diff --git a/doc/bugs/import_memleak_from_the_assistant/comment_3_b193a4a0901c681b59a97b93b456765b._comment b/doc/bugs/import_memleak_from_the_assistant/comment_3_b193a4a0901c681b59a97b93b456765b._comment
new file mode 100644
index 000000000..6d03b4cdb
--- /dev/null
+++ b/doc/bugs/import_memleak_from_the_assistant/comment_3_b193a4a0901c681b59a97b93b456765b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 3"
+ date="2014-01-05T20:41:35Z"
+ content="""
+Well, EKG either cannot see the leak, or perhaps haskell profiling generally cannot see it. Don't have a lot of experience with EKG, it's just a lot easier to ask for than full ghc profiling data..
+
+It's certainly useful information that you are constantly changing the files.
+
+I have tried to replicate this setup, with a few hundred files, and writing random stuff to them repeatedly. The RSS did not grow at all despite repeatedly changing and committing the files.
+
+I then tried adding a remote for it to sync with, and see evidence of a small leak there -- around 8 bytes per file transferred. The leak appears to be in the transfer code, not the git sync code; it happens with both git remotes and with directory special remotes.
+
+"""]]
diff --git a/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment b/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment
new file mode 100644
index 000000000..ec53f7aac
--- /dev/null
+++ b/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRRUUZo3W7pAoRoST8P_l0PtUBhvYuzDg"
+ nickname="Lyle"
+ subject="exactly this use case: cloud remotes too small"
+ date="2014-01-06T00:31:34Z"
+ content="""
+I want to store a lot of scientific data in git-annex and have only a specific subset of my often used data in a box.com account so it is quickly synced between computers (my home internet has a limited upload speed). My home server will store all the files as it has effectively unlimited space. 
+
+I basically want the opposite of archive for git-annex-assistant, I'd like to mark the box.com special remote to store every *except* a certain special directory called less used files or whatever, or vise-versa, only store a folder of often used files, the local clients would store everything and my home server would also store everything. 
+
+It seems like transfer control and the groups.log can do this but I'm just not sure how to actually set it up?
+
+Thanks!
+"""]]