Unless things have changed significantly since I last used it, the Apache module is much more flexible. For instance, I did not find a way in svnserve to have multiple users, where user A is given read- only access to some directories and no access to others. FWIW it's also relatively easy to do load-balancing and redundant connections on an apache configuration, if that's of interest.
Subversion supports serving from svnserve or an apache module - both work, and both are part of the current and (AFAIK) future versions of subversion.
The majority of the web runs on Apache, so it can't be /that/ bad :-)
If svnserve does the job, stick with it. svnserve is a lighter program, it is simpler, easier to configure, and easier to keep secure (it does less, so there is less to check and less to get wrong in the configuration). Apache configuration for svn is not hard either, assuming you are using a Linux distribution with reasonable apache defaults - there are plenty of references on the web, and in the subversion documentation. But if you are happy with svnserve, then there is no requirement to change.
Apache is far more flexible, especially if you have multiple users with different permissions for different areas, or want a more advanced authentication, logging, etc. Many servers also have apache already for other purposes, so adding svn support is simple.
I regularly use an svnserve server and an Apache server, and both do their work. A nice feature of Apache server is that you can provide easy access to non-techie people in your organization to versioned documents that you can maintain with svn, without obliging them to install and use an svn client.
We're running the Apache module; it works quite nicely. The ability to just point folks to a webpage without having SVN installed is really handy. It probably even makes up for all the grief we had getting it up and running.
Rob Gaddi, Highland Technology
Email address is currently out of order
Thanks for the responses. I am running into an issue with svnserve where it starts hogging CPU time for no apparent reason. Otherwise I might not even consider this. From an operations perspective we deviate from the general SVN concept and have many reposistories. This allows easy limitations on project to project access, but has limitations on sub-projects that we would like to have restricted. Last thing I need is something else to maintain, so I may stick with svnserve, unless one of my people has Apache experience. Glutton for punishment that I am, it might be time to switch over to IBM Rational Team Concert. Scott
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5782 (20110112) __________
This sounds like a particular problem that you may get help with from subversion mailing lists or forums. svnserve is certainly considered stable and reliable for normal use, so there is probably something odd in your setup. Perhaps svnserve some problem accessing the files it needs, and is hanging?
Multiple repositories is not "deviant" - it is common practice. If you are the sort of company or group that has just one serious project, or at least that the projects are all related, then you might have just one repository. But if you have lots of independent projects, then it is common practice to have them as multiple repositories. And as you know, it is simple to have different access controls on different repositories.
It is also perfectly possible to have different access controls on different subprojects or other directories within a project (and therefore on branches, tags, trunk, etc., and directories within these). It can be done with relatively modern versions of svnserve, and it is an easy matter if you are using apache (it's just standard "" directives, along with whatever form of authentication you want).
I can pretty much guarantee that learning some basic Apache setup from a web how-to is going to be very much faster and easier than learning about a Team Concert. And I can /definitely/ guarantee that the change for the users will be far greater. From a users viewpoint, changing from svnserve to apache means changing their URL's from svn:// to http://, but otherwise the system works as before. If the clutch on your car is sticking, would you consider buying a helicopter instead?
David, Thanks for the comments. I have posted to the Collabnet SVN forum. Have not tried any others.
Granted going to Team Concert would be a much larger change, but the feature set has my interest. It appears to have a "label" feature similar to Visual SourceSafe which we used for many years. I also don't like the impact SVN has on the client file system. On a large project it is very easy to have a set of .svn files that dwarfs the project.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5788 (20110114) __________
I have never had to use Visual SourceSafe, so have no idea what their "label" feature is and thus can't say if I know of an equivalent feature in svn. VSS has always had such a terrible reputation (MS themselves never used it, apparently, because it was too unreliable) that I never considered it.
SVN does store a lot in .svn directories. That's the way it works, and makes a number of operations faster because they can be handled locally. Some source code control systems store less "metadata" locally, and therefore rely more on the server - others (like git) store lots more so that the system is more distributed. It's the kind of choices you make when picking a system.
For me, svn is the only system I know of that fits my requirements (cross-platform clients with serving from Linux, gui and command line clients on Linux and Windows, centralised server, reputation for reliability, atomic commits, cheap branches and tagging, at least reasonable support for non-text files). I would also prefer not to have as much in the .svn directories, as I have fast access to the server. But it's a small price to pay :-)
git is much better in this regard, much faster too. I switched to it from svn a few years ago. Thanks to its fast, efficient compression, for me it typically stores the entire history of the project in less space than the live files. It has made it attractive to put the entire toolchain under version control, i.e. each project contains its own copy of the tools needed to build it. Check out an old version, and you check out the old compiler needed at the same time. I found svn to be a pain in other respects too, directory renames spring to mind.
git is possible now on Windows, but was poor. Mercurial on the other hand is very similar in its capabilities but has always supported Windows well. Personally I use git, but if I needed good Windows support I'd use Mercurial.
I haven't had enough experience of git to be a fair judge. There is a fair amount of cost involved in changing source control systems, especially in a company, so I have to rely somewhat on things I read and learn about rather than first-hand knowledge.
AFAIUI, git has a number of strong points. It is particularly good when you have a fairly decentralised development, with different people in different places working on their own parts of a combined system (which is hardly surprising given its author and history). It is not good for centralised development, which is something you often want in a company. It is also not good for cross-platform work (again, unsurprising given its intended use). While it is sort-of possible to use it under Windows, it is very much "alien" on that platform. There is also only limited gui client support, which is also a hinder to usage for many people. Subversion is equally at home on Linux and Windows, with good gui client integration on both.