2

几周前，我们的免费增值版 subversion 主机向我们发送了一条消息，说我们超出了我们的大小限制。经过几次尝试解决这个问题（并意识到如果不进行转储->加载循环和修剪，就不可能缩小存储库），我们决定是时候迁移到具有更宽松大小限制的新主机了（并迁移同时 git。）

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

这一切都奏效了——经过一个涉及主机帮助的漫长过程，我已经成功转储->重新加载了我们的存储库，它处于修订版 1。

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

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

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

我意识到我可以签出一个新的工作副本——但同样，我们有一些本地编辑，如果可能的话，希望将它们整合起来。

4

3 回答 3

0

您最安全的选择可能是创建一个带有更改的补丁（或多个补丁 - 如果我们正在谈论多个工作副本中的更改） - 这可以“离线”完成，而无需联系存储库。然后检查一个新的工作副本并将补丁应用到它。

您创建一个补丁svn diff > patch.diff并使用svn patch.

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

于 2012-05-29T17:06:16.283 回答
0

从冲突文件夹中删除隐藏的 .svn 文件并更新到 HEAD。它将保留本地更改。

于 2012-10-31T02:36:58.303 回答
0

使用较新版本的 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;
于 2014-03-27T16:12:40.677 回答