由于从备份回滚,子版本工作副本比服务器更新

你必须再次退房。

你的工作副本已经死了。

管理员真的应该尝试在每次提交时同步其备份,或者通过hook脚本将提交存储为转储。

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

有一种方法可以做到这一点,我刚刚发现-只要您的机器上有一个合理的最新版本的Tortoise SVN,并且您的工作副本是由这个版本维护的(即简单地安装最新的Tortoise SVN是行不通的)。

进入顶层目录并删除.svn文件夹-这将删除所有本地缓存的svn信息。注意:.svn文件夹只显示在顶级签出文件夹中,并且是隐藏的。

然后在现有本地副本的顶部签出。Tortoise将重新版本这些文件,重要的是将修改后的文件单独保存。然后您就可以提交更改和更新,而不会出现任何问题。

你的工作副本还没死。是的,你可以再结账…但在我的情况下,这超过20GB,需要很长时间。

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

您可以做的是快速稀疏签出(仅签出一个目录)到临时位置。接下来,从这个部分签出位置,获取隐藏的.svn文件(该目录的历史记录),并将其放置到有问题的工作副本(保存较新的历史记录)。

这不会影响您的源文本文件,只会使它们更旧,但会使存储库匹配历史记录。回滚时间后的提交文本将丢失,但很容易重新键入。

在我这样做之后,SVN工作得很好,显示了自回滚时间以来所做的所有更改。当然,您必须再次提交这些更改。

svn up -r HEAD

或者指定另一个特定的修订应该有效。

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

几周前同样的事情发生在我们身上。我重新命名了我的主干文件夹,签出了一个干净的主干,然后手动将崩溃日期及之后的所有更改文件复制到主干中,这样我就可以重新提交这些更改。

至少对于SVN 1.8 SVN更新-R 1525 (正如迈克尔·哈克纳建议的那样)会起作用,并且会保持本地更改的文件不变。几分钟前遇到了类似的问题,并用这个命令解决了它。

核实1525至1531年间提交的文件发生了什么。