> 4. Our SVN server is running 32-bit RHEL 4 and hasn't been configured
> for large file support; files are limited to 2 GB. All
> repositories are
> created using the file system.
> The largest, real concern is hitting the 2 GB limit.
If you are using RHEL 4, I would suggest getting the RPMs from
Collabnet and installing those. They use Apache 2.2 which I'm
assuming is set for large file support. (Someone please correct me if
I'm wrong about this). That should put you on a stable tested stack
for Subversion, Apache OpenSSL, etc. And it is very, very easy to
Here is a script to get you to the setup wizard:
rpm -i CollabNetSubversion-client-1.4.2-8.i386.rpm
rpm -i CollabNetSubversion-server-1.4.2-8.i386.rpm
> 1. What happens when an analyst ends up checking out the entire thing?
> (They just learn not to do it again, IMHO)
The Collabnet version comes with a "Don't Do That" module that will
let you prevent this type of thing.
I still think you would be better of with a single repository (or
possibly 5 repositories). If one part starts getting too large, you
can consider moving it off to its own repository. (There are tools to
make this fairly easy.)
About how many users will you have?
What are you going to use for authentication?
> I apologize if this seems blatantly obvious to some, however, I was
> "elected" to be the SVN administrator simply because I was the
> with the most experience using it. Other than this mail list, I
> scarcely find commentary about these issues anywhere else.
Subversion is an interesting beast because a lot of system admins
don't quite understand what it does and most developers don't really
understand how to set it up. :) So often the developer with the most
experience gets handed the admin responsibility.
I would setup subversion for easy administration and then break it
apart (if you have to) for performance reasons later on.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Apr 18 22:35:59 2007