大型开发团队和SVN
关于此主题的几个问题：
1) 您在单个 SVN 存储库上拥有的最大的开发团队（进行实际提交，不包括只读）是什么？你有什么问题吗？
2) 在单个 SVN 存储库上您能接受的最大团队规模是多少？对于非常大的团队来说，不同的版本控制工具是否更好？ （不要命名 IBM Rational，因为它会被忽视和批评，但如果可以提出有效的理由，其他的也可能是可能的。可靠的 Eclipse 和 Flex/Flash Builder IDE 兼容性是必须的。）
2a) 显然，这取决于项目，但是依赖将“大型”开发团队拆分为小型模块化团队所有这些团队都使用自己的 SVN 存储库有什么重大缺点吗？
3) 对于一个组织来说，拥有两种标准版本控制工具是否有意义，一种用于大型系统（如果需要），一种用于小型（〜5 个开发人员或更少）系统？
如需额外积分：
4) 您认为什么是“大型”团队（仅计算开发人员，因为这与 SVN 使用有关，不 QA、管理、测试人员等）？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
1/ 我们的众多存储库中有一些已被 50 到 100 名开发人员使用多年。
那么问题是：
2/ 中央 VCS 通常在存储库方面没有特殊限制。
大型团队欣赏Perforce，很快就可以查看他们的工作空间。
2a/ 正如你所说，这取决于项目。对于具有许多相互依赖部分的真正的整体项目，主要缺点是您需要在存储库之间进行内容同步（您无法在不影响其他模块的情况下更新模块）。
3/ 当然，这就是我们所拥有的。
但 SVN 仍然可以在“免费”的同时管理两种项目规模（您仍然需要为管理员和基础设施（服务器、磁盘、备份等）付费，以运行任何工具，无论是否免费）。
4/ 任何超过（平均）15 人的团队都可能以不同的速度开发应用程序的不同部分。这成为模块化开发，并且涉及仔细构建其 SVN 存储库。
1/ We have amongst our many repo some used by 50 to 100 developers, for many years.
The issues are then:
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.
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.
我曾开发过一个 SVN 存储库，该存储库拥有超过 100 个活跃提交者，修订号超过 80.000， 已在 3 年前从 CVS 迁移。
一般来说，我认为 SVN 对于大型项目和大型开发团队来说不会是一个可能的瓶颈。当然，它可能缺少一些可以使某些方面变得更容易的功能，但这与组织问题相比完全微不足道。
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.