Re: [rdiff-backup-users] Restarting development

[Daniel Miller]

> I'm looking forwarding to hearing your responses.


Are you sure about that? :)

> 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?

Hmm, ok, I'll rename it. It will likely be a completely new project. I'd like 
to explore deduplication anyway, which requires an even bigger divergence from 
the rdiff-backup design (it will likely eliminate the current mirror in favor 
of a block-level database, but it solves a host of other cross-platform issues 
so its appealing to me).

As it is, I believe the current repository design is flawed with a performance 
issue that gets worse with bigger backup sets and long-term use. I don't know 
if that can be fixed without changing the repository structure. You also 
mentioned that unicode support will require a transition period--I'm not sure 
if this implies changing the repository structure, but thats what it sounds 
like to me.

> 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.

I understand the value in supporting many different systems. I was not 
intending to drop that feature, although it may take some time to implement (I 
might point out here that it's going to take time to get tests written for the 
current system too, which is sorely needed to continue development beyond 
simple bug fixes). A notable thing that is missing is OS X ACLs. ACLs have been 
turned on by default since Mac OS 10.5, so technically rdiff-backup can no 
longer make a complete backup of a modern OS X system.

One of the problems with the current design is that many of these 
platform-specific features were tacked on after the core design had hardened. 
That contributed to the rather poor quality of the current codebase. Things 
really need to be more modular. I'm not saying this can't be done with the 
current codebase, but it's going to be really hard, especially if the current 
system has to be fortified with tests before anything new can be written.

> Personally, I'd like to have your help developing tests for the current 
> codebase.

I'm not feeling very excited about that...

> 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.

Maybe, but I probably won't be the one getting it to that point.

Oh yeah, I've read a lot of Joel Spolsky (including the one on "Things you 
should never do"). While he makes some great points in that article, Joel 
doesn't have all the right answers (did you read his more recent article on 
distributed version control). I know the current codebase could be refactored 
and have tests written and everything, but I just don't have the drive to do 
that right now. There are times when what you're starting with takes more work 
to fix than starting something new.

~ Daniel