我需要将自定义元数据附加到我的源文件中，并通过Mercurial进行跟踪。 svn属性 命令正是我所需的。
是否有一个类似于 propset, propget, propdel 的 Mercurial 扩展命令？
如果没有扩展，为什么？
在使用 Mercurial 时，是否有其他替代或更好的方法来处理自定义元数据？
自定义元数据是否对其他人有用？
这个扩展是否非常受欢迎但只是还没有被编写出来而已？
额外信息：如有帮助，我正在跟踪的元数据是每个文件是否经过了代码审查、单元测试、QA等。这些数据需要可追溯性，并且分支/克隆之间的合并不够精细。
.hg*的文件放置在仓库的根目录下，并将它们用作词典(某种类型)，以将文件名映射到属性值。例如，hgeol扩展使用.hgeol文件来代替svn:eol-style。Mercurial的哲学是跟踪文件而不是文件夹，甚至无法将空文件夹检入，因为Mercurial不知道文件夹存在！
所以，这里是答案：
我找不到任何可以满足你需求的扩展。（当然你可以自己编写）
按照Mercurial的方法，实现你想要的功能是将数据存储在一个平面文件中，并使用一些脚本来处理它。(不好意思)
看起来你已经有了一个非常成熟的系统和优秀的工程实践，所以我不会唠叨太多。但是我们可以合理地认为你的方法只会影响可移植性，属性并没有什么神奇的地方。你可以运行svn proplist -v .命令在你的目录上，将它导出到隐藏文件（如：.tracking），并显式地将其与普通文件一起合并。这样做并不会增加额外的工作量，因为您必须合并属性。
我希望这对你有帮助！
我要为这个问题添加一个非常晚的准答案，因为许多人，包括我在内，使用Mercurial时都会问这个问题 - 这是我们想要并且期望在使用其他工具（如svn属性）后拥有的东西。
据我所知，目前还没有这样的Mercurial扩展。
是的，Mercurial的方式似乎是跟踪文件和仅文件。也许编写这样的扩展的方法是将必要的元数据放入...repo/.hg*文件中。
好的。我一直在手动尝试，然后再尝试编写工具。
版本化.hg文件方法的关键弱点是，如果您检出非tip版本，例如“hg update -r OLD-VERSION”，则会得到旧版本的元数据。
因此，我认为关键是将元数据放入...repo/.hg*文件中。
但是...大多数操作应该使用或针对这些文件的最新版本执行。也就是说，我认为这些元数据文件“超越”版本 - 也就是说，它们想要被版本化，但在理想情况下，您可以将它们想象成覆盖在通常版本化的文件上，您可能已经检出了旧版本。
此外，在许多情况下，您希望处理此类元数据文件的分支。例如，想象一下一个文件，您正在尝试编写所有分支的描述。也许比较分支，例如“branch1.1是branch1的更近期版本”。您不希望该描述位于任何一个分支上；或者，更确切地说，您希望它同时位于两个分支上，并且您希望更改反映在两个分支上。
这样一个假设性的扩展程序将在“hg cat -r tip ...repo/.hg-my-new-metadata”上运行。或者它将以某种方式将文件的版本化版本与通常版本超越的元数据文件叠加在一起。
我已经在子仓库中取得了一些进展：
superrepo
files // normally-versioned-files <-- a subrepo
metadata // version transcending metadata <-- a subrepo
这使我能够在旧版本文件旁边检查最新的元数据。
它还不够完美，因为检出超级仓库的特定版本可能会得到元数据子仓库的旧版本。但至少新版本在子仓库中。
我还要注意的是，无论您将元数据放在相邻的子仓库中，还是将其保留在同一仓库中（但操作顶部），都存在一个问题，您可以执行
hg clone -r OLD-REVISION repo newrepo
这将剥离掉晚于OLD-REVISION的元数据。包括“OLD-REVISION通过了所有测试”的元数据，即它将从后续修订中剥离可能适用于OLD-REVISION的元数据。
在hg标记中也会出现同样的问题。
有人可能会说“好吧，永远不要那样做” - 永远不要剥离历史记录。 不幸的是，这经常被推荐作为“整理”存储库的一种方式。
似乎很难避免这种情况在Mercurial中发生。