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

7 files changed, 69 insertions, 0 deletions

diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn b/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn
new file mode 100644
index 000000000..2caf332af
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn
@@ -0,0 +1,18 @@
+I have previously been confused by how to have a bit more manual control over where files are (as in [[bugs/git-annex_immediately_re-gets_dropped_files/]]).
+
+I thought perhaps something like an archive directory would work, but as I might want different computers to have different content, perhaps a per-computer archive repository.
+
+To that end, I have
+
+<pre>walter@dionysus:~/annex$ git annex content .
+(exclude=archive/dionysus/* or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1)
+ok</pre>
+
+which is a modified version of the archive [[preferred_content]], but with the intention that I change the part after `exclude` to be different for each client.
+I also set the group to client for this client (dionysus).
+
+However, it does not seem to drop files when I move them into `archive/dionysus/`, and I cannot see anything in the logs to suggest why.
+
+What am I doing wrong here? Or, is this the wrong approach?
+
+--Walter
diff --git a/doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment b/doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment
new file mode 100644
index 000000000..4b4bf3eb7
--- /dev/null
+++ b/doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.128"
+ subject="comment 24"
+ date="2013-09-17T15:56:17Z"
+ content="""
+@Kristian, a new version of the DNS library has caused this. A workaround is to pass `-f-DNS` to the cabal command.
+
+I am in the process of adding support for the new DNS library version in git now.
+
+By the way, please [[file_a_bug|bugs]] if you have a big ugly looking build failure like that, so as to not clutter up this page.
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment b/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment
new file mode 100644
index 000000000..7643d4d7d
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="46.19.143.203"
+ subject="Missing prerequisites for XMPP syncing?"
+ date="2013-09-17T06:53:59Z"
+ content="""
+I set up two fresh annexes that can talk via XMPP and no other way. After I fire up the assistants I expect them to sync their metadata, but nothing happens. One log gives me an 'XMPPClient: received: [\"Unknown message\"]' message every two minutes. The other one doesn't contain the string XMPP at all, not once. So my suspicion is that this particular version of git-annex doesn't support XMPP, which is weird because:
+
+    $ git annex version
+    git-annex version: 4.20130909
+    build flags: Assistant Pairing Testsuite S3 Inotify XMPP DNS Feeds
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+This is the version output from the other machine: 
+
+    $ git annex version
+    git-annex version: 4.20130827
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+What am I missing? Are there more build flags for XMPP than the one called XMPP? (Also, no, I can't just copy versions between machines b/c the architectures are different. And yep, the one giving me trouble is ARM.)
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment
new file mode 100644
index 000000000..bd2212ffb
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPOttrEmm9CQYxzWrmgGN7LXy98gDkrlM"
+ nickname="binet"
+ subject="annex.largefiles and direct mode"
+ date="2013-09-16T22:50:48Z"
+ content="""
+I was wondering if the annex.largefiles feature was compatible with direct mode?
+"""]]
diff --git a/doc/todo/wishlist:_archive_from_remote_with_the_least_free_space.mdwn b/doc/todo/wishlist:_archive_from_remote_with_the_least_free_space.mdwn
new file mode 100644
index 000000000..acc8b363e
--- /dev/null
+++ b/doc/todo/wishlist:_archive_from_remote_with_the_least_free_space.mdwn
@@ -0,0 +1 @@
+An interesting feature, when an archived file cannot be removed from all clients because of the minimum number of copies required, would be to remove it from the repositories with the smallest amount of free space available.
diff --git a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn b/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn
new file mode 100644
index 000000000..004194a79
--- /dev/null
+++ b/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn
@@ -0,0 +1 @@
+When addWatcher gets a permission denied, it would be helpful to display the name of the object on which the permission was denied, in the error message which shows in the webapp.
diff --git a/doc/todo/wishlist:_display_status_of_remotes_in_the_webapp.mdwn b/doc/todo/wishlist:_display_status_of_remotes_in_the_webapp.mdwn
new file mode 100644
index 000000000..741466994
--- /dev/null
+++ b/doc/todo/wishlist:_display_status_of_remotes_in_the_webapp.mdwn
@@ -0,0 +1 @@
+It would be nice to have an indication of the status of the remotes in the webapp, for example with a field showing "In Sync", "Syncing", or the date of the last successful synchronization for unreachable remotes.