在变化无常的情况下，当彼得"hg克隆“我，而我提交和他拉和更新，他得到了我的版本，但不是当我回滚？

Question

也就是说，如果彼得是从我那里克隆的

hg clone c:\mycode e:\code

进入他的e：\密码

假设有一个文件code.txt，它包含文本the code is 7

现在，当我将它更改为the code is 11和hg提交时，他就可以使用hg和he获得我的代码。现在他的说法是the code is 11

但是，如果我认为更改和hg回滚是错误的，那么我的存储库应该有7版本，而工作目录应该有11版本。

所以，当Peter进行hg拉和hg更新时，他应该被同步到我的当前存储库，即7，但我发现情况并非如此--他仍然得到了11版本。为什么会这样呢？他能得到回滚代码( 7)吗？吉特的行为也是一样吗？

更新：我认为commit影响存储库的方式和rollback影响存储库的方式一样-提交和回滚都是DB事务词.现在我们要说的是，commit会影响存储库，但是rollback不会吗？这里的规矩是什么？

更新2:如果玛丽做了一个

hg clone c:\mycode e:\marycode

此时，她实际上得到了7版本。玛丽得到了7。彼得得到了11。他们都是“最新”的？这是什么？

Answer 1

hg pull从远程存储库中提取新的变更集--但是它不会删除那些不存在远程的变更集。否则，做一个拉力就会抹去你自己的任何工作，而这些工作还没有被推到遥控器上。因此，拉不掉一个被拉过的变更集，然后遥控器将它回滚，因为没有新的变更集可抓取。

如果您进行了一个具有回滚状态的新提交，那么该提交将被删除，Peter将看到它。

换句话说，您需要做的是首先使用hg revert -r <previous-rev>签出您想要更改回的早期版本，然后使用hg commit创建基于旧版本的新提交，然后让用户提取该提交。

Answer 2

我不使用汞，但既然你问Git在这方面的行为.

在Git中，有两种撤消方法：revert和reset。

revert命令对现有代码进行修补，使其类似于以前的状态:历史记录将记录从原来的“代码为7”到“代码为11”的更改，然后将补丁记录为“代码为7”。

另一方面，reset实际上是历史的“倒退”。如果使用此命令，对“代码为11”的更改将从历史树中删除，存储库的状态就好像从未发生过一样。

因此，虽然revert和reset都可能导致存储库明显恢复到“代码为11”之前存在的状态，但它们在概念上是非常不同的操作。revert实际上创建了新的历史记录，而reset删除了现有的历史记录。

实际上，如果在存储库上执行revert操作，并且Peter从其中提取，那么实际上，他的存储库也会将更改记录回“代码为7”。另一方面，如果在存储库上执行reset操作，那么，从Peter的repo中，他正在提取的存储库实际上处于比他的存储库更旧的状态，不会发生任何事情。这就是为什么在使用Git时，只有当没有人拉动您的更改(或者您没有将更改推送到远程时)，您才应该使用reset。在所有其他情况下，您应该使用revert。

Answer 3

hg pull不是完全同步。hg pull remote所做的就是将不在本地存储库中的remote中的每个变更集复制到本地存储库中。rollback所做的就是删除最近的提交(或者更广泛地说，是DB操作，但这几乎总是一个提交)-它不记录任何类型的“提交已被删除”消息。除非有另一个存储库拥有提交，否则提交将永远消失。要记录它的反转，所以其他存储库需要反转提交(这可以通过hg backout创建)。然后，您将有另一次提交，它将逆转前一次提交的效果。

所以，当你做回滚，彼得再次拉，你没有任何新的改变集彼得拉。事实上，你的零钱比彼得少一个。所以，如果彼得向你施压，你就会再次得到11修订版。

在克隆场景中，它们都是最新的(因为它们都包含7修订版)，但是Peter还有一个额外的变更集。就好像彼得自己创造了11变更，并签了你的名字。

rollback不能在跨存储库通信中安全或有意义地使用。为此，您需要backout。出于这个原因，我总是喜欢推到一个发布的位置，让人们从那里提取，而不是让他们直接从我的工作存储库中提取，这样我就可以知道rollback什么时候是安全的，什么时候不安全(在我需要它的时候)。