Mercurial:为什么拉出的变更集不公开？

Question

考虑以下情况:

$ md repo1; cd repo1
$ echo some data > myfile
$ hg init; hg addremove; hg commit -m "First commit."
adding myfile
myfile
committed changeset 0:32c7aa047f3b
$ hg serve
listening at http://vostro.rath.org:8000/ (bound to *:8000)

然后在另一个终端:

$ hg clone http://vostro.rath.org:8000/ repo2
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
updating to branch default
resolving manifests
getting myfile
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd repo2; hg phase tip
0: public

..再次在第一个终端:

127.0.0.1 - - [25/May/2013 16:38:40] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
^Cinterrupted!
$ hg phase tip
0: draft

对我来说，这看起来很不对。有人刚刚从第一个存储库中提取了变更集，所以它显然是公开的。但是，它在存储库中仍显示为“草稿”。

有人可以解释这种行为的基本原理吗？作为第一个存储库的所有者，我非常想知道什么时候有人提取了修订版(这样我就不再对它进行 rebase 了)，所以我认为如果 hg 服务器进程更新阶段是明智的因此。

Answer 1

你可能会在邮件列表上得到更好的答案，但我的理解是:

hg pull 一直是只读命令，无需对远程存储库进行写访问即可运行。更改远程存储库中的阶段(显然)需要写入。另一方面，hg push 一直写入远程存储库，因此阶段没有引入任何变化。

将 hg pull 从只读更改为读写可能会导致某些人的工作流程中断，这是 mercurial 开发中的大罪。 (例如，匿名用户从公共(public)服务器拉取，通过电子邮件包发回更改)

基本上这是一个历史怪癖，因为阶段是一种改造。

这留下的漏洞是，变更集的原始所有者可以修改它，而没有意识到变更已经荒废了。我希望这个漏洞不会让太多人担心，因为正在开发的“变更集演化”功能以更好的方式解决了这个问题。

我倾向于将阶段视为:

• 公共(public) - 公开可见且不可变
• 草稿 - 公开可见且可变
• secret - 不公开可见且可变

我认为 draft 存在只是因为那基本上是我们在添加阶段之前的状态，并且是一个有点薄弱的概念。真的，如果你在一个人们可能直接从你那里获取信息的环境中工作，那么我建议更多地使用 public 和 secret 阶段，并避免 draft.