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

This commit is contained in:
Joey Hess 2013-12-02 20:33:30 -04:00
commit 33f89c9d03
3 changed files with 26 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
nickname="maurizio"
subject="comment 9"
date="2013-12-02T20:49:14Z"
content="""
I had already tried ```git annex fsck``` and for all files the command returned ```ok```. Nevertheless, it was still not possible to get the data. Now after a few days it seems I can get all the data I tried from both clients. Maybe because the repository contains many files (about 1.5e6) the daily sanity check spawns git processes which do not seem to terminate even when the delay has expired but other than that the repository does not seem to be in a bad state, the only weirdness being the 155 nonrepositories in the status.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.64"
subject="comment 4"
date="2013-12-02T20:35:45Z"
content="""
@helmut Well, true, it could overwrite the old ref with a new one at the start of a new fsck pass. If there was a separate ref for each uuid, this would work even for mixed local/remote fscking. And git should eventually drop the objects associated with the old ref, probably in `gc --auto`, which has a default --prune of 2 weeks.
The git overhead would probably be fine for fsck. I am less sure about it for the direct mode mapping files, which can be queried quite frequently. In particular inAnnex is used lots of places, often repeatedly on a lot of files, and it uses withObjectLoc, which uses associatedFiles.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.64"
subject="comment 14"
date="2013-12-02T20:05:00Z"
content="""
Should be fixed; the git commit is now avoided.
"""]]