Daniel Miller wrote:
I'm looking forwarding to hearing your responses.
Are you sure about that? :)
Absolutely! I really would be excited about another project that uses
some of the same algorithms. As I said, more competition is good...
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've not had any problems with performance on large data sets that
change often. My backups typically only run once a day though, so I
rarely have more than a few million increment files per repository.
The unicode changes will require some repository changes, but the
changes will necessarily be backwards compatible, and won't entail
structural changes.
The more I think about it, the more I think starting another project
isn't an all bad solution - I think we may have increasingly divergent
goals. For myself, having a current mirror is well worth the cost in
disk space; it means that it's much easier to recover from a file
corruption or program bug. OTOH, loosing this requirement opens the
door to other features.
Thanks,
JoshN
|