我不得不对subversion存储库数据库进行更改。我创建了一个转储,过滤掉了一个修订版并创建了一个新的数据库。
这个新的存储库当然与已经签出的旧存储库的工作副本客户端共享了很多内容,但是它缺少一个修订版。
删除的修订版没有添加任何数据,只更改了一些文件。
是否可以简单地用新服务器数据库替换旧服务器数据库,而不会对现有客户端工作副本造成严重破坏?或者我是否必须让所有客户查看新回购的新副本?
更一般地说,subversion客户端如何处理服务器端的结构变化?我主要对TortoiseSVN感兴趣。
答案 0 :(得分:2)
我们遇到过一次腐败签到的问题,这要求我将其从回购中删除。我在工作完成后运行了一些测试签名,因此最新版本号至少与其他开发人员在他们的盒子上相同(如果不是更大)。我们没有遇到任何问题。
答案 1 :(得分:1)
只要转储中的版本号没有更改,并且保留了UUID,它就不应该有太大的区别。 Subversion跟踪工作副本文件的修订号以及存储库的UUID和URL。即使历史发生了变化,也不应影响工作副本。
但 ,理论与事实之间始终存在差异。在进行转储和加载之前,我会提前警告开发人员。我让他们检查他们的代码。然后,我进行转储和加载,然后告诉开发人员进行干净的结账。
为了安全起见,请做一个干净的结帐。您可以对旧的工作副本执行svn status
查找已更改但未提交的文件,并将其复制到新的清理结帐中。 svn status
没有ping存储库,因此这是一个安全的操作。
答案 2 :(得分:0)
根据我的经验,Tortoise SVN客户端1.7稳定地增长他的.svn目录,并且只有在工作副本的顶部运行“清理”时才会减少它。
此外,如果TSVN已经看到过滤版本的日志消息(以及其他详细信息),它将继续向用户显示它,除非他清除此特定缓存(这可以通过GUI实现)。 p>
如果您过滤了包含其不同版本号的整个修订版(以便下一版本现在获得过滤版本的编号),我不会尝试保留旧的工作副本。
我不太了解客户内部直接回答您的问题。但我处于类似情况,因此我建议首先测试服务器。
您的 svnadmin加载(或 svnrdump加载)应该已经偶然发现了丢失的历史记录(“delta”)。但我建议收集服务器真正提供的更多证据:
从新的存储库中,密切关注服务器和您最喜欢的客户端以获取任何警告......