Right, so we've done most of the work required to get the SVN repository open, which is great news. However, we'd like people to provide insight on whether it should be opened using svnserve or Apache. The server is a dual pentium4 3ghz with a gig of ram, and other than SVN, it only handles a couple of dozen email addresses (exim + imap), websites (primarily trac), and because its in our office, we have a number of samba shares to it. So, point is, its not really overwhelmed with work; if anything its SVN and trac.
In terms of usage, we're not certain of what to expect. There's the core team, of which perhaps a dozen of us use SVN constantly through the day, often to other private areas of SVN, and there's out global community. Presumeably in the scheme of things, our repository and usage is inconsequential in comparison to large projects like Ruby on Rails, so we don't need to over intellectualise the debate ...
Hayden, doing the work, asks:
Does anyone think that it might be a good idea to serve this through
Apache rather than the svnserve application? Points to consider:
* This should handle load better than svnserve via inetd which has been
flaky in the past with emails and might be under prolonged. Apache's
security is also more robust than svnserve. I think that mod_dav_svn is
the recommended way of doing this.
(Or should we just move to a daemon)
* I don't know if you can simultaneously serve the same repository with
both the svn and http protocols. Relocating repositories is simple, but
time-consuming for multiple repositories. Eclipse provides a facility to
do this easily though.
Basically, does the added robustness of Apache justify the inconvenience
of switching our repositories to http from svn? I would say that it does
given public access of version control systems are common for open source