svn - 在恢复旧存储库备份后，从无效工作副本中收获的 Subversion 最佳实践是什么？

Question

我有一些关于恢复到旧的 subversion 存储库备份的问题。

假设在某个存储库 (repo) 中存在基于修订的各种工作副本 (wc)。存储库可能处于修订版 100，例如，工作副本基于各种修订版，例如 80、60、40:

repo @100
wc-1 @80
wc-2 @60
wc-3 @40

现在假设发生了灾难，存储库丢失了，并且可用的最新有效备份有点旧，比如修订版 50。这是恢复的，现在的情况是这样的:

repo @50
wc-1 @80 X
wc-2 @60 X
wc-3 @40 ?

标记为“X”的工作副本现在显然是无效的。他们的 BASE 不存在。

无法更新(即向下更新)无效的工作副本，因为所需的增量不再存在于存储库中。在任何情况下都不要这样做，因为这样的工作副本可能是丢失修订版的唯一现有来源。

此外，假设在存储库恢复之后，没有适当的流程，并且允许发生以下情况。

工作副本 3 显然没问题。 (好吧，单独考虑确实很好，但也许在全局解决问题之前不应该触及它。)

它的所有者现在更新了，并提交了几组更改，使存储库的 HEAD 修订版达到 70。现在的情况是这样的:

repo @70
wc-1 @80 X
wc-2 @60 X!
wc-3 @70 ?

工作副本 2 现在处于困惑状态。其 BASE 的修订版 60 是 不是 和原来一样。但是，它无效可能并不明显。此工作副本和存储库之间的明显差异是真实本地更改、工作副本 3 引入的差异以及代表丢失修订的差异的混合。也就是说，这是一团糟。

所以我的问题如下:

(1) SVN 在这方面的表现如何？具体来说，SVN 将如何响应 wc-1 的提交尝试？ SVN 将如何响应 wc-2 的提交尝试(一旦存储库 HEAD 超出 wc-2 的 BASE)？这在任何地方都有记录吗？

(2) 是否有记录在案的最佳实践程序，用于恢复到旧的 SVN 存储库备份、识别无效的工作副本以及尝试从存在的各种无效工作副本中“收获”丢失的更改？

(据推测，部分答案是，一旦存储库被恢复，所有无效的工作副本都应该作为工作副本放弃，并将它们的更改转移到新的 check out ，并且所有工作副本都应该搁置直到恢复计划已到位。)

谢谢。

Answer 1

也许我遗漏了一些东西，但我在这里没有看到问题。

具有修订版 80 的工作副本的用户执行以下操作

保持此工作副本不变(这是“原始”厕所)

check out 一个较低版本的新工作副本(例如 50 或 70)(这是克隆 wc)

将原始 wc 中的所有文件手动复制到克隆 wc

将所有更改从克隆 wc 提交到“恢复的”存储库

所有其他用户结帐(完成后)到一个全新的厕所。所有其他厕所都可以丢弃(灾难前的)。

现在每个人都处于“修订版 80”(实际上是 51 或 71 版)，这是最好的情况，因为这是灾难后的更高修订版。

关键是无论数字多少，每个人都可以获得最佳/最新版本的可用文件。

这样你甚至不必关心“颠覆在这方面的表现”