Question

几个星期前，我们的免费增值颠覆主机向我们发送了一条消息，告知我们超出了我们的规模限制。经过几次尝试解决这个问题（并且意识到在不进行转储 - >加载循环和修剪事情的情况下缩小存储库是不可能的），我们决定是时候迁移到具有更宽松的大小限制的新主机（和同时迁移到git。）

然而在此期间，我们被锁定为“只读”访问 - 这是不幸的，因为有一些重要的本地更改尚未签入。所以我决定采取严厉的措施并删除旧的服务器修订通过dump-＆gt;加载循环方法让我们重新开始工作，这样我们就可以让我们的本地修改工作了。在对所有内容进行本地备份之后，我实际上抛弃了除最新版本（r525）之外的所有内容。

这一切都奏效了 - 经过一个涉及主持人帮助的漫长过程，我已成功转储 - >重新加载我们的存储库，并且它是在修订版1中。

但是，现在我们的客户拒绝更新我们现有的工作副本，因为他们认为他们正在修订525版的副本：

svn: A reported revision is higher than the current repository HEAD revision.

所以问题是：是否有可能“修复”我的工作副本以认为它是修订版1？

我意识到我可以签出一份新的工作副本 - 但是，我们还会进行一些本地编辑，如果可能的话，我希望将这些内容编辑好。

Answer 1

你最安全的选择可能是创建一个补丁（或几个补丁 - 如果我们正在谈论多个工作副本的变化）和变化 - 这可以“脱机”完成，而无需联系存储库。然后查看一个新的工作副本并将补丁应用到它。

您使用svn diff > patch.diff创建了一个补丁，并将其应用于svn patch。

关于二进制文件的问题：您可以编写一个脚本，以递归方式将修改后的二进制文件复制到新的工作副本。您可以使用svn status创建已修改文件的列表，然后按扩展名或其他属性对其进行过滤。

Answer 2

从冲突的文件夹中删除隐藏的.svn文件，然后更新为HEAD。它将保持当地的变化。

Answer 3

对于较新版本的Subversion，你可以使用sqlite来修改工作副本数据库，这是相当危险的，你可能完全破坏了。如果你想试试这里是怎么做的。

首先找出远程存储库中的最新修订版本：

$ svn info https://example.com/svn/project/trunk/
Path: trunk
URL: https://example.com/svn/project/trunk
Repository Root: https://example.com/svn
Repository UUID: fdecad78-55fc-0310-b1b2-d7d25cf747c9
Revision: 86002 <-- This is the value you want
Node Kind: directory
Last Changed Author: user@example.com
Last Changed Rev: 49367
Last Changed Date: 2008-05-23 17:01:34 +0100 (Fri, 23 May 2008)

然后编辑sqlite DB并将修订版更改为存储库中最新的版本：

cd .svn
$ sqlite3 wc.db 
SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> update nodes set revision = 86002 where revision > 86002;
sqlite> .exit
$ cd ..
$ svn up
Updating '.':
At revision 86002.

如果在项目中进行了最近的提交，则可能还需要运行此SQL：

update nodes set changed_revision = 86002 where changed_revision > 86002;

Subversion：如何在转储 - >加载周期后修复工作副本

3 个答案: