Rdiff-backup

A change in python from the 2.2a series to 2.2b series made remote backup on version 0.3.3 stop work, a small change fixes it.
(Thanks to Berkan Eskikaya for telling me about this.)

Listed some missing features/bugs on the manual page.

Changed quoting system yet again after learning that the old system was not very portable between shells (thanks Hans link:mailto:hguevremonteternitee.com[hguevremonteternitee.com])

Added --list-increments and --remove-older-than commands.
--list-increments will just tell you what increments you have and their dates.
This isn't anything you couldn't get from "ls", but it may be formatted more nicely.
The --remove-older-than command is used to delete older increments that you don't want, or don't have space for.

Also, on some systems ssh was adding a spurious "Broken pipe" message, even though everything went fine.
Maybe this version will prevent this confusing message.

Fix for stupid bug - when running remotely as users with different uids, rdiff-backup now doesn't check the uid/gid.
Before it kept thinking that the files needed to be updated because they didn't have the right ownership.
This shouldn't have resulted in any data loss - just some unnecessary .rdiff files.
(Thanks to Michael Friedlander for finding this.)

Added check to make sure that rdiff exits successfully.

rdiff-backup has been almost completely rewritten for v0.3.0, as it was for v0.1.0.
The main problem with versions 0.2.x was that the networking code was added to the not-remote-capable v0.1, and the result was unwieldy and prone to bugs when operating over a pipe.

There are some new features:

* Hopefully very few bugs, at least in basic file handling.
rdiff-backup has an extensive testing suite now, so it should be much more reliable.
* Complete support for reading and writing from and to files and directories that lack permissions, by temporarily changing them, and then changing them back later.
(See for instance the --change-source-perms switch.) As I found out there is a lot to this, so much that I'm not sure in retrospect I should have bothered.
:-)
* New more standard format for increment files.
See https://www.w3.org/TR/NOTE-datetime for the time standard.
The old format, besides being less standard, didn't take timezones into account.
* In the initial mirroring, rdiff-backup only copies the files that it needs to, so it is much quicker when you almost have an initial mirror already.
You can even the --mirror-only switch and make rdiff-backup into a slow version of rsync.
* Terminal and file verbosity levels can be selected separately.
So if you like a lot in your backup.log/restore.log but not much on your terminal, or vice-versa, you can set them at different numbers.
* New --test-server option so if something goes wrong you can see if it is because the server on the other side isn't being initialized properly.
* New --no-rdiff-copy option, which disables using rdiff to move files across a connection (it will still be used to make increment files however).
If the bottleneck is not bandwidth but local disks/CPUs, this options should speed things up.

There are, however, a few negatives:

* rdiff-backup now requires Python version 2.2 or later.
Sorry for the inconvenience but I use the new features a lot.
* It may be slightly slower overall than versions 0.2.x - the remote code is cleaner, but probably has higher overhead.
At least on my computer, rdiff-backup is still quicker than rsync for local mirroring of large files, but for remote mirroring, rsync will usually be much quicker, because it uses a fairly low-overhead pipelining protocol.
* Any old increments are incompatible because they use a different date/time standard.
If this is a big deal, try mailing me.
A converter shouldn't be very difficult to write, but I didn't want to take the time unless someone really wanted it.

Fixed two stupid bugs that would cause rdiff-backup to exit with an exception.
(I can't believe they were in there.)