在我的组织中，出于各种原因，我们希望从使用CVS切换到Mercurial。我们在尝试确定如何根据代码库中的内容以及我们的工作方式来组织Hg存储库时，已经做了大量的调查。我们已经为大多数问题提出了令人满意的答案，但是有一点让我们感到困惑，这让我很生气，因为为我们的工作流程组织回购的最方便的方式似乎是错误的方式来自一个概念的立场。我试图弄清楚我们对“假设”如何工作的看法是错误的，或者我们是否只是碰到可用工具中的合法特征差距。
我们主要维护一个中等大小的代码库，该代码库由一组应用程序组成，这些应用程序可以在同一个软件包中发布。从概念上讲，您可以将我们的代码分为三类：
这对我来说似乎并不常见，但我想强调一点，即我们同时维护应用程序代码和共享代码，并且总是希望它们相互之间处于最前沿。也就是说，我们希望所有应用程序构建始终使用最新版本和相同版本的共享代码。我们经常同时添加或修改应用程序代码和共享代码。目前，共享代码在一个CVS模块中，并且应用程序都在它们自己的单独模块中。签出共享代码和应用程序模块，以便共享代码构建一次，然后链接到每个应用程序。我们经常进行cvs提交，包括同时在共享和应用程序模块之间进行更改。我们真的希望保持这种能力。
据我所知，Hg中的提交在存储库中是原子的 - 这很好，但我希望能够在“同一时间”对应用程序和共享库进行区分和提交（即我不在乎是否它真的是原子的，但我不想手动做两个单独的差异和两个单独的提交动作。）
从概念上讲，为共享代码设置一个或几个repos似乎是正确的，并且每个应用程序和每个小实用程序都有一个单独的repo。这意味着您需要检查每个构建的多个存储库，但这对我们来说不是问题。问题是似乎没有任何工具可以让您一次查看多个repos上的更新或更改，或者一次diff多个repos然后按顺序为它们提交它们。这很容易编写脚本，但这对于想要使用各种GUI前端来补充命令行的开发人员来说无济于事。
似乎为了能够同时提交多个代码库（从用户的角度来看）并将所有内容放在最前沿，唯一的解决方案是：
想要同时使用多个“同行”存储库并不是那么不寻常，即使这些操作并非真正原子化所有这些 - 但我找不到大量的文章或者吵着要求这种能力。
总结：
我在这里缺少什么？
答案 0 :(得分：1)
在我的商店里，我们有许多项目只是在单独的回购中，但主要应用程序的回购中有2个其他项目。一个是与主应用程序共享大量代码的模块，另一个是用于应用程序的数据库迁移（甚至使用不同的语言）。我希望将应用程序和迁移器中的相关更改一起提交，这是不可分割的。总而言之，这个仓库中的所有源文件都在10到11 MB之间。
因此，如果将所有内容放在一个存储库中是非常有意义的，因为您不想处理子存储库，那么将所有内容放在一个存储库中并没有错。在我看来，我的那个是中等的一小部分。 TortoiseHg的来源大约是20 MB，OGRE超过100 MB。
在不了解您的项目及其关系的情况下，我得到的印象是单个存储库可以正常工作，并且您不会错误地查看它。
如果您改变主意，hg convert可以帮助您将项目提取到自己的存储库中，并保留这些文件的历史记录。
如果单一存储库方法不适合您，那么我认为应该给subrepos一个机会，因为这是我所知道的唯一一种用于处理TortoiseHg支持的多个repos的方法（见Recommendations部分）。
但是，我不确定如何处理部门间访问，因为它似乎没有已经与其他人共享的既定子集。