基于Mercurial Commits的单调增加版本号

时间:2010-03-21 06:30:37

标签: mercurial versioning

当我使用subversion作为应用程序的代码时,我可以将svnversion的句点和结果附加到版本号,以创建唯一且单调递增的版本号,并且还可以保证任何检查-out相同版本的代码将生成相同的版本号。

在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 个答案:

答案 0 :(得分:6)

正如@Matthew所述,您不能指望克隆之间的版本号之间的任何比较都具有任何价值。但是,如果您将应用程序基于单个存储库并始终从任何克隆返回到该中央存储库,那么只要您坚持使用单个分支,就可以依赖该单个中央版本号。

基本上,如果您以模仿Subversion的方式使用Mercurial,即使用单个中央存储库,则可以使用版本号作为应用程序构建的标记。

希望这有帮助。

答案 1 :(得分:5)

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

答案 2 :(得分:4)

你几乎击中了头部。使用任何单调增加的本地修订号可能会与分布式性质发生冲突。围绕这一基本设计决策没有优雅的方法。

答案 3 :(得分:4)

仍然需要尝试维护各种开发构建的排序和匹配,我首先尝试使用上次提交的unix时间戳:

REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ')
然而,这是令人讨厌的长(10位数)。 (当然,它不能保证是唯一的,但在我是唯一开发人员的项目中,同一秒内两次提交的概率基本上为0;实际上,两次提交的概率在1分钟内彼此基本上都是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 '.'指的是工作副本所在的修订版本基础的。)