Итак, мой босс - хороший парень, готовый пробовать новые идеи, и я уговорил его разрешить мне начинать новые проекты на svn (вместо старой системы контроля версий). На данный момент мы поняли, что в наших интересах иметь доступ к нашему svn-серверу извне. Я сказал, что это легко, просто откройте порт 80. (Мы не требуем высокой безопасности для нашего svn, даже если он опубликован в Интернете, поэтому, пожалуйста, не меняйте тему на http и https, это будет отдельный вопрос, если когда-либо И, очевидно, пока мы не решим сиюминутную проблему, обезопасить нечего.)
Ужасная вещь, которую я сейчас обнаружил, это то, что svn st -u не работает, но другие подкоманды работают, например, svn relocate и svn log. В частности, svn st -u ничего не выводит и зависает, пока я не убью его с помощью ^ C. Когда я svn переместил свою рабочую копию на наш общедоступный IP-адрес, меня правильно спросили о моих учетных данных svn, и команда прошла успешно. Svn log печатает журнал, т. Е. Ведет себя как обычно. Все вышеизложенное применимо к командам, выполняемым на рабочей копии, корень репозитория которой является публичным IP-адресом (или, перемещая корень репозитория на наш публичный IP-адрес, в особом случае svn relocate). Для рабочих копий с сетевым именем сервера в интрасети для корня репозитория все команды продолжают работать нормально.
Чтобы исключить «блокировку http-глагола» внешним брандмауэром в качестве объяснения, я попытался изменить метод доступа на http на порт 81 и https на порт 443, перемещая рабочую копию каждый раз, когда я менял метод доступа на сервере. Фирма не может выборочно блокировать http-команды для трафика, который не идет на http-порт или где глаголы зашифрованы. Но эти ходы ничего не решили. Используя Wireshark, я могу видеть трафик между svn на моем клиентском компьютере и нашим общедоступным IP-адресом в любом из этих режимов, однако я не уверен, где найти точку, в которой разговор идет не так (особенно если используется протокол https!) .
Мы используем VisualSVN Server v3.5.3 «Standard Edition». Этот сервер поддерживает только доступ по протоколам http: // и https: //, но не svn: //. Клиент - TortiseSVN v1.9.3. Операционная система - Windows 7 как для клиента, так и для сервера (это два разных компьютера в одной интрасети).
Вы упомянули, что используете VisualSVN v3.3.1. Есть ли причина, по которой вы используете такую старую версию VisualSVN? Этой версии уже больше года, и в ней может отсутствовать исправление ошибки, связанной с возникшей у вас проблемой. Я бы посоветовал выполнить обновление до версии 3.5.3, а затем проверить, сохраняется ли проблема. VisualSVN - это продукт, который необходимо очень тщательно поддерживать в актуальном состоянии, особенно если вы делаете сервер общедоступным, поскольку он использует Apache и OpenSSL, которые часто обновляются из-за публично раскрытых уязвимостей. Вероятно, существует более 50 CVE, для которых вам не хватает исправлений при запуске 3.3.1 (см. https://www.visualsvn.com/server/changes/).
Если обновление версии по-прежнему не решает проблему, я бы сказал, что лучше всего будет напрямую связаться со службой поддержки VisualSVN.
Оказывается, настройка моего svn-клиента с любым прокси решает проблему. Это можно сделать либо в командной строке (как в ответе @bahrep), либо в файле конфигурации серверов. Прокси-сервер может быть бесплатным публичным прокси, например 50.97.88.2.
P.S. Я также обратился в службу поддержки visualsvn, как это предлагается в ответах ниже. Они были быстрыми и полезными, как и здесь, и привели к тому же решению.
По-прежнему похоже, что проблема связана с вашим брандмауэром или прокси. Скорее всего, проблема вызвана каким-то прозрачным прокси, который может быть настроен вашим интернет-провайдером.
svn status -u использует запрос PROPFIND, например, svn log не. А как насчет других команд вроде svn ls которые также используют PROPFIND? Как насчет svn log что не использует PROPFIND? Они работают?В любом случае вы можете установить Fiddler, записать журналы и отправить их команде VisualSVN по адресу support@visualsvn.com.
Установите Fiddler и запустите команду svn status -u <URL> --config-option=servers:global:http-proxy-host=127.0.0.1 --config-option=servers:global:http-proxy-port=8888 чтобы запросы проходили через Fiddler. Отправьте журнал на support@visualsvn.com, и мы внимательно его рассмотрим.