Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CACL7EFkA9q-FUyPKvfWq14iBGoWxseG=a-e7XpXECFPj6ekN=Q@mail.gmail.com>
References: <CACL7EFk==b0ZozQ7WL5jozd0h+o6=iE5APh+pe+_0DaSNhrksw@mail.gmail.com>
 <D8715BD4-1191-415C-9C93-41C5E9825E82@ryandesign.com> <20170927111601.GC45420@ted.stsp.name>
 <CACL7EFkA9q-FUyPKvfWq14iBGoWxseG=a-e7XpXECFPj6ekN=Q@mail.gmail.com>
From: Paul Hammant <paul@hammant.org>
Date: Wed, 27 Sep 2017 13:14:31 -0400
Message-ID: <CA+298UjTaSrfgHNp4QRKsMhM42Hc_8NJKFg7B1X2AX3j_wLeuw@mail.gmail.com>
Subject: Re: Checkout without storing two copies
To: Robert Hickman <robert.e.hickman@googlemail.com>
Cc: Subversion Users <users@subversion.apache.org>
Content-Type: multipart/alternative; boundary="001a11397df4d9b599055a2eec31"
archived-at: Wed, 27 Sep 2017 17:14:43 -0000

--001a11397df4d9b599055a2eec31
Content-Type: text/plain; charset="UTF-8"

> * HTTP(S) based sync protocol.

Mine uses Subversions WebDAV as is.

> * All files, both on the client and the server, are stored as plain files
with there original names.

Mine too, or plain binary 'as is'

> * Stores limited version history on the server only. Has limited support
for file versioning.

Mine: Only current version is stored on the client. Works out if 'clash' is
about to happen.

> * No web/graphical UI Designed to perform a single function only,
provides a minimal command line interface.

Yup, though I'll have a tray piece in time like
https://www.sparkleshare.org/ and DropBox.

> * No database dependency Stores file manifest information as regular
JSON.

I've metadata stored client side in JSON too.

> * Atomic file system operations through journaling.

I've no server side beyond Subversion.

* Supports partial checkouts

Got that too :)

For your README, you'd be better to move the rationale to a separate page,
and concentrate on hooking the potential user in.

- Paul

--001a11397df4d9b599055a2eec31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; * HTTP(S) based sync protocol.=C2=A0 =C2=A0<div><br><=
/div><div>Mine uses Subversions WebDAV as is.<br><div><br><div>&gt; * All f=
iles, both on the client and the server, are stored as plain files with the=
re original names.=C2=A0</div><div><br></div><div>Mine too, or plain binary=
 &#39;as is&#39;</div><div><br><div>&gt; * Stores limited version history o=
n the server only. Has limited support for file versioning.=C2=A0</div><div=
><br></div><div>Mine: Only current version is stored on the client. Works o=
ut if &#39;clash&#39; is about to happen.</div><div><br></div><div>&gt; * N=
o web/graphical UI Designed to perform a single function only, provides a m=
inimal command line interface.=C2=A0</div><div><br></div><div>Yup, though I=
&#39;ll have a tray piece in time like=C2=A0<a href=3D"https://www.sparkles=
hare.org/">https://www.sparkleshare.org/</a> and DropBox.</div><div><br></d=
iv><div>&gt; * No database dependency Stores file manifest information as r=
egular JSON.=C2=A0</div><div><br></div><div>I&#39;ve metadata stored client=
 side in JSON too.</div><div><br></div><div>&gt; * Atomic file system opera=
tions through journaling.=C2=A0</div><div><br></div><div>I&#39;ve no server=
 side beyond Subversion.</div><div><br></div><div>* Supports partial checko=
uts</div></div></div></div><div><br></div><div>Got that too :)</div><div><b=
r></div><div>For your README, you&#39;d be better to move the rationale to =
a separate page, and concentrate on hooking the potential user in.</div><di=
v><br></div><div>- Paul</div></div>

--001a11397df4d9b599055a2eec31--