Мои файлы, которые мне нужно было стереть, были последней проверкой в истории. Поэтому я смог использовать дамп svnadmin, чтобы получить дамп всех оборотов до сломанного оборота.
Это похоже на то, что описано на этой странице: http://robmayhew.com/delete-parts-of-subversion-history/
Мне нужно было избавиться от ошибки проверки на 8195-й версии, поэтому я запустил что-то вроде этого:
svnadmin dump /path/to/current/repo -r0:8194 > svn.dump
svnadmin create /path/to/new/repo
svnadmin load /path/to/new/repo < svn.dump
Это сработало, за исключением того, что в моей извлеченной рабочей копии все еще была информация от 8195. Это вызвало ошибку при попытке обновления, так как версия, в которой моя рабочая копия находилась на сервере, не существовала.
Мне нужно было сделать небольшую проверку и где-нибудь внести тривиальное изменение, чтобы вернуть версию репозитория до 8195, затем я мог очистить и обновить свою рабочую копию после удаления файлов, затронутых неудачной регистрацией. Это работало с использованием SVN в Linux.
Сотрудник использует svn в Windows, и Tortoise svn действительно трудно обойти это исправление хранилища. По-видимому, он хранит собственный внутренний кеш последней ревизии, а когда обновляет рабочую копию, он восстанавливает «плохие» файлы ревизий из своего кеша. Я думаю, что мне придется проверить все снова и создать новую рабочую копию, чтобы сделать это правильно.