在我的构建系统中,每次运行新构建时,我都会将当前提交的修订和哈希信息保存在几个变量中,并在我的源代码中使用它们而不会出现问题。例如,窗口标题的格式类似于“NAME-REVISION-HASH”。
唯一的问题是,有时人们通过下载不包含提交信息的标准源来构建项目,因此修订和哈希都是 0ed。
可以做些什么来防止这种情况发生?添加包含此类信息的单独文件违背了使用分布式版本控制系统的优势,因为它需要在每次提交时手动更新......
有没有办法让没有 dvcs 的人获得正确的修订和哈希信息?
在我的构建系统中,每次运行新构建时,我都会将当前提交的修订和哈希信息保存在几个变量中,并在我的源代码中使用它们而不会出现问题。例如,窗口标题的格式类似于“NAME-REVISION-HASH”。
唯一的问题是,有时人们通过下载不包含提交信息的标准源来构建项目,因此修订和哈希都是 0ed。
可以做些什么来防止这种情况发生?添加包含此类信息的单独文件违背了使用分布式版本控制系统的优势,因为它需要在每次提交时手动更新......
有没有办法让没有 dvcs 的人获得正确的修订和哈希信息?
添加包含此类信息的单独文件会破坏使用分布式版本控制系统的优势
怎么回事?“人们通过下载标准源来构建项目......”因为他们没有任何 VCS,还有一个文件“无视”任何东西
因为它需要在每次提交时手动更新
什么?带有专门准备的关键字(或文本常量)的自动提交文件不是一个大问题,至少对于 Mercurial 而言
您可以使用git describe
来获取唯一的字符串,然后您可以将其包含在您的构建中。git
它自己这样做是为了设置它的版本(git version
这里返回git version 1.8.2.rc1.19.g443d803
,即 1.8.2-rc1 + 19 次提交,最新提交有 SHA1 443d803e0dacd0a1c6700503689f3cd95751aba1;git describe
返回v1.8.2-rc1-19-g443d803
)。
从 SCCS 时代开始,就出现了扩展$Id:$
和其他关键字结构的习惯,这在 VCS 只处理单个文件的时代非常有意义;今天是退化的(并且git
根本不做任何“关键字扩展”)。
从另一个问题:
到目前为止,Git 中已经支持 $Id:$。要为文件 README启用它,您可以将“README ident”放入.gitattributes。支持文件名上的通配符。有关详细信息,请参阅man gitattributes。
如果您使用 Mercurial 生成档案,它已经为您处理好了。该hg archive
命令为 Web UI tarball / zip 下载提供动力,它自动包含一个.hg_archival.txt
文件,如下所示:
repo: 0339f7b37c3416248e4e0b183a481aa40ade150e
node: 0339f7b37c3416248e4e0b183a481aa40ade150e
branch: default
latesttag: null
latesttagdistance: 1
因此,您的代码可以使用首先检查本地存储库以获取版本信息的逻辑,如果不存在则查找.hg_archival.txt
文件。如果您要标记发布,则 and 特别方便latesttag
。latesttagdistance
您可以使用它们来构建对人类和 DVCS 都有用的版本字符串,例如:
2.0.1-5-40ade150e
可以理解为“自 2.0.1 版以来的五次提交,哈希值为 40ade150e”