Я использую svn 1.8.9 и при проверке кода соединительной линии я получаю следующую ошибку
svn: E120106: ra_serf: сервер отправил усеченное тело ответа HTTP.
Из-за ошибки выше я не могу проверить весь код соединительной линии. Пожалуйста, предложите подход для решения этой проблемы.
Спасибо
У меня была такая же проблема, и поскольку это большая проверка, но у меня нет доступа к расширению тайм-аута сервера, он решил ее:
$ svn cleanup
$ svn up
Каждый раз, когда я получаю эту ошибку (пока проверка не будет завершена).
Это проблема сервера Apache, связанная с таймаутом (клиент SVN не работает так, как нужно, с огромным количеством больших файлов). Поместите здесь на httpd.conf и перезапустите httpd, и проблема будет решена, без необходимости в будущем делать очистку и обновление:
Timeout 12000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
это мое решение:
1 - используйте очистку или очистку sudo
svn cleanup
2- использовать обновление или обновление sudo
svn update
Попробуйте настроить параметр клиента http-timeout на большое значение, как описано здесь: https://mail-archives.apache.org/mod_mbox/subversion-users/201410.mbox/%[email protected]om%3E
~/.subversion/серверов:
[global]
http-timeout = 6000
http://www.hostingezpublish.com/FAQ/Solving-checkout-problems-with-svn-repositories
В 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 и попробуйте!
Причина этой ошибки заключается в том, что открытие одного из внутренних файлов SVN на сервере завершается с ошибкой. Это проблема с сервером, но не ошибка.
Если ваше программное обеспечение сервера SVN - это расширение Apache WebDAV в Linux:
Вам нужно перейти в местоположение на сервере, где apache хранит базу данных репозитория. Используйте sudo chown -R www-data:www-data folder_name, чтобы изменить владельца папки. Проблема с фиксациями от клиентов исчезнет.
Что я знаю об этой ошибке.
Это может произойти во время больших проверок или больших слияний, когда вы отправляете код через svn webdav. Обычно увеличение тайм-аута сервера поможет.
Возможно, немного поздно, но если вы отчаянно пытаетесь решить проблему с помощью Google, и ваш сервер Subversion недавно обновился до Debian Buster, вы можете попытать счастья с помощью этой опции в своем хосте хранилища Apache Subversion:
SVNAllowBulkUpdates prefer
Поместите это после директивы SVNParentPath, выполните sudo service apache2 reload и попробуйте снова.
Источник: https://audeuro.com/node/44
Что делает этот параметр (цитата из руководства по подрывной деятельности):
Включает поддержку комплексных ответов на REPORT в стиле обновления Запросы. Клиенты Subversion используют запросы REPORT для получения информации о проверке дерева каталогов и обновлениях от mod_dav_svn. Они могут попросить сервер отправить эту информацию одним из двух способов: всю информацию о дереве в одном массивном ответе, или с Скелта (скелетное представление дерева дельта), который содержит только достаточно информации для клиента, чтобы знать, какие дополнительные данные для запрос с сервера. Когда эта директива включена со значением из Off, mod_dav_svn будет только когда-либо отвечать на эти запросы отчета с skelta ответами, независимо от типа запрошенных ответов клиентом.
Большинству людей вообще не нужно использовать эту директиву. Это в первую очередь существует для администраторов, которые желают - в целях безопасности или аудита - заставить клиентов Subversion извлекать все файлы по отдельности и каталоги, необходимые для обновлений и проверок, таким образом оставляя аудит след запросов GET и PROPFIND в логах Apache. Значение по умолчанию этой директивы On.
Это звучит немного устарело. Я подозреваю, что если у вас достаточно большой репозиторий, размер всеобъемлющего отчета может быть просто слишком большим для транзита, поэтому "большинству людей вообще не нужно использовать эту директиву" комментарий больше не применяется.
В моей ситуации это было вызвано некоторой "прозрачной" инфраструктурой между сервером SVN и моей рабочей станцией. Я подозреваю, что это был прокси (websense/mcafee/forcepoint).
Большинство коммитов были в порядке, но при этом не удавалось передавать содержимое одного особенно большого коммита, предположительно, содержимое было слишком большим и вызывало сбой/разрыв соединения прокси-сервером.
Я смог решить, обойдя эту инфраструктуру. В моем случае я смог установить альтернативный прокси в моем .git/config, который обходит проблемную инфраструктуру.
Вы не писали, какая версия - ваш SVN-сервер. Вероятно, ваша проблема будет решена при понижении вашего клиента до 1.7 - вам придется удалить локальный репозиторий и синхронизировать его снова из-за несовместимости между версиями 1.8 и 1.7.
сегодня я столкнулся с той же проблемой, используя SVN 1.9.9 и собирая некоторые данные 'diff' по командной строке SVN с сервера Apache SVN. Что ж, предложение от Kompjuteras установить параметры конфигурации Apache следующим образом [==, чтобы увеличить время ожидания]:
"Тайм-аут 12000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15 "
решил проблему (вместо Timeout 12000 я установил 3600 [== 1h]). Кроме того, выше был задан вопрос от "Ethan Field" о значении параметров. Они очень хорошо объяснены здесь: http://httpd.apache.org/docs/2.4/mod/directives.html
Ну, я думаю, что проблема, описанная здесь, вызвана слишком коротким временем ожидания, настроенным на сервере Apache SVN. (По умолчанию это всего 60 == 1MIN с версии 2.4 !!!!!)
Удачи и большое спасибо!
Если вы используете NGINX в качестве http-прокси, проверьте разрешения
# chown -R nginx:nginx /var/lib/nginx