I debated joining this thread, since I don't really work here
anymore ;->. But what the hey.
Greg Stein <gstein_at_gmail.com> writes:
> Recall that svnserve was started as a simplification over Apache. But
> since then, it has added multiple auth modes, logging, threading, and
> all the other goodies that Apache was providing us that svnserve was
> "going to stay away from in staying simple". I believe we may want to
Last time the snickering about svnserve catching up with apache
came up (it seems to come up a lot), I figured it was about time
someone posted some numbers, but I dropped it.
I don't think anyone ever promised svnserve would not gain such
features. It can and has grown them while remaining simpler,
easier to understand, and easier to manage. I'm well aware of
the pitfalls of such a comparison, but comparing lines of code
may be illuminating:
+ httpd/modules/dav/main 11612
+ pick your poison:
libsvn_ra_neon 13731 => 39902
libsvn_ra_serf 16285 => 42456
+ libsvn_ra_svn 5996 => 11137
Beyond that, it's pretty fuzzy: do you count all Apache against
svndav? What about OpenSSL? If you do either of those, it's
only fair to count cyrus sasl against svnserve, but it's a much
smaller dependency. And openssl and cyrus sasl are already
required for even the most minimal server installation of every
modern Linux distribution. So, too fuzzy.
Now you guys are talking about adding a second HTTP layer.
Unless we dump svndav and declare 2.0, how on earth is this
reducing the burden? If you have to hack 5 ra clients (2 of
which are difficult to understand, and I'm doubtful the new one
can be much better) and 3 servers (1 of which is impossible to
understand, and I'm doubtful the new one can be much better) to
add a new ra call, how many will bother? How much will it slow
down those who do?
I saw at least one reference to having ra_serf speak both svndav
*and* the new protocol. I don't know how serious that suggestion
was, but it sure scared me. Maybe I misunderstood, though.
Eric Gillespie <*> epg_at_pretzelnet.org
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-03 20:45:57 CEST