У меня была такая же проблема, после коммита я не смог добраться до своего локального сетевого диска, в котором хранится SVN-репозиторий, созданный с помощью черепахи.
Я получил "Нет такой ревизии 108".
Это заняло у меня какое-то время, так как я отправил пустой репозиторий со своим старым, используя WinMerge, и начал систематически удалять файлы, пока черепаха не дала мне ничего. Сначала только пустой репозиторий, потом я нашел проблему ...
По какой-то причине первое, что делает черепаха в локальном репозитории, - это то, что она обновляет текущий номер ревизии в файле "db / current" до самого нового, чем она выделяет новый файл ревизии и заполняет данными. Проблема возникает, если процесс прерывается и «текущий» указывает на недопустимый или несуществующий номер редакции.
Короче говоря:
Мне удалось «восстановить» мой репозиторий, отредактировав указанный номер файла «db / current» в допустимую ревизию (действительный номер можно найти в «revs / 0 / xxx», где xxx - самая последняя версия.
Это верно только для локально созданных репозиториев.
Чтобы преодолеть эту проблему в будущем, я настоятельно рекомендую вам сделать то же самое, что и я:
вместо того, чтобы хранить каждый проект в одном репозитории, создайте отдельные репозитории с простой структурой ствола / ветвей / тегов для каждого проекта, таким образом, повреждение будет изолировано для одного проекта.
Также обратите внимание, что редактирование текущей ревизии в действительной означает, что вы, вероятно, потеряете данные (будет потеряна последняя фиксация или обновление), и я мог бы найти способ ее восстановить.
Но не стал разбираться, потому что я потерял только несколько часов работы.
Надеюсь, это поможет многим страданиям одного и того же ..