I have routinely used rdiff-backup for years. I appreciate that it just works. I appreciate that it stores the backup uncompressed so that I don't have to have access to rdiff-backup to restore the data if worse comes to worst. I appreciate that you are working carefully on useful enhancements.
More list traffic is okay, but I appreciate both that I don't have to read a lot to use this routinely and that it seems like there are plenty of people here who can help if there are questions. As a result, I'm also okay if the list is relatively quiet. Bill On Wed, Feb 7, 2018 at 8:03 PM, Wes Cilldhaire <w...@sol1.com.au> wrote: > > Also wrote this: https://eugenemakerspace.com/ > wiki/Sites/Rdiff-backup-delete > > would be nice if that functionality could be folded back in to > Rdiff-backup. > :-) > > Clif Cox > > Hi, sorry we haven't been able to give rdiff-backup the attention it > deserves > before now but we have been familiarizing ourselves with the open issues as > well as the state of the inherited codebase and unreleased changes from the > original repo before we start making new changes and deploying. As I'm > sure > you can all understand it's something that should be done delicately - I'd > hate to push a previously undeployed change without analyzing and testing > it > only to find it corrupts people's backups, or likewise not deploying a > pending > change people have been waiting for that fixes some critical issue. > > I just wanted to let you know that we have included the functionality from > rdiff-backup-delete into the github repository as a python script already: > https://github.com/sol1/rdiff-backup/blob/master/rdiff- > backup/misc/rdiff-backup-delete.py > > There's more work to be done with it though - at the moment it's a pretty > slow > algorithm that operates on supplied filenames sequentially and there is > plenty > of opportunity to optimize it for better performance. > > Also, people are free to submit PR's if they have bug fixes or new features > that they feel will benefit the rdiff-backup user community and we will > consider all submissions. At this stage, momentum is slow but building > and we > will address open issues in turn. I've started to triage them internally > so > we can address some low hanging fruit that won't involve drastic code > changes > and hope to get some time to push these through soon. > > Thanks, > Wes Cilldhaire > Sol1 > > > > _______________________________________________ > rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index. > php/RdiffBackupWiki > _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
