颠覆：当修订号是连续的时，为什么“混合修订”？答案

【问题标题】：Subversion: why "mixed revisions" when revision numbers are sequential?颠覆：当修订号是连续的时，为什么“混合修订”？
【发布时间】：2012-06-30 22:01:46
【问题描述】：

一个例子：假设在svn update 之后我处于修订版10。如果我现在添加一个文件并执行提交，svnversion 将报告我处于混合修订版的状态；即10:11。但由于这些数字是按顺序排列的，显然在这两者之间没有任何其他提交。不能 subversion 从中推断出我的版本是最新的 (=HEAD)，所以我不需要运行另一个 svn update 来删除这种混合修订状态？

我意识到这没什么大不了的；我只是想知道我是否遗漏了一些特殊情况，上述推理可能不正确。

【问题讨论】：

我从来没有通过提交新文件意外地创建“混合修订”状态。然后我再次使用 TortoiseSVN 并且通常在项目根目录上执行提交操作。也许这样它就会发现整个事情都是最新的。

标签： svn

【解决方案1】：

Subversion 声称您修改的文件是 11 版，这让我感到有点惊讶，因为它们可能不是。如果其他人在您之前提交了版本 11，那么您的文件最终将是版本 12 或更高版本。

我猜原因是您的本地 subversion 不能声称您添加文件的版本是完整的 11 版，因为它还不确定。

【讨论】：

我在上面试图描述的场景是在我的“更新”和后来的“提交”之间没有人提交版本，并且由于版本号是按顺序排列的，因此颠覆应该能够推断出这一点。当然，如果有人在我之前做出了某些事情，那么我将获得第 12 版（或更高版本）并且“混合修订”状态是合理的。
但是你本地的 Subversion 不知道没有其他人已经提交了任何东西，而不与服务器通信。
你是说当我执行 Commit 时我的本地 Subversion 没有与服务器通信？
对不起，我一定是看错了你说的话。（要么这样，要么我使用 Git 太久了。）当然你是对的，客户端在提交时确实会与服务器通信。但我想它不一定知道其余文件的状态而不做svn update。
完全正确 :) 我的意思是，在这种特殊情况下，Subversion 实际上现在确实是其余文件的状态；它只是没有利用它。

【解决方案2】：

如果我正确理解了您的问题，我可以告诉您，您的工作副本几乎总是会有混合修订。这是因为不同的文件已在不同的修订版中提交并在那时发生了更改。您是否注意到某些文件（例如）显示修订版 10 和其他 25，但您仍处于 HEAD 修订版中。这是因为您的工作区包含文件和修订的附加元数据。

通常这根本不应该是一个问题，就我而言，它是 SVN 工作流程的一部分。我记得这在 SVN 文档中的某处进行了解释，但我现在似乎找不到它。如果我这样做，我会相应地编辑我的答案。

【讨论】：