Я не системный администратор, но, видимо, должен играть в него по телевизору. Однако я убедил свое рабочее место начать использовать контроль версий и, следовательно, быть тем, кто его администрировал. Загвоздка в том, что я должен делать это в их существующих системах. Итак, я использую визуальный SVN в 32-разрядной версии Windows Server 2003 Web Edition. Я ни с чем не ласкал, потому что не знаю, что делаю. Это наш веб-сервер разработки, на который я только что произвел стандартную установку visualSVN. Репозиторий размещен на этом компьютере, а рабочая копия клиента находится на подключенном сетевом диске, который указывает на местоположение на этом же компьютере.
У моих пользователей 32-битных версий Windows 7 нет проблем ни с черепахой, ни с клиентами Smart SVN. Однако мои 64-битные пользователи периодически получают
"соединение отклонено сервером запросом OPTIONS не удалось"
сообщение и не может подключиться к серверу SVN, это сохраняется до тех пор, пока они не перезагрузят свой компьютер, и не произойдет с обоими клиентами, упомянутыми выше. Как бы то ни было, есть небольшой 64-битный патч для Smart SVN, связанный с интеграцией оболочки, и он был применен.
Итак, что означает это сообщение и как его решить? Пожалуйста, имейте в виду, что, хотя у меня есть приличный опыт пользователя компьютеров, я не понимаю, когда дело доходит до их администрирования, и снисходительно относитесь ко мне, пожалуйста. Также обратите внимание, что если бы была возможность запускать SVN на Linux, это уже было бы сделано. У меня нет выбора, кроме как работать в этой среде.
РЕДАКТИРОВАТЬ 2012/3/15
У меня снова возникла проблема с пользователем, и, согласно совету Lazy Badger, перебежал и использовал slikSVN для попытки обновления. Ошибка также произошла с интерфейсом командной строки, но формулировка немного отличалась:
"svn: OPTIONS of 'http: // [наш server]: 8080 / svn / [repo] / trunk / [toplevelfolder] ': не удалось подключиться к серверу (http: // [наш сервер]: 8080) "
РЕДАКТИРОВАТЬ 2012/3/19
Я нашел возможное решение. Сегодня я снова столкнулся с ошибкой, как пользователь. Просто чтобы проверить, в порядке ли сеть, я попросил его просмотреть репо в своем веб-браузере, просто перейдя наhttp: // [наш server]: 8080 / svn 'и вход в систему. Похоже, это позволило его клиенту (-ам) SVN снова получить доступ к серверу без ошибок и без прерывания перезагрузки. Будет обновлено снова, если этот обходной путь повторяется успешно.
Когда вы говорите «visualSVN», вы имеете в виду «VisualSVN Server», да ?!
Кстати, примечание
рабочая копия клиента находится в сопоставленной сети
очень и очень плохая идея
Обновить
Разъяснение и подробности
Можете ли вы дать ссылку или включить инструкции по редактированию журнала, упомянутого в пункте 3?
VisualSVN Server Standard Edition имеют
ErrorLog nul
LogLevel error
в конфигурации Apache, таким образом - почти ничего не записывать в Журнал событий (в отдельном разделе). Доступ и оперативный журнал (в журнал событий) можно включить из окна графического интерфейса только в Enterprise Edition. Вы можете включить стандартное ведение журнала, определив обычные ErrorLog и AccessLog, и просматривать действия и ошибки в расширенной версии, по сравнению с веб-интерфейсом (причина для «Ошибка запроса OPTIONS»). Но SVN Книга также есть совет о Дополнительное ведение журнала Apache в CustomLog, которые позволяют «переводить» команду WebDAV в команды SVN.
Уточните, почему рабочая копия, находящаяся на подключенном сетевом диске, - плохая идея?
нам нужно, чтобы он был на веб-сервере для обработки языка на стороне сервера
КАКИЕ?! Сервер на разработчика или одна общая копия для всех разработчиков? У вас (или у менеджера, или ...) есть переосмыслить о рабочем процессе после внедрения VCS - нельзя использовать общая куча как и раньше, только версии сверху. Эта почта будет (может) быть использовано для понимания моей реакции и этот ответ в FAQ по Subversion поможет выстроить обновленный рабочий процесс. Решение ловушки после фиксации есть острые углы (параллельные операции), но когда и если это станет проблемой, вы можете перейти на производственные инструменты Build-CI-Deploy.
Вы уверены, что 32-битные или 64-битные окна виноваты? Если в 64-битной версии вашего svn-клиента нет конкретной ошибки, я сомневаюсь, что проблема заключается в битах.
Одна из причин, по которой вы можете получить обнаруженную ошибку, заключается в том, что метод HTTP OPTIONS фильтруется брандмауэром или самим svn-сервером. Отключите брандмауэр (менее безопасный), который может работать на компьютере пользователя с Windows (или, что более безопасно, разрешить такой трафик).
Если пользователь получает сообщение «Ошибка запроса OPTIONS», можете ли вы получить «статус svn», можете ли вы вообще связаться с сервером svn? Клиент svn должен иметь возможность получить статус.