title: How do I fix a repository with one broken revision?
body: <p>My home server had a hard drive failure.</p>
  
  <p>Once I realized the disk was going, I logged in and did a straight copy of my repository, which contains multiple projects.</p>
  
  <p>However, since the disk was failing, one of the revisions is broken:</p>
  
  <pre><code>$ svnadmin verify master/
  [...]
  * Verified revision 820.
  * Verified revision 821.
  * Verified revision 822.
  svnadmin: No such revision 823
  </code></pre>
  
  <p>The <code>master/db/revs/</code> and <code>master/db/revprops/</code> directories do, indeed, not contain any files called <code>823</code>, so this revision is missing (broken). There are subsequent revisions (that I really want to keep!) in the <code>master/</code> repository going up to revision #947.</p>
  
  <p>Today I fetched my most recent off-site backup (!), which happily includes this revision. I would like to "heal" the broken repository in <code>master/</code> by fixing the missing revision, since it is more recent than the backup.</p>
  
  <p>I made sure to load the dump file into a newly created repository with the same version as the copied one in <code>master/</code>, so it's all the old "linear" format 3.</p>
  
  <p>I tried the obvious, to just copy the file <code>823</code> from the backup's <code>db/revs/</code> and <code>db/revprops/</code> directories:</p>
  
  <pre><code>$ cp repos/db/revs/0/823 master/db/revs/
  $ cp repos/db/revprops/0/823 master/db/revprops/
  </code></pre>
  
  <p>The directory <code>repos/</code> contains a repository that has been loaded from the backup dump. Now I get:</p>
  
  <pre><code>$ 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 &lt; ndx-&gt;offs[ndx-&gt;length]' failed.
  Aborted
  </code></pre>
  
  <p>Which is not very encouraging. I've tried various other <code>svnadmin</code> commands, but none have made the verifier happy.</p>
  
  <p>My next idea was to back out the copying and start with a "fresh" copy of the broken repository, then dump out the revisions <em>after</em> 823, and merge with the backup. But that doesn't seem possible, I can't dump revisions after the missing one:</p>
  
  <pre><code>$ svnadmin dump -r 824 master/ &gt;r824.dmp
  svnadmin: No such revision 823
  </code></pre>
  
  <p>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:</p>
  
  <pre><code>$ svnadmin dump --incremental -r 824:947 master/ &gt; dump.txt
  svnadmin: No such revision 823
  </code></pre>
  
  <p>This does write output to <code>dump.txt</code>, but I'm not sure if it can be relied upon. Note that it doesn't log that it successfully dumped <em>any</em> revision.</p>
  
  <p><strong>Update</strong>: I had another idea: to copy the newer revision files from the crashing-disk-copy in <code>master/</code> into the backup, to provide the "missing tail":</p>
  
  <pre><code>$ 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
  </code></pre>
  
  <p>However, this seems to do nothing but corrupt the target repository:</p>
  
  <pre><code>$ svnadmin verify repos/
  [...]
  * Verified revision 907.
  * Verified revision 908.
  * Verified revision 909.
  svnadmin: Corrupt representation '907 21815 45 30922 158d3e72732f45bf6f02919b22fc899a'
  svnadmin: Malformed representation header
  </code></pre>
  
  <p>Now, I've run out of ideas.</p>