我有一些关于恢复到旧的 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 ，并且所有工作副本都应该搁置直到恢复计划已到位。)
谢谢。
最佳答案
也许我遗漏了一些东西，但我在这里没有看到问题。
具有修订版 80 的工作副本的用户执行以下操作
所有其他用户结帐(完成后)到一个全新的厕所。所有其他厕所都可以丢弃(灾难前的)。
现在每个人都处于“修订版 80”(实际上是 51 或 71 版)，这是最好的情况，因为这是灾难后的更高修订版。
关键是无论数字多少，每个人都可以获得最佳/最新版本的可用文件。
这样你甚至不必关心“颠覆在这方面的表现”
关于svn - 在恢复旧存储库备份后从无效工作副本中获取的 Subversion 最佳实践是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2400741/