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

This commit is contained in:
Joey Hess 2014-06-04 12:49:32 -04:00
commit e066a6f892
9 changed files with 170 additions and 2 deletions

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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