svn - `hg pull --rebase` 类似于 `svn update` 吗？

Question

这个问题假设有一个“有福的”中央存储库，团队成员可以使用它

1. 克隆自
2. 当他们有希望其他团队成员看到的贡献时推送
3. 当他们想看到其他人的贡献时就退出。
4. 等等

如果是这样，我会假设 hg update 与 svn update 不同(为什么会有两个命令执行完全相同的操作？)。据我所知，hg update 更像是svn revert。这是正确的吗？

更新:

我对 rebase 的理解很大程度上基于本页的“常见案例”部分:
https://www.mercurial-scm.org/wiki/RebaseProject

Answer 1

正如其他人所指出的，几乎但不完全是。按照与 svn update 的相似性递减的顺序(并提高对一般 DVCS，特别是 Mercurial 最佳实践 [1] 的合规性):

1. hg pull -u(或 hg pull 后跟 hg update)，您的更改未提交，并且自您提交以来没有提交任何更改最后拉。这与 svn update 非常接近，但这是非常糟糕的 DVCS 实践。 DVCS 的优点之一是，您可以在尝试将更改与其他更改 merge 之前提交更改，从而拥有一个备份版本来回滚并重试失败的 merge ，而这种做法放弃了这一点。不要这样做。

提交更改后

2. hg pull --rebase。这会拉取上游更改，在其之上重新应用您的更改，并让您将更改作为线性历史推回。最终结果看起来与 Subversion 修订历史非常相似，但您可以获得在 merge 之前提交的 DVCS 好处。不过，我不知道 Mercurial 和 Git 之间这种操作模式的安全性如何；在 Git 中，更改的预 rebase 版本仍然会存在，直到您执行 git gc，但 Mercurial 没有明确的 gc 安全网。

3. hg pull 后跟 hg merge，您的更改已提交到本地副本。这是传统的 Mercurial 实践，用于进行 svn update 的功能模拟，尽管有下面的脚注 1。这会导致非线性版本历史记录，但所有更改都会被跟踪和检查。

也就是说，按照 Mercurial(和其他 DVCS)自己的方式来思考，而不是尝试从 Subversion/CVS 风格的思维进行转化，这是非常明智的。

1. 如果您不属于“重写历史以保持线性”的思想流派。如果是的话，那么rebase可能比update更可取。 Mercurial 社区倾向于支持更新。