Ошибка проверки TortoiseSVN svn: E120106: ra_serf: сервер отправил усеченное тело ответа HTTP

Ответ 1

Некоторые идеи от разработчика TortoiseSVN:

Отправленные данные слишком велики, и сервер закрывает соединение из-за достигая предела.

Возможные шаги, которые могут помочь устранить эту проблему:

• Увеличить значение таймаута на сервере
• установить уровень сжатия на ноль на сервере (сделает все медленнее, но поможет с этой проблемой)
• убедитесь, что все прокси, находящиеся между вами и сервером svn, также имеют увеличенные значения тайм-аута.

Ответ 2

Затем возьмите обновление вместо повторной проверки... Не удаляйте копию с проверкой, просто обновите ее еще раз.

Ответ 3

У меня возникла одна и та же проблема, но в контексте нашей командной команды CI. вместо того, чтобы использовать команду teamcity для проверки, некоторые скрипты выполняют ручную проверку svn и вызывают эту ошибку.

Внутренняя очистка SVN отменена в больших хранилищах для работы скопируйте формат 1.7 с помощью svn.exe через script вместо встроенного teamcity SVN с сообщением: "svn: E120106: ra_serf: сервер отправлен усеченное тело ответа HTTP."

• чистая проверка работы небольшого репозитория независимо от формата рабочей копии
• чистое оформление большого хранилища с использованием формата рабочей копии 1.5
• использование экспорта вместо работ по проверке
• Использование teamcity 8.1.5. Работа с внутренними клиентами svn (не знаю почему)
• Использование svn client 1.7 вместо 1.8 приводит к аналогичной ошибке, связанной с таймаутом: "svn: E175002: REPORT of '/! svn/me': Не удалось прочитать тело ответа: защищенное соединение усечено"

Увеличение значения тайм-аута SVN на сервере действительно устранило проблему, и с тех пор не произошло ни "ra_serf", ни "усеченная ошибка с защищенным соединением".

Предложение Aniket Thakur о возврате версии клиента svn действительно повлияло на эту проблему, но я не смог найти нужную версию. (если есть)

Предложение Sanmat Jhanjhari об уменьшении уровня сжатия является не только частью принятого решения, но и причиной того, что это может сработать, так это то, что он поддерживает время отклика между сервером SVN и клиентом и сжатие больших файлов больше не вызывает тайм-аутов.

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

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

Ответ 4

Обязательно используйте самую последнюю и самую актуальную версию клиента Subversion. Если проблема все еще возникает, вы должны

• обратитесь к системному администратору, чтобы проверить сеть на наличие проблем подключения.
• убедитесь, что прокси-сервер, который у вас есть между клиентской машиной и сервером Subversion, работает нормально и не убивает соединение преждевременно,
• убедитесь, что антивирус, который вы, возможно, установили на клиентском или серверном компьютере, не мешает трафику Subversion HTTP (S). Вы должны добавить правило исключения/исключения, которое отключит проверку доступа или трафика на сервер Subversion и обратно.

ПРИМЕЧАНИЕ.. Понижающий клиент Subversion является неправильным и уродливым обходным решением. Проблема должна быть решена в сети.

Ответ 5

Неправильные настройки прокси могут вызывать одно и то же сообщение об ошибке.

В ходе проверки я столкнулся с той же ошибкой в ​​разные моменты времени. Первые несколько файлов всегда были успешными, но после 5-10 файлов появилась ошибка ra_serf. То же самое произошло с большими и маленькими файлами.

После некоторых проб и ошибок (другое оборудование, проводное соединение) я не был ближе к решению. Я решил проверить все настройки SVT Tortoise и нашел простой ответ: настройки моего прокси были неправильными!

Ответ 6

В SVN 1.8 включена новая клиентская библиотека HTTP (Serf).

который, как мне кажется, отвечает за это. Я установил TortoiseSVN-1.8.6.25419-x64-svn-1.8.8.msi, а выполнение svn merge выдало ту же ошибку. Первоначально я, хотя это проблема с тайм-аутами сервера svn, но такая же операция слияния работала с 1.6. Поэтому я думаю, проблема связана с SVN версии 1.8 и выше. Пожалуйста, верните версию клиента svn версии 1.7 или 1.6 и попробуйте!

Ответ 7

Задайте следующее значение ключа в файле конфигурации SVN. Что это.

DeflateCompressionLevel 5

1 - самое низкое значение. 9 - максимальное значение.