3

背景

Mercurial 现在有阶段，这是一个很好的机制，可以防止人们改变不应该改变的历史。当一个变更集被推送到远程存储库时，它已经生成public并且不再是rebased. 如果存储库是公开的并且您不希望其他人更改您的变更集，这通常是一件好事。

但是，如果您有自己的临时存储库draft仅与自己共享变更集，则可能会非常烦人。Mercurial 可以选择将其关闭。将此添加到远程存储库.hg/hgrc的文件中。

[phases]
publish = False

这将防止推送到远程存储库的变更集从一个draft阶段移动到另一个阶段（本地变更集和刚刚推送到远程存储库的变更集。但是，拉下这个变更集仍然会在阶段public中拉下它。public

问题

draft我希望在该阶段下拉变更集。我只是想将变更集推送到我的个人服务器，然后在家里将其拉下来。在我拉取它之后，我将在rebase我从我们真正的发布服务器拉下的任何提交之上进行临时提交。

任何避免将拉取的变更集自动移动到的public方法都会很棒。这个远程存储库是我自己的完整和完整的草稿服务器。draft在尝试不成功后被迫手动将变更集移回原处，这rebase真的开始让人紧张。

参考

4

2 回答 2

1

这似乎是一个错误。您使用的是什么版本的 Mercurial？您是否尝试在https://bz.mercurial-scm.org提交错误？

于 2013-03-20T10:20:14.977 回答
0

我通过对 Bugzilla 的帮助解决了这个问题。这是我在那里的最后一篇文章的片段（感谢你让我走上正确的轨道 djc）。

看起来我们可以将其归结为用户错误/错误测试用例（当然）。如果要责怪任何人（除了我自己），那可能是 TortoiseHg。我的测试用例包括从两个存储库之一中剥离提交，然后在另一个存储库中更改该提交的阶段并再次推/拉。似乎 TortoiseHg 有时会进入错误的阶段（可能是缓存问题）。当我在发布和非发布之间来回切换服务器时，我仍然可以重现这一点（但不像以前那样一致）。

但是，执行命令行拉取似乎每次都能正常工作。我正在使用命令行来检查传出/传入，进行相位更改等，但可能从未将其用于实际拉动。

很抱歉浪费大家的时间。我将其解决为无效，不确定是否有人想将其更改为更好的类别。让我知道您是否希望我检查或扩展其他任何内容。

我会编辑任何更新，让我知道是否有人仍然遇到此问题。

于 2013-03-21T21:01:44.810 回答