如何用一个不完整的修订版来修复存储库? [英] How do I fix a repository with one broken revision?

问题描述

我的家庭服务器发生硬盘故障.

My home server had a hard drive failure.

一旦我意识到磁盘将要运行，我便登录并直接复制了我的存储库，其中包含多个项目.

Once I realized the disk was going, I logged in and did a straight copy of my repository, which contains multiple projects.

但是，由于磁盘发生故障，其中一个修订版本被破坏了:

However, since the disk was failing, one of the revisions is broken:

$ 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.

The master/db/revs/ and master/db/revprops/ directories do, indeed, not contain any files called 823, so this revision is missing (broken). There are subsequent revisions (that I really want to keep!) in the master/ repository going up to revision #947.

今天，我获取了最新的异地备份(！)，其中愉快地包含了此修订版.我想通过修复丢失的修订来修复" master/中损坏的存储库，因为它比备份的要新.

Today I fetched my most recent off-site backup (!), which happily includes this revision. I would like to "heal" the broken repository in master/ by fixing the missing revision, since it is more recent than the backup.

我确保将转储文件加载到新创建的存储库中，该存储库的版本与在master/中复制的版本相同，因此都是旧的线性"格式3.

I made sure to load the dump file into a newly created repository with the same version as the copied one in master/, so it's all the old "linear" format 3.

我尝试了显而易见的方法，只是从备份的db/revs/和db/revprops/目录中复制文件823:

I tried the obvious, to just copy the file 823 from the backup's db/revs/ and db/revprops/ directories:

$ cp repos/db/revs/0/823 master/db/revs/
$ cp repos/db/revprops/0/823 master/db/revprops/

目录repos/包含从备份转储中加载的存储库.现在我得到了:

The directory repos/ contains a repository that has been loaded from the backup dump. Now I get:

$ 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命令，但没有一个使验证者满意.

Which is not very encouraging. I've tried various other svnadmin commands, but none have made the verifier happy.

我的下一个想法是退出复制，并从损坏的存储库的新"副本开始，然后在 823之后转储修订，并与备份合并.但这似乎是不可能的，我无法在缺少的版本之后转储修订版本:

My next idea was to back out the copying and start with a "fresh" copy of the broken repository, then dump out the revisions after 823, and merge with the backup. But that doesn't seem possible, I can't dump revisions after the missing one:

$ svnadmin dump -r 824 master/ >r824.dmp
svnadmin: No such revision 823

请注意，使转储递增"是无济于事的，希望它可以假装世界始于824版本，然后从那里开始:

Note that it doesn't help to make the dump "incremental", in the hopes that it should pretend the world started with revision 824 and just go from there:

$ svnadmin dump --incremental -r 824:947 master/ > dump.txt
svnadmin: No such revision 823

这确实将输出写入dump.txt，但是我不确定是否可以依赖它.请注意，它不会记录它已成功转储任何版本.

This does write output to dump.txt, but I'm not sure if it can be relied upon. Note that it doesn't log that it successfully dumped any revision.

更新:我有另一个想法:将更新的修订文件从master/中的崩溃磁盘副本复制到备份中，以提供遗漏的尾巴":

Update: I had another idea: to copy the newer revision files from the crashing-disk-copy in master/ into the backup, to provide the "missing tail":

$ 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

但是，这似乎什么也没做，只是破坏了目标存储库:

However, this seems to do nothing but corrupt the target repository:

$ svnadmin verify repos/
[...]
* Verified revision 907.
* Verified revision 908.
* Verified revision 909.
svnadmin: Corrupt representation '907 21815 45 30922 158d3e72732f45bf6f02919b22fc899a'
svnadmin: Malformed representation header

现在，我的想法用光了.

Now, I've run out of ideas.

推荐答案

我解决了.

一旦我意识到，解决方案就很明显(当然).

The solution was (of course) obvious, once I realized it.

我有这个:

• master/:已损坏的存储库的副本，具有版本0..947，但实际上缺少版本823的文件.
• repos/:从备份(转储文件)加载的存储库，覆盖版本0..910.

• master/: A copy of a broken repository, featuring revision 0..947, with revision 823's files physically missing.
• repos/: A repository loaded from a backup (dump file), covering revision 0..910.

解决方案只是从master/版本911起转储.这是可能的，没有任何错误，我认为这意味着911..947范围内的任何修订都不直接依赖于修订823中的状态，或者什么:

The solution was simply to dump from master/, from revision 911 and onwards. This was possible without any errors, which I take it means that none of the revisions in the range 911..947 directly depended on the state in revision 823, or something:

$ svnadmin dump --incremental -r 911:947 master/ > tail.txt
* Dumped revision 911.
* Dumped revision 912.
* Dumped revision 913.
[...]
* Dumped revision 947.

无论如何，然后将转储应用于来自备份的存储库:

Anyway, then just apply the dump to the repository coming from the backup:

$ cat tail.txt | svnadmin load repos/
[lots of commits]

现在我已恢复了完整的历史记录，没问题了:

And now I have the full history restored, no problems:

$ svnadmin verify repos/
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
[...]
* Verified revision 945.
* Verified revision 946.
* Verified revision 947.

是的！

这篇关于如何用一个不完整的修订版来修复存储库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！