有像 svn propset 这样的 Mercurial 扩展吗？
我需要将自定义元数据附加到通过 Mercurial 跟踪的源文件中。 svn properties 命令正是我所需要的。
是否有一个 Mercurial 扩展提供类似于 propset、propget、propdel 等命令？
如果没有扩展，为什么不呢？
使用 Mercurial 时是否有替代/更好的自定义元数据方法？
自定义元数据对其他人没有用吗？
扩展是否非常需要但尚未编写？
额外信息：如果有帮助的话。我跟踪的元数据是每个文件是否经过代码审查、单元测试、质量保证等。这些数据需要可追踪，并且分支/克隆之间的合并不够细粒度。
I need to attach custom metadata to my source files that at tracked via Mercurial. The svn properties commands are exactly what I need.
Is there a mercurial extension that provides commands similar to propset, propget, propdel, etc?
If there isn't an extension, why not?
Is there an alternative/better approach for custom metadata when using Mercurial?
Is custom metadata not useful to anyone else?
Is the extension dearly desired but just not written yet?
extra info: If it helps. The metadata I'm tracking is whether each file has been codereviewed, unittested, qa'd, etc. This data needs to be traceable and merges between branches/clones aren't fine grained enough.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Mercurial 的理念是您跟踪文件并且仅跟踪文件。您甚至无法签入空文件夹，因为 Mercurial 不了解文件夹！
所以，答案如下：
我找不到任何可以满足您要求的扩展。 （当然，您可以编写自己的扩展。）
执行您想要的操作的 Mercurialful 方法是将数据存储在平面文件中并使用一些脚本来处理它。 :(
听起来你已经有了一个经过深思熟虑的系统并且很好贵公司的工程实践，所以我不会在这里对此迂腐，但人们可以提出一个合理的论点，即你的方法除了损害可移植性之外没有任何作用。属性没有什么神奇的，我只是运行一个 svn proplist -v 。 . 在你的树上，将其转储到隐藏文件 - 类似
.tracking- 只需将其与你的普通文件显式合并即可，因为你已经完成了。无论如何，我希望这对你有用！
Mercurial's philosophy is that you track files and only files. You can't even check in an empty folder because Mercurial doesn't know about folders!
So, here are the answers:
I can't find any extension that does what you want. (You can write your own of course.)
The Mercurialful way to do what you want is to store the data in a flat file and use some scripts to process it. :(
It sounds like you've got a pretty well thought out system in place and good engineering practice at your company so I won't be pedantic here about it, but one can make a reasonable argument that your method does nothing except hurt portability. There's nothing magical about properties, I would just run an
svn proplist -v .on your tree, dump that to hidden files -- something like.tracking-- just explicitly merge it along with your normal files. This doesn't really add any work since you have to merge properties anyway.I hope that works for you!
Mercurial 约定是将文件名
.hg*放入存储库的根目录中，并将它们用作字典（某种类型）以将文件名映射到属性值。例如，hgeol 扩展使用 .hgeol<，而不是svn:eol-style/a> 文件。在跟踪代码审查的情况下，我建议编写另一个允许操作此元数据的扩展，并让该扩展以合并友好的格式存储其状态。
The Mercurial convention is to put files name
.hg*into the root of the repository, and use them as dictionaries (of some kind) to map file names to property values. For example, instead ofsvn:eol-stylethe hgeol extension uses a .hgeol file.In case of tracking code review, I'd recommend to write another extension that allows manipulation of this metadata, and have that extension store its state in a merge-friendly format.
我要为这个问题添加一个非常晚的准答案，因为这是一个很多很多使用 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”上运行。或者它会以某种方式用超越元数据文件的正常版本覆盖文件的版本。
我在使用子存储库方面取得了一些进展：
这使我可以检查最新的元数据以及旧版本的文件。
它并不完全存在，因为检查超级存储库的特定版本可能会获得元数据子存储库的旧版本。但至少较新的版本位于子存储库中。
我还要注意的是，无论您将元数据放在相邻的子存储库中，还是将其保留在同一个存储库中（但在提示上操作），都存在一个问题，您可以这样做，
这将删除 OLD-REVISION 之后的元数据。包括表示“旧版本通过了所有测试”的元数据，即它将从可能适用于旧版本的后续版本中删除元数据。
hg 标签也会出现同样的问题。
有人可能会说“好吧，永远不要这样做”——永远不要剥夺历史。不幸的是，这通常被推荐作为“整理”存储库的一种方法。
Mercurial 似乎很难避免这种情况。
I'm going to add a really late quasi-answer to this question, since it is one that many, many, people using Mercurial, including me, ask - something we want to have, and expect to have, after using other tools like svn properties.
As far as I can tell, there is no such extension for Mercurial. yet.
Yes, the Mercurial way seems to be to track files and only files. And it might be that they way to right such an extension is to put the necessary metadata into ...repo/.hg* files.
OK. I've been playing around with that. Doing stuff by hand, before trying to write tools.
The key weakness of the versioned .hg files approach is that if you check out a non-tip version, e.g. "hg update -r OLD-VERSION", you get an old version of the metadata.
I think the key thing, therefore, may be to put the metadata in ...repo/.hg* files.
But... most operations should be performed with or upon the latest version of such files. I.e. I think such metadata files "transcend" versions - i.e. they want to be versioned, but in an ideal situation you might imagine them as overlaid upon the normally versioned files that you may have checked out an older version of.
Moreover, in many cases you want the branching of such metadata files to be handled separately. E.g. imagine a file where you are trying to write a description of all branches, together. Perhaps comparing branches, like "branch1.1 is a more recent version of branch1". You don't want that description to be on either branch; or, rather, you want it to be on both brancges, at the same time, and you want changes to be reflected on both branches.
Such a putative extension would either operate on "hg cat -r tip ...repo/.hg-my-new-metadata". Or it would somehow overlay the versioned of the files with the normally version transcending metadata files.
I have made some progress on doing this with subrepos:
this allows me to check out the latest metadata alongside an older version of the files
It's not quite there, because checking out a particular version of the superrepo may get old versions of the metadata subrepo. But at least the newer versions are in the subrepo.
Let me also note that, whether you put the metadata in a neighboring subrepo, or keep it in the same repo (but operate on the tip), there is a problem that you can do
This will strip out metadata later than OLD-REVISION. Including the metadata that says that "OLD-REVISION passed all of the tests", i.e. it will strip out metadata from a later revision that might apply to OLD-REVISION.
This same problem happens with hg tags.
One might say "well, never do that" - never strip out history. Unfortunately, that is often recommended as a way of "tidying up" the repository.
It seems hard to avoid this with Mercurial.