Коррупция в хранилище Subversion

У меня просто была проблема, когда во вновь созданном репозитории Subversion было повреждено около 80% его ревизий (пользователь получил повреждение файловой системы и ошибки несоответствия контрольной суммы, когда он в конечном итоге стал непригодным для использования). Тем не менее, инженер смог работать с репозиторием и даже создать ветку из одной из поврежденных ревизий и обновлять эти ревизии до тех пор, пока не начали появляться ошибки, упомянутые выше. Поскольку проекту был всего недельный срок, мы в итоге удалили и воссоздали его, но это могло бы быть намного хуже, если бы это был проект с большой историей. Я имел дело с повреждением репозитория прежде, но некоторые из поведений, которые я видел при диагностике репозитория, действительно бросают меня в тупик, и я надеюсь получить некоторое представление о том, что могло произойти.

Что было действительно странным в этом, так это то, что если я проверял версию HEAD проекта, я сам получал несоответствие контрольной суммы и ошибки файловой системы. Однако, если я извлек ревизию 1, а затем последовательно обновлялся до каждой отдельной ревизии, включая известные поврежденные ревизии, эти ошибки никогда не возникали, и было похоже, что ничего не случилось с хранилищем ("svnadmin verify" подтвердил, что действительно была коррупция, и " Сбой svnadmin 'с одинаковыми ошибками в каждой поврежденной ревизии). Как правило, поврежденные версии не обновляются, поэтому я очень озадачен тем, что здесь произошло.

Это самая странная проблема с хранилищем, которую я видел за 6 лет, и я надеюсь, что кто-то более знающий, чем я, сможет помочь мне понять, что могло пойти не так. У меня есть резервная копия хранилища, поэтому я могу получить любую информацию, необходимую для диагностики.

В настоящее время мы используем SCM Manager для размещения проектов Subversion и Git, но мы не видели ничего подобного, поскольку мы начали использовать SCM Manager в качестве платформы управления версиями. Мы используем TortoiseSVN 1.8 против 1.7 совместимых репозиториев (svnsync имеет серьезные проблемы в 1.8, поэтому мы используем 1.7 для этого), но некоторые из нас также используют инструменты командной строки svn. В этом случае TSVN был клиентом, используемым в этом хранилище, мое собственное тестирование проводилось через версию командной строки.