在我的组织中,出于各种原因,我们希望从使用CVS切换到Mercurial。在尝试根据代码库中的内容以及工作方式来确定如何组织Hg存储库时,我们进行了大量调查。我们已经对大多数问题提出了满意的答案,但有一点使我们感到困惑,这让我发疯了,因为为我们的工作流程组织 repo 协议(protocol)的最便捷方法似乎是一种错误的解决方法概念上的立场。我试图弄清楚我们对“应该”如何工作的看法是错误的,或者我们是否只是在弥补可用工具中的合法功能差距。

首先,我们维护一个中等大小的代码库,其中包含一整套应用程序,所有应用程序都在同一软件包中发布。从概念上讲,您可以将我们的代码分为三类:

  • 共享代码
  • 我们的主要套件的应用程序代码(使用共享代码)
  • 很少维护(使用共享代码)的其他小型实用程序

  • 这对我来说似乎并不罕见,但是我想强调一点,我们要同时维护应用程序代码和共享代码,并始终希望它们在彼此之间处于前沿。也就是说,我们希望所有应用程序构建都始终使用最新版本和相同版本的共享代码。我们经常同时添加或修改应用程序代码和共享代码。当前,共享代码位于一个CVS模块中,而应用程序都位于其自己的单独模块中。 check out 共享代码和应用程​​序模块,以使共享代码生成一次,然后链接到每个应用程序中。我们经常执行cvs提交,一次包含跨共享模块和应用程序模块的更改。我们真的很想保持这种能力。

    我知道Hg的提交在存储库中是原子的-很好,但是我希望能够在“同一时间”差异并提交到应用程序和共享库(即,我不在乎它是否真的是原子的)但我不想手动进行两个单独的diff和两个单独的提交操作)。

    从概念上讲,为共享代码提供一个或几个存储库,为每个应用程序和每个小实用程序单独存储库,似乎是正确的。这意味着您需要为每个构建 checkout 多个存储库,但这对我们来说不是问题。问题在于似乎没有任何工具可以让您一次查看多个存储库上的更新或更改,或一次比较多个存储库然后为您顺序提交。这很容易编写脚本,但是对希望使用各种GUI前端来补充命令行的开发人员没有帮助。

    为了能够一次提交多个代码库(从用户的角度来看)并将所有内容保持在一起,似乎只有两个解决方案是:
  • 使用包含所有内容的整体存储库。
  • 创建一些子存储库,但是通过一个大型的整体“主”存储库访问/提交所有内容,该存储库包含所有子存储库,以使所有内容都保持最新版本(对我而言,这似乎并不比(1)更好)。

  • 想要同时使用多个“对等”存储库并不是一件很不寻常的事情,即使这些操作并非对所有存储库都具有真正的原子性,但是我并没有发现大量的文章或帖子大声疾呼为此能力。

    总之:
  • 我们想组织我们的代码,以便我们可以从用户的角度同时比较和提交应用程序代码和共享代码(它们不一定是原子的)。
  • 似乎我们应该将应用程序代码和共享代码放在单独的存储库中。
  • 子存储库将父存储库绑定(bind)到我们不希望的特定修订版。

  • 我在这里想念什么?

    最佳答案

    在我的商店中,我们有很多项目只是放在单独的存储库中,但是主应用程序的存储库中还有另外两个项目。一个是与主应用程序共享大量代码的模块,另一个是用于应用程序的数据库迁移的模块(甚至使用另一种语言)。我希望将应用程序和迁移器中的相关更改一起提交,这是密不可分的。总而言之,此存储库中的所有源文件都在10到11 MB之间。

    因此,如果因为不想处理子存储库而将所有内容都存储在一个存储库中确实是有意义的,那么将所有内容都存储在一个存储库中就没有错。我认为,我的一个只是中等偏上的一面。 TortoiseHg的来源约为20 MB,OGRE的来源超过100 MB。

    在不了解您的项目及其之间的关系的情况下,我得到的印象是,单个存储库就可以正常工作,并且您不会对此有错误的看法。

    如果您改变主意, hg convert 可以帮助您将项目提取到其自己的存储库中,并维护这些文件的历史记录。

    如果单存储库方法不适合您,那么我认为应该给subrepos一个机会,因为这是TortoiseHg支持的唯一一种凝聚地处理多个存储库的其他方法(请参阅Recommendations部分)。

    但是,我不确定您将如何处理部门间访问,因为似乎没有一个已建立的子集已经与其他人共享。

    关于mercurial - 一组相关应用程序中的模块的单片vs多Mercurial仓库,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/6714302/

    10-13 07:18