由于从备份回滚，Subversion 工作副本比服务器更新答案

【问题标题】：Subversion working copy newer than server because of rollback from backup由于从备份回滚，Subversion 工作副本比服务器更新
【发布时间】：2009-11-07 15:07:13
【问题描述】：

所以，我的服务器管理员从备份中回滚了 subversion 服务器。我的工作副本是修订版 1534，但服务器现在是 1525，这会产生一些问题：

$ svn up
svn: Revision 1534 not found

当然，总是可以选择进行干净的结帐，但有没有更简单的方法让我的本地工作副本与服务器同步？

【问题讨论】：

您的修改是顺便提交的吗？如果没有，您可能会遇到一些问题，必须先恢复（确保先复制修改后的文件！）。不过，我不是 100% 确定。
它们已提交，但现在由于回滚而在服务器上丢失。我的磁盘上有更改，还有一个额外的副本，可以再次应用更改。
好吧，由于似乎没有任何工作，您可能需要再次检查所有内容：/ 之前，如果您还没有，您仍然可以进行最后一次检查以查看所有内容是否实际上都在服务器上直到修订版 1525 (svn log -r HEAD <URL>)，正如您所期望的那样......
是的，直到 1525 的所有内容都在服务器上，但缺少 1526 到 1534，因为备份的版本是 1525。

标签： svn

【解决方案1】：

我刚刚发现有办法做到这一点 - 只要你的机器上有一个合理的最新版本 Tortoise SVN 并且你的工作副本由这个版本维护（即简单地安装最新的 Tortoise SVN 不会工作）。

进入顶级目录并删除 .svn 文件夹 - 这将删除所有本地缓存的 SVN 信息。注意： .svn 文件夹仅出现在顶级签出文件夹中并且是隐藏的。

然后在现有本地副本的顶部结帐。然后 Tortoise 将重新版本文件，重要的是不理会您修改过的文件。然后您就可以毫无问题地提交更改和更新。

【讨论】：

这会导致每个现有文件都被重新“版本化”，并为我完美地工作，为我节省了数小时的结帐时间。没有其他工作。谢谢@Martin

【解决方案2】：

您的工作副本没有死。是的，您可以再次结帐...但在我的情况下，它超过 20GB，并且需要很长时间。

我只需要处理几个文件，这些文件在工作副本上比在服务器存储库上更新（也是由于回滚）。

您可以做的是快速 SPARSE CHECKOUT（仅签出一个目录）到临时位置。接下来，从这个部分签出位置，获取隐藏的 .svn 文件（该目录的历史记录），并将其放置到有问题的工作副本（包含更新的历史记录）中。

这不会影响您的源文本文件，只会为它们提供较旧但存储库匹配的历史记录。自回滚时间以来的 Commit 文本已丢失，但很容易重新键入。

在我这样做之后，svn 工作正常，并显示了自回滚时间以来我所做的所有更改。当然，您必须再次提交这些更改。

【讨论】：

【解决方案3】：

您必须再次结帐。

您的工作副本已失效。

您的管理员真的应该尝试在每次提交时同步他们的备份或通过挂钩脚本将提交存储为转储

如果您使用的是 Windows/TortoiseSVN，请查看下面的Martins answer。

【讨论】：

可悲的是，这实际上是计划中的停机时间，是一次没有成功的升级。我没有收到通知，他们在进行备份后让服务器存活了 2 多个小时...... :(
也许您的管理员应该学习一些 svnbasics .. 将他们指向 subtrain.tigris.org
看看@Martin 的回答，它对我有用，并帮助我避免了大量的重新结帐。
@moodboom：我明白你的意思，但这是 TortoiseSVN 唯一的行为。我更新了指向马丁的答案

【解决方案4】：

svn up -r HEAD

或指定另一个特定的版本应该可以工作。

【讨论】：

您是否尝试过使用特定的修订号？ svn up -r 1525?
这不能工作，因为 svn up（在服务器上）总是会在拉取更新之前尝试比较，但是没有这样的修订。

【解决方案5】：

除了进行新的结帐并将未提交的更改手动合并到新的工作副本中之外，我看不到任何解决方案。基本上，您的工作副本来自另一个现实——服务器升级实际工作的现实——而且我认为 Subversion 没有任何解决此问题的规定。

【讨论】：

【解决方案6】：

几周前我们也发生了同样的事情。我重命名了我的主干文件夹，检查了一个干净的主干，然后手动将崩溃日期及以后的所有更改文件复制到我的主干中，以便我可以重新提交更改。

【讨论】：

是的，我最终也是这样做的。

【解决方案7】：

至少对于 svn 1.8 svn更新-r 1525 （正如 Michael Hackner 所建议的）将起作用，并将保持本地更改的文件不受影响。几分钟前遇到了类似的问题，用这个命令解决了。

有待验证在 1525 和 1531 之间提交的文件会发生什么。

【讨论】：