我的家庭服务器出现硬盘故障。
一旦我意识到磁盘正在运行,我就登录并直接复制了我的存储库,其中包含多个项目。
但是,由于磁盘出现故障,其中一项修订已损坏:
$ 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/
中的 crashing-disk-copy 复制到备份中,以提供“缺失的尾部” “:
$ 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
现在,我已经没有想法了。
最佳答案
我解决了。
一旦我意识到,解决方案(当然)是显而易见的。
我有这个:
master/
:损坏的存储库的副本,具有修订版 0..947,修订版 823 的文件物理丢失。repos/
:从备份(转储文件)加载的存储库,涵盖修订版 0..910。
解决方案只是从版本 911 及更高版本的 master/
转储。这是可能的,没有任何错误,我认为这意味着 911..947 范围内的任何修订都没有直接依赖于修订 823 中的状态,或者其他什么:
$ svnadmin dump --incremental -r 911:947 master/ > tail.txt
* Dumped revision 911.
* Dumped revision 912.
* Dumped revision 913.
[...]
* Dumped revision 947.
无论如何,只需将转储应用到来自备份的存储库即可:
$ cat tail.txt | svnadmin load repos/
[lots of commits]
现在我已经恢复了完整的历史记录,没有问题:
$ svnadmin verify repos/
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
[...]
* Verified revision 945.
* Verified revision 946.
* Verified revision 947.
耶!
关于svn - 如何修复一个版本损坏的存储库?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5543285/