Недавно мне было поручено позаботиться об установке SVN нашей компании, и, конечно же, проблема в одном из хранилищ, хранящихся в нем.
Я вижу, что если я сделаю новую проверку из хранилища, я могу внести изменения в исходный код и зарегистрировать его без проблем, но если я попытаюсь проверить новый бинарный файл (jar или dll), я получу ошибка, указывающая, что он не может установить указатель местоположения на файл. Файл находится в каталоге `\db\txn-protorevs '. Ошибка продолжает объяснять, что доступ запрещен.
После некоторого исследования я понял, что мы используем не только Subversion, но и Collabnet Subversion 1.8.13 и Collabnet Subversion Edge для управления. Эти службы работают на виртуальном сервере в сети нашей компании под управлением Windows Server 2008 R2. Сами репозитории хранятся не на этом сервере, а на нашем файловом сервере (скорее всего, для целей резервного копирования). Файловый сервер также является ОС Windows, но я не знаю версию. Все это было настроено и настроено до того, как я унаследовал его, и я не уверен, смогу ли я протолкнуть изменения, чтобы разместить службы и репозитории на одном сервере и, таким образом, устранить необходимость в сетевом ресурсе было проинформировано о проблеме Subversion.
Я также сравнил рабочий репозиторий со сбойным репозиторием, и кажется, что формат файловой системы отличается. Хороший репозиторий использует FSFS версии 3, а сбойный репозиторий - FSFS версии 4.
У меня есть права администратора на виртуальном сервере со службами Subversion, и я могу получить доступ к общему сетевому ресурсу, где хранятся репозитории. Так что запускать svnadmin не проблема. Не все репозитории на нашем SVN затронуты.
Я попытался следующие средства правовой защиты, ни один из которых не работал:
- Выполнена
svn cleanupрабочей копии. - Проверено, что у пользователя учетной записи службы есть полный доступ к папкам репозитория.
- Создано временное хранилище, но у пользователя все еще была та же проблема.
- По сравнению с правами доступа между рабочими и сбойными репозиториями они все одинаковы.
- Проверена клиентская версия SVN рабочей копии.
То, что я пытаюсь выяснить, это
- Как я могу восстановить эти репозитории, чтобы их можно было использовать снова?
- Как определить причину и, как мы надеемся, предотвратить ее повторение?
Одна мысль заключалась в том, чтобы выполнить дамп хранилища, удалить его, создать новый и затем загрузить файл дампа обратно в него. Однако, если создание нового хранилища только для временной регистрации не помогло, я не уверен, что решение dump/delete/create/load улучшит его.
Я вполне уверен, что версия FSFS не является проблемой, так как я нашел другой репозиторий FSFS версии 4, у которого также нет проблем с двоичными файлами. Я также просматривал файлы svnserve.conf, но опять же не могу найти ничего, что могло бы помешать возврату файлов.
Я буду обновлять здесь, поскольку я пытаюсь найти другие возможные причины для такого поведения.
Я нашел один обходной путь, но я не уверен, почему это работает. Очевидно, что когда я изменяю тип MIME jar-файла со стандартного «application /octet-stream» на «application /java-archive», я могу зарегистрировать jar-файл без ошибки. Теперь, если бы я только знал, почему это работает, но позволить Subversion использовать его тип MIME по умолчанию - нет.