[Top][All Lists]

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

Re: [rdiff-backup-users] Maintenance

From: Dominic Raferd
Subject: Re: [rdiff-backup-users] Maintenance
Date: Sun, 28 Apr 2013 17:47:54 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Ned, I think it would be great it you wanted to be maintainer, if you have the time to do it. Andrew went off to pastures new a while ago and isn't seen around here now, so the project has been unmaintained for a while. I might be able to get you an email address for him though. Failing that I guess you could create a fork.

There is a wish-list somewhere (quite a long and old one I'm afraid). But it might be easier to look back at bug-related issues that have arisen on the mailing list over the last couple of years. Or I dare say if you ask here you will get suggestions (too many maybe!)

Some of the recurrent issues relate to backups to/on Windows filesystems or saving/recovering Windows ACLs. However rdiff-backup is stable in my experience for backups *from* Windows onto Linux fs and back to Windows, ignoring ACLs. I am not sure about how well it works on Macs these days, but I haven't seen many issues raised here... One serious failing in rdiff-backup is its verification procedures which are rather inadequate.

My suggestion would be to focus on fundamental bug issues and functionality rather than 'front-end' because others can always wrap rdiff-backup with tools that make it easy to use. The bigger problem is if it is, or is perceived to be, unreliable.

I created and maintain TimeDicer (http://www.timedicer.co.uk) which is a (free) front-end for rdiff-backup on Windows (among other things it handles snapshots), but I don't do python so I can't help with coding - sorry.

Someone else looked at the rdiff-backup codebase a while back and said it was very untidy and repetitious and they lost interest in updating it. Just warning you before you get stuck in! But you would be performing a great service...



On 28/04/13 14:35, Edward Ned Harvey wrote:

Hey everyone - Andrew here?  Anybody else a current maintainer?


I'd like to offer some assistance.  While I don't have a lot of time, I'm very good as a sysadmin, and pretty good at python and C.  (Currently a half-time IT person, and half-time C# / .Net developer, and in a past life, have had roles as fulltime java and python developer.)


The very first thing I'd like to address is the broken links on the rdiff-backup page.


Does a wiki still exist?  If so, I'd like to correct that link.  And if not, remove it.


I'd like to correct the link to the mailing list.


After that, I'd like to discuss moving off CVS, perhaps go to svn or git.  I would bias toward svn just cuz it's simpler, and this is a very low activity project...  Git would win hands-down if it were a huge rapidly developing project with a lot of maintainers.  But if you want to use git, I can go along with that, and for that matter ...  If you really don't want to get off CVS, so be it.


But I want to move to subversion.


I would like to add two really simple features: 


#1  Ability to store comments, when you send a backup.  Similar to a versioning system commit message.  I presume the argument syntax would be like

-m "message goes here"

(Heck, it would be nice to store a list of changed files in each backup rev too, or create the ability to easily display differences from rev X to rev Y, but that might be a little tougher.  Create the --show-log option and --diff to compare two backups against each other.)


#2  A config file that allows user to specify named backup sets.  So you don't need to specify the complete source & destination path every time you want to send a newly updated backup.  You just say something like:

sudo rdiff-backup etc -m 'updated ssl certs due to expiration date'

rdiff-backup-users mailing list at address@hidden
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

reply via email to

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