On Fri, Sep 17, 2010 at 2:23 AM, Gary <subversion-user_at_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.
Received on 2010-09-19 14:39:24 CEST