Re: Proposal: new fsfs.conf properties

On rationale ...

This is a file sync agent. 600 lines of Python that I'm going to open
source. The same thing I was working on in 2016 when I chatting on this
list.

Goals: 1) *not have two copies of everything on the clien*t, 2) have
different semantics to pushing back changed files.
Secondary goals: 3) not require a svn install on the client.

Users: families (movies, music, photos). Corporates (docs, s/sheets etc).

The break through last year was the techniques to lean on the server-side
Merkle tree, as well as config settings to expose them to a place of
usefulness.

I'd paused the project because I was busy with other stuff, and I picked it
up again recently - coinciding with the purchase of a SFF computer that
spoke USB3. Last year the performance of the thing was unacceptable on a
range of Raspberry Pi sized things, and all of them spoke USB2 to my 4TB
Seagate external drive. Performance is adequate on the new combo (this
thread, and others in the last two weeks), but it could be better with a
few config choices, I think.

Functionally, I'm nearly there (one bug that's hard to reproduce). Later I
want to get into permissions on directories.

> I'm wondering what you gain with curl and autoversioning over, e.g.,
> > svnmucc or using our bindings (or even our libraries)? [...]
> >
> As I said in my previous response here, I think the reason for Paul to
> go for curl+autoversioning is speed, because it eliminates client-side
> deltification. [...]

>

But I'm wondering if that curl advantage won't disappear if we develop
> a solution for a normal svn client to skip deltification.
>
Received on 2017-07-13 11:46:53 CEST