version-control - 源代码管理中多语言项目的合理结构是什么？

在工作中，我们正在开发一个包含大量前端，后端和支持组件的大型应用程序。通常，前端是用C＃开发的，而后端是用Java开发的，虽然后端的部分也是用C＃开发的，后来可能是用C ++开发的。

语言和平台的选择不是任意的;我们试图权衡开发时间，工具链成本，特定开发团队对语言的熟悉程度等各自的相对优点。但是，所有这些组件的共同之处在于它们都是完整操作所必需的。该产品，并由独立（但高度沟通）的团队同时开发。

以前，我们使用Team Foundation Server作为.NET代码，使用Subversion作为Java代码;因为团队的责任明显分开，所以除了将从一个源树生成的二进制文件（在这种情况下为WAR）放在另一个源代码树中的不便之外，这几乎没有引起任何问题，以及保持分支和修订版同步的高手动开销。通过这个项目，团队之间的分离程度有意地小得多，分支/合并的数量预计会大大增加;结果我们转向统一的VCS，更具体地说是Subversion。

这让我想到了问题：如何有效地混合使用Java和C＃代码？在实践中，我们将使用依赖于Java代码库的.NET代码; Java二进制文件需要运行除单元测试代码之外的任何东西（集成测试已经需要二进制文件，QA，验收测试等也一样）。我们目前的想法看起来像：

/trunk
    /java
        /component1
        /component2
        /library1
        /library2
    /net
        /assembly1
        /assembly2
        /...
        project.sln

这个想法是将整个源树放在一个分支下; .NET代码依赖于Java代码，因此我们将向解决方案添加一个后构建步骤，该步骤将（很可能）调用Java组件的ant脚本。这允许整个代码库（对于.NET开发人员）或仅仅Java组件（对于Java开发人员）进行分支。

此解决方案的问题是：

当两个代码库中的一个变得如此之大以至于为每个分支复制它时会发生什么变得不切实际？（我们的想法：拆分为.NET和Java代码的独立存储库并使用svn：externals，对此的任何输入都将非常赞赏）。
我们使用Eclipse进行Java开发。我们如何管理“共享”工作区（即哪些组件需要哪些项目，依赖图等）？到目前为止，我们的Java组件相对较少，因此每个开发人员可以同时将所有这些组件保留在工作区中。随着Java组件和Java开发人员的增加，我看不出我们如何继续这样做;关于如何保持工作区版本化（解决方案文件）的任何建议，同时仍保持两个代码库之间的同步？

我很想听听你的意见！

1：我发现最好按组件分组，而不是langugage。如果一个组件需要多种语言的接口，您仍然需要开发，测试和发布它们。因此，将组件拆分到多个repos是不一个好主意。

如果代码的一部分紧紧依赖于另一部分，请将它们保持在一起。最好在回购中拆分组件。（这甚至适用于内部结构，其中，特别是随着事物的增长，如果你按类型而不是按函数包装东西很困难，例如在MVC中，每个类别都没有三个大包，而是保留FooView，FooModel和FooController很紧。）

svn：externals可能会起作用，对于更高版本，我认为你可以使用“internals”，即链接到同一个repo中的其他目录。这比管理单独的回购更容易，特别是标记和分支。（颤动）

2：您可以随时让开发人员设置不同的工作区，或者使用工作集。商业Eclipse版本比OS版本更好地支持共享工作区设置。（没试过，只是工作并且对操作系统感到沮丧）

我在一个回购中完成了C ++（MSVS）和Java（Eclipse），它运行得很好。同样C ++ / Python也是如此。确保您的构建系统支持构建和测试所有内容（即使您的IDE只构建一个部分）。

源代码管理中多语言项目的合理结构是什么？

1 个答案: