У меня только что возникла проблема, когда во вновь созданном репозитории Subversion было повреждено около 80% его ревизий (пользователь получил ошибки повреждения файловой системы и несоответствия контрольной суммы, когда он в конечном итоге стал непригодным для использования). Однако инженер смог работать с репозиторием и даже создать ветку из одной из поврежденных ревизий и обновлять эти ревизии до тех пор, пока не начнут появляться упомянутые выше ошибки. Поскольку проекту была всего неделя, мы в итоге удалили и воссоздали его, но это могло быть намного хуже, если бы это был проект с большой историей. Раньше я имел дело с повреждением репозитория, но некоторые особенности поведения, которые я видел при диагностике репозитория, действительно вызывают у меня зацикливание, и я надеюсь получить некоторое представление о том, что могло произойти.
Что действительно было странно в этом, так это то, что если я проверил ревизию HEAD проекта, я сам получил несоответствие контрольной суммы и ошибки повреждения файловой системы. Однако, если я проверял ревизию 1, а затем последовательно обновлял каждую отдельную ревизию, включая известные поврежденные ревизии, эти ошибки никогда не возникали, и это было похоже на то, что с репозиторием все было в порядке (svnadmin verify 'подтвердил, что действительно было повреждение, и svnadmin dump 'сбой с одинаковыми ошибками для каждой поврежденной ревизии). Как правило, поврежденные версии не обновляются до, поэтому я очень смущен тем, что здесь произошло.
Это самая странная проблема с репозиторием, которую я видел за 6 лет, и я надеюсь, что кто-то более осведомленный, чем я, сможет помочь мне разобраться в том, что могло пойти не так. У меня есть резервная копия репозитория, поэтому я могу получить любую информацию, которая может понадобиться для диагностики.
В настоящее время мы используем SCM Manager для размещения проектов Subversion и Git, но мы не видели ничего подобного с тех пор, как начали использовать SCM Manager в качестве платформы управления версиями. Мы используем TortoiseSVN 1.8 против 1.7 совместимых репозиториев (svnsync имеет серьезные проблемы в 1.8, поэтому мы используем 1.7 для этого), но некоторые из нас также используют инструменты командной строки svn. В данном случае TSVN был клиентом, используемым в этом репозитории, мое собственное тестирование проводилось через версию командной строки.
Мне удалось изолировать причину, похоже, из-за неполной фиксации, которая почему-то не была выброшена, когда фиксация не удалась.