Daniel Miller wrote:
Hi Josh,
Development
on rdiff-backup has stagnated for the last while. I think that this is
attributable to several reasons:
* Andrew has dropped of the face of the earth, (he's working on
graduate studies, IIRC) and I've been busy with other things. Since
we're the two core maintainers, that tends to slow things down.
* I started work on unicode support, but realized that it requires a
transition period. In current CVS, it's broken just enough to make life
difficult.
* The code isn't structured all that well. This is at least partially
because we don't have good automated tests, so it's hard to refactor
without breaking things.
* We're still using CVS :-)
Thanks for bringing up these issues to get development started
again. I didn't intend to hijack your thread...
I'm interested in collaborating with you going forward if you're
interested in the same. I will attempt to migrate my git repo to hg if
that's what you want, although I haven't used hg before, so it will be
new for me. I am reluctant to publish the code under the rdiff-backup
name if you are not interested in working on the new codebase. How
would you like me to handle that? Would you like a copy of the code so
you can have a look over it before you make any decisions? It's still
pretty new, and there is definitely more work to do to implement the
features I have planned and to bring it up to par on all of the
currently supported platforms.
A little background on why I went down this road: you may
remember my posts back in Feb on the full-verify patch. I had a working
patch that I had contributed and started using on my system. I was very
careful when I developed that patch because I wanted it to be useful on
a production system. Then, the first time I tried to start a new
repository with that patch applied I got all kinds of strange errors.
This really made me worried because I had no idea why it happened--the
errors just didn't make any sense. Since then, I tried again with the
same setup, and it worked the second time! That's even more
frightening... to me it says there is something non-deterministic in
the design of rdiff-backup (it could be something in my setup too,
although I've gone over it and even run it by others many times). Since
then I've been using a version of rdiff-backup 1.2.8 with my
full-verify patch (and some minor tweaks), and its been working well.
Surprisingly, and somewhat unbelievably, the new verify mechanism
detected a hard drive going bad on my system, so I'm glad I'm using it.
Soon after the verify started failing I had other warnings as well
(rsync started failing too) so it's not like I wouldn't have known if I
didn't have the full-verify, but it gave me the earliest warning.
After that experience I decided that I would try a redesign to
see how far I could get. If it never goes anywhere, no problem, it has
been fun to solve the problems and learn how the rsync algorithm works
and is used in rdiff-backup. But I think this new design is much
cleaner, and opens up a lot of potential for long-awaited features to
be added to rdiff-backup. I'm be interested to hear your thoughts.
First, I'm delighted that you're taking an interested in the project!
More creativity (and competition) is a good thing.
Here's my personal perspective. Our current users get grumpy when we
change the wire protocol across major versions - I suspect that losing
backwards compatibility at the repository level would be a deal-killer
for many. (I know it would be for me, since I have hundreds of
repositories with multiple years of history.) Because of that, I doubt
that I'll contribute meaningfully to a new project. I'm also a little
hesitant to call it rdiff-backup, since it is a complete rewrite. Maybe
rdiff-backup-ng (or something like that) would be a good compromise?
I'm a little torn - I don't want to discourage you from starting from
scratch at all, but I think that the current codebase has lots of value
in it that make it worth salvaging. I can understand where you're
coming from to start a new version, yet I wonder if you might not be
underestimating the amount of work required to bring it to parity with
the current codebase. Supporting OS X resource forks and Windows ACLs,
for example. A lot of value that I see in rdiff-backup is in its myriad
of workarounds for handling all sorts of situations, from simple things
like chmod'ing unreadable files temporarily to be able to back them up,
to handling backups from a unix (case-sensitive) file system to a
windows (case-insensitive) one.
Personally, I'd like to have your help developing tests for the current
codebase. I really think that if we come up with good functionality
tests, we can refactor the codebase to the point where we can start
writing unit tests. However, that's certainly less enjoyable than
starting from scratch(!), so I can't blame you for not getting excited
about that.
I'm looking forwarding to hearing your responses.
Thanks for your interest and input so far!
JoshN
|