代码之家 › 专栏 › 技术社区 › Isaac

基于mercurial提交的单调递增版本号

versioning mercurial

Isaac · 技术社区 · 15 年前

当我对应用程序的代码使用Subversion时,我可以附加一个句点和 svnversion 对版本号创建一个唯一且单调递增的版本号,同时也保证任何签出相同版本的代码都会生成相同的版本号。

在Mercurial中,由于版本号在克隆之间不一定一致,因此本地版本号不适合。散列是适当唯一和一致的,但不会创建单调递增的数字。如何根据Mercurial存储库提交生成一个合适的编号附加到版本号上?

编辑: 我有一个应用程序具有自动更新检查功能,它依赖于一个版本号,该版本号是一个由句点分隔的整数链,用于确定版本是否更新。在两次发布之间,我有一些用户尝试测试构建已经变得很常见了。通常,这些构建会解决测试人员遇到的问题,因此测试人员停止使用发布的版本并切换到测试构建。我将附加组件添加到版本号的最初目标是:

确保在发布时,那些使用测试构建的版本也会自动显示更新。
能够很容易地分辨测试人员是否正在使用最新的测试构建

例如,0.5.0版本的版本号为0.5.0.410;在0.5.1发布之前,存在版本号为0.5.1.411、0.5.1.420和0.5.1.421的测试版本;然后,0.5.1版本的版本号为0.5.1.423。

4 回复 | 直到 14 年前

Community CDub 8 年前

AS @Matthew 也就是说,您不能期望跨克隆的版本号之间的任何比较都有任何价值。但是,如果您的应用程序基于单个存储库,并且总是从任何克隆中推回该中央存储库,那么只要您坚持使用单个分支,就可以依赖该单个中央版本号。

本质上,如果您使用Mercurial的方式类似于Subversion,即使用单个中央存储库,则可以将版本号用作应用程序构建上的标记。

希望这有帮助。

Igor Brejc 14 年前

这就是Fog Creek如何使用Mercurial+其他一些建议进行构建版本控制的方法: http://kiln.stackexchange.com/questions/2194/best-practice-generating-build-numbers

Matthew Flaschen 15 年前

你的头上钉了很多钉子。使用任何单调增加的局部修订号可能与分布性质相冲突。围绕这个基本设计决策没有优雅的方式。

Isaac 15 年前

仍然需要一些东西来尝试维护各种开发构建的顺序和匹配,我首先尝试使用上一次提交的Unix时间戳:

REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ')

然而,这是令人讨厌的长(10位数)。(当然,它不能保证是唯一的,但是在我是唯一开发者的项目中,同一秒两次提交的概率基本上是0;事实上,在一分钟内两次提交的概率基本上是0。)

由于“基本”版本号(附加此版本号的部件)仅在标记的发布后立即更改,因此我最终使用的是提示和最新标记的祖先之间的分钟数:

HG_LAST_TAG_TIMESTAMP=$(hg log -r "$(hg log -r '.' --template '{latesttag}')" --template "{date|hgdate}\n" | cut -f1 -d' ')
HG_TIP_TIMESTAMP=$(hg log -r '.' --template "{date|hgdate}\n" | cut -f1 -d' ')
REV=$(( ($HG_TIP_TIMESTAMP - $HG_LAST_TAG_TIMESTAMP) / 60 ))

( 编辑使用 tip 是一个错误,因为它指的是对任何分支的最新承诺;使用 log -r '.' 指工作副本所依据的修订。)