Large development teams and SVN

Question

A few questions regarding this topic:

1) What's the largest development team (doing actual commits, not counting read-only) you've had on a single SVN repository? Did you have any issues?

2) What's the largest size team you'd be comfortable with on a single SVN repository? Is a different version control tool better for very large teams? (Don't name IBM Rational, because it will get ignored and flamed, but others may be possible if a valid justification can be made. Solid Eclipse and Flex/Flash Builder IDE compatibility is a must.)

2a) Obviously this depends on the project, but are there any major shortcomings with reliance on splitting up 'large' dev teams into small, modular teams all of which utilize their own SVN repos?

3) Does it make sense for an organization to have two standard versioning tools, one for large systems (if needed) and one for small (~5 devs or less) systems?

For extra points:
4) What would you consider a "large" team (counting only developers since this is relating to SVN use, not QA, management, testers, etc)?

Answer 1

1/ We have amongst our many repo some used by 50 to 100 developers, for many years.
The issues are then:

• bad naming convention (for branches or files, with special characters used when they really shouldn't)
• pooling performance issue (with FishEye for instance)

2/ A central VCS has usually no special limit in term of repository side.
Large teams appreciate Perforce, very quick to checkout their workspace.

2a/ As you say, it depends on the project. For a true monolithic project with many inter-dependent part, the major shortcoming is the content synchronization you need to make between repo (you cannot update a module without impacting the others).

3/ Sure, that what we have.

• Usually, the one reserved for large projects is a non-freeware one (especially because managers need to know there is actual VCS product support team they can rely on in case of major issues with this tool).
• for smaller project, an open-source VCS (freeware) is enough.

But SVN can still manage both project sizes while being "free" (you still to pay for an administrator and for the infrastructure -- server, disk, backups, ... -- to run any tool, freeware or not).

4/ Any team larger than (in average) 15 people is likely to develop different parts of an application, at different pace. That becomes a modular development, and involve structuring its SVN repo carefully.

Answer 2

I've worked on an SVN repository that had well over a hundred active commiters, a revision number of over 80.000, and had been migrated from CVS 3 years before.

Generally, I'd say that SVN is not a likely bottleneck when it comes to large projects and large development teams. Sure, it may lack some features that could make some aspects easier, but that's completely insignificant compared to the organizational problems.