Странная ошибка 500 с svn commit на одном простом файле

Question

Мы используем сервер VisualSVN здесь, на работе, и все работает нормально, у нас более 50 репозиториев.Сегодня я попытался поместить в хранилище веб-сайт, но он продолжает зависать в одном отдельном файле, который я выделил.

Adding: C:\Work\LAN6505\web\trunk\common_files\includes\fr\debut.inc.php  
Sending content: C:\Work\LAN6505\web\trunk\common_files\includes\fr\debut.inc.php  
Error: Commit failed (details follow):  
Error: Server sent unexpected return value (500 Internal Server Error) in response to  
Error:  PUT request for  
Error:  '/svn/LAN6505/!svn/txr/13-i/web/trunk/common_files/includes/fr/debut.inc.php'  
Completed!:   

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

Если я скопирую файл в другой репозиторий с аналогичной структурой, проблема не возникнет ...

Кодфайл можно найти: http://pastebin.com/PwTCQSP7

Надеюсь, что кто-то может помочь ...

---

ОБНОВЛЕНИЕ

Event Type:       Error
Event Source:   VisualSVN Server 2.5
Event Category:               Apache 
Event ID:             1001
Date:                    1/23/2012
Time:                    9:37:10 AM
User:                    ACTIVIS-991RBEL\Mathieu Dumoulin
Computer:         DELL-PE2900-01
Description:
Could not get next bucket brigade  [500, #0]
[client 192.168.0.64]

---

ОБНОВЛЕНИЕ # 2

Оооочень, потратив 2,5 дня на перенос моего SVN-сервера в Windows на SVN-сервер в Linux, я снова столкнулся с той же проблемой:

[Пт 24 февраля 16:35:21 2012] [ошибка] [клиент 192.168.0.64] Не удалось получить следующую бригаду ведра (URI: / svn / LAN6505 /! Svn / wrk / 289e3161-cdbf-d44d-9716-c6390289ec92 / web/trunk/common_files/includes/fr/debut.inc.php) [500, # 0]

[Пт 24 февраля 16:36:12 2012] [ошибка] [клиент 192.168.0.64] Не удалось получитьбригада следующего ведра (URI: /svn/LAN6505/!svn/wrk/554a4a6c-a015-7045-b0c6-072ffe01f854/web/trunk/common_files/includes/fr/debut.inc.php) [500, # 0]

[Пт 24 февраля 16:48:17 2012] [ошибка] [клиент192.168.0.64] Не удалось получить следующую бригаду ведра (URI: /svn/LAN6505/!svn/wrk/15bd0f7e-06b9-b046-8c67-5f9778fab9b5/web/trunk/common_files/includes/fr/debut.inc.p)500, # 0]

Answer 1

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

Отключение Kaspersky Internet Security 2012 помогает, но не всегда.

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

Другим решением является предотвращение фрагментации IP.Вы можете проверить, что ваши пакеты фрагментированы, используя команду ping: ping host_name -f

Если есть фрагментация пакета, вы можете уменьшить размер MTU.Эта ссылка дает хорошее описание того, как изменить размер MTU.

К сожалению, все вышеупомянутые решения не являются надежными на 100%.Эта ошибка выглядит загадкой и для меня.Я не могу понять, почему SVN так чувствителен к этим вещам.

Answer 2

У меня была похожая проблема, и я подтверждаю, что отключение Kaspersky Internet Security 2012 на время коммита решает проблему в моем случае. Если кто-то также сталкивается с такой проблемой, следует проверить, не блокирует ли антивирус / брандмауэр передачу svn.

Answer 3

Это похоже на эту ошибку:

• https://issues.apache.org/bugzilla/show_bug.cgi?id=33098

Оказалось, что это входной фильтр (связанный с кодированием по частям); если загрузка заканчивается раньше ожидаемого, загрузка завершится неудачно, поскольку сервер ожидает больше данных, даже если конец потока был отправлен.

хорошо, тогда ошибка во входном фильтре.

У меня было (неправильное) впечатление, что эта ошибка появляется, только если указано content-length. Но это также появляется при чанкованном кодировании, если передается первый чанк полностью и тело усекается позже.

Я ожидаю, что вам могут помочь две вещи:

• Обновление VisualSVN, чтобы исправить это для вас; сообщается, что связанная ошибка имеет исправление для apache в r792409

  *) core: вернуть APR_EOF, если тело запроса короче объявленной длины клиентом. PR 33098 [Stefan Fritsch]

• Отсутствие у меня (недавнего) опыта работы с VisualSVN заставляет меня усомниться в том, что что-то может происходить с конкретным файлом (он может содержать оскорбительные символы; это Windows, я полагаю, что ascii 26 (^ Z) может интерпретироваться как EOF) Посмотрите, содержит ли ваш файл какие-нибудь «забавные» символы, или вы можете перевести его в двоичный режим (либо для отдельного файла, либо для всего сервера).

Answer 4

Мне кажется, я нашел возможный источник этой ошибки (по крайней мере, в моем случае):
Это связано с нехваткой дискового пространства на диске / разделе, где находится ваше хранилище.

Мой случай:
Обнаружена ошибка
Попытка поиска, если фиксация прошла успешно с помощью VisualSVN
Репо все еще находилось в состоянии до фиксации
Случайно проверено дисковое пространство, было ноль
Удалить какой-нибудь случайный файл для освобожденияобъем оперативной памяти (около 10 МБ)
Коммит работает сейчас

TL; DR: Освободите часть памяти на диске, на котором хранится репозиторий, недостаточно памяти, вероятно, является причиной этой ошибки

Answer 5

В конце концов, мы выяснили, что простое изменение файла и фиксация работ могут все еще быть связаны с брандмауэром, поскольку это единственный последний элемент на пути.Но изменение подписи файла работает ...

действительно очень странная проблема ...

Answer 6

В последние несколько дней я страдаю от этой проблемы и, наконец, мне удалось ее исправить.

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

Как только я правильно сделал чау со следующим:

sudo chown -R www-data:www-data /home/svnrepo

Мои проблемы исчезли.

Answer 7

Антивирусная (Kaspersky) программа вызывала большинство проблем в нашей локальной офисной сети. Отключение антивирусной программы решило проблему (в большинстве случаев).

Answer 8

Я решил эту проблему, отключив Kaspersky Internet Security на клиентском ПК при коммитах, но не решу, если это также решит проблему в вашем случае.