diff options
9 files changed, 170 insertions, 2 deletions
diff --git a/doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment b/doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment new file mode 100644 index 000000000..66d3c07f8 --- /dev/null +++ b/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. :) +"""]] diff --git a/doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn b/doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn new file mode 100644 index 000000000..658a5a5e1 --- /dev/null +++ b/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. diff --git a/doc/bugs/unwanted_repository_version_upgrades.mdwn b/doc/bugs/unwanted_repository_version_upgrades.mdwn new file mode 100644 index 000000000..189550803 --- /dev/null +++ b/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. diff --git a/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn new file mode 100644 index 000000000..0b49f422f --- /dev/null +++ b/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 diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn new file mode 100644 index 000000000..08aa843cf --- /dev/null +++ b/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. diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn new file mode 100644 index 000000000..bba7762da --- /dev/null +++ b/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** === diff --git a/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment new file mode 100644 index 000000000..32beef427 --- /dev/null +++ b/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? +"""]] diff --git a/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment new file mode 100644 index 000000000..6e376e316 --- /dev/null +++ b/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\". + +"""]] diff --git a/doc/users/anarcat.mdwn b/doc/users/anarcat.mdwn index 003d412b7..94741aa9f 100644 --- a/doc/users/anarcat.mdwn +++ b/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 =========== |