Ошибка подключения Subversion для 64-битных клиентов
Я не системный администратор, но мне, видимо, приходится играть по телевизору. Тем не менее, я убедил свое рабочее место начать использовать контроль версий и, следовательно, должен был управлять им. Подвох в том, что я должен сделать это на своих существующих системах. Итак, я запускаю визуальный SVN на Windows Server 2003 Web Edition, которая является 32-битной. Мне ничего не нравилось, потому что я не знаю, что делаю. Это наш веб-сервер для разработки, на котором я только что выполнил стандартную установку Visual SVN. Хранилище размещается на этом компьютере, а рабочая копия клиента находится на подключенном сетевом диске, который указывает на местоположение на этом же компьютере.
У моих пользователей в 32-битных версиях Windows 7 нет проблем ни с черепахой, ни с клиентами Smart SVN. Однако мои 64-битные пользователи периодически получают
"соединение отклонено запросом сервера OPTIONS"
сообщение и не может подключиться к серверу SVN, оно сохраняется до тех пор, пока они не перезагружают свою машину, и происходит с обоими клиентами, упомянутыми выше. Для этого стоит небольшой 64-битный патч для Smart SVN, посвященный интеграции оболочки и уже примененный.
Итак, что означает это сообщение и как мне его разрешить? Пожалуйста, имейте в виду, что, хотя я достаточно опытен в качестве пользователя компьютеров, я над головой, когда дело доходит до их администрирования, и, соответственно, снисходите до меня. Также обратите внимание, что если бы была возможность запустить SVN на Linux-боксе, это было бы уже сделано. У меня нет выбора, кроме как работать в этой среде.
РЕДАКТИРОВАТЬ 2012/3/15
У меня снова возникла проблема с пользователем, и, согласно совету Ленивого Бэджера, он попытался обновить файл с помощью slikSVN. Ошибка также произошла с CLI, но формулировка немного отличалась как:
"svn: ВАРИАНТЫ ' http://[наш сервер]:8080/svn/[repo]/trunk/[toplevelfolder]': не удалось подключиться к серверу ( http://[наш сервер]:8080)"
РЕДАКТИРОВАТЬ 2012/3/19
Я нашел возможный обходной путь. У меня как пользователя снова возникла ошибка сегодня. Просто чтобы проверить, была ли сеть в порядке, я заставил его просмотреть репозиторий в своем веб-браузере, просто зайдя на " http://[наш сервер]: 8080 / svn" и войдя в систему. Это, казалось, позволило его клиенту SVN (s)) затем снова получить доступ к серверу без ошибок и без прерывания перезагрузки. Обновится снова, если этот обходной путь повторился успешно.
2 ответа
Когда вы говорите "VisualSVN", вы имеете в виду "Сервер VisualSVN", да?!
- "Запрос OPTIONS не выполнен" вообще не коррелирует с клиентом (и архитектурой клиента) - это чисто ошибка на стороне сервера
- Без лога Apache мы ничего не сможем
- В VisualSVN Server полностью отключено ведение журнала, вы должны включить его вручную в httpd.conf
- Для тестирования я рекомендую использовать CLI svn-клиентов - в случае ошибок они сообщают более подробную информацию (64- битный клиент SVN CLI - SlikSVN, 32- битный может использоваться любой)
Кстати, sidenote
рабочая копия клиента находится в подключенной сети
очень, очень плохая идея
Обновить
Разъяснение и детали
Можете ли вы дать ссылку или включить инструкции по редактированию журнала, который вы упомянули в пункте 3?
VisualSVN Server Standard Edition имеют
ErrorLog nul
LogLevel error
в конфиге Apache, таким образом - почти ничего не регистрировать в журнале событий (в отдельном разделе). Доступ и оперативное ведение журнала (в журнал событий) могут быть включены из окна в графическом интерфейсе только в Enterprise Edition. Вы можете включить стандартное ведение журнала, определив обычные ErrorLog и AccessLog и увидев действия и ошибки в расширенной версии, в зависимости от внешнего интерфейса (причина "запрос OPTIONS не выполнен"). Но в SVN Book также есть совет о дополнительной регистрации Apache в CustomLog, которая позволяет "переводить" команду WebDAV в команды SVN.
Хотите уточнить, почему рабочая копия на подключенном сетевом диске - плохая идея?
- Visual Studio + SVN: рабочие копии на сетевом диске или локальном? тема здесь
- Ответ в FAQ по TortoiseSVN
- Рабочие копии SVN в сети Поделиться темой
- Немного устаревшее предупреждение о BDB-репо (в любом случае используйте FSFS). "Не создавайте и не обращайтесь к репозиторию Berkeley DB в общей сетевой папке. Он не может существовать в удаленной файловой системе. Даже если сетевой диск сопоставлен с буквой диска. вы пытаетесь использовать Berkeley DB на общем сетевом ресурсе, результаты непредсказуемы - вы можете сразу увидеть таинственные ошибки или могут пройти месяцы, прежде чем вы обнаружите, что ваша база данных хранилища слегка повреждена "
нам нужно, чтобы он был на веб-сервере для обработки языка на стороне сервера
КАКИЕ?! Сервер на разработчика или одна общая копия для всех разработчиков? Вы (или менеджер или...) должны переосмыслить рабочий процесс после внедрения VCS - вы не можете использовать общую кучу, как раньше, просто версионно сверху. Этот пост будет (может) использоваться для понимания моей реакции, и этот ответ в Subversion FAQ поможет создать обновленный рабочий процесс. Решение для перехвата после фиксации имеет некоторые острые углы (параллельные операции), но когда и если это станет проблемой, вы можете перейти к инструментам Build-CI-Deploy производственного качества
Вы уверены, что 32-битные или 64-битные окна виноваты? Если в 64-битной версии вашего svn-клиента нет конкретной ошибки, я сомневаюсь, что проблема заключается в битах.
Одна из причин, по которой вы можете получить обнаруженную ошибку, заключается в том, что метод HTTP OPTIONS фильтруется брандмауэром или самим сервером svn. Отключите брандмауэр (менее безопасный), который может быть запущен на компьютере пользователя Windows (или, что более безопасно, разрешите такой трафик).
Если пользователь получает запрос "OPTIONS failed", можете ли вы получить "svn status", можете ли вы вообще получить доступ к серверу svn? У клиента SVN должен быть способ получить статус.