我的家庭服务器出现硬盘故障。
当我意识到磁盘正在运行时,我登录并直接复制了我的存储库,其中包含多个项目。
然而,由于磁盘出现故障,其中一项修订已损坏:
$ svnadmin verify master/
[...]
* Verified revision 820.
* Verified revision 821.
* Verified revision 822.
svnadmin: No such revision 823
The master/db/revs/
and master/db/revprops/
目录确实不包含任何名为823
,因此此修订版丢失(损坏)。还有后续的修订(我真的想保留!)master/
存储库将更新至修订版 #947。
今天,我获取了最新的异地备份(!),其中很高兴包含此修订版。我想“治愈”损坏的存储库master/
通过修复丢失的修订版,因为它比备份更新。
我确保将转储文件加载到新创建的存储库中,其版本与中复制的版本相同master/
,所以都是旧的“线性”格式 3。
我尝试了显而易见的方法,只是复制文件823
从备份的db/revs/
and 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
命令,但没有一个能让验证者满意。
我的下一个想法是取消复制并从损坏的存储库的“新”副本开始,然后转储修订版本after823,并与备份合并。但这似乎不可能,我无法在丢失的版本之后转储修订版本:
$ 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
,但我不确定它是否可以依赖。请注意,它不会记录已成功转储any修订。
Update:我有另一个想法:从 crashing-disk-copy 中复制较新的修订文件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
现在,我已经没有想法了。