reorg

doc/todo/add_a_git_backend.mdwn

@@ -0,0 +1,6 @@
+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.

doc/todo/backendSHA1.mdwn

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

doc/todo/branching.mdwn

@@ -0,0 +1,36 @@
+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.

doc/todo/done.mdwn

@@ -0,0 +1,4 @@
+recently fixed [[todo]] items.
+
+[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10
+archive=yes]]

doc/todo/file_copy_progress_bar.mdwn

@@ -0,0 +1,3 @@
+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?

doc/todo/fsck.mdwn

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

doc/todo/gitrm.mdwn

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

doc/todo/network_remotes.mdwn

@@ -0,0 +1,5 @@
+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..

doc/todo/parallel_possibilities.mdwn

@@ -0,0 +1,13 @@
+One of my reasons for using haskell was that it provides the possibility of
+some parallell processing. Although since git-annex hits the filesystem
+heavily and mostly runs other git commands, maybe not a whole lot.
+
+Anyway, each git-annex command is broken down into a series of independant 
+actions, which has some potential for parallelism.
+
+Probably they would need to be split further. Each action currently has 3
+distinct phases, basically "check", "do", and "record". If the check action
+returned a do action that returned a record action, then it could easily
+make sense to parallelize the check actions and start on the do actions
+(which probably won't parallelize well) while they are still being
+generated, and possibly parallelize the record actions at the end.

doc/todo/pushpull.mdwn

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

doc/todo/rsync.mdwn

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

doc/todo/symlink_farming_commit_hook.mdwn

@@ -0,0 +1,12 @@
+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.

doc/todo/using_url_backend.mdwn

@@ -0,0 +1,11 @@
+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]]