汞库识别 [英] Mercurial repository identification

问题描述

我需要能够唯一地标识Mercurial存储库，并将该标识符放置在克隆时包含的文件中.如果我可以将标识符放在.hg文件夹中的文件中，而不是简单地将普通文件添加到仓库中，那该怎么办?

我了解我可以从所提交的第一个更改中获得接近特定的标识符.我知道hgrc文件不能用于存储标识符，因为它没有被克隆.

所以，我的问题是:.hg文件夹中是否存在另一个可用来放置标识符的克隆文件?谢谢.

解决方案

从一读开始，您似乎希望能够确保该存储库的克隆是正确的存储库的克隆，而不是某些标准的-在冒名顶替者中.但是，如果您正在考虑使用的标识信息与其他所有信息都被克隆，那么冒名顶替者仍将通过此测试.您需要将该标识符分开，以便可以将其与克隆中的信息进行比较.

无论这是否是您的目标，.hg中克隆的任何文件都可能不需要编辑.您必须在.hg之外的回购的其他区域中添加一个要跟踪的文件.但是，您根本不需要一个额外的文件，因为更改集哈希不仅可以确定，而且可以确定，因此便于识别存储库的信息内置在该存储库中.本身.

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

> hg id -i -r0
89abf5502e3c

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

如果我对比较2个标识符的愿望是正确的，以便您或其他人知道存储库的克隆是真正的克隆而不是假的克隆，那么您将分别具有相同的changset ID，以便某人可以使用以上命令之一，以查看其克隆的ID并将其与您应该说的内容进行比较.这就像有多少个具有可下载可执行文件的网站在下载链接旁边显示哈希标识符，以便您可以自己对文件进行哈希处理并将结果与​​网站上的哈希进行比较.

编辑 关于您对此目的有何了解的评论

:

由于您需要能够从文件中读取文件，因此有两种选择:

在存储库根目录中跟踪的文件

除了创建自己的文件之外，您可能还会考虑一个文件:.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的文件格式， RevlogNG ，以及至少对于我自己的存储库中的2个，.hg\store\00changelog.i包含偏移量0x20(20字节长)的第一个变更集的哈希.可能，至少从Mercurial 0.9开始，它在所有存储库中都是相同的. RevlogNG还注意到该文件的前4个字节将指示Revlog版本号和标志.虽然变更集ID当前只有20个字节长，但它的实际字段为32个字节长，可能用于将来扩展为更长的哈希值.

由于此选项不需要更改现有存储库，仅涉及读取主索引的前52-64个字节，因此我很可能会使用它.如果我在产品的早期阶段就抓住了这一要求，而在它管理的任何存储库没有出现之前，我都会倾向于自定义文件方法，因为我很可能会在回购开始时就创建并添加了自己的元数据文件.

I need to be able to uniquely identify a Mercurial repository and have that identifier placed in a file that is included when cloned. If I can put the identifier in a file in the .hg folder that is preferable to simply adding a normal file to the repo.

I understand that I can get a near certain identifier from the first changes that are committed. I know that the hgrc file cannot be used to store the identifier, because it is not cloned.

So, my question is: Is there another file in the .hg folder that is cloned that I can use to put the identifier? Thanks.

解决方案

From first read, it sounds like you want to be able to make sure that a clone of the repository is a clone of the correct repository and not some stand-in impostor. However, if the identification information you're thinking of using is cloned with everything else, then an impostor would still pass this test. You'd need to keep that identifier separate so that it can be compared against information in the clone.

Whether that is your purpose or not, any file in .hg that is cloned you may not want to edit. You'd have to add a file to be tracked in the other areas of the repo, outside of .hg. However, you don't really need an extra file at all, as the changeset hash is not just near certain, but very certain, so the information for handily identifying a repository is built-in to the repository itself.

On the commandline, you can get either the short or full versions of the very first changeset's hash identifier:

> hg id -i -r0
89abf5502e3c

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

If I am correct about your desire to compare 2 identifiers so that you or someone else knows a clone of the repository is a true clone and not a false clone, you would have the same changset id available separately so that someone can use one of the above commands to see the id of their clone and compare it to what you say it should be. This is much like how many websites with downloadable executable files show a hash identifier next to the download link so that you can hash the file yourself and compare the result to the hash on the website.

Edit regarding your comment that sheds light on the purpose of this:

Since you need to be able to read it from a file, there are a couple options:

Tracked file in repository root

There is one file you might consider, other than creating your own: .hgtags.

hg tag -r0 ident

...would tag the very first revision, allowing you to use ident as a reference to that changeset rather than -r0. Mercurial always uses tag information from the latest version of .hgtags, no matter what changeset the working directory is updated to, but that may not matter to your app. hg tag appends a line such as this to the .hgtags file, creating the file if it doesn't exist:

a247494248c4b96a571bbd12e90eade3bf559281 ident

This is most handy if you don't have a tags files yet in your repos, because it will be the first line in the file for easy finding. You might think could simply write this file yourself, but then you'd still have to call hg to get the changeset id and again at some point for adding it to tracking and then committing: hg tag does all that for you.

If there is already the possibility of a tags file to consider, that's ok, too, because they tend to be relatively short and you just need to look for the 1 line that ends with your chosen tag name. Mercurial is designed for append-only operations to .hgtags, but everything would still work fine if you inserted the line for this tag as the very first line if .hgtags already exists because: 1. The tag will never be moved or removed. 2. You'll be using a tag name not already used in the file.

Reading hg's guts

There are files that normally only Mercurial itself touches deeper in .hg that can be read to get the first changeset's hash. I looked into Mercurial's File Formats, Revlog, and RevlogNG, and at least for 2 of my own repos, .hg\store\00changelog.i contains the first changeset's hash at offset 0x20 (20 byte length). Probably, at least since Mercurial 0.9, it will be the same in all repos. RevlogNG also notes the first 4 bytes of that file will indicate Revlog version number and flags. While the changeset id is only 20 bytes long currently, the actual field for it is 32 bytes long, probably for future expansion to a longer hash.

Since this option requires no alteration of existing repositories and only involves reading the first 52-64 bytes of the main index, it's the one I'd probably go with. If I was catching this requirement in the early stages of the product before any repos it manages were out in the wild, I would lean toward the custom file approach because I would probably have my own metadata file created and added from the beginning of the repo.

这篇关于汞库识别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！