| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
chunkcount file to not be written. Work around repositories without such a file, so files can still be retreived from them.
|
| |
|
|
|
|
| |
late-night hlint bit me on this one..
Reviewed f32cb2cf1576db1395f77bd5f7f0c0a3e86c1334 and
the rest of it seems ok
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There was confusion in different parts of the progress bar code about
whether an update contained the total number of bytes transferred, or the
number of bytes transferred since the last update. One way this bug
showed up was progress bars that seemed to stick at zero for a long time.
In order to fix it comprehensively, I add a new BytesProcessed data type,
that is explicitly a total quantity of bytes, not a delta.
Note that this doesn't necessarily fix every problem with progress bars.
Particularly, buffering can now cause progress bars to seem to run ahead
of transfers, reaching 100% when data is still being uploaded.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Files are now written to a tmp directory in the remote, and once all
chunks are written, etc, it's moved into the final place atomically.
For now, checkpresent still checks every single chunk of a file, because
the old method could leave partially transferred files with some chunks
present and others not.
|
| | |
|
| | |
|
| |
|
|
|
| |
Note that receiving encrypted chunked content currently involves buffering.
(So does doing so with the directory special remote.)
|
|
|
However, directory still uses its optimzed chunked file writer, as it uses
less memory than the generic one in the helper.
|
Joey Hess