Question

我需要将自定义元数据附加到通过Mercurial跟踪的源文件中。 svn properties命令正是我所需要的。

是否有一个mercurial扩展提供与propset，propget，propdel等类似的命令？

如果没有延期，为什么不呢？
使用Mercurial时是否有替代/更好的自定义元数据方法？
自定义元数据对其他人没用吗？这个扩展是非常需要的，但还没写好吗？

额外信息：如果有帮助的话。我正在跟踪的元数据是每个文件是否已经过代码审查，单元测试，qa'd等。这些数据需要是可追踪的，并且分支/克隆之间的合并不够精细。</ p>

Answer 1

Mercurial约定是将文件名.hg*放入存储库的根目录，并将它们用作字典（某种类型）将文件名映射到属性值。例如，hgeol扩展名使用.hgeol文件而不是svn:eol-style。

如果要跟踪代码审核，我建议您编写另一个允许操作此元数据的扩展程序，并让该扩展程序以合并友好格式存储其状态。

Answer 2

Mercurial的理念是您跟踪文件和仅文件。您甚至无法签入空文件夹，因为Mercurial不知道文件夹！

所以，这里是答案：

我找不到任何你想要的扩展名。（你当然可以写自己的。）
执行所需操作的Mercurialful方法是将数据存储在平面文件中，并使用一些脚本来处理它。：（

听起来你已经有了一个非常深思熟虑的系统和良好的工程实践在你的公司所以我不会在这里迂腐，但人们可以做出合理的论证，你的方法什么都不做，除了伤害可移植性。关于属性没有什么神奇之处，我只会在树上运行svn proplist -v .，将其转储到隐藏文件 - 类似于.tracking - 只需将其与普通文件明确合并即可。这并没有真正添加任何工作，因为无论如何你必须合并属性。

我希望这适合你！

Answer 3

我将为这个问题添加一个非常晚的准答案，因为很多很多人使用Mercurial，包括我在内，问我们想要拥有的东西，并期望在使用后其他工具如svn properties。

据我所知，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

这允许我查看最新的元数据以及旧版本的文件

它并不完全存在，因为检查特定版本的superrepo可能会获得旧版本的元数据subrepo。但至少新版本是在subrepo。

我还要注意，无论您是将元数据放在相邻的子库中，还是将其保存在同一个仓库中（但在提示上操作），都会出现问题

hg clone -r OLD-REVISION repo newrepo

这将比OLD-REVISION更晚地删除元数据。包括说“OLD-REVISION通过了所有测试”的元数据，即它将从可能适用于OLD-REVISION的更高版本中删除元数据。

hg标签也会出现同样的问题。

有人可能会说“好吧，永远不要那样做” - 永远不要剥夺历史。不幸的是，这通常被建议作为“整理”存储库的一种方式。

使用Mercurial似乎很难避免这种情况。

是否有类似svn propset的Mercurial扩展？

3 个答案: