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