2010/3/2 Kutter, Martin <martin.kut...@siemens.com>: > This sounds a bit like our issue discussed in thread > "Corrupted FSFS commit" just a few days ago on this list. > We managed to create a copy of the repository without the corrupted > files using path-based authorization and svnsync.
Could you give me some more insight on how exactly you performed the restore? I read up on your problem a bit, but theres no any details. Cloning my repo ends up the same way as everything does: Copied properties for revision 1024. Committed revision 1025. Copied properties for revision 1025. Committed revision 1026. Copied properties for revision 1026. Transmitting file data ............................................................................................... svnsync: Decompression of svndiff data failed > However, I'm a bit concerned about the issue arising again: Is there > some error in svn which allows for corrupted FSFS revisions to > enter into the repository? I read up a lot of problem-posts on the net, and theres a lot of people complaining about broken revs in their repo. Unfortunately the only solution which pops is the third party fsfsverify.py, which is failing in my case. I saw some posts about cases, when fsfsverify.py didn't worked, but usually there was no further information on if and how they managed to recover the data. Other solutions with dumping. cloning, skipping rev didn't worked, as I mentioned in the OP. My subversion version is 1.5.1. -- Mariusz Drozdziel
