Subversion ble designet med et abstrakt nettverkslag. Dette betyr at et depot kan bli aksessert av alle typer serverprosesser, og klientens API for depottilgangen gir programmerere anledning til å lage programtillegg som forstår relevante nettverksprotokoller. I teorien kan Subversion bruke et uendelig antall nettverksimplementasjoner. I praksis er det for tiden bare to servermodeller tilgjengelig.
Apache er en ekstremt populær webserver. Ved å bruke mod_dav_svn-modulen kan Apache aksessere et depot og gjøre det tilgjengelig for klienter via WebDAV/DeltaV-protokollen, som er en utvidelse av HTTP. I det andre hjørnet er svnserve: Et lite, enkeltstående serverprogram som kommuniserer med klientene ved hjelp av en egendefinert protokoll. Tabell 6.1, “Sammenligning av nettverksservere” viser en sammenligning av de to servermodellene.
Tabell 6.1. Sammenligning av nettverksservere
| Funksjonalitet | Apache + mod_dav_svn | svnserve |
|---|---|---|
| Autentiseringsvalg | vanlig HTTP(S)-autentisering, X.509-sertifikater, LDAP, NTLM eller enhver annen mekaniske som er tilgjengelig for Apache httpd | CRAM-MD5 eller SSH |
| Valg for brukerkontoer | privat fil med brukerliste | privat fil med brukerliste eller eksisterende systemkontoer (SSH) |
| Authorization options | read/write access can be granted over whole repository, or specified per-path. | read/write access can be granted over whole repository, or specified per-path. |
| Kryptering | via valgfri SSL | via valgfri SSH-tunnel |
| Logging | full Apache logs of each HTTP request, with optional “high-level” logging of general client operations | no logging |
| Samspillsevne | delvis brukbar for andre WebDAV-klienter | Kommuniserer bare med svn-klienter |
| Visning på web | begrenset innebygget støtte, eller via tredjeparts verktøy som for eksempel ViewVC | kun via tredjeparts verktøy som for eksempel ViewVC |
| Hastighet | Noe langsommere | Noe raskere |
| Innledende oppsett | Noe komplekst | Ganske enkelt |
Install and configure a standard Apache 2.0 server, then activate a special subversion-server module. Clients speak to server via HTTP or HTTPS, using the WebDAV protocol.
Allows Subversion to use any of the numerous authentication systems already integrated with Apache.
No need to create system accounts on server.
Full Apache logging.
Network traffic can be encrypted via SSL.
HTTP(S) can usually go through corporate firewalls.
Built-in repository browsing via web browser.
Repository can be mounted as a network drive for transparent version control. (See “Autoversioning”.)
Noticeably slower than svnserve, because HTTP is a stateless protocol and requires more turnarounds.
Initial setup can be complex.
A lightweight serve process which can run either as a persistent daemon, or as something automatically launched by inetd when necessary. Clients authenticate via CRAM-MD5 algorithm and speak a custom network protocol.
Quick and easy to set up.
Network protocol is stateful and noticeably faster than WebDAV.
No need to create system accounts on server.
Password is not passed over the network.
Network protocol is not encrypted.
Only one choice of authentication method.
Password is stored in the clear on the server.
No logging of any kind, not even errors.
Each client uses an existing SSH (system) account to spawn a temporary svnserve process (running as themselves) on the server machine. The svnserve process accesses the repository, communicates with the client over the SSH tunnel, then dies when the SSH connection is closed. (There is no long-running svnserve process.)
Network protocol is stateful and noticeably faster than WebDAV.
You can take advantage of existing ssh accounts and user infrastructure.
All network traffic is encrypted.
Only one choice of authentication method.
No logging of any kind, not even errors.
Requires users to be in same system group, or use a shared ssh key.
Can lead to file permissions problems.
So, which server should you use? Which is best?
Obviously, there's no right answer to that question. Every team has different needs, and the different servers all represent different sets of tradeoffs. The Subversion project itself doesn't endorse one server or another, or consider either server more “official” than another.
In general, the authors of this book recommend a vanilla svnserve installation for small teams just trying to get started with a Subversion server; it's the simplest to set up, and has the fewest maintenance issues. Remember, you can always switch to a more complex server deployment as your needs change.
Here are some general recommendations, based on years of supporting users:
If you're trying to set up the simplest possible server for your group, then a vanilla svnserve installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. If your deployment is entirely within your company's LAN or VPN, this isn't an issue. If the repository is exposed to the wide-open internet, then you might want to make sure the repository's contents aren't sensitive (e.g. it contains only open-source code.)
If you need to integrate with existing identity systems (LDAP, Active Directory, NTLM, X.509, etc.), then an Apache-based server is your only real option. Similarly, if you absolutely need server-side logs of either server errors or client activities, then an Apache-based server is required.
If you've decided to use either Apache or stock
svnserve, create a
single svn user on your system and run
the server process as that user. Be sure to make the
repository directory wholly owned by
the svn user as well. From a security
point of view, this keeps the repository data nicely
siloed and protected by operating system filesystem
permissions, changeable by only the Subversion server
process itself.
If you have an existing infrastructure heavily based on SSH accounts, and if your users already have system accounts on your server machine, then it makes sense to deploy an svnserve-over-ssh solution. Otherwise, we don't widely recommend this option to the public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by svnserve or Apache, rather than by full-blown system accounts. If your deep desire for encrypted communication still draws you to this option, we recommend using Apache with SSL instead.
Do not be seduced by the simple
idea of having all of your users access a repository
directly via file:/// URLs. Even if
the repository is readily available to everyone via
network share, this is a bad idea. It removes any layers
of protection between the users and the repository: users
can accidentally (or intentionally) corrupt the repository
database, it becomes hard to take the repository offline
for inspection or upgrade, and it can lead to a mess of
file-permissions problems (see
“Støtte for flere metoder for
tilgang til depotet”.) Note
that this is also one of the reasons we warn against
accessing repositories via svn+ssh://
URLs — from a security standpoint, it's effectively
the same as local users accessing
via file:///, and can entail all the
same problems if the administrator isn't careful.