Huh... My last full checkout was with building OE - without errors. But it was many weeks ago... And on my machine is only updated tree.

Okay, well I've made a copy of the repository. Here's what I get from svnadmin verify:

...
* Verified revision 138.
* Verified revision 139.
svnadmin: Checksum mismatch while reading representation:
expected: 0854657ac1d5f13ae62b7cd63a428b98
actual: 2b5413bf9a5f60a009d1a68e5adc6e9f

fsfsverify.py dies with this error:

ValueError: invalid literal for int(): ?5182335

There seems to be corrupted bytes scattered throughout the file, this is not going to be easy to fix.

Well I managed to fix revision 140 by manually going through and changing corrupted characters here and there, now there's problems with 896.

svnadmin: Checksum mismatch while reading representation:
expected: 6551138eec84e8e0d3bae536c021c04d
actual: 898c1ad27ed48027707b262444895b79

Right, I've hex-edited the database enough that I can now checkout with no problems, although there may be one or two corrupted or truncated files (luckily mostly in architectures, machines and drivers we don't use).

I'll see if I can import the fixed version but it may take a while or even fail as the dump of our repository is larger than the soft-limit on the SF.net shell server group space. Worst-case we may need to clear the repository and start afresh (with erased history) or alternatively move SVN to some other hosting service.

Is there any way to clone the svn tree? We could then try fixing it locally (and maybe left it locally hosted at all).

Anyways working copies are ok, so we are not going to loose everything... And maybe it might be right timing to switch to git ;)

Hmm. Importing my fixed version failed, it may be that it's too big (the repository is 331 MB).

Farcaller: I have a local backup of the corrupted repository (the whole thing) at home which I grabbed via rsync as well as the version I've hacked so that checking out and doing other svn commands works (let me know if you want a copy of them). So yes, either we could move the repository onto one of our servers (or even mirror it across multiple of them), or as you say convert it to git. I'll try running git-svn on the kernel trunk part of the repository and see what happens.

Here's what SF.net's import tool said:

Last request for migration is:
Requested by: bobofdoom Project Admin
Requested on: 2007-11-19 08:24
Source data type: SVN dump file archive
Source path: /home/groups/h/ha/hackndev/hackndev-svndump-fixed-corruption.bz2
Destination:
Replacement: Yes
Current status: FAILED

Tries:
Start End Status
2007-11-19 08:45 2007-11-19 08:58 FAILED
2007-11-19 08:35 2007-11-19 08:44 FAILED
2007-11-19 08:25 2007-11-19 08:33 FAILED

git-svn worked fine, except the output is rather huge:

$ du -sh .git/
452M .git/

Hmph. Maybe I'll try it again with only revisions since the last kernel upgrade.

It seems to have some bug with all that mv's we had in earlier svn times. I'd suggest to leave only latest revs and keep old (broken) svn tree just for history.

I don't care about -rt branch history, no need to move it over (I can just fork and patch the HEAD again).

PS: My vote is git ;)

I vote for .git, too. Also, Alex, no need to re-checkout again - you can do just git-format-patch til latest
hh.org merge and then re-apply. And you will have chance to toss all crap (since it is best to re-apply to hh.org HEAD anyway).