~juan-f/duplicity/progress : changes

~juan-f/duplicity/progress » Changes from revision 922

From Revision 922 to 903

Rev	Summary	Authors	Date
922	progress: Removed an unneeded if progress: Removed an unneeded if	Juan A. Moya Vicén	11 years ago
921	progress: Fixes for the previous commit after extensive test... progress: Fixes for the previous commit after extensive testing: - Fixed the index computation for the rotating cache of Snapshots - Moved the start point for the Log progress thread after a proper computation of the starting volume in case of restart, and adapted code for it	Juan A. Moya Vicén	11 years ago
920	progress: Cover the sigtar and manifest upload with the prog... progress: Cover the sigtar and manifest upload with the progress reporting. Now the last 1% will be dedicated to this upload and properly report stallment when network goes off while this happens.	Juan A. Moya Vicén	11 years ago
919	progress: Fixed a missing condition for when the progress fl... progress: Fixed a missing condition for when the progress flag is not used	Juan A. Moya Vicén	11 years ago
918	progress: Cap data progress upload from 0..99% and show 100%... progress: Cap data progress upload from 0..99% and show 100% only when sigtar and manifest file has uploaded correctly	Juan A. Moya Vicén	11 years ago
917	progress: Avoid completed percentage to drops between backup... progress: Avoid completed percentage to drops between backup retries when backup fails and has to be restarted. The current progress is offset by the previous uncompleted backup from the last volume that upload correctly. To achieve it, the progress tracker now snapshots the current progress to the cache each completed volume, then recovers this information later when retrying a failed backup.	Juan A. Moya Vicén	11 years ago
916	progress: The algorithm now will drop the confidence interva... progress: The algorithm now will drop the confidence interval adaptively when overpassing the 100%. This may happen when the sigma is large due to a very heterogeneous distribution of the size of deltas in files. In this case, the C.I. will be drop by half to adapt to the variability. If it happens again, it will disregard the sigma and trust the mean only.	Juan A. Moya Vicén	11 years ago
915	progress: Simplified computation of progress to compute an u... progress: Simplified computation of progress to compute an upper bound, fit to a smooth curve. This method embraces better more "change distribution" scenarios and is much simpler to compute. And also, full backups will assume 1:1 correspondence in change distribution, so progress bars during full will be computed linearly, which is closer to reality.	Juan A. Moya Vicén	11 years ago
914	progress: Reporting speed in bps for log file progress: Reporting speed in bps for log file	Juan A. Moya Vicén	11 years ago
913	progress: Changed verbosity to NOTICE, so progress messages ... progress: Changed verbosity to NOTICE, so progress messages appears by default when --progress flag is on	Juan A. Moya Vicén	11 years ago
912	progress: Added average speed to the log file progress: Added average speed to the log file	Juan A. Moya Vicén	11 years ago
911	progress: Fixed a typo in if clause progress: Fixed a typo in if clause	Juan A. Moya Vicén	11 years ago
910	progress: Bugfixed a posible division by zero progress: Bugfixed a posible division by zero	Juan A. Moya Vicén	11 years ago
909	progress: New feature to compute progress of compress & uplo... progress: New feature to compute progress of compress & upload files The heuristics try to infer the ratio between the amount of data collected by the deltas and the total size of the changing files. It also infers the compression and encryption ration of the raw deltas before sending them to the backend. With the inferred ratios, the heuristics estimate the percentage of completion and the time left to transfer all the (yet unknown) amount of data to send. This is a forecast based on gathered evidence.	Juan A. Moya Vicén	11 years ago
908	* Merged in lp:~duplicity-team/duplicity/po-updates * Merged in lp:~duplicity-team/duplicity/po-updates - Updated translations	Kenneth Loafman	11 years ago
907	* Merged in lp:~mterry/duplicity/py3rsync * Merged in lp:~mterry/duplicity/py3rsync - This branch lets one build the _librsync module with Python 3. You can't really do anything useful with it, but it's a nicely-isolated piece to add Python 3 support for. - The changes are a mix of modernization and #ifdef logic. - All tests still pass in Python 2.7 and 2.4. I tested manually that the module worked as expected in Python 3.	Kenneth Loafman	11 years ago
906	* Merged in lp:~mterry/duplicity/pygi * Merged in lp:~mterry/duplicity/pygi - Python bindings for the gobject stack (used in the gio backend) have changed from static to dynamically-generated bindings. The old static bindings are deprecated. So here's a branch to change the gio backend from old to new ones.	Kenneth Loafman	11 years ago
905	* Merged in lp:~ed.so/duplicity/webdav.manpage * Merged in lp:~ed.so/duplicity/webdav.manpage - explanation of webdav changes above	Kenneth Loafman	11 years ago
904	* Merged in lp:~ed.so/duplicity/webdav.fix-retry * Merged in lp:~ed.so/duplicity/webdav.fix-retry - added ssl certificate verification (see man page) - more robust retry routine to survive ssl errors, broken pipe errors - added http redirect support	Kenneth Loafman	11 years ago
903	* Merged in lp:~mterry/duplicity/static-corruption * Merged in lp:~mterry/duplicity/static-corruption - This branch fixes three possible ways a backup could get data-corrupted. Inspired by bug 1091269. A) If resuming after a volume that ended in a one-block file, we would skip the first block of the next file. B) If resuming after a volume that ended in a multi-block file, we would skip the first block of the next file. C) If resuming after a volume that spanned a multi-block file, we would skip some data inside the file. - A and B are because when finding the right place in the source files to restart the backup, the iteration loop didn't handle None block numbers very well (which are used to indicate the end of a file). - C is what bug 1091269 talks about. This was because data block sizes would get smaller as the difftar file got closer and closer to the volsize. Standard block sizes were 64 * 1024. But say we were close to the end of the difftar... When resuming, duplicity doesn't know the custom block sizes used by the previous run, so it uses standard block sizes. And it doesn't always match up, as you can imagine. So we would leave chunks of data out of the backed up file. - Tests added for these cases. - This branch is called 'static-corruption' because all these issues occur even when the source data doesn't change. I still think there are some corruption issues when a file changes in between duplicity runs. I haven't started looking into that yet, but that's next on my list. - C only happened without encryption (because the gpg writer function already happened to force a constant data block size). A and B happened with or without encryption.	Kenneth Loafman	11 years ago

Older »