DVCS：跨不同编程语言的单一源代码控制存储库？
我的系统分为三种不同的编程语言：C#、C++ 和 Java。前两个在两个单独的 Visual Studio 解决方案中管理，后者在 Eclipse 项目中管理。
我想使用分布式版本控制系统解决方案（DVCS）来管理这三个项目的源代码。特别是水银。
以下哪个选项会更好： A. 拥有一个包含所有系统源代码的存储库。 3 个“面向语言”项目中的每一个都驻留在不同的子文件夹中。
B. 为每个面向语言的项目提供一个存储库。共有3个独立存储库。
在这两个选项中，我计划通过在 Visual Studio (TortoiseHg) 和 Eclipse (MercurialEclipse) 之间交替来管理存储库。
预先感谢，乌里格
I have a system that's broken down to three different programming languages: C#, C++ and Java. The first two are managed in two separate Visual Studio solutions, the latter in an Eclipse project.
I would like to manage the source code for all three using a distributed version control system solution (DVCS). Specifically Mercurial.
Which of the following options would be better:
A. Have a single repository containing all the system's source code. Each of the 3 "language oriented" projects to reside in a different sub-folder.
B. Have one repository for each language oriented project. Totaling 3 independent repositories.
In both options I plan on managing the repository/ies by alternating between Visual Studio (TortoiseHg) and Eclipse (MercurialEclipse).
Thanks in advance, urig
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 DVCS，存储库通常与一个“组件”绑定在一起，即作为一个整体发展的一组连贯的文件：如果您修改一个文件，您将标记所有文件。
因此，如果您的三组文件（每种语言各一个）可以彼此独立地发展（例如，一个版本为 1.2，另一个版本为 3.4），那么最好考虑为每组文件建立一个单独的存储库。文件。
然后，您可以采用更“基于组件的方法”将这些存储库分组为子模块。
如果它们紧密联系在一起，一组中的一项修改会触发其他组文件中的修改，那么一个具有单独目录的存储库就可以了。
With a DVCS, a repository is generally tied to a "component", ie a coherent set of files which evolve as a all unit: if you modify one file, you will tag all the files.
So if you three set of files (one for each language) can evolve independently one from another (for example, one being at a version 1.2 while the other is at 3.4), then it is best to consider a separate repo for each group of files.
You can then group those repos as submodules, in a more "component-based approach".
If they are closely tied together, one modification in one group triggering modifications in the other groups of files, then one repo with separate directory is fine.