3

我不得不对 subversion 存储库数据库进行更改。我创建了一个转储，过滤掉了一个修订并创建了一个新的数据库。

当然，这个新存储库与已经签出的旧存储库的工作副本客户端共享大量内容，但是，它缺少中间的修订。

被删除的修订没有添加任何数据，它只是改变了一些文件。

是否可以简单地用新的服务器数据库替换旧的服务器数据库，而不会对现有的客户端工作副本造成严重破坏？还是我必须让所有客户检查新回购的新副本？

更一般地说，颠覆客户端如何处理服务器端的结构变化？我主要对 TortoiseSVN 感兴趣。

4

3 回答 3

2

我们曾经遇到过一次损坏的签入问题，这要求我将其从存储库中删除。工作完成后我运行了一些测试签入，所以最新的修订号至少与其他开发人员在他们的盒子上的相同（如果不是更大的话）。我们这样做没有任何问题。

于 2012-01-20T15:30:53.983 回答
1

只要转储中的修订号没有更改，并且保留了 UUID，它应该不会有太大的区别。Subversion 跟踪工作副本文件的修订号以及存储库的 UUID 和 URL。即使历史被更改，它也不应该影响工作副本。

但是，理论和事实之间总是存在差异的。在进行转储和加载之前，我会提前警告开发人员。我让他们检查他们的代码。然后，我进行转储和加载，然后告诉开发人员进行干净的结帐。

为了安全起见，请进行干净的结帐。您可以svn status对旧的工作副本执行 a 以查找已更改但未提交的文件，并将它们复制到新的干净结帐中。svn status不会 ping 存储库，所以这是一个安全的操作。

于 2012-01-20T19:14:12.547 回答
0

根据我的经验，Tortoise SVN 客户端 1.7 会稳定地增长他的 .svn 目录，并且只有当您在工作副本的顶部运行“清理”时才会减少它。

此外，如果 TSVN 已经看到过滤修订的日志消息（和其他详细信息），它将继续向用户显示，除非他清除此特定缓存（通过 GUI 可以实现）。

如果您过滤了包括其不同修订号的整个修订版，我不会尝试保留旧的工作副本（以便下一个修订版现在获得过滤后的修订版号）。

我不了解客户的内部情况，无法直接回答您的问题。但我处于类似情况，因此我建议先测试服务器。

  • 在新的（过滤的）存储库上运行“svnadmin verify”

甚至更多您的svnadmin load（或svnrdump load）应该已经偶然发现丢失的历史记录（“delta”）。但我建议收集更多证据证明服务器确实提供了：

在新的存储库中，同时密切关注服务器和您最喜欢的客户端是否有任何警告......

  1. 至少检查受您的过滤影响的文件，并且 - 为了更好地衡量 - 这些文件上方的目录。（我猜这些目录不需要包含其他文件和子目录。）
  2. 将此结帐更新为过滤前的一个修订，然后是过滤后的一个修订
  3. 如果仍然有修订号，请尝试签出/更新到过滤的修订版
  4. 测试（2.）并没有证明太多，如果文件在那些修订版中没有被修改，那么根据需要更新到修订版以在过滤之前和之后的另一次修改之前和之后的状态之间来回切换所有文件， 如果可供使用的话。看看历史上的“差距”是否会造成麻烦。
于 2013-09-19T13:57:50.337 回答