4

我有许多带有子存储库的项目：

/project              <- Main repository
/project/src          <- Source code subrepository  (subrepository to /project)
/project/src/module   <- Module subrepository (subrepository to /project/src repository)

我现在处理了一个功能分支（feature1），它有一些修订，我现在想将其合并回默认分支。自创建feature1分支以来，默认分支没有任何更改。

我尝试将分支合并为默认值，但最终在子存储库中发生了一些奇怪的事情。

我已按照另一篇文章中的说明进行操作，并得到以下结果：

$ hg checkout default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge feature1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
$ hg status -S
  M .hgsubstate
$ hg commit -S -m "branch merge test"
  nothing changed
$ hg branches
   default                       19:c2398dc23428
   feature1                      17:98dc0efbad90 (inactive)

奇怪的是，即使模块子存储库中更改了许多文件，合并仅表明更新了 1 个文件。我假设这恰好是.hgsubstate。

当我显式更新子存储库时，我得到以下信息：

$ cd src/module
$ hg update
  39 files updated, 0 files merged, 23 files removed, 0 files unresolved
$ cd ../..
$ hg commit -S -m "feature1 merge"
   committing subrepository src
$ hg status -S
   M .hgsubstate

因此，在进行hg update以将所有更改带入工作目录之后，我看到了需要提交的模块子存储库中的更改。但是，.hgsubstate始终保持修改状态。我试过hg remove。我试过hg forget。但无论我做什么，当我做hg status时它仍然被标记。

所以我的问题是：

  1. 我合并分支的过程是否正确（考虑到存在子存储库）？
  2. 是否有必要在子存储库中进行hg update以使主存储库识别更改？
  3. 为什么.hgsubstate行为不端？
4

1 回答 1

3

你没有说你正在使用哪个版本的 hg - subrepo 支持随着时间的推移发生了一定的变化。我刚刚在 hg v2.8 中使用 3 个子存储库级别尝试了类似你的测试，它对我有用。

当你在顶层得到一个脏的 .hgsubstate 时，这在你提交一个子仓库时是正常的。[如果仅独立提交了一个子存储库，则只有 .hgsubstate 在顶层将是脏的。]如果您随后进入顶层并在该级别提交，则 .hgsubstate 将被提交，一切都很好。请记住，顶级存储库以与文件类似的方式跟踪子存储库 - 它在每个顶级提交时从子存储库提交一个特定的变更集。

FWIW。推荐的做法是单独提交子存储库，即如果子存储库脏，则避免在顶层提交。原因是子存储库通常需要不同的提交消息 - 毕竟它们是子存储库是有原因的；但如果你愿意，你可以在顶层提交。在您有 3 个级别的情况下，序列将是：

cd src/module
hg commit -m "src/module commit reason"
cd ..
hg commit -m "src commit reason"
cd ..
hg commit -m "top level reason"

原本打算不经常更改子存储库，例如第三方库。如果您的子存储库要经常更改，您和您的团队将必须保持警惕以避免错误，尤其是在与其他人的工作合并时。[但是考虑到问题的日期，您现在可能已经自己解决了。]

于 2014-09-12T20:41:02.960 回答