几个独立供应商开发的分布式系统的SVN实际结构是什么？分布式开发中的SVN - 最佳实践？
假定系统具有例如三层（用户界面，服务，数据）以及它们之间的服务合同：每层由不同供应商开发的几个组件组成，这些组件由不与特定层绑定的不同供应商开发。供应商A为UI和服务层开发组件，供应商B为服务和数据层开发组件。
每个供应商只能对自己的组件拥有写入权限，并且可以读取所需的服务合同。
- >在这种设置中构建SVN的好方法是什么？
供应商？按层？都？ ...？
如果这些供应商真的是独立的，那么我不会建议将所有这些组件保留在一个SVN存储库中。我宁愿给供应商分开SVN仓库和控制合同以及通过定义良好的发布流程到普通工件（Maven-like）仓库的交互。例如，Nexus具有限制哪些用户可以使用哪些工件并允许控制读/写的功能。
您需要保持供应商的独立性，因此需要进行隔离。每个供应商组件的主干都是有意义的。
在最近的一个重大软件项目中，我们允许每个供应商拥有自己的存储库，并可以读取其他存储库。然后，我们使用触发的脚本创建了一个只读合并主干。这些每天在午夜运行。
整合主干然后被一个Jenkins构建环境所拉动，该环境进行回归和系统集成测试，在每天开始时将失败和问题发回给开发团队。
为了清楚起见，我建议按层组织结构。这样看，看结构揭示组件之间的关系。即使客户（即供应商）有更多的开销，或者设置每个客户访问存储库的开销较大，这也是值得的，因为每个客户都会习惯于考虑项目的总体结构，这会减少从长远来看，错误和API冲突的可能性。
这种情况下，如果经理人有他们的方式，他们可能倾向于按供应商分开存储库。作为程序员，你知道得更好。为了清楚起见和更好的编程，将一些工作交给经理去确保遵守正确的工作流程。另外，仅仅让不同的供应商在相同的结构中看到彼此的工作，就会以这种小小的方式鼓励互动（无论多么小）。这也是开放和沟通的努力，比安全和限制更重。如果你一开始就像程序员一样说，那就是一个机会。
顺便说一下，Git优于SVN。