0

我正在研究 Mercurial，但我不明白它是如何检测文件冲突的。

当集中式 SCM（作为 SubVersion）检测到我的项目中文件的两个版本之间存在冲突时，这意味着我的本地文件的版本号比远程存储库中相同文件的版本号小，因为另一个开发人员（pe John Smith ) 在我之前提交（使用相同的初始版本号）。

在分散的 SCM（Mercurial、Git 等）中，我没有中央存储库，那么：

  • 我克隆了一个存储库，从远程服务器下载了一个版本的文件；
  • John Smith 克隆了同一个仓库，从远程服务器下载了同一个版本的文件 A；
  • 约翰·史密斯（John Smith）编写了一些代码，并在他本地提交了代码；
  • 之后，我在本地提交；

Git 如何理解我们的文件是数字版本 A 的直接后代？Mercurial/Git/Bazaar/etc 没有一个内部编号来识别：他们如何理解修改后的文件何时发生冲突？

4

2 回答 2

2

只有在您和 John Smith 相互通信（使用hg pushand hg pull）并且你们中的一个想要合并两条工作线（使用hg merge）之后，才会检测到任何冲突。

将 John Smith 的更改拉入本地存储库后，更改集图可能如下所示：

... [a] --- [b]
       \
        `---------- [c]

你在哪里做了 changesetb和 John Smith 做了c，都基于 changeset a。在a和之间b，您更改了文件helloworld.c，并且在a和cJohn Smith 之间更改了同一个文件。Mercurial 现在能够判断此处可能存在潜在冲突（重叠编辑），它会在您运行hg merge.

该系统不基于与文件关联的版本号——它基于上述变更集图。具体来说，当你与 合并b时c，Mercurial 会找到最大的共同祖先，即a。然后它会查看 , 中的清单（给定变更集中存在的文件（及其版本）的列表）a，b并c注意到该文件helloworld.c存在于三个不同的版本中。这告诉 Mercurial 它需要进行三向合并，a作为基本版本，b以及c作为本地和其他版本。默认情况下，它会尝试在内部进行合并，但如果失败，它将调用外部合并工具（如 KDiff3）。

于 2013-07-06T09:09:33.927 回答
0

如果你真的想知道它是如何工作的，我推荐《Mercurial: The Definite Guide》一书的第 4 章

简而言之，Mercurial 为每个版本创建一个唯一标识符。它在所有存储库中都是唯一的 - 基于散列。您和 John Smith 在您的存储库中将具有相同的版本 A 标识符。您的本地更改将具有不同的标识符。当你们中的一个人决定拉取和合并更改时，Mercurial 能够确定你们都对同一个版本 A 进行了更改。这两个更改都与基本版本 A 进行了比较。然后很容易检查生成的补丁是否冲突.

于 2013-07-12T18:30:52.423 回答