【发布时间】：2011-07-29 10:26:01
【问题描述】：
我的家庭服务器出现硬盘故障。
当我意识到磁盘正在运行时，我登录并直接复制了我的存储库，其中包含多个项目。
但是，由于磁盘出现故障，其中一个修订版已损坏：
$ svnadmin verify master/
[...]
* Verified revision 820.
* Verified revision 821.
* Verified revision 822.
svnadmin: No such revision 823
master/db/revs/ 和 master/db/revprops/ 目录确实不包含任何名为 823 的文件，因此此修订版丢失（损坏）。 master/ 存储库中有后续修订版（我真的很想保留！），直到修订版 #947。
今天我获取了我最近的异地备份 (!)，其中很高兴地包含了这个修订版。我想通过修复丢失的修订来“修复”master/ 中损坏的存储库，因为它比备份更新。
我确保将转储文件加载到一个新创建的存储库中，该存储库与master/ 中复制的版本相同，所以它都是旧的“线性”格式 3。
我尝试了显而易见的方法，即从备份的 db/revs/ 和 db/revprops/ 目录中复制文件 823：
$ cp repos/db/revs/0/823 master/db/revs/
$ cp repos/db/revprops/0/823 master/db/revprops/
目录repos/ 包含已从备份转储加载的存储库。现在我明白了：
$ svnadmin verify master/
[...]
* Verified revision 821.
* Verified revision 822.
svnadmin: /build/buildd/subversion-1.6.12dfsg/subversion/libsvn_delta/compose_delta.c:165: search_offset_index: Assertion `offset < ndx->offs[ndx->length]' failed.
Aborted
这不是很令人鼓舞。我尝试了其他各种svnadmin 命令，但没有一个让验证者满意。
我的下一个想法是取消复制并从损坏的存储库的“新”副本开始，然后转储 823 之后的修订，并与备份合并。但这似乎不可能，我无法在丢失后转储修订：
$ svnadmin dump -r 824 master/ >r824.dmp
svnadmin: No such revision 823
请注意，使转储“增量”无济于事，希望它应该假装世界从修订版 824 开始，然后从那里开始：
$ svnadmin dump --incremental -r 824:947 master/ > dump.txt
svnadmin: No such revision 823
这确实将输出写入dump.txt，但我不确定是否可以依赖它。请注意，它不会记录成功转储任何修订版。
更新：我有另一个想法：将更新的修订文件从master/ 的崩溃磁盘副本复制到备份中，以提供“缺失的尾巴”：
$ for a in $(seq 910 947) ; do cp master/db/revs/$a repos/db/revs ; cp master/db/revprops/$a repos/db/revprops/ ; echo $a ; done
但是，这似乎只会破坏目标存储库：
$ svnadmin verify repos/
[...]
* Verified revision 907.
* Verified revision 908.
* Verified revision 909.
svnadmin: Corrupt representation '907 21815 45 30922 158d3e72732f45bf6f02919b22fc899a'
svnadmin: Malformed representation header
现在，我的想法已经用完了。
【问题讨论】：
-
开始认为也许这在其他 StackExchange 站点之一上得到了更好的服务，但这里似乎有很多类似的问题。
-
没关系，关于版本控制工具的问题在这里很公平。 FAQ 提到“程序员常用的软件工具”，其他领域很少使用版本控制（至少非程序员使用）。
-
关于恢复损坏的存储库，我刚刚发现这篇非常有趣的文章：spin.atomicobject.com/2015/10/06/svn-corruption-recovery