对于 Mercurial，拥有 2 个克隆可以像拥有 2 个分支一样工作吗？答案

【问题标题】：For Mercurial, having 2 clones can work the same as having 2 branches?对于 Mercurial，拥有 2 个克隆可以像拥有 2 个分支一样工作吗？
【发布时间】：2010-11-05 05:20:24
【问题描述】：

因为我想比较我在 7 或 10 天前所做的所有更改，而看不到其他团队成员的更改，所以我保留了一个克隆，比如说

c:\dev\proj1

然后我保留另一个克隆

c:\dev\proj2

所以我可以更改 proj1 的代码，然后在另一个 shell 中，从中提取代码，并与其他团队成员合并，然后运行测试。然后 10 天后，我仍然可以通过转到 proj1 的 shell 并执行 hg diff 或 hg vdiff 来区分我和其他人编写的所有代码。

我认为这也可以通过使用分支来完成。拥有 2 个这样的克隆与拥有 2 个分支的工作方式完全相同吗？一种方法比另一种方法有什么优势？

【问题讨论】：

标签： mercurial

【解决方案1】：

简短的回答是：是的。

Mercurial 不关心变更集来自何处，何时合并。从这个意义上说，在合并更改时，分支和克隆同样有效。

更好：您描述的工作流程正是Chapter 3 of the Mercurial book 中的策略。

分支机构的唯一优势是它们有名称，因此您没有立即合并的动力。如果您想将这些 proj2 更改分开，同时仍将它们从 proj1 推送和拉出，请给它们一个真正的分支。同样，在功能上，它们是相同的。

是的，这是 DVCS 的特性，而不是 Mercurial 独有的特性。

【讨论】：

Mercurial 本身的开发是使用用于开发和稳定分支的单独存储库的模型完成的。在 Mercurial 开始时，这是唯一的模型，在引入命名分支支持后，开发人员并没有看到需要进行更改。
是的，忽略那些建议命名分支的人。这是要走的路。
我是建议命名分支的人之一。如果你不理我，遇到下面的问题，就上你！克隆的问题在于它们是轻量级的。您养成了从 master 克隆的习惯，将您的工作区克隆到第二个工作区，删除第一个工作区等。如果您不小心删除了具有独特更改的工作区，那就太糟糕了。而如果您使用命名分支，您可以将这些更改推送到其他克隆 - 主，您自己的。等等。命名分支使您不太可能失去工作，因为它可以在副本中保持一致。
你有没有看过一个包含数十个不同状态的项目克隆存储库的目录，并想知道“这些克隆中的每一个到底是什么？”或者被 rm -r some-repo 诱惑，意识到它有你想要保留的更改，为时已晚？是的，你可以比较回购。但是有了分支，它们都生活在一个合乎逻辑的地方。 // 也就是说，你很容易丢失一个克隆的 repo，或者失去对它们的跟踪，而对于分支，它们存在于一个逻辑位置，但可能在物理上被复制。
我的典型工作流程是： // hg clone project-master my-local; hg clone project-master working-repo1； cd 工作-repo1；编辑; hg push my-local; cd .. // hg clone project-master working-repo2; cd 工作-repo2；编辑; hg push my-local; cd ../working-repo1；编辑; hg 推动我的本地。 etc. // 如果工作是在分支上完成的，它不会干扰 my-local。而且你只有一个你必须不能删除的repo，my-local。

【解决方案2】：

注意：我对git 比hg 更熟悉，但想法应该是一样的。

如果您更新两个克隆（它们都在编辑同一个分支），差异将变得明显，例如快速修复集成沙箱的错误。

正确的方法是让您拥有一个主题分支（您的第一个克隆），这是您进行开发的地方，另一个用于集成（您的第二个克隆）。然后，您可以根据需要将更改从一个合并到另一个。如果您确实在集成分支上进行了更改，您就会知道它是在那里进行的。

【讨论】：

【解决方案3】：

hg diff -r <startrev> -r <endrev> 可用于比较 Mercurial 历史中的任意两点。

历史示例：

       rev      author  description
       ---      ------  ----------------------
@       6       me      Merge
|\
| o     5       others  More other changes.
| |
| o     4       others  Other changes.
| |
o |     3       me      More of my changes.
| |
o |     2       me      My changes.
|/
o       1       others  More Common Changes
|
o       0       others  Common Changes

如果修订版 1 是原始克隆：

Revs 2 和 3 代表您的更改。
Revs 4 和 5 是您在分支开发过程中所做的其他更改。它们在 6 修订版中被合并到您的更改中。
此时，要仅查看 me 在合并前所做的更改，请运行 hg diff -r 1 -r 3 以仅显示这些更改。

【讨论】：

【解决方案4】：

为什么不干脆有两个分支呢？（分支/合并在像 Hg 或 Git 这样的 DVCS 中比在像 TFS 或 SVN 这样的集中式 VCS 中更容易和更安全！）它会更加安全和可靠。
这将变得明显，例如当您想要将两个分支/克隆重新合并在一起时。此外，从两个不同的物理位置编辑一个分支很容易导致混乱和错误。 Hg 旨在避免此类情况。

托马斯

【讨论】：

【解决方案5】：

正如一些答案已经指出的那样，分支（命名或匿名）通常比两个克隆更方便，因为您不必拉/推。

但是两个克隆具有完全物理分离的明显优势，因此您实际上可以同时处理两件事，并且在切换项目时无需重新构建。

之前我向question 询问了有关使用 hg 进行并发开发的问题，选项 1 是两个克隆，选项 2 是两个分支。

【讨论】：