4

我们有一个受 Mercurial 版本控制的 Java 应用程序。我们正在努力在应用程序中实现版本控制模式，我想知道 TortoiseHG 如何帮助解决这个问题。是否可以在提交时执行诸如增加构建版本之类的操作，还是必须由开发人员自行决定？我们当前的计划包括在推送到 UAT 时为每个版本号创建书签。

4

2 回答 2

9

原则上，您必须在 TortoiseHg 之外执行此操作 — Mercurial（以及 TortoiseHg）的工作是保持工作副本的状态与单击“提交”时完全相同。

不过，您可能会得到一些帮助：TortoiseHg 可以使用pre-commit hook触发这个“外部”动作。这是在运行之前hg commit运行的脚本，并且该脚本有机会更改文件。

当您尝试实施这样的方案时，请记住 Mercurial 是一个分散的版本控制系统（这应该不足为奇......），因此人们在本地进行提交而不与中央服务器通信。因此，无法保证版本号不被其他人使用。唯一的解决方法是使用变更集哈希作为版本“编号”，但是您不会得到很好的递增数字。但是，如果您有一个集中式构建服务器，那么您可以让它增加版本号，然后回到一个简单的集中式世界观。

最后，让我提一下，Mercurial 有一个latesttagdistance模板关键字，它对集中式构建机器非常有帮助：它计算到最新标签的距离，并且这个距离在构建机器上通常是单调递增的。像这样使用它

hg parents --template "{latesttag}+{latesttagdistance}-{node|short}"

有关更多灵感，请参阅Mercurialsetup.py文件。

于 2012-05-24T19:58:22.777 回答
3

最好让构建系统将当前版本标识符插入到您的分发存档和/或文件名中。

第一个问题是，如何获取这个版本标识符。基本上有三种方式：

  1. 通过让构建服务器发出hg id命令来找出构建错误。
  2. 通过在 Mercurial 存储库配置中配置version一个由钩子填充的文件。changegroup
  3. 通过拥有一个version使用关键字扩展名填充的文件。（不建议！）

第一种方法直接从 Mercurial 中提取信息，这对开发人员几乎不需要任何设置。缺点是它将构建系统与特定版本控制系统的存在紧密结合。

第二种方法保持独立于存储库系统，并且如果您从源存档构建，或者如果您想手动指定版本标签，它将保持可用。缺点是它确实需要你设置一个钩子，但是由于构建机器通常是专门配置的中央服务器，这应该不是一个大问题。

为了完整起见，我提到了第三种方法，但我认为普遍认为你真的想避免这种机制。

最好采用 1 和 2 的混合方法，首先尝试方法 2，然后在version找不到文件时使用方法 1。为了更好地支持hg archive源导出，您还可以检查.hg_archival.txt文件。

第二个问题是，您对内部版本号使用什么样的值：

  1. 版本标识符（来自hg id -i）。
  2. 本地修订号（来自hg id -n）。
  3. 使用latesttagand的标识符latesttagdistance，请参阅 Martin 的答案。

第一个的优点是它相当简单并且唯一地标识了所构建的确切版本。虽然它不是很可读，并且不能从哈希中得出相对年龄。

第二个有一个递增的数字，但是这个数字仅适用于构建机器的存储库，因此您应该为开发人员提供一种方法来循环该数字以获取变更集哈希 id，否则它将毫无用处。

我个人特别喜欢的第三种方法，它使用标签和距离以非常易于阅读的方式提供时间信息，并另外指定确切修订的节点 ID。不过还是比较长的。

于 2012-05-25T12:08:01.210 回答