保持Mercurial子仓库集合处于最新版本：我的方案是否有未预见问题？

嘿，从多年使用的SVN单体仓库转去Mercurial，还打算拆成独立子仓库来解决“不能单独克隆子目录”的痛点，这个思路很务实，但确实有几个容易被忽略的潜在坑，我帮你一一拆解：

1. 原子提交的丢失 #

在SVN里，你可以一次提交跨多个顶层目录的变更——比如同时修复了模块A和模块B的关联bug，整个提交是原子性的，要么全成要么全败。但拆成独立Mercurial仓库后，你必须分别对每个仓库执行提交操作。万一中间出岔子（比如A提交成功，B因为本地冲突提交失败），就会出现各子仓库状态不一致的情况，这对有强依赖的模块来说，很容易引发线上问题。

2. 跨仓库依赖的版本同步风险 #

如果你的子仓库之间存在代码依赖（比如仓库C的功能依赖仓库D的某个函数实现），单纯把所有仓库拉到tip版本就很危险：可能仓库C的最新tip是基于仓库D的v1.2版本开发的，但你把D更到了v2.0（最新tip），这时候C的代码大概率会出现兼容性报错。Mercurial本身没有内置的跨仓库版本绑定机制（除非用subrepos，但你目前的方案没提到这个），如果没有额外的版本约定或依赖管理工具，这种“版本不匹配”的问题会频繁出现。

3. 批量维护的复杂度 #

要让所有子仓库保持tip，你肯定得写脚本批量执行hg pull+hg update。但实际操作中会遇到各种异常：

• 某个仓库本地有未提交的变更，hg update会失败
• 拉取时遇到冲突，需要手动解决
• 个别仓库网络拉取失败，导致整个批量流程中断
  这些情况都需要额外的脚本逻辑处理（比如检测本地变更、冲突提醒、失败重试），长期维护下来，脚本的复杂度会越来越高，尤其是子仓库数量增多后。

4. 历史追溯的割裂 #

原来SVN里的跨目录提交历史，拆仓后会被分散到各个独立仓库中。比如原来一次提交修复了三个模块的联动问题，现在变成三个仓库里的三个独立提交，你没法直观看到这次变更的全貌。后续排查问题时，需要跨多个仓库搜索历史记录，效率会大打折扣。

5. 权限管理的冗余 #

如果原来SVN里对不同顶层目录有不同的权限控制（比如只有特定团队能修改模块E），拆成独立Mercurial仓库后，你需要给每个仓库单独配置权限规则。仓库数量越多，权限配置的重复工作就越多，很容易出现配置遗漏或不一致的情况。

一点小建议 #

如果你的子仓库之间依赖较强，不妨考虑Mercurial的subrepos功能——它能让你在一个主仓库中管理多个子仓库的特定版本，既解决了单独克隆子目录的问题，又能绑定子仓库的版本关系，避免依赖不匹配的问题。当然subrepos也有自己的学习成本，但比单纯拆成独立仓库要更可控。

另外，如果你坚持当前的方案，建议写批量脚本时加上：

• 本地未提交变更的检测提醒
• 冲突自动检测与手动处理入口
• 失败仓库的重试机制和日志记录

内容的提问来源于stack exchange，提问作者chew socks