Проблема фиксации Subversion: данные XML не были правильно сформированы

Question

Я испытываю странное поведение SVN. У меня есть SVN-репозиторий, работающий на Apache 2.2.9 с mod_dav, mod_dav_svn и SVN 1.5.2. Когда я пытаюсь проверить (с удаленного клиента 1.5.4 или локального сервера 1.5.2 - оба svn-файла по умолчанию), я получаю что-то вроде:

mx-mac: тест mx $ svn ci -m "" Добавление test.txt svn: Сбой при фиксации (подробности приведены ниже): SVN: данные XML не были правильно сформированы

Что я обнаружил, прослушивая HTTP-соединение, так это то, что один запрос к удаленному SVN-хранилищу (Apache) завершается сообщением «Reset by peer» и не возвращает ответ (используется HTTP Scoop для прослушивания).

Что касается конфигурации Apache, все модули загружены. Для репо установлены правильные разрешения, и репозиторий был создан командой svnadmin create, а затем заблокирован для пользователя apache (в любом случае, он не работал, даже если у меня есть каталог репозитория chmod -R 777).

Конфигурация Apache содержит директивы DAV и SVNPath вместе с аутентификацией.

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

Answer 1

Наконец, я выяснил, что переопределенный ErrorDocument в файле .htaccess для того же VirtualHost, что и SVN, приводил к тому, что некорректные данные иногда отправлялись клиенту SVN и по какой-то причине перехватывали процесс фиксации.

Answer 2

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

Что касается apache, я бы поспорил, что это невиновно в любой проблеме. Неудачные коммиты почти всегда связаны с чем-то другим, чем с подключением к хранилищу. (Предполагая, что никто не возился с apache или сервером svn.) Нет гарантии, но попытка свежего извлечения и ручного копирования файлов может просто сработать или, по крайней мере, открыть новую диагностическую информацию.

Answer 3

Я получил то же сообщение об ошибке:

svn: не удалось зафиксировать (подробности приведены ниже): svn: данные XML были сформированы неправильно

Причина была: накопитель на SVN-репозитории переполнен. Еще немного места на диске, и проблема была решена.

Answer 4

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

Answer 5

Я обнаружил, что это вызвано тем, что вы не используете правильный URL для проверки содержимого. Я использовал URL-адрес, который обслуживал веб-сервер, когда набирал команду извлечения, например "svn co http://blah.com/stuff_in_here/contents" Затем я играл с URL, пока не нашел реальное местоположение SVN, которое я мог бы использовать в командной строке, например «http://blah.com/svn/contents"

Answer 6

Дарен, ты сейчас не совсем прав. Я перепробовал все возможные комбинации рабочих копий, новых репозиториев и так далее. Я пробовал в основном все. Наконец, я нашел одно странное сообщение в сообщениях отладки NEON, отображающее мою страницу 404 на домашней странице, о которой я в основном забыл. Затем я понял - как он был создан давно - я отправил неправильный код состояния HTTP со страницы 404 (200 вместо 404), поэтому NEON посчитал это правильным выводом и обработал, оставив его в каком-то неправильном состоянии. *

Итак, сейчас это была проблема apache, вызванная глупым веб-разработчиком - мной в 2003 году ...:)