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

The one firm I worked at that used Subversion for hundreds of users didn't have their own servers. Instead it was a managed service from Collabnet.

Answer 2

• 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 3

I have seen hundreds of developers use CVS for hundreds of projects, so svn should do it fine. The only issue I have been aware of was about disk space used for working directories and their backups.

Answer 4

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).

Answer 5

I totally agree to Nitin Bhide. My additions:

if you used to CVS some workflows in SVN are very different, for example vendor branches, which are non-existent in CVS, because you just deleted all files in the vendor folder and copy the new version inside. This will not work in SVN anymore.

Also if you are used to eclipse, a lot of things in subversive as in subclipse are different. You should train the users to get used to global revision numbers as the most difficult to grasp point for CVS users

Also important is a migration strategy to avoid stall time for developerteams if their repository migration was not successful