b261df735d
bup already splits files and does rolling deltas, so there is no reason to use chunking here. The new API made it easier to add progress support for storeKey, so that's done. Unfortunately, bup-split still outputs its own progress with -q, so a little ugly, but not too bad. Made dropping remove the branch for an object, for two reasons: 1. The new API calls removeKey to roll back a storeKey when the content changed unexpectedly. 2. So that testremote will be happy. Also, fixed a bug that caused a crash when removing the branch for an object in rollback.
43 lines
1.5 KiB
Markdown
43 lines
1.5 KiB
Markdown
Currently, git-annex takes a very lazy approch to displaying
|
|
progress into. It just lets rsync or whatever display the progress
|
|
for it, in the terminal.
|
|
|
|
Something better is needed for the [[webapp]]. There needs to be a
|
|
way for the web app to know what the current progress is of all transfers.
|
|
|
|
This is one of those potentially hidden but time consuming problems.
|
|
|
|
## downloads
|
|
|
|
* Watch temp file as it's coming in and use its size.
|
|
Can either poll every .5 seconds or so to check file size, or
|
|
could use inotify. **done**
|
|
* When easily available, remotes call the MeterUpdate callback as downloads
|
|
progress. **done**
|
|
* S3: TODO
|
|
While it has a download progress bar, `getObject` probably buffers the whole
|
|
download in memory before returning. Leaving the progress bar to only
|
|
display progress for writing the file out of memory. Fixing this would
|
|
involve making hS3 stream better (also avoids it wasting memory).
|
|
|
|
## uploads
|
|
|
|
Each individual remote type needs to implement its own support for calling
|
|
the MeterUpdate callback as the upload progresses.
|
|
|
|
* git: **done**
|
|
* rsync: **done**
|
|
* directory: **done**
|
|
* web: Not applicable; does not upload
|
|
* webdav: **done**
|
|
* S3: **done**
|
|
* glacier: **done**
|
|
* bup: **done**
|
|
* hook: Would require the hook interface to somehow do this, which seems
|
|
too complicated. So skipping.
|
|
|
|
## communication
|
|
|
|
It may be worth using a better communication channel than files on disk for
|
|
the transfer progress. Shared memory could be used, or http posts to the
|
|
webapp.
|