Subversion与合同开发团队

Question

有关向第三方开发团队提供subversion访问权限的最佳做法的任何建议。我们聘请了团队来完成项目的一小部分迭代，我不想让他们访问整个资源库。我们使用BeanStalk来托管我们的subversion，因此不可能将细粒度的访问控制降到一个分支（我不知道beanstalk是否是这里的限制或者通常是svn）。

我没有在主存储库中创建分支，而是创建了一个新的存储库，并且只使用了他们需要的最新代码快照，让他们可以访问它。我想我将不得不手动合并他们的更改。

你会做什么？

Answer 1

坦率地说，我对SVN服务器设置了解不多。我们的SVN服务器 - “Collabnet”是名称的一部分，就像我所知道的那样 - 允许我们将用户分组，然后以任何粒度级别为每个组分配权限。

考虑到这一点，我们有一些离岸开发人员，他们在“分支”下给他们自己的目录，让他们在那里做提交，然后将这些合并到主干。

但事实证明这会产生不必要的合并问题，所以我们现在已经切换到让它们提交到trunk。我们可以在日志中看到提交时的用户ID，这样我们就知道是谁提交了什么。

总的来说，我的理念是，如果你不相信你的开发人员正在编写的代码 - 无论是内部代码，承包商还是其他代码 - 你应该得到不同的开发人员，而不是寻找减速的方法他们糟糕的代码造成的伤害。迟早你将不得不合并他们的代码，那么延迟这个会得到什么呢？

Answer 2

我可能会在Google Code上启动一个项目并做同样的事情，在完成后将这些更改合并。

或者，如果您的软件是组件化的，则为每个独立组件创建一个单独的项目，然后您就可以访问它们，以便为他们提供完成工作所需的内容。

Answer 3

我想我已经转储了一个现有的存储库，然后将相关的部分加载到一个新存储库中，然后将该新存储库的访问权交给第三方团队，因此他们将有一个现有的代码库来开始工作。我达到这样长度的最终原因是，在这种情况下，我能够产生一个或多或少明智的差异，因此手动合并不会是一项艰巨的任务。

Answer 4

有一个很好的解决方案 - 请查看answer。但是，由于您使用的是外部提供商，因此可能无法执行此操作。

Answer 5

我不打算翻转，但我想要一个允许我在我的存储库中使用细粒度访问控制的SVN主机。

除此之外，我还会探讨使用svn:externals来连接外包团队和我的主存储库。一个聪明的设置可能会减轻一些合并的努力。