Oops, meant to include the list.
--- Begin Message ---
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
--- End Message ---
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
