有没有办法克隆subrepos附带的repo，但没有让Mercurial拉出所有的subrepos？
虽然可以使用hg clone -U获取repo的空克隆，但没有什么可以说服hg update通过拉动所有子目录来避免启动。
我应该指出，在创建这样的克隆之后，保持轻松同步到头版本的能力至关重要。
答案 0 :(得分：13)
这应该做你想要的：
REM Take a new clone, but do not update working directory
hg clone --noupdate %REPO_PATH% %DESTINATION%
REM Update working directory but exclude the certain subprojects
hg revert --all --rev %BRANCH% --exclude %SUBREPO_PATH_1% --exclude %SUBREPO_PATH_2%
答案 1 :(得分：8)
这个答案可能会增加所需的问题，但是当你无法更新到一个糟糕的子存储库路径或版本时，会提供一些有关使用Mercurial的有价值的说明。
步骤1：在没有任何更新的情况下克隆存储库
hg clone --noupdate source_repository destination_repository
第2步：使用revert获取正确的文件
hg revert --all --rev revision_number --exclude subrepo_1 --exclude subrepo_2 ...
此时，您有一个新的变更集;您可能需要确保父修订版是正确的。当我这样做时，我的新变更集的父级是变更集0.为了解决这个问题，我必须设置父变更集AND切换分支（因为我的变更集位于不同的分支上）。
步骤3：更改当前更改的父级
hg debugsetparents revision_number
hg branch branch_name
应该这样做。
答案 2 :(得分：5)
发现了一种hacky方式。它仍然需要一次检出所有子目录，但之后可以删除它们。
hg remove .hgsub 我试图在克隆subrepos之前说服Mercurial hg remove .hgsub，但我得到的最好的是not removing .hgsub: file is untracked。
答案 3 :(得分：3)
如果你有一个subrepo，工作目录必须包含该subrepo的某个版本。如果指定，该版本可能是固定的旧版本，如果没有，则可能是小费。
如果没有获得subrepos，您将无法更新您的仓库;如果你有一个没有它们的完整工作目录，你不应该使用subrepos - 使用真正的外部存储库。
如果你的subrepos与某个远程版本挂钩，那么在第一个版本之后更新将不会触发subrepo更新 - 它们已经是最新的。但是对于工作目录的初始创建，您将不得不进行远程拉动。
您可以通过隐藏hgsubstate文件来欺骗Mercurial。但实际上，你的模型和概念模型不同，所以如果这是一个问题，你可能不适合subrepos。
编辑：如果您发现自己克隆并多次更新到提示，请尝试使用本地分支或mq。这样你只需要进行一次初始克隆。