因此,我的服务器管理员从备份中回滚了subversion服务器。 我的工作副本是修订版1534,但服务器现在是1525,这会产生一些问题:
$ svn up
svn: Revision 1534 not found
当然,总是可以选择进行干净的结账,但是有更简单的方法让我的本地工作副本与服务器同步吗?
答案 0 :(得分:2)
有一种方法可以做到这一点我刚刚发现 - 只要你的机器上有一个合理的最新版本Tortoise SVN,你的工作副本就是由这个版本维护的(即只需安装最新的Tortoise SVN即可工作)。
进入顶级目录并删除.svn文件夹 - 这将删除所有本地缓存的SVN信息。注意:.svn文件夹仅出现在顶级检出文件夹中并被隐藏。
然后在现有本地副本的顶部结帐。然后,Tortoise将重新编辑文件,重要的是保留修改后的文件。然后,您就可以毫无问题地提交更改和更新。
答案 1 :(得分:2)
您的工作副本不是死的。是的,你可以再次结账......但在我的情况下超过20GB,需要很长时间。
我需要处理一些文件,这些文件在工作副本上比在服务器存储库上更新(也是由于回滚)。
您可以做的是快速SPARSE CHECKOUT(仅检出一个目录)到临时位置。接下来,从这个部分结帐位置,您获取隐藏的.svn文件(该目录的历史记录),并将其放入有问题的工作副本(包含较新的历史记录)。
这不会影响您的源文本文件,只会使它们更旧,而是存储库匹配历史记录。回滚时间丢失后的Commit文本,但很容易重新键入。
在我这样做之后,svn运行良好,并显示了自回滚时间以来我所做的所有更改。当然,您必须再次提交这些更改。
答案 2 :(得分:1)
svn up -r HEAD
或指定其他特定修订版应该有效。
答案 3 :(得分:1)
你必须再次结账。
你的工作副本已经死了。
您的管理员应该尝试在每次提交时同步备份或通过钩子脚本将提交存储为转储
如果您使用的是Windows / TortoiseSVN,请查看下面的Martins answer。
答案 4 :(得分:0)
除了进行新的结帐外,我无法看到任何解决方案,并手动将未提交的更改合并到新的工作副本中。基本上,你的工作副本来自另一个现实 - 服务器升级实际工作的一个 - 我不认为Subversion有任何修改这个的条款。
答案 5 :(得分:0)
答案 6 :(得分:0)
至少对于svn 1.8 svn update -r 1525 (正如迈克尔·哈克纳所建议的那样)将起作用并保持本地更改的文件不受影响。几分钟前经历过类似的问题并用这个命令解决了。
要验证1525和1531之间提交的文件会发生什么。