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

doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 4"
+ date="2014-06-04T04:53:36Z"
+ content="""
+ah. i see. certainly an operator error then. feels like a usability issue now, or i just feel stupid, not sure which. :)
+"""]]

doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn

@@ -0,0 +1,9 @@
+### Please describe the problem.
+
+I have found various `.tmp` files in a directory in which I performed various `git annex import` that failed because the destination disk was full.
+
+These files should be removed when import detects that its has no more space to proceed and exists.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 5.20140517.4 in Ubuntu 12.04.

doc/bugs/unwanted_repository_version_upgrades.mdwn

@@ -0,0 +1,25 @@
+Is it possible to freeze or peg repositories at a particular version, or to prevent automatic repository version upgrades?  Is it possible to "downgrade" a repository?
+
+### Please describe the problem.
+
+We have a number of repositories on a shared file server.  These repositories are accessed by multiple machines.  Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex.
+
+We're getting this message:
+[[!format sh """
+user@system:/path/to/repository$ git annex status
+git-annex: Repository version 5 is not supported. Upgrade git-annex.
+"""]]
+
+The machine experiencing the problem is running Debian Wheezy (Stable).
+[[!format sh """
+user@system:/path/to/repository$ git version
+git version 1.7.10.4
+user@system:/path/to/repository$ git annex version
+git-annex version: 3.20120629
+local repository version: 5
+default repository version: 3
+supported repository versions: 3
+upgrade supported from repository versions: 0 1 2
+"""]]
+
+I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action.

doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn

@@ -0,0 +1,76 @@
+Hi, I tried with several git annex versions, on 3 different clients, and using 2 different remotes (an home server and box.com) and trying out different remotes setups but I've been unable to get git annex working as I expected.
+
+
+I used the assistant for setup, I can sync files between clients just fine if they're connected at the same time, but if I sync a file from client A to the remotes when client B is off, and then later I turn off client A and power on client B, I've never been able to successfully sync files.
+
+on client B, inside .git/annex/daemon.log there's nothing interesting: just messages like:
+
+```(scanning...) [2014-06-03 14:53:26 CEST] Watcher: Performing startup scan
+
+Already up-to-date.```
+
+`git annex sync` just outputs
+
+`"commit  ok"`
+
+and `git annex list`:
+
+```
+here
+
+|berdario
+
+||soloud
+
+|||web
+
+||||box.com
+
+|||||
+
+XX__X IMG_20130202_100444.jpg
+
+XXX_X cookies.png
+
+XXX_X dancingllama.png
+
+XXX_X dario_bertini_cv.pdf
+
+XX__X steam_latest.deb
+```
+
+while this is what I get on client A:
+
+```
+here
+
+|berdario
+
+||web 
+
+|||box.com 
+
+||||
+
+XX_X IMG_20130202_100444.jpg
+
+X__X Russian Lesson 5 - Wikibooks, open books for an open world.html
+
+XX_X cookies.png
+
+XX_X dancingllama.png
+
+XX_X dario_bertini_cv.pdf
+
+XX_X steam_latest.deb
+```
+
+(they're just a bunch of random files I'm using to test it, both clients are called berdario, soloud is the home server (currently down) and the other working remote is box.com)
+
+As you can see the russian wikibooks html file is successfully synced with the remotes, but client B is unable to see it...
+
+I tried to set the remotes as incremental backup, full backup, transfer, client (!?) but none of these settings work.
+
+Is git annex not what I'm looking for? Is it supposed to work only on contemporarily connected clients?
+
+Thanks

doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn

@@ -0,0 +1,3 @@
+I have made some mistakes while using `git annex import` in direct mode. Now I see that some files have been erroneously added and there are other problems. I have not yet used `git annex sync`.
+
+How can I tell git-annex in direct mode (or bare git) to forget about all these changes and revert back to the last known good (pre-import) state? This means also removing the few imported files and recreate their links.

doc/forum/views___40__branches__41___never_get_deleted.mdwn

@@ -0,0 +1,16 @@
+Hello everyone,
+I would like to know if this is normal behavior or if it's a problem with my repository:
+
+Whenever I set a view with 
+
+git annex view attr="\*"'
+
+a new branch representing the selected view gets created, as expected. The problem is that when I switch back to master ('git checkout master' or even 'git annex vpop') the view branch stays there, and all subsequent operations on the annex also consider the view branch, resulting a great slowdown if one has done many views (attr="this", attr="that", etc.). Is this normal? If so, why is it necessary for the branch to stay on? Does it speed up going back to the branch? Redoing git annex view attr="*" does not seem to take less time. 
+
+Am I doing it wrong? Should I be deleting used view branches on my own? How?
+
+thanks for your replies.
+
+**EDIT:** I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this?
+
+=== git-annex version: **5.20140529-gb71f9bf** ===

doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="erics"
+ ip="76.10.136.8"
+ subject="comment 5"
+ date="2014-06-03T17:49:10Z"
+ content="""
+> It doesn't seem to solve the original use case.
+
+It doesn't?  The OP requested:
+
+> I would like to hold onto this data if possible, but if you need the space, please delete it
+
+It looks to me as though my suggestion does just that -- or am I misunderstanding what they asked for?
+"""]]

doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="erics"
+ ip="76.10.136.8"
+ subject="Metadata vs "drop --relaxed""
+ date="2014-06-03T18:20:50Z"
+ content="""
+[This isn't as much about my suggested implementation for \"drop --relaxed\" as about whether the feature is worth providing in the first place.  I'm not arguing strongly for it, actually; just continuing the discussion.]
+
+> I'd be inclinded to instead use the new metadata support.
+
+I see metadata as more for static attributes of a given file -- this thing is \"a picture\", \"related to project X\", \"from Mary\".  Thus, the combination of metadata plus preferred-content settings seems to me more suitable for static preferences (likely ones that implement some kind of policy, however informal); e.g. \"this repo wants pictures but not mp3s\", or \"Mary's stuff but not Alex's\".
+
+\"drop --relaxed\", on the other hand, would be good for more ad-hoc usage: \"disk space is getting tight; hmm, I'm not using *foo* today, so git-annex, please delete my local copy of *${myrepo}/foo* -- but only as much as you have to, because I'm going to want it again tomorrow\".
+
+One reason not to want to use metadata and preferred-content settings for such short-term, ad-hoc needs is that you then have to remember to go undo the changes later.  That's even worse if you had to add ad-hoc metadata, and now have to go delete it all again.  Undoing a \"drop --relaxed\", on the other hand, consists of a simple \"git annex get\".
+
+"""]]

doc/users/anarcat.mdwn

@@ -32,13 +32,13 @@ My bugs
 ... same.
 
 [[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
-link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0]]
+link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
 
 Fixed
 -----
 
 [[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
-link(users/anarcat)" feeds=no actions=yes archive=yes show=0]]
+link(users/anarcat)" feeds=no actions=yes archive=yes show=0  template=buglist]]
 
 Forum posts
 ===========