Using Subversion as a standard source control repository for a large development firm

Question

I am seeking previous experience and best practices in setting up a large development firm to use Subversion as a source control repository.

By large here, I mean hundreds of developers/users!

Answer 1

• Pick the right directory structure from the start - it's a bitch to change later.
  • I tend to think that the "best" is organized by project, with a trunk/tags/branch under each project
• Every person does not need every project checked out. Only check out what you need
• Figure out some way to share tools among developers. Little things like a SQL diff program that grabs procs off servers and diffs them is invaluable.
• Try not to let any one project be too large. Trying to update or commit across a folder with 1GB is annoyingly long to compute
• Figure out some upgrade strategy for the subversion server
• Backup your repository of course - with full revision history
• Trac is useful for linking people directly to changelongs and diffs
• Make it fun. Run keyword searches over the repo on the weekend and graph how often people say curse words in code. Run a code swarm

Answer 2

I have worked on team which implemented in-house Subversion hosting across 3 geographical locations and hundreds of developers and 100+ projects. Some key learnings

1. Use Apache mod_svn rather than svnserve. You can then link the 'subversion authentication' to LDAP (or ActiveDirectory authentication) to that teams don't have to remember one more loginname and password.

2. Create multiple repositories on the same server rather than one big repository with different subfolders for each project. This way managing users and access control is simplified. Also task of closing and archiving the repositories on finishing project is simplified.

3. We developed simple python cgi-scripts to manage users, permissions and svn-hook scripts for email notifications and RSS feeds. The scripts helped in faster acceptance of svn by project teams.

4. You can put a reverse proxy and selectively expose the few projects over 'https' access from outside the corporate network. This way external supplier/contractor teams can get controlled access the projects.

Overall, we moved all project teams in about one year to new systems (including migrating data from existing systems like CVS and Visual SourceSafe).