On 6/4/20 11:43 AM, Patrik Dufresne wrote:
But two cent on the subject is, should we really keep this filebase ? For
rdiffweb, scanning the metadata files is a nightmare. When I just need a
subset of the data to be displayed to the user. I always thought a database
could be better fit for the
Hi,
that's an interesting idea, I was more in the optic of keeping a simple
file based structure but if there are requirements, we can think about
alternatives, it could be a SQL or even a noSQL DB, or a keystore.
Regarding the terabytes of data, I take the point, I never foresaw to
convert the
Hi Eric,
My priority in that regard would be to make sure all of this backward
compatible with the previous repository. I mean, I have terabytes of data
and I don't foresee a way to convert all these metadata files to a new
format. And I'm probably not alone with this situation.
We should
Thanks!
On Thursday, June 04, 2020 08:37:24 AM EricZolf wrote:
> Correct, configuration files and "metadata" files, but also potentially
> to exchange information between client and server (e.g. the version
> string could be enriched to exchange more information than just
> version).
EricZolf writes:
[snip]
> Any comments on those plans?
So long as there isn't a client-server wire-format incompatiblity with
older 2.x versions, I don't care! (I want to ensure we never make that
same mistake again of a wire incompatibility due to a change in
underlying tooling).
> KR, Eric
On 04/06/2020 14:20, rhkra...@gmail.com wrote:
>* what is the rdiff file format used for? Presumably it is not the format
> of
> the stored backups, right? Is it the configuration files? Something else?
Correct, configuration files and "metadata" files, but also potentially
to exchange
Top posting because I'm not really replying to a specific comment in the post.
From the peanut gallery (I like sitting here, sometimes ;-), two things:
* +1 on opening the dsicussion early
* what is the rdiff file format used for? Presumably it is not the format
of
the stored backups,
Hi,
On 04/06/2020 12:54, Dominic Raferd wrote:
> On Thu, 4 Jun 2020 at 11:46, EricZolf wrote:
>>
>> rdiff-backup has currently its own file formats, which are far from
>> being standard, meaning a lot of custom code to handle these formats,
>> respectively a lot of different files...
>
> +1 for
On Thu, 4 Jun 2020 at 11:46, EricZolf wrote:
>
> rdiff-backup has currently its own file formats, which are far from
> being standard, meaning a lot of custom code to handle these formats,
> respectively a lot of different files...
+1 for YAML, but please retain compatibility (at least for
Hi,
rdiff-backup has currently its own file formats, which are far from
being standard, meaning a lot of custom code to handle these formats,
respectively a lot of different files.
Middle term I'd like to move to a more standard format for code
efficiency reasons: if the code is in a library, I
Hi,
from a past survey, we know that some of you still use Python 3.5, but
we'd like sooner or later to get rid of it and wanted to ask you if
there is a _big_ issue with it.
Here the reasons for the foreseen move:
- Python 3.5 is out-of-support by 13th of September according to [1]
- The
11 matches
Mail list logo
