Вопрос: Как исправить репозиторий SVN, где он позволяет проверять исходный код или текстовые файлы, но не бинарные файлы или банки?


Недавно мне была предоставлена ​​работа по уходу за установкой 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 рабочей копии.

То, что я пытаюсь понять, это

  1. Как я могу восстановить эти репозитории, чтобы их можно было использовать снова?
  2. Как определить причину и, таким образом, надеюсь, предотвратить ее повторение?

Одна мысль заключалась бы в том, чтобы выполнить дамп репозитория, удалить его и создать его, а затем загрузить в него файл дампа. Однако, если создание нового репозитория только для временной проверки не помогло, помогите, я не уверен, что решение dump / delete / create / load сделает его лучше.

Я вполне уверен, что версия FSFS не является проблемой, так как я нашел другой репозиторий FSFS версии 4, который также не имеет проблемы с двоичными файлами. Я также просматриваю файлы svnserve.conf, но снова не могу найти ничего, что могло бы помешать проверке файлов.

Я обновляю здесь, когда я попытаюсь найти другие возможные причины такого поведения.

Я нашел одно обходное решение, но я не уверен, почему он работает. Очевидно, когда я изменяю MIME-тип файла jar из стандартного «приложения / октета-потока» в «application / java-archive», я могу проверить файл jar без ошибки. Теперь, если только я знал, почему это сработало, но разрешить Subversion использовать свой MIME-тип по умолчанию, нет.


1
2018-01-18 15:09


Источник


1. Не размещайте репозитории по сетевым ресурсам, это всегда Плохая идея (tm) 2. Проверьте (возможно существующие) крючки предварительной фиксации - Lazy Badger
@lazy грустно 1 не в моих руках, что решение было принято нашим ИТ-отделом. Я проверю на 2, хотя. - JRSofty
Кажется, что никаких активных крючков для предварительной фиксации не существует. - JRSofty
Вы пытались скопировать это репо в новое имя и посмотреть, есть ли у него проблема ?, то есть просто проверить файлы, создать новое репо (не удалять его старые) и передать весь файл в новое репо. Кажется, что проблема с сетевой записью возникает только на вашем репо, который повреждает узел каталога. Если вы воссоздаете, это может исправить. - Sumit Gupta
Мы создали новый отдельный репозиторий, но не экспортировали / не загружали копию существующего репозитория. Новый репозиторий показал аналогичные проблемы, как оригинал, даже в новом состоянии. - JRSofty


Ответы: