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

Question

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

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

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”的工作副本现在显然无效。他们的基地不存在。

不可能将无效的工作副本向下更新(即向下更新)，因为所需的增量不再存在于存储库中。无论如何，这样做是不可取的，因为这种工作副本可能是现有唯一的订正损失的来源。

此外，假设在恢复存储库之后，不存在任何过程，并且允许发生以下情况。

工作副本3显然很好。(好吧，孤立地考虑它真的很好，但也许在全球范围内解决问题之前，它不应该被触及。)

它的所有者现在更新了，并提交了几组更改，从而使存储库的总版本达到了70次。现在的情况是：

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

工作副本2现在处于混乱状态。它的基础版本60是，而不是原来的。然而，它可能不明显，它是无效的。此工作副本与存储库之间的明显差异是真实的本地更改、工作副本3引入的差异以及表示丢失的修订的差异。就是，这是一团糟。

因此，我的问题如下：

(1) SVN在这方面表现如何？具体来说，SVN将如何回应WC-1提交的尝试？SVN将如何回应WC-2的提交尝试(一旦存储库的头超出了WC-2的基础)？这里有记录吗？

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

(部分答案可能是，一旦恢复了存储库，所有无效的工作副本都应该作为工作副本放弃，它们的更改应该转移到新的签出，所有工作副本都应该暂停，直到恢复计划到位。)

谢谢。

Answer 1

也许我错过了什么，但我在这里没有看到任何问题。

具有工作副本(在第80版)的用户执行以下操作

1. 将此工作副本保持不变(这是“原始”wc )，
2. 签出了一个新的工作副本，该副本位于较低版本(例如50或70) (这是克隆wc )
3. 手动将所有文件从原始wc复制到克隆wc，
4. 将从克隆wc提交到“恢复”存储库

>G29的所有更改。

所有其他用户签出(完成后)到一个全新的wc。所有其他的wc都可以被丢弃(灾难之前的那些)。

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

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

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