Subversion oddity-svn信息版本高于项目文件夹上上次更改的版本

有些事我无法解释

我有一份我的项目的工作副本-完成svn更新（上面写着：更新到1895版），我知道这是最新的。当我在项目文件夹上执行

svn info

时，修订版是1895，但最后更改的修订版是1888

用乌龟检查日志显示1888年是最后一次修订，没有1895年的痕迹。1895年的

svn日志

为空，1895年和1888年之间的

svn diff

也为空，即无差异

我怎么会以一些没有真正改变任何东西的流氓修订而告终？它基本上是导致生成服务器（认为它在1888年）与我的MSBuild svversion任务（认为修订版是1895年）不同步

如有任何建议，我们将不胜感激

编辑：如果修订版始终显示整个存储库的最新修订版，这意味着SvnVersion MSBuild任务（使用SvnVersion.exe，但表现出类似的行为）等内容不会显示正确的修订版，因为当您有多个项目的单个存储库时，您将需要使用“上次更改的修订版”为您的版本号

---

因此，现在开始执行我自己的SvnLastChangedRev MSBuild任务。

这不是问题或奇怪之处。。。修订号适用于整个Subversion存储库，因此，由于存储库中其他地方的更改，修订号可能高于您正在使用的存储库分支中发生更改的最后修订号

---

要澄清的是，如果您承诺使用

trunk

，将存储库更改为第10版，然后

分支和
标记中的一系列更改将存储库更改为第1000版，那么第10版将是
trunk
文件夹的“最后更改版本”，但整个存储库的当前修订号将为1000。
我知道每个存储库的修订号都是全局的。但是，当我在存储库树下的某个层次结构级别的工作文件夹中执行更新时，我从未注意到它会全局更新为最新版本，仅更新为该路径的最新版本。@WimHollebrandse只有在签出/存储库的根目录下运行svn update时，才能全局看到更新的版本。Subversion永远不会更新父目录的元数据。事实上，这不是一个大问题，它是整个repo：如果您签出该修订版，您仍然可以获得该项目的正确代码副本，并能够再次构建它。如果您使用的是CruiseControl之类的东西，设置为仅基于更改生成，那么无论如何您都不会获得该项目的新版本（假设它是唯一签出的东西）。SvnLastChangedRev MSBuild任务有进展吗？因为我有一个类似的issue@James-是的，我在CodePlex上发布了一系列有用的MSBuild任务，其中包括SvnLastChangedRev任务。见：