Mercurial 存储库识别

Question

我需要能够唯一地标识 Mercurial 存储库，并将该标识符放置在克隆时包含的文件中。如果我可以将标识符放入 .hg 文件夹中的文件中，这比简单地将普通文件添加到存储库更好。

我知道我可以从提交的第一个更改中获得几乎确定的标识符。我知道 hgrc 文件不能用于存储标识符，因为它没有被克隆。

所以，我的问题是：克隆的 .hg 文件夹中是否还有另一个文件可以用来放置标识符？谢谢。

Answer 1

从第一次阅读开始，听起来您希望能够确保存储库的克隆是正确存储库的克隆，而不是某个替代者的克隆。但是，如果您正在考虑使用的身份信息与其他所有信息一起克隆，那么冒名顶替者仍然可以通过此测试。您需要将该标识符分开，以便可以将其与克隆中的信息进行比较。

无论这是否是您的目的，您可能不想编辑 .hg 中克隆的任何文件。您必须在存储库的其他区域（.hg 之外）添加一个要跟踪的文件。但是，您实际上根本不需要额外的文件，因为变更集哈希不仅接近确定，而且非常确定，因此用于轻松识别存储库的信息内置于存储库中本身。

在命令行上，您可以获得第一个变更集的哈希标识符的简短或完整版本：

> hg id -i -r0
89abf5502e3c

> hg log -r0 --template "{node}"
89abf5502e3c5c65e532db04d8d87141f0ac8b73

如果我对您比较 2 个标识符的愿望是正确的，以便您或其他人知道存储库的克隆是真正的克隆，而不是如果是假克隆，您将单独获得相同的变更集 ID，以便有人可以使用上述命令之一来查看其克隆的 ID，并将其与您所说的进行比较。这很像许多具有可下载可执行文件的网站在下载链接旁边显示哈希标识符，以便您可以自己对文件进行哈希并将结果与​​网站上的哈希进行比较。

编辑关于阐明此目的的评论：

由于您需要能够从文件中读取它，因此有几个选项：

存储库中的跟踪文件root

除了创建自己的文件之外，您还可以考虑一个文件：.hgtags。

hg tag -r0 ident

...将标记第一个修订版，允许您使用 ident 作为对该变更集的引用，而不是 -r0。 Mercurial 始终使用最新版本 .hgtags 中的标签信息，无论工作目录更新到什么变更集，但这对您的应用程序来说可能并不重要。 hg tag 将这样的一行附加到 .hgtags 文件中，如果文件不存在则创建该文件：

a247494248c4b96a571bbd12e90eade3bf559281 ident

如果您没有标签，这是最方便的文件尚未在您的存储库中，因为它将是文件中的第一行以便于查找。您可能认为可以简单地自己编写此文件，但您仍然需要调用 hg 来获取变更集 id，并在某个时候再次将其添加到跟踪中，然后提交：hg tag 为您完成这一切。

如果已经有可能需要考虑标签文件，那也没关系，因为它们往往相对较短，您只需要查找以您选择的标签名称结尾的 1 行。 Mercurial 专为 .hgtags 进行仅追加操作而设计，但如果 .hgtags 已存在，则如果将此标记的行插入为第一行，一切仍然可以正常工作因为： 1. 标签永远不会被移动或移除。 2. 您将使用文件中尚未使用的标签名称。

读取 hg 的内容

通常只有 Mercurial 本身才能深入了解 .hg 中的一些文件，可以读取这些文件来获取第一个变更集的哈希值。我研究了 Mercurial 的文件格式，Revlog 和 RevlogNG，至少对于我自己的 2 个存储库，.hg\store\00changelog.i 包含第一个变更集的哈希值，位于偏移量 0x20（20 字节长度）处。也许，至少从 Mercurial 0.9 开始，所有存储库中的情况都是相同的。 RevlogNG 还指出该文件的前 4 个字节将指示 Revlog 版本号和标志。虽然变更集 ID 目前只有 20 字节长，但它的实际字段长 32 字节，可能是为了将来扩展到更长的哈希值。

由于此选项不需要更改现有存储库，并且只涉及读取主索引的前 52-64 个字节，因此我可能会选择它。如果我在产品的早期阶段在它管理的任何存储库出现之前就抓住了这个需求，我会倾向于自定义文件方法，因为我可能会从存储库的开头创建和添加自己的元数据文件。

Answer 2

错误：存储库不相关消息来自mercurial/treediscovery.py：

base = list(base)
if base == [nullid]:
    if force:
        repo.ui.warn(_("warning: repository is unrelated\n"))
    else:
        raise util.Abort(_("repository is unrelated"))

base变量存储两个存储库的最后一个公共部分。通过给出推/拉检查的想法，我们可以假设存储库如果具有共同的根，则它们是相关的，因此从命令检查哈希值：

$ hg log -r "roots(all())"

出于我未知的原因 hg log -r 0 始终显示相同的根，但您可能会遇到FIRST_REPO保留SECOND_REPO历史记录的情况，但SECOND_REPO的明显0转数与SECOND_REPO不同FIRST_REPO 但 Mercurial 检查已通过。

您可能不会通过精心制作存储库来欺骗根检查，因为构建两个存储库看起来像这样（具有共同部分但根不同）：

0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ

不可能，因为这意味着您反转 SHA-256，因为每个后续哈希都取决于先前的值。