Hi Daniel
I welcome your proposal. The issue about verifying the integrity of
rdiff-backup repositories is an important one.
We haven't heard (on this mailing list) from the maintainer of
rdiff-backup, Andrew Ferguson, for nearly a year so I hope he is okay.
When he introduced the 1.3.0 development branch (4 Jan 09) he wrote:
Today, I have started a new Development/Unstable branch which will
include new features, new bug fixes, and yes, new bugs. Remember: in
the Development branch, there is no guarantee of backwards-
compatibility. In order to fix some of the more subtle Windows and
Linux/FAT32 bugs, it looks like it will be necessary to do that every
so often, which is why I have started this new Development branch.
For now, this branch will not be focused on porting to Python 2.6/3.
There are plenty of useful features and bug fixes to focus on instead.
I would prefer to see this new branch become a new stable series
(1.4.x) on a much shorter time scale than the last one did (which took
nearly three years!).
Releases from the Development branch will never purposefully destroy
your backups. (I try to give them at least a basic shakedown.
However, if you choose to run them, the expectation is that you will
keep up with the releases on both your clients and your servers. Also,
expect that sometimes features will break in unexpected ways. If that
happens, please submit a bug report.
New in v1.3.0 (2009/01/03)
---------------------------
New option: --use-compatible-timestamps, which causes rdiff-backup to
use - as
the hour/minute/second separator instead of :. Enabled by default on
systems
which require : to be escaped. (Oliver Mulatz)
Allow rdiff-backup to backup files which it cannot read, but can change
the permissions of. (Andrew Ferguson)
Take start and end times from same system so that the elapsed time
printed in
the statistics is not affected by time zone. (Andrew Ferguson)
Properly fix escaping DOS devices and trailing periods and spaces; now
supports native Windows and Linxu/FAT32. (Andrew Ferguson)
I guess his aim of a short development timetable has not worked out.
Personally I use rdiff-backup for windows (as client) and for linux (as
server) version 1.2.5 and I would say work from the 1.2.8 stable branch,
but I am not a python coder and have never tried to use rdiff-backup 1.3.3.
Dominic
On 03/02/2010 21:58, Daniel Miller wrote:
Hi,
I'm planning on implementing some new features in rdiff-backup.
Specifically, I'm going to attempt to implement the features I was
asking for a while ago in a thread with the subject "*Verify times
increasing*" (that is, real full-repository verification).
I'd like to know which version of rdiff-backup to implement these new
features against. Should I develop them against the stable (1.2.
or
should I develop them against the development version in CVS? (aside:
are we really still using CVS??? ever heard of git?)
I'm going to use the features I implement in a production environment,
so I need whatever I end up with to be stable. Which brings up the
question: How stable is the development branch? Is it stable enough to
use in a production environment?
Thanks, Daniel
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
