Re: [Gnu-arch-users] the state of the union

[Greg Hudson]

[Disclaimer: Invading Subversion developer here.]

> In the early days, when we collectively didn't know much, there was
> an actual debate to be had about how to implement file orientation:
> Does it require a fancy delta-compressed version-transactioned
> filesystem (Subversion)?  or can you get by with low-tech
> brute-force techniques combining compressed archives with
> client-side caches (Arch).  The debate is over.  We know the answer.
> The answer is that the Subversion approach can deliver lower
> command-line latency for some operations but that Arch delivers
> lower administration costs, better scalability, and higher
> throughput.

I think you may be prematurely closing the debate.  Please review
<http://web.mit.edu/ghudson/info/fsfs> and, if your interest runs that
deep,
<http://svn.collab.net/repos/svn/trunk/subversion/libsvn_fs_fs/structure>.

The salient point is that svn's back end can, like arch's, run over a
networked filesystem.  Although there is no application-level support
in Subversion for treating HTTP/FTP/scp services as dumb file
transport and running an FSFS repository over them, that seems like an
implementation detail.  (To date, there hasn't been any demand for
such a feature.)  So a back end of svn's design can, at least in
principle, be as easy to administer as arch purportedly is and scale
as well as arch purportedly can.

(In reality, Subversion's user base is generally happy to run a
server; the safety benefits of not allowing commiters to corrupt the
repository generally outweigh the security benefits of reusing an
existing server code base.  But that's neither here nor there.)