I'm going to throw about quotes from my Linux Journal
article... everbody duck. :-)
(http://www.linuxjournal.com/article.php?sid=4768)
Garrett Rooney <rooneg@electricjellyfish.net> writes:
> On Fri, Jan 25, 2002 at 10:33:03AM -0600, Eric M. Hopper wrote:
>
> > Using Berkeley DB extensively is a bad idea. Plain text files much more
> > readable. Keep seperate revisions in seperate files or seperate
> > directories. Take advantage of the filesystem as a database. Using
> > Berkeley DB essentially creates an extra superfluous namespace. Try
> > reading reiserfs naming system docuement
> > (http://www.namesys.com/whitepaper.html) to understand why this is a bad
> > idea.
>
> svn is architected such that it will be possible in the future to drop
> in a different implementation of the filesystem (which is currently
> implemented with berkeley db), and many people have voiced some
> interest in a plain text back end, but nobody has jumped up and said
> "i'm writing one" yet. for now, berkeley db solves a great deal of
> problems for us, so that's why we're using it.
Right -- "data integrity, atomic writes (commits), recoverability and
hot backups."
> > WebDAV? Why? Seems like adding a useless layer to me. Lets replace
> > the very simple xinetd with a much more complex Apache, and add an extra
> > superfluous protocol layer as well! OSes that make writing to a socket
> > somehow different from doing any other kind of IO deserve to have it be
> > complicated to port stuff to them. Luckily, you were farsighted enough
> > to make this easy to change if someone gets irritated enough by it.
>
> we would have to write a network layer anyway... also, apache gives
> us a much more flexible server than any form of inetd would. plus,
> now we can browse the repository from any web browser, which is just
> plain cool (the current server installed on svn.collab.net doesn't
> have this capability, but the dev version of the code does). plus, in
> the future, once we have devoted time to better webdav compatability,
> this will enable greater compatability with other tools that use
> webdav.
"Why was Apache chosen? Ultimately, the decision was about not
re-inventing the wheel. Apache is a time-tested, open-source server
process ready for serious use, yet is still extensible. It can sustain
a high-network load. It runs on many platforms and can operate through
firewalls. It's able to use a number of different authentication
protocols. It can do network pipelining and caching. By using Apache
as a server, Subversion gets all these features for free. Why start
from scratch?"
> > Actually the other problem with WebDAV is an added dependency on Apache.
> > The hardest part about compiling your system is getting it to find
> > Apache, and having the right version of Apache around.
>
> this will become less of a problem when apache 2 has a stable release
> we can target.
Whether or not Apache2 is a pain to locate or set up is a matter of
debate; but remember that *most* users don't need to run a SVN network
server at all. All they need is the SVN client. And if they have DB,
they can work with local-disk repositories.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 2006