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-09-17 12:48:09 -04:00
commit cac0688d0e
7 changed files with 69 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

18
doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn Normal file
View file

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

12
doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment Normal file
View file

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

28
doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment Normal file
View file

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

8
doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment Normal file
View file

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

1
doc/todo/wishlist:_archive_from_remote_with_the_least_free_space.mdwn Normal file
View file

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

1
doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn Normal file
View file

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

1
doc/todo/wishlist:_display_status_of_remotes_in_the_webapp.mdwn Normal file
View file

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