Не удается подключиться к репо с TortoiseSVN

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

Мне нужно добавить еще один блок в проект, но TSVN, возможно, невозможно подключиться к репозиторию. Это тот материал, который я обнаружил или опробовал:

У меня есть два клиентских ящика: "старый" и "новый"...

  • Настройка и проверка второй папки в "старом" окне отлично работает.
  • Просмотр в репо через Chrome/IE в "новом" поле также отлично работает.
  • В браузере моего "нового" окна не используется прокси (то же самое касается "старого" ).
  • Я запускаю TSVN 1.7.4, Build 22459 - 64 бит в обоих ящиках

  • Когда я пытаюсь подключиться к репо из "нового" поля с помощью браузера репо или проверять его в новой папке, я получаю следующее сообщение об ошибке:

    Невозможно подключиться к репозиторию по URL-адресу 'https://(ip-адрес опущен)/usvn/svn/(проект опущен)' ОПЦИИ "https://(ip-адрес опущен)/usvn/svn/(проект опущен) ': не удалось  подключиться к серверу (IP-адрес опущен)

  • Я сравнил все настройки TSVN между "новыми" и "старыми" полями, и все они выглядят как

  • По словам людей, работающих на сервере, нет доступных сертификатов
  • Брандмауэр Windows в "новом" окне отключен.
  • Я запускаю как "старое", так и "новое" поле из той же сети. "Старый" подключается через WIFI, но "новый" подключен к сети.

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

Спасибо

ОТВЕТЫ

Ответ 1

Вам нужно определить, является ли это проблемой для TortoiseSVN, вашего репозитория Subversion или вашего сетевого подключения.

  • Прежде всего, проверьте свой URL. Я никогда не использовал Дружественный SVN, поэтому я не знаю, что он делает с конфигурацией Apache httpd. Однако стандартная конфигурация Apache для нескольких репозиториев обычно http://<server>/svn/<module>, а не http://<server>/svn/ usvn /<module>. Предполагается ли, что каталог /usvn/ существует?
    • Кстати, как настроен Apache? Поддерживает ли пользовательский SVN это тоже, или он просто позволяет вам настраивать репозитории? Вы используете Visual-SVN или кто-то вручную настроил Apache httpd?
  • Если URL-адрес верен, попробуйте выполнить команду pinging на сервере Subversion. Можете ли вы выполнить ping из окна Windows? Если нет, у вас есть проблема с сетью. По какой-то причине IP-адрес недоступен даже из вашего клиентского окна.
  • Попробуйте открыть браузер и поместите URL-адрес репозитория Subversion в окно. Это должно сработать. Если это так, проблема, вероятно, связана с TortoiseSVN. Загрузите клиент командной строки Subversion и посмотрите, можете ли вы проверить с этим.
  • Попробуйте использовать тот же URL-адрес в другом поле. Можете ли вы проверить там? Если это так, это указывает на проблему с сетью.

Ответ 3

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

Например, используйте:

http://111.11.11.111/svn/Directory

вместо:

http://www.url.com/svn/Directory

Ответ 4

Я боролся с одной и той же проблемой. Я заменил свой рабочий ноутбук, и вдруг я перестала подключаться к серверу. Как ни странно, изначально я получал ошибки, которые только блокировали меня от совершения, например: Команда: Commit Ошибка: Commit failed (подробности следуют): Ошибка: MKACTIVITY of/svn//! Svn/act/c511b853-23b4-db4a-8991-0bc689a63353 ': Ошибка: не удалось проанализировать строку состояния ответа (http://*. **. Com) Завершено!:

Когда я перешел на работу в другую ветку (сервер SVN был доступен без проблем для всех в обеих ветвях, у кого есть надлежащая безопасность), я начал получать ошибку, например:

Команда: Checkout from http:// .com/svn/fineos//trunk, ревизия HEAD, полностью рекурсивная, внешние ссылки включены Ошибка: невозможно подключиться к репозиторию по URL-адресу Ошибка: "http://**.com/svn/fineos * /*/trunk ' Ошибка: ОПЦИИ Ошибка: "http:// *.com/svn/fineos * /*/trunk ': может Ошибка: не подключиться к серверу (http:// *.com) Завершено!:

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

Это помогло мне удалить клиент Tortoise, а затем удалить папку кеша Tortoise из локальных и роуминг-папок в папке C:\Users\ user\AppData. Кроме того, я переименовал TortoiseSVN node в реестр Windows, чтобы не удалось найти старую конфигурацию. Затем после переустановки клиент подключился к репо красиво. Я не уверен, что требуется выполнить оба действия, возможно, просто изменить реестр будет достаточно, я оставлю это вам, чтобы подтвердить.

Извинения за длительный отклик, но поскольку я не видел ответа на эту проблему после поиска в Google дольше, я думал, что это может быть полезно для разных случаев.

Ответ 6

Посмотрите на это:

Проблема: После вызова SVN в командной строке на сервере с брандмауэром ничего не видно в течение 15 секунд, затем программа завершает работу со следующей ошибкой:

svn: E170013: невозможно подключиться к репозиторию по URL-адресу SVN.REPOSITORY.REDACTED

svn: E730054: Ошибка при запуске контекста: существующее соединение было принудительно закрыто удаленным хостом.

Исследование: Исследование Интернета по вышеуказанным ошибкам не выявило какой-либо соответствующей информации.

Трассировка процесса (procmon) показала попытку подключения к серверу Akamai (облачных сервисов) после установления связи SSL/TLS с сервером SVN. Имя хоста для сервера не было показано в трассировке процесса. Обратный поиск DNS показал a184-51-112-88.deploy.static.akamaitechnologies.com или a184-51-112-80.deploy.static.akamaitechnologies.com как имя хоста, а IP был либо 184.51.112.88, либо 184.51. 112.80 (2 записи в кеше DNS).

Инструмент захвата пакетов (MMA) показал попытку подключения к имени хоста ctldl.windowsupdate.com после подтверждения SSL/TLS на сервере SVN.

API Crypto Windows пытался подключиться к Центру обновления Windows, чтобы получить информацию об отзыве сертификата (CRL - список отзыва сертификатов). Тайм-аут по умолчанию для получения CRL составляет 15 секунд. Таймаут для аутентификации на сервере - 10 секунд; поскольку 15 больше 10, это терпит неудачу.

Разрешение: Исследование Интернета выявило следующее: (также см. снимок внизу)

Решение 1: Уменьшить тайм-аут CRL. Групповая политика → Конфигурация компьютера → Параметры Windows → Параметры безопасности → Политики открытого ключа → Настройки проверки пути сертификата → Сетевое извлечение - см. рисунок ниже.

https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.microsoft.com/en-us/kb/2625048

blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx

Решение 2. Откройте брандмауэр для трафика CRL

support.microsoft.com/en-us/kb/2677070

Решение 3: флаги командной строки SVN (непроверенные)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - альтернативное решение флага командной строки svn.

Дополнительная информация: Отладка этой проблемы была особенно сложной. SVN 1.8 отключила поддержку библиотеки Neon HTTP RA (доступ к хранилищу) в пользу библиотеки Serf, которая удалила журналирование отладки клиента. [1] Кроме того, возвращенный код ошибки SVN не соответствует строке, указанной в svn_error_codes.h [2] Кроме того, коды ошибок SVN не могут быть легко сопоставлены с меткой ENUM, этот случай код ошибки SVN E170013 отображается в SVN_ERR_RA_CANNOT_CREATE_SESSION.

  • stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
  • people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  • code.google.com/archive/p/serf/issues/172

Предлагаемые изменения SVN:

  • Включить многозначность в команде, как и для всех операций

  • Добавить ошибку ENUM name to stderr

  • Добавить флаг конфигурации для регистрации отладки библиотеки Serf.

Ответ 7

Как указано David W. "Прежде всего, проверьте свой URL" - наша запись dns изменила разрыв всех соединений svn repo. Соединение на ip вместо url, как заявил Уес, - (теперь мы должны исправить наши DNS)

Ответ 8

Однажды я столкнулся с той же проблемой. Я пытался взять svn checkout, используя URL-адрес репозитория, состоящий из DOMAIN NAME. Я попытался подключиться с использованием IP-адреса вместо DOMAIN NAME, и я смог взять чек