| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Since the queue is flushed in between subcommand actions being run,
there should be no issues with actions that expect to queue up some stuff
and have it run after they do other stuff. So I didn't have to audit for
such assumptions.
|
|
|
|
| |
git-annex-shell. This results in some oddly named keys in the v1 annex. Recognise and fix those keys when upgrading, instead of crashing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a cheap way to query the size of a queue.
runQueueAt is not the default yet only because there may be some code that
expects to be able to queue some suff, do something else, and run the whole
queue at the end.
10240 is an arbitrary size for the queue. If we assume annexed
filenames are between 10 and 255 characters long, then the queue will
build up between 100kb and 2550kb long commands. The max command line
length on linux is somewhere above 20k, so this is a fairly good balance --
the queue will buffer only a few megabytes of stuff and a minimal number
of commands will be run by xargs.
Also, insert queue items strictly, this should save memory.
|
| |
|
|
|
|
| |
In a large repo, just queuing the things to do used a lot of ram.
|
| |
|
| |
|
|
|
|
| |
still need to move location log files, and auto-commit
|
|
pulled in old versions of functions for working with keys
Wrote a parser from old key filenames to new keys.
|