我们有几个开发团队，每个团队开发多个项目(通常为10多个(。我们目前正在CVS中评估是否转移到SVN或GIT。我倾向于GIT，但我不确定如何有效地管理权限。例如
我们有开发团队A，开发团队B，开发团队C。每个团队都有12名开发人员。每个开发团队至少有10个独立的项目。团队A可以看到每个人的代码，团队B和C只能看到他们的代码。此外，一些开发人员只有只读访问权限，而其他开发人员则具有完全访问权限。
因此，在CVS中，我们有三个存储库，每个团队一个。所以它就像：
/cvsroot/TeamARepos/project1
/cvsroot/TeamARepos/project2
/cvsroot/TeamBRepos/project1
/cvsroot/TeamBRepos/project2
/cvsroot/TeamCRepos/project1
/cvsroot/TeamCRepos/project2
等等。我可以管理整个存储库，并说John Doe对A有只读访问权限，但对B有写访问权限，对C没有访问权限，因此我不必给他对每个项目的明确访问权限(而且他们经常被添加，所以我不必每次都将每个人添加到每个新项目中(。
我对GIT的理解是，每个项目都有一个存储库。因此，没有一种真正合乎逻辑的方式来说"团队a的所有代码都在这里，这些用户可以向它写入"one_answers"团队B的所有代码在这里，他们可以阅读"，并将其分开。
我甚至不知道如何正确地问这个问题，但我认为转到GIT是一场行政噩梦。
我们还使用ant脚本从CVS中检查代码，进行构建，并部署到服务器。我刚开始观察，但我希望蚂蚁也能在这个意义上和GIT打得很好。
我建议使用git而不是svn，因为它的速度、分布式版本控制模型和总体上合理的做事方式。我们在工作中使用SVN有几年了，与git相比，这真的很痛苦。我看到SVN的唯一优势是它与Windows的集成，例如TortoiseSVN。但是，只有当您喜欢受GUI的约束，并且不愿意学习更强大的命令行时，才可以这样做。
使用git，您显然需要gitolite来处理访问控制。使用此模型，您可以为每个项目设置不同的存储库。Gitolite配置文件允许您将开发人员分组到团队中，然后您可以为每个存储库、分支甚至工作树路径设置非常细粒度的访问控制。您可以根据团队或个人指定权限，无论哪种方式最适合您。
如果您需要代码审查，还应该检查gerrit是否是适合您的工具。两者都不需要，使用gitolite或gerrit。
有时人们发现git很难学。为此，我建议开发人员参考一本好书，例如这本书。它也有印刷版。
Subversion对您来说可能是一种更顺利的方式(至少在以后的迁移和管理领域(。
"合并地狱"是来自Git男孩和懒惰的不合格SVN用户的一个大肆宣传的神话和柏忌。好吧，它确实存在于某种条件下(以任何质量的团队的"重构地狱"的形式(，你只需要检测，这个条件适用于你的工作流程吗。
您没有提到现有服务器操作系统和基础设施的共同点，在某些情况下这很重要。Git服务器和Win下的一些前端是真正的噩梦和恐怖，例如，对于Linux方面，我找不到像VisualSVN server(Enterprise Edition(for Windows这样紧凑且可用的基于http的Subversion解决方案(UberSVN从我的POV中过度迁移(。如果您在服务器上有Java，您可以考虑(团队的规模和转发数量(SCM manager(对于任何选择的SCM-它支持Git、SVN、Hg(
如果你想在多个项目上查看来自所有团队A的代码，你可以制作一个catch-all repo，它可以远程访问所有repo，并且只有git fetch --all，然后进行分析。
Gitolite让管理(直到自定义挂钩(变得轻而易举。它让你可以控制谁可以在树枝上读或写。您甚至可以实现自己的git挂钩，以放入其他自定义安全措施，例如确保每个人在每个提交消息中都包含一个票证引用。在过去的两年多里，我一直在使用它，它非常棒。
我们从SVN转移到Git是因为冲突解决的痛苦、速度和许多其他原因，其中之一是Git的采用率。将分辨率存储在rere中可以方便地混合和匹配功能。钩子很容易编写，我们可以在某些包含代码契约的repo上强制执行OCP。所有这些在SVN中都非常麻烦——如果不是不可能的话。
根据CI过程，git在命令行中运行良好，因此您可以在任何自动构建工具中执行自己喜欢的操作。现在，对所有此类主要工具的支持都是开箱即用的。
这是我们在每个带有git的存储库中遵循的过程：http://dymitruk.com/blog/2012/02/05/branch-per-feature/