2009-12-07 60 views
11

有些事情正在进行我无法解释。颠覆奇怪 - svn信息修订版本比上次更改项目文件夹上的版本更高

我有我的项目的工作副本 - 完成svn更新(其中说:更新到修订1895年),我知道这是最新的。当我对项目文件夹执行svn info,修订1895年是的,但最近修改的版本是1888年

检查使用TortoiseSVN日志显示1888年的最后一次修订,没有一丝1895. 1895年的svn log是空的,1895年至1888年间的svn diff也是空的,即。没有区别。

我是怎么得到一些没有真正改变什么的流氓修正?它基本上导致构建服务器(认为它是在1888年)与我的MSBuild SvnVersion任务不同步(认为修订版本是1895年)。

任何建议表示赞赏。

编辑:如果修改将始终显示整个库中的最新版本,这意味着像svnversion,如果MSBuild任务的事情(使用svnversion.exe,但表现出类似的行为)不显示时正确的版本你有一个多个项目的单一存储库,你需要使用“Last Changed Rev”作为你的版本号。

因此,现在滚动我自己的SvnLastChangedRev MSBuild任务。

+0

实际上这不是一个大问题,它是整个回购:如果您签出该修订,您仍然会得到正确的代码副本该项目,并能够再次构建它。如果您使用的是CruiseControl等设置,仅建立在更改上,那么您无法为该项目获取新版本(假设它是唯一签出的)。 – gregmac 2009-12-31 00:30:48

+0

你有没有得到任何与你的SvnLastChangedRev MSBuild任务?因为即时通讯有类似的问题 – 2013-08-07 11:55:29

+1

@詹姆斯 - 是的,我已经在CodePlex上发布了一堆有用的MSBuild任务,其中包括SvnLastChangedRev。请参阅:http://zealanditmsbuild.codeplex.com/ – 2013-08-28 13:58:10

回答

20

这不是一个问题或奇怪的问题......版本号适用于整个Subversion版本库,因此版本号可能会更高,这是因为版本库中其他地方的更改比最后一次版本号更改在您工作的存储库的分支中。为了说明,如果您承诺trunk,将版本库带到修订版本10,然后branchestags中的一系列更改将版本库带到修订版本1000,那么10将成为“最后更改的版本” trunk文件夹,但整个存储库的当前修订版本号将为1000.

+0

我知道每个存储库的修订号都是全局的。但是当我在一个工作文件夹中执行更新时,这个工作文件夹是存储库树中的一些层次结构级别,我从来没有注意到它会在全局范围内更新到最新的修订版本,只是最新的版本。 – 2009-12-07 09:42:34

+0

@WimHollebrandse只有在检出/存储库的根目录下运行svn update时,才会在全局中看到更新的修订版本。 Subversion永远不会更新父目录的元数据。 – 2012-01-04 07:47:18