SVN在分布式开发中的最佳实践？

Question

由几个独立供应商开发的用于分布式系统的实际证明的SVN结构是什么？

假设一个系统有三层(UI、服务、数据)和它们之间的服务合同:每一层由几个组件组成，这些组件由不同的供应商开发，这些组件不依赖于特定的层，例如，供应商A为UI和服务层开发组件，供应商B为服务和数据层开发组件。

每个供应商应该只拥有对其自己的组件的写访问权限以及对所需服务合同的读访问权限。

->在这样的环境下构建你的SVN的好方法是什么？

按供应商？一层一层？两者都有？

Answer 1

为了清楚起见，我建议按层组织结构。这样，查看结构可以揭示组件之间的关系。即使客户(即供应商)有更多的开销，或者设置每个客户端对存储库的访问的开销更多，这也是值得的，因为每个客户端将习惯于考虑项目的整体结构，这将在长期内减少bug和API冲突的可能性。

这是一种情况，如果经理们有他们的方式，他们可能倾向于按供应商分离存储库。作为一名程序员，您应该知道得更清楚。为了清晰和更好地编程，将一些工作放在经理身上，以确保适当的工作流程得到遵守。

此外，仅仅是让不同的供应商在相同的结构中看到彼此的工作，就会以这种小的方式鼓励互动(无论多么小)。再一次，这是一种开放和交流的努力，比安全和限制更重要。如果你一开始就是一个程序员，这是一个机会。

顺便说一句，Git优于SVN。

Answer 2

您需要保持供应商的隔离，因此需要隔离那里。每个供应商组件的主干对此很有意义。

在最近的一个大型软件项目中，我们允许每个供应商拥有自己的存储库，并拥有对其他供应商的读取权限。然后，我们使用触发脚本创建了一个只读合并主干。这些都是每天午夜运行的。

合并后的主干随后由Jenkins构建环境拉动，该环境进行回归和系统集成测试，每天一开始就将故障和问题发布给开发团队。

Answer 3

如果这些供应商确实是独立的，那么我不建议将所有这些组件都保存在一个SVN存储库中。我宁愿为供应商提供单独的SVN存储库，并通过一个定义良好的发布流程与公共工件(类Maven)存储库之间的交互来控制契约和交互。例如，Nexus能够限制哪些工件对哪个用户可用，并允许控制读/写。