我的家庭服务器出现硬盘故障。
一旦我意识到磁盘正在运行，我登录并直接复制了我的存储库，其中包含多个项目。
但是，由于磁盘出现故障，其中一个修订被破坏：
$ 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。
我尝试了显而易见的方法，只是823从备份db/revs/和db/revprops/目录中复制文件：
$ 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
现在，我已经没有想法了。