我们有几个开发团队，每个团队开发多个项目（通常为10个以上）。我们目前正在使用CVS并评估是否转向SVN或GIT。我倾向于GIT，但我不确定如何有效地管理权限。例如。
我们有Dev Team A，Dev Team B，Dev Team 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的所有代码都在这里并且这些用户可以写入'并且'所有团队B的代码都在这里，这些用户可以阅读它'并保持它的分离。
我不确定我是否知道如何正确地提出这个问题 - 但我想到将GIT作为行政噩梦转移。
我们还使用ant脚本来检查CVS中的代码，执行构建并部署到服务器。我刚开始看，但我希望蚂蚁在这个意义上与GIT打得很好。
答案 0 :(得分：4)
我建议使用git over svn，因为它的速度，分布式版本控制模型和整体理智的做事方式。我们在工作中使用SVN已经有几年了，与git相比，它真的很痛苦。我在SVN中看到的唯一优势就是它与Windows的集成。 TortoiseSVN的。但是，只有当你喜欢被GUI限制，并且不愿意学习更强大的命令行时才会这样。
使用git，您显然需要gitolite来处理访问控制。使用此模型，您可以为每个项目设置不同的存储库。 Gitolite配置文件允许您将开发人员分组到团队中，然后您可以为每个存储库，分支甚至工作树路径设置非常精细的访问控制。您可以根据团队或个人的方式指定权限，无论哪种方式最适合您。
如果您需要进行代码审核，还应检查gerrit是否适合您。你不需要两者，使用gitolite或gerrit。
有时人们发现git很难学。为此，我建议给开发人员一本好书，例如this。它也有印刷版本。
答案 1 :(得分：0)
Subversion可能是一种更顺畅的方式（至少在以后的迁移和管理区域中）。
“Merge Hell”是一个大肆宣传的神话和柏忌，来自Git-boy和懒惰的不合格SVN用户。好吧，在某种情况下确实存在（对于任何质量的团队都是“重构地狱”的形式），你只需要检测，这个条件是否适用于你的工作流程。
您对现有的服务器操作系统和基础设施没有任何共同之处，有些情况下这很重要。 Win下的Git服务器和一些前端是真正的噩梦和恐怖，fe，对于Linux端我无法通过http找到Subversion这样紧凑且可用的解决方案，因为Windows的VisualSVN服务器（企业版）（UberSVN从我的POV过度浮出水面） ）。如果您在服务器上安装了Java，您可以考虑（针对您的团队规模和回购量）关于SCM管理器（对于任何选择的SCM - 它从一个框中支持Git，SVN，Hg）
答案 2 :(得分：-1)
如果您希望在多个项目中查看来自所有A队的代码，您可以创建一个包含所有repos和仅git fetch --all的遥控器的全能仓库，然后进行分析。
Gitolite使管理（自定义挂钩）变得轻而易举。它可以让您控制谁可以读取或写下分支。您甚至可以实现自己的git挂钩以放入其他自定义安全措施，例如确保每个提交消息中的每个人都包含一个票证引用。我在过去2年多的时间里一直在使用它，这太棒了。
我们从SVN转移到Git，因为解决冲突的痛苦，速度和许多其他原因，其中一个原因是git的采用率。在rerere中存储分辨率可以轻松混合和匹配功能。钩子很容易编写，我们可以在包含代码契约的某些repos上强制执行OCP。所有这些在SVN中都非常麻烦 - 如果不是不可能的话。
根据CI过程，git在命令行中运行良好，因此您可以在任何自动构建工具中执行您喜欢的操作。现在支持开箱即用，适用于此类所有主要工具。
这是我们使用git：http://dymitruk.com/blog/2012/02/05/branch-per-feature/
在每个存储库中遵循的过程