mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

new plan

Browse source
This commit is contained in:
Joey Hess 2011-06-29 20:22:19 -04:00
parent 06a1f5f742
commit 8725fde5c6
1 changed files with 20 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/speed_up_fsck.mdwn
View file

@ -5,6 +5,8 @@ are slightly slower but are swamped by the normal runtime.
For fsck though, it has to pull each file's location log info out of git. For fsck though, it has to pull each file's location log info out of git.
And, it's typically run on the entire tree. And, it's typically run on the entire tree.
Another slow one in `git annex copy --from`.
It would be possible to run a single `git cat-file --batch` and pass it It would be possible to run a single `git cat-file --batch` and pass it
sha1s of location logs for file that is going to be fsked (gotten via sha1s of location logs for file that is going to be fsked (gotten via
`read-tree`). Then just read its output until the next requested sha1 to `read-tree`). Then just read its output until the next requested sha1 to
@ -16,3 +18,21 @@ provide the info on a side channel of some sort.
If this is implemented, the same infrastructure could be used for other If this is implemented, the same infrastructure could be used for other
commands like whereis and add. --[[Joey]] commands like whereis and add. --[[Joey]]
> Updated plan:
>
> Run `git ls-file --batch`, and cache its stdin and out handles in Branch
> state.
>
> To see a git-annex branch file, send it something like
> "git-annex:uuid.log", and read the content fron stdout handle.
>
> To detect the end of content, send "TOKEN\n", and look for
> "TOKEN missing" in its output. A good choice for TOKEN is anything
> that will never exist in the repo; 40 0's would be a fairly good choice,
> but even better seems to be something completely invalid and impossible
> to have as a sha1 or filename or ref: "".
>
> Hmm, except that's actually an error message sent to stderr. Unless
> stderr is connected to stdout, it might be better to look for a known,
> empty object. Could just add a git-annex:empty file to that end.