Обновление из репозитория SVN возвращает ошибку «Не удалось прочитать размер куска»

Question

При обновлении из хранилища Subversion с использованием Tortoise SVN-клиента я получаю сообщение об ошибке, похожее на это:

Could not read chunk size: An existing connection was forcibly closed by the remote host.

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

Что может быть причиной такого поведения и как его исправить?

Answer 1

Я получал сообщение «Не удалось прочитать размер куска» от клиентов на нескольких машинах.

Ключ к разгадке был в журнале ошибок Apache:

[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response.  [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision  [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files  [500, #24]

В процессе Apache, обрабатывающем операцию svn, заканчивались файловые дескрипторы. На моем сервере Ubuntu я исправил это, отредактировав /etc/security/limits.conf и добавив его внизу:

*               hard    nofile          5000
*               soft    nofile          5000

Что увеличивает лимит файловых дескрипторов с 1024 до 5000. Затем я вошел в систему на новой оболочке и подтвердил, что лимит увеличен через ulimit -n. Затем перезапустил Apache.

Answer 2

Я только что получил сообщение «Не удалось прочитать размер куска» И НАЙТИ РЕШЕНИЕ - по крайней мере для одного сценария.

Сначала моя конфигурация ...

СЕРВЕР: CollabNet Subversion Edge Server 2.0.0-2190.74 (двоичные файлы Subversion 1.6.17-2190.74), работающий на 32-разрядной Windows Server 2003.

КЛИЕНТ: TortoiseSVN 1.6.16, сборка 21511 - 32-разрядная (Subversion 1.6.17), работающая в 32-разрядной ОС Windows XP Pro с пакетом обновления 3 (SP3).

Шаги для воспроизведения ...

Я получил эту ошибку после перетаскивания правой кнопкой мыши версионной подпапки в другую версионную подпапку в моей локальной папке рабочей копии и выбора 'SVN Копировать версионные элементы здесь' (это TortoiseSVN команда контекстного меню в проводнике Windows при перетаскивании папок вправо). Подпапка содержала один текстовый файл в кодировке ANSI, MANIFEST.MF, который, как мне кажется, я не изменил (моя конфигурация Subversion не включает тип mime для файлов .MF). Впоследствии я зафиксировал только что скопированную подпапку. Позже, всякий раз, когда я пытался обновить локальные папки рабочей копии Subversion на этом компьютере, я получал ошибку размера чанка.

Работа вокруг ...

Я решил эту проблему, перезапустив службу Subversion / Apache (которая сама по себе не помогла и, возможно, не понадобилась), а затем удалив только что добавленную подпапку из локальной папки рабочей копии ( я уже добрался до репо, поэтому я ничего не потерял), и ТО выполнили обновление , которое прошло успешно без ошибки размера чанка и повторно загрузило только что удаленную подпапку.

В моем случае я скопировал ДВЕ версионные подпапки таким образом, и я не смог успешно обновить корень моей локальной папки рабочей копии, пока не удалил ОБА из этих новых подпапок.

Последующие меры ...

Я предполагаю, что это ошибка сервера Subversion и / или клиента TortoiseSVN, но у меня нет навыков отладки, чтобы сделать это определение. Я сообщу о своих выводах в системе отслеживания проблем TortoiseSVN и посмотрю, к чему это приведет.

Answer 3

Я только что это случилось со мной, и это была не проблема с сервером; моя рабочая копия была повреждена (мной случайно).

Answer 4

Проблема и (некоторые другие) исчезли после отключения клиентского антивируса.

Я использую сервер Ubuntu с Subversion 1.7.4 через Apache.

Answer 5

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

Если в журнале ошибок ничего нет, проверьте настройки антивирусного сканера / брандмауэра: некоторые из этих инструментов прервут соединение, если они считают, что переданные данные опасны.

Answer 6

Для нас проблемой был тайм-аут на Apache. Обновление заняло около 15 минут, но время ожидания Apache истекло через 10 минут, в результате чего наш сервер SVN выдал ошибку, которую вы видите. Окончательным решением было увеличение времени ожидания для Apache. Мы используем сервер VisualSVN - подробные инструкции по изменению этого параметра смотрите здесь: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html

Answer 7

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

Итак, эта ошибка, похоже, была вызвана повреждением моего локального каталога.

Answer 8

Я перешел на сервер Ubuntu, и у нас была такая же ошибка - на разных клиентских ПК, ОС и клиентских версиях.

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

(см. http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/)

Я в конечном итоге решил проблему, используя пакет apache2-mpm-prefork, а не пакет apache2-mpm-worker.

Answer 9

VisualSVN 2.5.8: Если произошла та же ошибка, следующие шаги помогли мне исправить эту ошибку:

На сервере:

1. Удалил на сервере проблемную папку;
2. Перезагрузите сервер VisualSVN.

На рабочей станции:

1. Обновить родительскую папку;
2. Добавить папку и файлы снова;
3. Добавить в SVN;
4. Commit.

Answer 10

Для нас обходным решением было понижение SVN клиент с 1,8 до 1,7 (клиент командной строки, который входит в комплект TortoiseSVN).