问题标签 [subrepos]

我在一家公司工作，我们在那里创建了许多针对客户的小型应用程序。我们是少数开发人员，但大多数时候每个项目只有一名开发人员。

今天，所有内容都存储在一个存储库中。

过程很简单。

1. 开发人员为客户承担了一个新项目
2. 为项目创建一个新文件夹
3. 新项目中的代码
4. 在另一个项目中进行一些维护
5. 签入维护项目的更新
6. 新项目中的更多工作
7. 签入新项目
8. 交付给客户

没有标记也没有分支。早期版本根据日期签出。

这个过程多年来一直运行良好，但当前工具 (CVS) 存在一些痛点

• 慢的。即使没有任何变化，结帐也需要几分钟。历史记录存储在服务器上，因此差异需要很长时间
• 添加新项目。如果你使用过 CVS，你知道它就像：添加文件夹，在文件夹中添加文件，添加下一个文件夹......
• 无法消除明显的错误（检查二进制文件等）
• 不支持重命名，这使得必要的重构更加痛苦。

我私下使用 Mercurial 已经有一段时间了，并希望将其扩展到所有开发人员。

我可能完全搞错了，但有些事情我不明白如何在我们的组织中实施。

CVS 提交只是当前文件夹，但在 mercurial 中，它们是存储库范围内的。在我们的例子中，这意味着在一个文件夹中提交维护工作也会在另一个文件夹中提交尚未完成的内容。（我假设我们可以hg ci ./**在更改的文件夹中执行此操作，但合并时不允许这样做，至少文档是这么说的If you are committing the result of a merge, do not provide any filenames or -I/-X filters.）

Mercurial 中的常见做法是每个项目有一个存储库。

每个项目一个存储库对我们来说是可以的，但它会产生一些其他问题，例如：

如何管理中央服务器上的多个存储库？
如果开发人员创建了一个新项目，他最终需要推送他的更改。只是在做

hg push http://localhost:8000/Customer1/NewProject

使用丑陋的堆栈转储使 hg-webserver 崩溃并挂起客户端。

我理解的方式是开发人员需要访问服务器外壳才能将新存储库添加到配置文件并重新启动 hgweb

另一种方法是使用 SSH 或共享（使用 SSH 代替文件共享有什么好处吗？）

有效，但对某些开发人员来说有点复杂

所有开发人员都需要拥有所有项目。
（并非所有项目都是链接的，因此它们需要存在，并且最容易拥有所有项目）

随着每周添加许多现有项目和新项目，我们需要一种方法来一次性提取所有项目并克隆新项目。

我在想 subrepos 可以解决“全局”拉，但文档中的以下行是一个展示者

“当我们提交时，Mercurial 将尝试创建整个项目及其子存储库状态的一致快照。它首先尝试提交所有修改的子存储库，然后记录所有子存储库的状态。”

回到全局提交的单一仓库问题。

（尝试了一些变体，hg ci .hgsub .hgsubstate <subrepo>但 .hgsubstate 似乎只在完整提交时更新。其他用户hg pull --update在项目文件夹中没有明确的情况下将看不到项目更改）

我目前的想法是在根目录中有一个批处理文件来拉取所有项目

关于如何在我们的组织中使用 mercurial 的任何其他想法？

编辑

谢谢回复。我目前正在评估每个项目的一个存储库如何为我们工作。我把一个批处理文件放在顶层

我有一个 mercurial 存储库，里面有多个子存储库。存储库有一个 Visual Studio 解决方案，其中包含存储库和子存储库中的项目。

假设我想实现一项新功能，该功能需要更改存储库中的主项目并更改解决方案中的其中一个依赖项项目（比如说，在依赖项中添加一个新的共享接口，并在主要项目）。

然后我想提交更改，但要提交到一个新的命名分支，因为它尚未完成并将稍后合并。使用 tortoiseHg 我在存储库中提交更改，指定要创建的新分支。提交反过来提交子仓库的更改，但在我的测试中，它不会在其存储库中创建新分支，而只是将更改集添加到当前分支。

我可以明确地执行对子存储库的提交并在那时指定分支名称，但我希望有一种方法可以将存储库中的整个更改集一次性提交到每个存储库中的新分支，这样我的工作流程就更干净了。这可能吗？

我对 mercurial 很陌生，我已经阅读了很多关于这个主题的主题，但我仍然不明白我是否能实现我想要做的事情。

基本上，我有兴趣在单个命令中从主存储库及其子存储库中克隆当前版本的分支（作用于主存储库）。我稍后会尝试更好地解释它。

假设我将代码分成模块（下面的示例中只有一个模块）。我希望每个模块都在自己的存储库中，并有一个主存储库（具有 .hgsub 的那个）作为粘合剂来保持所有子存储库的位置。主存储库仅包含 .hgsub 和一个脚本，该脚本 (1)hg archive预定义目录中的每个子存储库和 (2) 执行代码的源外构建。所有开发、提交、推送、拉取、合并都在各个子存储库中完成。

到目前为止，一切都很好。如果我hg clone main得到 subrepo 的默认分支的当前版本，如预期的那样。

但是，现在让我们想象一下，我已经准备好将我的代码发布到一个版本中：1.0.0。我会做如下。

这就是问题发生的地方。当我执行时，如何更改主存储库以获取默认的当前版本，或者最终获取子存储库的 1.0 分支hg clone？

我会说这行得通。

但是当我hg clone主要回购时，我得到

有没有办法实现我想做的事情？

谢谢。

快速更新：在我发布问题一分钟后，我找到了一个我以前从未见过的答案。在那里，建议使用以下语法

通过使用#branchname代替#revision. 因此，在我的示例中，以下内容应该有效（对于分支 1.0）：

但是当我hg clone得到主仓库时：

我正在开发 Ubuntu 10.04，mercurial 1.4.3-1。建议？

——迪伦

我对 mercurial 很陌生，我已经阅读了很多关于这个主题的内容，但我一直无法找到明确的答案。

反复无常的指南说：“为了提高效率，只要源和目标位于同一文件系统上，就使用硬链接进行克隆（请注意，这仅适用于存储库数据，不适用于工作目录）。”

存储库wiki 页面说：“与存储库根目录中的 .hg 目录共存的所有文件和目录都被认为存在于工作目录中”。

现在，要在主仓库中“链接”一个子仓库，我会这样做：

上面的定义是否意味着我实际上是在执行 (1) 时创建一个副本？？subrepo还是我只是创建一个符号链接../subrepo？根据 的输出ls，它是一个实际的副本。但这对我来说听起来很奇怪......如果有人可以对这个主题有所了解，我将不胜感激。

我的项目由以下位置的代码组成

目前，这些文件夹中的每一个都是一个完全独立的 Mercurial 存储库。项目 A 一直在变化，图书馆 B 和图书馆 C 很少变化。

我目前在项目 A 的每个版本发布时都对其进行标记，并且（当我记得时）将相应的标记放在库 B 和 C 存储库中。

我可以通过使用子存储库来改进这一点吗？这是否需要我将库 B 和 C 设为项目 A 的子目录？

如果库 B 和 C 必须是项目 A 的子目录，如果我想启动一个使用库 B 但根本不隶属于项目 A 的项目 D，我该怎么办？

有时，当我进行代码更改时，我需要对我的存储库中的共享库代码进行相应的更改，该存储库本身就是一个子存储库。当我想提交更改时，我会在父存储库中提交，Mercurial 会负责在子存储库中进行相应的提交。

但是，我最近开始使用 MQ 来更好地跟踪我自己的更改历史，并给自己更多的自由来进行实验和更安全地进行大规模重构工作。我在父存储库和子存储库上都启用了 MQ。

在上述场景中，我是否正确假设如果我“提交”到新的或现有的 MQ 补丁，那么子存储库会被忽略？这似乎是我的测试中发生的事情。这是否意味着我需要手动管理子存储库中的补丁队列？这很快就会变得笨拙。

如果这不起作用，那很好——当我有跨仓库工作要做时，我可以调整我的工作流程并避免使用 MQ——但我想知道我是否遗漏了一些东西，或者其他人是否有他们可以分享的这种情况的解决方案。

更新：根据此线程，此时似乎“不支持”：https ://www.mercurial-scm.org/bts/issue2499

我尝试了以下方法：

1. 手动提交子存储库更改。
2. 使用来自子存储库提交的哈希手动更新了父存储库中的 .hgsubstate 文件。
3. 试图 qrefresh 父存储库。

这个想法是我可以从父存储库获取提交以始终与正确的子存储库版本同步，即使我必须手动执行。不幸的是，Mercurial 似乎想在这里保护我（应该如此！），当我尝试 qrefresh 时，会出现以下问题：

为了“修复”事情，我在父存储库上的 hgfinish 之后做了一个空提交，以使事情同步备份。但是......这似乎很愚蠢，并且使代码历史更难理解。

哦，好吧，当涉及到子存储库时，我想我会回到石器时代并停止在我的工作流程中使用 MQ。

我有一个基于 CodeIgniter 开发的项目。该项目的主要部分是我正在创建的一个私有系统，但我想将它添加到源代码控制中，以获得所有相关的好处。现在我正在使用 Mercurial，所以我做了整个 hg init 位，所以我已经设置了存储库。

现在，我做的一件事是为我在这个项目中使用的 CodeIgniter 创建一个库。现在我想让这个库打开，所以我需要一个单独的仓库。

对于不熟悉 CodeIgniter 库开发的任何人，这里有一个参考：

现在我可能会在这个项目的过程中开发更多的库，所以我不能只是在应用程序文件夹中转储一个 repo 而不将它们全部聚集在一起。

我所做的是这样的：

现在在这两个文件夹中，我创建了一个存储库。我想做的是让项目存储库自动引用库存储库，这样我就可以拥有一个私有和一个公共存储库，正如我之前解释的那样。

我读过，这样做的主要方法是使用子存储库，但我只能找到嵌套存储库的示例（我发现无论如何都不清楚）。如何让它引用另一个存储库，如 svn:externals？

我一直在阅读有关子存储库以及如何使用转换扩展名和文件映射将现有文件夹从 Mercurial 存储库提取到子存储库的信息。我可以成功地做到这一点。如果我有以下文件夹结构：

我可以制作 SubFolder 的子存储库。以同样的方式，我可以将其他所有内容提取到单独的存储库中（在此示例中，第二个存储库将只有 root.txt 文件）。之后，我可以将 SubFolder 存储库作为子存储库添加到第二个存储库。但是，尽管两个存储库都有完整的历史记录，但这些历史记录没有关联 => 将根存储库更新到较早的状态不会使子存储库处于此时应处于的状态。更新到一致的旧版本（自动更新根和子存储库）只有在更新到已经知道子存储库并具有 .hgsubstate 文件的版本时才有效。

我想到的替代方法只是忘记当前存储库中 SubFolder 中的文件，并在 SubFolder 中启动一个新存储库，同时添加一个 .hgsub 文件。我希望在这里实现的是从这一点开始使用子存储库，但仍然有办法更新到旧版本（在分离子存储库之前），因为 SubFolder 的文件仍在当前存储库的历史记录中。

但是这不起作用：当我忘记了 mercurial 中的文件时，启动了一个新的存储库并将其链接为当前存储库中的子存储库，并且在子存储库存在之前更新到旧版本我收到此错误：

这里的问题是，当更新到不知道子存储库的旧版本时，此更新希望将文件放在子文件夹中。但是这个 SubFolder 仍然是另一个 repo（有一个 .hg 目录），虽然主 repo 不记得它，但更新不想将文件放在 SubFolder 中，因为它是一个 repo。

是否有解决此错误的方法，或者是否有更好的方法可以切换到对现有 Mercurial 存储库中的某个文件夹使用子存储库并保持历史记录完整（以及两个历史记录链接）？

我有一个使用相当标准的源代码树方法 + mercurial 子存​​储库的主项目。

现在，最近确定 Sub2 需要来自 Sub1 的一些代码，因此我必须针对这个新的依赖结构进行调整。

问题当然是，如果我遵循与上述相同的方法并将 Sub1 添加为 Sub2 的子存储库，我最终会遇到这种丑陋的情况。

Master现在有2个独立的Sub1副本！

所以我知道在引用 subrepos（= 的 RHS）时我应该使用相对路径——但据我所知，这对我的场景没有帮助。我认为没有任何方法可以使 LHS位于主存储库之外，我认为这是我在这里真正需要的。

我有几个关于如何解决这个问题的想法，但没有一个适合我，我认为必须有更好的方法。我理想的解决方案允许我在多个项目之间共享相同的子存储库，而无需支付拥有多个副本的代价。在我的场景中，这似乎既浪费又低效（另外，我希望所有依赖 Sub1 的项目都使用相同的 hg 修订，而不是独立修订）

1. 删除 Sub1 作为 Master 的子存储库，并更改 Master 解决方案中的任何相对路径以引用双重嵌套的 Sub1。这种路径结构不仅可怕，而且如果将 Sub3 添加到依赖于 Sub1 的主控，我仍然有 2 个 Sub1 副本。

2. 编译 Sub1 的副本并将其放入 \lib 目录。Sub1 仍在经历一些混乱，我宁愿针对源版本进行构建。我不想一直为不断地将新的二进制文件复制到源代码树而付出代价（并使树膨胀）。

3. 以某种方式打破 Sub2 对 Sub1 的依赖。根据存储库的架构，这可能不会发生。Sub1 包含一些非常通用的共享库代码。Sub2 包含两个非常独立的项目（客户端 SDK 和服务器实现）所需的 WCF 服务合同/接口/类型。此时，将这些存储库分开是有意义的。

也许我在想这个错误......或者我可能不知道一些汞技巧。

任何帮助表示赞赏。

这将是一个很长的帖子……抱歉。

我正在努力思考如何将“每个项目分支的存储库”组合在一起，以及这将对团队产生什么影响。

目前看来

• 可以递归地签入嵌套签入的代码，尽管 hg status 没有提供有关嵌套存储库中文件更改的太多信息
• 看来我——以及每个想要从事同一个项目的团队成员——必须手动编辑他们的子存储库.hgrc文件，以使签入尽可能轻松和自动化。
• 可以递归签入，但不支持递归签出。

这是对 Hg 能力的正确分析吗？

我真的不希望这样，因为这比我见过的普通开发团队在保持生产力的同时可以处理更多的棒式编码（即到处摆弄命令提示符）。据我了解，重构单个程序集可能会使团队陷入停顿，因为他们停下来编辑.hgrc文件以添加位置、用户和密码。不？

我真的想仔细检查一下 Hg 不能递归拉？听起来像是一个遗漏，我觉得我一定错过了什么。

谢谢！

PS：对于勇敢或愚蠢的人（如果有帮助），我在解决引用其他库模块的引用库模块的项目问题时一直保留的注释如下（注意 ??? ? QUESTIONS??? 穿插在其中...