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

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

这是不可能的 过时的 (即向下更新)无效的工作副本,因为存储库中不再存在所需的增量。无论如何,这样做都是不可取的,因为这样的工作副本可能是丢失修订的唯一现有来源。

此外,假设在存储库恢复之后,没有任何流程,并且允许发生以下情况。

工作副本3是 显然地 好的(好吧,如果单独考虑的话,它确实是好的,但也许在事情解决之前不应该碰它 全球地 .)

它的所有者现在得到了最新信息,并提交了几组更改,使存储库的HEAD修订版达到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存储库备份、识别无效的工作副本,以及尝试从现有的各种无效工作副本中“获取”丢失的更改?

(大概,部分答案是,一旦恢复了存储库,所有无效的工作副本都应该作为工作副本放弃,并将其更改转移到新签出中,并且 全部的 在恢复计划到位之前,应暂停工作副本。)

谢谢