This commit is contained in:
Joey Hess 2010-10-25 11:47:45 -04:00
parent fed1d3c1f5
commit 81f71e57b9
15 changed files with 22 additions and 0 deletions

View file

@ -1,6 +0,0 @@
There should be a backend where the file content is stored.. in a git
repository!
This way, you know your annexed content is safe & versioned, but you only
have to deal with the pain of git with large files in one place, and can
use all of git-annex's features everywhere else.

View file

@ -1 +0,0 @@
This backend is not finished.

View file

@ -1,36 +0,0 @@
The use of `.git-annex` to store logs means that if a repo has branches
and the user switched between them, git-annex will see different logs in
the different branches, and so may miss info about what remotes have which
files (though it can re-learn).
An alternative would be to store the log data directly in the git repo
as `pristine-tar` does. Problem with that approach is that git won't merge
conflicting changes to log files if they are not in the currently checked
out branch.
It would be possible to use a branch with a tree like this, to avoid
conflicts:
key/uuid/time/status
As long as new files are only added, and old timestamped files deleted,
there would be no conflicts.
A related problem though is the size of the tree objects git needs to
commit. Having the logs in a separate branch doesn't help with that.
As more keys are added, the tree object size will increase, and git will
take longer and longer to commit, and use more space. One way to deal with
this is simply by splitting the logs amoung subdirectories. Git then can
reuse trees for most directories. (Check: Does it still have to build
dup trees in memory?)
Another approach would be to have git-annex *delete* old logs. Keep logs
for the currently available files, or something like that. If other log
info is needed, look back through history to find the first occurance of a
log. Maybe even look at other branches -- so if the logs were on master,
a new empty branch could be made and git-annex would still know where to
get keys in that branch.
Would have to be careful about conflicts when deleting and bringing back
files with the same name. And would need to avoid expensive searching thru
all history to try to find an old log file.

View file

@ -1,3 +0,0 @@
Find a way to copy a file with a progress bar, while still preserving
stat. Easiest way might be to use pv and fix up the permissions etc
after?

View file

@ -1 +0,0 @@
add a git annex fsck that finds keys that have no referring file

View file

@ -1,2 +0,0 @@
how to handle git rm file? (should try to drop keys that have no
referring file, if it seems safe..)

View file

@ -1,5 +0,0 @@
Support for remote git repositories (ssh:// specifically can be made to
work, although the other end probably needs to have git-annex
installed..)
[[done]], at least get and put work..

View file

@ -1,2 +0,0 @@
--push/--pull should take a reponame and files, and push those files
to that repo; dropping them from the current repo

View file

@ -1,2 +0,0 @@
Transferring a file from a ssh:// remote should use rsync to allow resuming
of a prior transfer.

View file

@ -1,12 +0,0 @@
TODO: implement below
git-annex does use a lot of symlinks. Specicially, relative symlinks,
that are checked into git. To allow you to move those around without
annoyance, git-annex can run as a post-commit hook. This way, you can `git mv`
a symlink to an annexed file, and as soon as you commit, it will be fixed
up.
`git annex init` tries to set up a post-commit hook that is itself a symlink
back to git-annex. If you want to have your own shell script in the post-commit
hook, just make it call `git annex` with no parameters. git-annex will detect
when it's run from a git hook and do the necessary fixups.

View file

@ -1,11 +0,0 @@
There is no way to `git annex add` a file using the URL [[backend|backends]].
For now, we have to manually make the symlink. Something like this:
ln -s .git/annex/URL:http:%%www.example.com%foo.tar.gz
Note the escaping of slashes.
A `git annex register <url>` command could do this..
[[done]]