我需要将自定义元数据附加到通过 Mercurial 跟踪的源文件中。svn 属性命令正是我所需要的。
是否有提供类似于propset, propget,propdel等命令的 mercurial 扩展？
如果没有扩展，为什么不呢？
使用 Mercurial 时，自定义元数据是否有替代/更好的方法？
自定义元数据对其他人没有用吗？
扩展是非常需要但还没有写吗？
额外信息：如果有帮助。我正在跟踪的元数据是每个文件是否已经过代码审查、单元测试、qa'd 等。这些数据需要可跟踪，并且分支/克隆之间的合并不够细。
Mercurial 约定是将文件名.hg*放入存储库的根目录，并将它们用作（某种）字典以将文件名映射到属性值。例如，svn:eol-style使用.hgeol文件代替 hgeol 扩展名。
在跟踪代码审查的情况下，我建议编写另一个允许操作此元数据的扩展，并让该扩展以合并友好的格式存储其状态。
Mercurial 的理念是跟踪文件并且只跟踪文件。您甚至无法签入空文件夹，因为 Mercurial 不知道文件夹！
所以，这里是答案：
我找不到任何可以满足您需求的扩展程序。（当然你也可以自己写。）
Mercurialful 做你想做的事情的方法是将数据存储在一个平面文件中并使用一些脚本来处理它。:(
听起来您的公司已经有了一个经过深思熟虑的系统和良好的工程实践，所以我不会在这里迂腐，但是可以合理地论证您的方法除了损害可移植性之外没有任何作用。属性没有什么神奇的，我只是svn proplist -v .在你的树上运行一个，将它转储到隐藏文件中——比如.tracking——只是将它与你的普通文件显式合并。这并没有真正增加任何工作，因为无论如何您都必须合并属性。
我希望这对你有用！
我要为这个问题添加一个非常晚的准答案，因为它是很多很多使用 Mercurial 的人，包括我在内，都会问的问题——在使用其他工具之后，我们想要拥有并期望拥有的东西，比如svn 属性。
据我所知，Mercurial 没有这样的扩展。然而。
是的，Mercurial 的方式似乎是跟踪文件并且只跟踪文件。可能他们纠正这种扩展的方法是将必要的元数据放入 ...repo/.hg* 文件中。
好的。我一直在玩这个。在尝试编写工具之前，先手工做一些事情。
版本化 .hg 文件方法的主要弱点是，如果您检查非提示版本，例如“hg update -r OLD-VERSION”，您将获得元数据的旧版本。
因此，我认为关键可能是将元数据放入 ...repo/.hg* 文件中。
但是......大多数操作应该使用或基于此类文件的最新版本执行。即，我认为此类元数据文件“超越”了版本——即它们希望被版本化，但在理想情况下，您可能会将它们想象为覆盖在您可能已经签出旧版本的正常版本化文件上。
此外，在许多情况下，您希望单独处理此类元数据文件的分支。例如，想象一个文件，您试图在其中一起编写所有分支的描述。也许比较分支，例如“branch1.1 是 branch1 的更新版本”。您不希望该描述出现在任一分支上；或者，更确切地说，您希望它同时出现在两个分支上，并且您希望更改反映在两个分支上。
这种假定的扩展将在“hg cat -r tip ...repo/.hg-my-new-metadata”上运行。或者它会以某种方式覆盖文件的版本与超越元数据文件的正常版本。
我在使用 subrepos 方面取得了一些进展：
superrepo
files // normally-versioned-files <-- a subrepo
metadata // version transcending metadata <-- a subrepo
这使我可以查看最新的元数据以及旧版本的文件
它并不完全存在，因为检查超级存储库的特定版本可能会得到元数据子存储库的旧版本。但至少较新的版本在 subrepo 中。
还要注意的是，无论您将元数据放在相邻的子存储库中，还是将其保存在同一个存储库中（但在提示上操作），都有一个问题，您可以做
hg clone -r OLD-REVISION repo newrepo
这将在 OLD-REVISION 之后删除元数据。包括表示“OLD-REVISION 通过了所有测试”的元数据，即它将从可能适用于 OLD-REVISION 的后续版本中删除元数据。
hg 标签也会出现同样的问题。
有人可能会说“好吧，永远不要那样做”——永远不要剥离历史。不幸的是，这通常被推荐为“整理”存储库的一种方式。
Mercurial 似乎很难避免这种情况。