Yes indeed,
The post bellow is exactly how I feel about rdiff-backup.
Having been using rdiff-backup for a long time and watching this list
for just as long I have seen many of these
little 'hairs' grow. As a user I can't believe that the core code is
that bad or thrown away, since rdiff-backup
On 04/06/2010 10:32 PM, Alexander Samad wrote:
But I would say on encryption and de duplication - why not leave that to the
filesystem - stay focused on what rdiff-backup does best - differential
backups, you can get de duplication, compression and encryption file systems
why not leave it to
On Wed, Apr 7, 2010 at 11:27 AM, Nicolas Jungers nico...@jungers.net wrote:
On 04/06/2010 10:32 PM, Alexander Samad wrote:
But I would say on encryption and de duplication - why not leave that to
the
filesystem - stay focused on what rdiff-backup does best - differential
backups, you can get
fyi: what is a spare file?
typo that should read sparse file?
(look it up on wikipedia.)
steve
--
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
Randy Syring rsyr...@inteli-com.com wrote:
Daniel Miller wrote:
I wasn't really prepared to make this announcement so soon, but now seems
like a good time to let the community know. I've been working on a new
implementation of rdiff-backup since about a month ago when I dug into the
I wasn't really prepared to make this announcement so soon, but now
seems like a good time to let the community know. I've been working
on a new implementation of rdiff-backup since about a month ago when
[snip]
I'm not a coder... [snip]
Now, on top of that I'd like to have all the
On 04/06/2010 02:34 PM, Daniel Miller wrote:
I wasn't really prepared to make this announcement so soon, but
now seems like a good time to let the community know. I've been
working on a new implementation of rdiff-backup since about a
month ago when
[snip]
I'm not a coder... [snip]
Now, on
Daniel Miller wrote:
I wasn't really prepared to make this announcement so soon, but now seems like
a good time to let the community know. I've been working on a new
implementation of rdiff-backup since about a month ago when I dug into the
current codebase and discovered its disappointing
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,
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
Josh Nisly spake thusly on 04/06/2010 09:27 AM:
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,
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
On Tue, Apr 06, 2010 at 11:59:55AM -0400, Daniel Miller wrote:
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
On 04/06/2010 05:59 PM, Daniel Miller wrote:
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
On 04/06/2010 05:59 PM, Daniel Miller wrote:
[snip]
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
[snip]
Without prejudging, is it
Oops, meant to include the list.
---BeginMessage---
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
On 04/06/2010 06:35 PM, Josh Nisly wrote:
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
Hi
rdiff-backup user, part time programmer. I would love to see some more work
on rdiff-backup, love to get some bugs fixed and see some performance
increase, not going to comment on rewrite or fix the current code base - I
haven't really looked at the code.
But I would say on encryption and de
On Wed, Apr 07, 2010 at 06:32:04AM +1000, Alexander Samad wrote:
But I would say on encryption and de duplication - why not leave that to the
filesystem - stay focused on what rdiff-backup does best - differential
backups, you can get de duplication, compression and encryption file systems
why
I wasn't really prepared to make this announcement so soon, but now seems like
a good time to let the community know. I've been working on a new
implementation of rdiff-backup since about a month ago when I dug into the
current codebase and discovered its disappointing quality. While what I
On Mon, Apr 05, 2010 at 02:25:27PM -0400, Daniel Miller wrote:
- Did I mention that the new version has been developed from the ground up
with full unicode support?
Please note that this new version will obviously not be backward
compatible with older rdiff-backup repositories. While a tool
Two questions:
1) are you planning to better handle renamed files? That's killin' me.
I have thought about this, and I don't think it would be too hard to implement
this using inode tracking. However, it might incur more memory overhead. Input
is welcome.
I'm a former rdiff-backup
On 04/05/2010 08:25 PM, Daniel Miller wrote:
I wasn't really prepared to make this announcement so soon, but now
seems like a good time to let the community know. I've been working
on a new implementation of rdiff-backup since about a month ago when
[snip]
I'm not a coder, an mainly a lurker
23 matches
Mail list logo
