[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Still maintained?

From: Bill Harris
Subject: Re: [rdiff-backup-users] Still maintained?
Date: Thu, 8 Feb 2018 19:05:54 -0800

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.


On Wed, Feb 7, 2018 at 8:03 PM, Wes Cilldhaire <address@hidden> 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 address@hidden
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.
> php/RdiffBackupWiki

reply via email to

[Prev in Thread] Current Thread [Next in Thread]