这个问题假设团队成员有一个“有福的”中央存储库
如果是这样,我会认为hg update
与svn update
不相似(为什么会有两个命令完全相同?)。根据我的收集,hg update
更像svn revert
。这是对的吗?
更新
我对rebase的理解主要基于本页的“常见案例”部分:
https://www.mercurial-scm.org/wiki/RebaseProject
答案 0 :(得分:41)
正如其他人所说,差不多但并不完全。为了降低与svn update
的相似性(并且越来越多地遵守一般DVCS,特别是Mercurial,最佳实践[1]):
hg pull -u
(或hg pull
后跟hg update
),您的更改未提交且自上次提取后未进行任何提交更改。这与你可以得到的svn update
接近,但DVCS的做法非常糟糕。 DVCS的一个细节是你可以在尝试将它们与其他人合并之前提交你的更改,从而有一个备份版本来回滚并重试失败的合并,这种做法就是这样。不要这样做。
hg pull --rebase
。这会拉动上游更改,在其上重新应用更改,并允许您将更改作为线性历史记录推回。最终结果看起来与Subversion修订历史非常相似,但您可以在合并之前获得DVCS提交的好处。我不知道这种操作模式的安全性如何在Mercurial和Git之间进行比较;在Git中,您的更改的pre-rebase版本仍然存在,直到您执行git gc
,但Mercurial没有明确的gc
安全网。
hg pull
后跟hg merge
,您的更改已提交到您的本地副本。尽管下面的脚注1,这是执行svn update
的功能类比的传统Mercurial实践。这会产生非线性版本历史记录,但会跟踪和检查所有更改。
也就是说,Mercurial(以及其他DVCS)在他们自己的条件下有很多智慧,而不是试图从Subversion / CVS风格的思维中进行翻译。
rebase
可能优于update
。 Mercurial社区倾向于支持update
。答案 1 :(得分:11)
不完全是。
hg pull
从其他存储库中获取修订版本并将其添加到存储库克隆中的本地可用修订版本,但不会更新您的工作副本 - 只有您的存储库(对于像hg / git / etc这样的DCVS与工作副本不同)。
hg update
将您的实际工作副本更新为本地存储库中的最新版本。
这与Subversion不同,因为在svn中,没有“本地存储库”这样的东西 - 唯一的存储库是服务器上的存储库;你只在本地有一份工作副本。因此,为什么update
只是一个命令,而不是Mercurial的pull
然后update
。
Mercurial的svn update
相当于hg pull --update
,相当于一个接一个地执行hg pull
然后hg update
。
具有“中央”回购的DCVS的端到端工作流程如下所示:
hg commit
进行一些更改。hg push
推送到中央存储库。hg pull
将它们从中央存储库拉到自己的克隆中。hg update
更新其工作副本,以反映其克隆中的更改。在没有中央回购的系统中,它看起来像这样:
hg commit
进行一些更改。hg pull
。hg update
将其工作副本更新为更改。此外,相当于svn revert
的是hg revert
。 :)
答案 2 :(得分:2)
hg pull --update
相当于svn update
所以在DVCS中,你有2个概念而不是1个:
答案 3 :(得分:2)
这是mercurial http://hginit.com/的精彩初学者指南。应该清楚解释大部分事情。从“不要尝试将svn知识应用于分布式vcs”开始!
答案 4 :(得分:2)
命令hg pull --rebase
与<{1}}的类似并不完全相同,但结果可能相同。
在Subversion中,如果您更新工作副本,则会获得与任何本地更改合并的存储库中的最新更改。因此,存储库中的文件是最新的,但您可能仍然有未提交的更改。
在Mercurial中,svn update
将从“中央存储库”(或您正在提取的任何存储库)获取最新更改,以更新您的存储库,然后随机提交您的本地提交。您仍然需要hg pull --rebase
才能使您的工作副本与本地存储库相同。