使用Subversion作为大型开发公司的标准源代码控制库

Question

我正在寻找以前的经验和最佳实践，建立一个大型开发公司，将Subversion用作源控制存储库。

在这里，我指的是数百名开发者/用户！

Answer 1

• 从一开始就选择正确的目录结构 - 这是后来改变的婊子。
  • 我倾向于认为“最好”是按项目组织的，每个项目下都有一个trunk / tags / branch
• 每个人都不需要检查每个项目。只检查你需要的东西
• 找出在开发人员之间共享工具的一些方法。像SQL差异程序这样的小东西可以抓取服务器上的proc并对它们进行区分是非常宝贵的。
• 尽量不要让任何一个项目太大。尝试更新或提交1GB的文件夹是非常长的计算时间
• 找出subversion服务器的一些升级策略
• 备份您的资源库 - 包含完整的修订历史记录
• Trac对于将人们直接链接到更换行和差异非常有用
• 让它变得有趣。在周末对repo运行关键字搜索，并绘制人们在代码中说出诅咒词的频率。 Run a code swarm

Answer 2

我曾在团队中工作，该团队在3个地理位置和数百名开发人员以及100多个项目中实施了内部Subversion托管。一些关键的学习

1. 使用Apache mod_svn而不是svnserve。然后，您可以将“subversion身份验证”链接到LDAP（或ActiveDirectory身份验证），以便团队不必再记住一个登录名和密码。

2. 在同一服务器上创建多个存储库，而不是为每个项目创建具有不同子文件夹的大型存储库。这样简化了管理用户和访问控制的方式。此外，还简化了在完成项目时关闭和存档存储库的任务。

3. 我们开发了简单的python cgi脚本来管理电子邮件通知和RSS源的用户，权限和svn-hook脚本。这些脚本有助于项目团队更快地接受svn。

4. 您可以放置​​反向代理，并通过公司网络外部的“https”访问选择性地公开少数项目。通过这种方式，外部供应商/承包商团队可以获得对项目的控制访问权。

总的来说，我们将所有项目团队在大约一年内迁移到新系统（包括从CVS和Visual SourceSafe等现有系统迁移数据）。

Answer 3

我工作的一家公司使用Subversion为数百名用户提供了自己的服务器。相反，它是来自Collabnet的托管服务。

Answer 4

我已经看到数百名开发人员将CVS用于数百个项目，所以svn应该做得很好。我所知道的唯一问题是用于工作目录及其备份的磁盘空间。

Answer 5

我完全同意Nitin Bhide。我的补充：

如果您曾经使用过CVS，SVN中的某些工作流程非常不同，例如供应商分支，这些在CVS中不存在，因为您刚刚删除了所有文件供应商文件夹并在里面复制新版本。这不再适用于SVN。

此外，如果你习惯了日食，那么像subclipse一样颠覆性的很多东西都是不同的。您应该训练用户习惯使用全局修订号作为CVS用户最难掌握的点

同样重要的是迁移策略，以避免在存储库迁移不成功的情况下开发工作站的停滞时间