源代码控制中多语言项目的合理结构是什么? [英] What is a sensible structure for multiple-language project in source control?

问题描述

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

语言和平台的选择不是随意的；我们尝试权衡每个组件在开发时间、工具链成本、特定开发团队对语言的熟悉程度等方面的相对优点. 然而，所有这些组件的共同点是，它们都是完整操作所必需的产品，并且它们是由独立(但高度沟通)的团队同时开发的.

以前，我们对 .NET 代码使用 Team Foundation Server，对 Java 代码使用 Subversion；由于团队职责明确分离，因此除了将一个源代码树生成的二进制文件(在本例中为 WAR)放置在另一个源代码树中的不便之外，几乎没有什么问题，以及保持分支和修订同步的高额手动开销.在这个项目中，团队之间的分离程度故意要小得多，并且分支/合并的数量预计要高得多；因此，我们正在转向统一的 VCS，更具体地说是 Subversion.

这让我想到了一个问题:如何有效地混合 Java 和 C# 代码?实际上，我们将拥有依赖于 Java 代码库的 .NET 代码；Java 二进制文件需要运行单元测试代码以外的任何东西(集成测试已经需要二进制文件，而 QA、验收测试等当然也需要).我们目前的想法是这样的:

<预>/树干/java/组件1/组件2/图书馆1/图书馆2/网/组装1/组装2/...项目.sln

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

这个解决方案的问题是:

1. 当两个代码库之一变得如此之大以至于为每个分支制作它的副本变得不切实际时会发生什么?(我们的想法:拆分为 .NET 和 Java 代码的单独存储库并使用 svn:externals，对此的任何输入都将非常 感激).
2. 我们使用 Eclipse 进行 Java 开发.我们如何管理共享"工作区(即哪些项目需要哪些组件、依赖关系图等)?到目前为止，我们拥有的 Java 组件相对较少，因此每个开发人员可以同时将所有这些组件保留在工作区中.随着 Java 组件和 Java 开发人员的增加，我不知道我们如何继续这样做；关于如何在保持两个代码库之间同步的同时保持工作区版本化(解决方案文件)的任何建议?

我很想听听您的意见！

解决方案

1:我发现最好按组件而不是语言对事物进行分组.如果一个组件需要多种语言作为接口，您仍然需要将它们作为一种语言进行开发、测试和发布.因此，将组件拆分到多个存储库中 不是一个好主意.

如果代码的一部分与另一部分紧密相关，请将其放在一起.更好地跨存储库拆分组件.(这甚至适用于内部结构，特别是随着事物的增长，如果你按类型而不是按功能打包是很困难的，即在 MVC 中，每个类别不要有三个巨大的包，而是保留 FooView、FooModel 和FooController 紧.)

svn:externals 可能有用，我认为在更高版本中你可以使用internals"，即链接到同一个 repo 中的其他目录.这比管理单独的存储库要容易数英里，尤其是在标记和分支方面.(颤抖)

2:您始终可以让开发人员设置不同的工作区，或者使用工作集.商业 Eclipse 版本比 OS 变体更好地支持共享工作区设置.(没试过，只工作过，但对操作系统感到沮丧)

我在一个 repo 中完成了 C++ (MSVS) 和 Java (Eclipse)，而且效果很好.C++/Python 也类似.确保您的构建系统支持构建和测试所有内容(即使您的 IDE 只构建了一部分).

At work we're developing a large-scale application with quite a few front-end, back-end and support components. Typically the front-end is developed in C# and the back-end is developed in Java, although parts of the back-end are also developed in C# and possibly later C++.

The choice of language and platform is not arbitrary; we try to weigh the relative merits of each in development time, tool-chain cost, familiarity with the language by the specific development team etc. What all these components have in common, though, is that they are all required for the complete operation of the product, and that they are being developed concurrently by independent (but highly communicative) teams.

Previously, we have used Team Foundation Server for our .NET code and Subversion for our Java code; because there was clear separation of the teams' responsibilities, this caused little problem beyond the inconvenience of placing binaries (WARs, in this case) generated from one source tree in another, and the high manual overhead of keeping the branches and revisions in sync. With this project, the degree of separation between the teams is intentionally much smaller, and the volume of branching/merging is expected to be considerably higher; as a result we're moving to a unified VCS, more specifically Subversion.

This brings me to the meat of the question: how does one mix Java and C# code effectively? In practice, we'll have .NET code dependent on a Java codebase; the Java binaries are required to run anything other than unit test code (integration tests already require the binaries, and QA, acceptance testing etc. certainly does as well). What we currently have in mind looks something like:

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

The idea is that the entire source tree is placed under one branch; the .NET code is dependant on the Java code, so we'll add a post-build step to the solution which will (most likely) call the ant script for the Java components. This allows branching of the entire codebase (for .NET developers) or just the Java components (for Java developers).

The problems with this solution are:

1. What happens when one of the two codebases becomes so large that making copies of it for every branch gets impractical? (our thoughts: split to separate repositories for .NET and Java code and use svn:externals, any input on this would be greatly appreciated).
2. We use Eclipse for Java development. How do we manage the "shared" workspace (i.e. which projects are required for which components, the dependency graph etc.)? Up until now we've had relatively few Java components, so each developer could just keep all of them in the workspace at the same time. With the increase in Java components and Java developers I don't see how we can keep doing that; any suggestions on how to keep the workspace versioned (a la solution files) while still maintaining sync between the two code-bases?

I would love to hear your input!

解决方案

1: I've found it best to group things by component, rather than langugage. If one component requires several languages for interface, you still need to develop, test and release them as one. So, splitting a component across several repos is not a good idea.

If one part of the code depends tightly on the other, keep it together. Better to split components across repos. (This even goes for internal structure, where, especially as things grow, it's difficult if you package things by type, rather than by function, i.e. in MVC, don't have three huge packages for each category, rather keep FooView, FooModel and FooController tight.)

svn:externals might work, and with the later versions I think you can use "internals", i.e. link to other dirs in the same repo. That is miles easier than managing separate repos, especially with tagging and branching. (shudder)

2: You could always have the developers setup different workspaces, or perhaps use working sets. Commercial Eclipse releases has better support for sharing workspace settings than the OS variant. (Haven't tried, only worked and been frustrated with the OS one)

I've done C++ (MSVS) and Java (Eclipse) in one repo, and it works pretty well. Also C++/Python similarly. Make sure your build system supports building and testing everything (even if your IDEs only build one part).

这篇关于源代码控制中多语言项目的合理结构是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！