我有一些关于恢复旧的subversion存储库备份的问题。
假设存在基于某个存储库（repo）中的修订版的各种工作副本（wc）。例如，存储库可能位于修订版100，并且工作副本BASEd在各种修订版本中，例如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存储库备份，识别无效的工作副本，以及尝试从已存在的各种无效工作副本中“收获”丢失的更改？
（据推测，答案的一部分是，一旦存储库被恢复，所有无效的工作副本都应该作为工作副本放弃，并且他们的更改会转移到新的结帐，所有在恢复计划到位之前，应暂停工作副本。）
感谢。
答案 0 :(得分：1)
也许我错过了一些东西，但我没有看到问题。
具有修订版80的工作副本的用户执行以下操作
所有其他用户结帐（完成此操作后）到一个全新的wc。所有其他wc都可以丢弃（灾难发生之前）。
现在每个人都处于“修订版80”（实际上是51或71），这是最好的情况，因为这是灾难发生后的更高版本。
关键在于，无论数字如何，每个人都可以获得最佳/最新版本的文件。
这样你甚至不必关心“颠覆在这方面的行为”