On Fri, Sep 17, 2010 at 2:23 AM, Gary <subversion-u...@garydjones.name> wrote: > Johnathan wrote: >> There's not much that Subversion cannot run on. > > No, sure :) I was really looking for hints as to what general properties > a server should have. For example I would suspect that CPU speed isn't > much of an issue because actually the server is only "active" > occasionally, whereas storage reliability would be a major > requirement. Like I said, I have my own ideas but was interested in > others' input as well.
Don't do checkouts of large repositories to CIFS shares (Windows shares). Seriously. A lot of the rest depends on what you want the server to do: how large are your repositories? How large are your working copies? Do they live on individual machines, or on a shared working space? Do you need offsite access? Do you need high security access, or ease of use? Is the UNIX/Linux client default of saving cleartext passwords locally for HTTP or HTTPS going to be a security policy problem for you? Can you use or educate people to use SSH keys? > If it should be Linux, BSD, whatever, is less of an issue because we > already have sooooo many variations in use *rolls eyes* I like CentOS 5 as a server, for cheap and fullly capable network tools and support, and the RPMforge version of subversion for well-integrated use in RedHat based operating systems. (The RedHat published for package for RHEL 5 is way, way, way out of date.) Hardware requirements depend massivly on load. For a small repository, any server class machine with decent disks should be fine. As your working copies grow in size, if they become well over a Gig, you'll want to think about striped disks and whether you want to spring for 15,000 RPM SAS drives, or will be happy with a cheap external USB drive that you can transfer to a spare server as needed.