[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Organizing repositories into hierarchy of directories at Apache's SVN root

From: Andrew R Feller <afelle1_at_lsu.edu>
Date: 2007-04-19 15:05:07 CEST

Thanks for the informative reply Mark!

I will certainly look into those RPMs you suggested. Do you happen to
know what the difference between the RPMs maintained by David Summers
and CollabNet aside from lack of BDB support? I am really interested in
this "Don't Do That" module you mention with CollabNet's Subversion

After sending my reply, I talked with a fellow analyst who informed me
that RHEL 4 should have large file support (LFS) by default. At my
previous place of employment, we used CentOS 4, which is based of RHEL,
and it didn't have LFS enabled by default as I hit the 2 GB file limit
several times with logs. I apologize for my ignorance.

As far as users and authentication is concerned, we have approximately
100 users and authentication is done through Kerberos to Active
Directory. I will have to email you some of the ideas we have / are
putting into place about ways of easing management of repositories.


Andrew R Feller, Analyst
University Information Systems
Louisiana State University
(office) 225.578.3737
-----Original Message-----
From: Mark W. Shead [mailto:mwshead@gmail.com]
Sent: Wednesday, April 18, 2007 3:35 PM
To: Andrew R Feller
Cc: Ryan Schmidt; users@subversion.tigris.org
Subject: Re: Organizing repositories into hierarchy of directories at
Apache's SVN root

> 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:

wget http://downloads-guests.open.collab.net/files/documents/61/85/

wget http://downloads-guests.open.collab.net/files/documents/61/84/

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
> developer
> 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 19 15:05:29 2007

This is an archived mail posted to the Subversion Users mailing list.