Как исправить ошибку SVN 409 Conflict

Question

Раньше я использовал SVN 1.4 на OS X Leopard, и все было хорошо. Пару недель назад я установил свежую копию OS X 10.6. Версия SVN, поставляемая со Snow Leopard, - 1.6.5. Я пошел дальше и построил свою собственную копию с 1.6.6. Я использую встроенный сервер Apache и просто размещаю репозитории локально.

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

Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost)

Это происходит с моими старыми репозиториями, поэтому я создал пару новых. Та же сделка Я также попытался использовать версию 1.6.5, которая поставляется с системой ... то же самое. Наконец, я попытался перейти на последнюю стабильную версию SVN (1.6.9) и все еще получил ту же проблему.

Ошибка Apache регистрирует следующее для каждой неудачной фиксации:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2".  [409, #0]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction.  [409, #2]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory  [409, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1.  [500, #0]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction.  [500, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory  [500, #2]

А из журнала доступа:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172

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

Я пытался найти в Google все варианты для этой проблемы, но результаты поиска практически бесполезны. Я не использую TortoiseSVN или что-то особенное, и коммиты не работают в новом репозитории, поэтому я знаю, что это не проблема с моими старыми репозиториями.

Любая помощь будет принята с благодарностью.

Обновление
Я попытался добавить автоверсионность в мой файл svn.conf. Вот что говорят мои файлы:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNAutoversioning on

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /usr/local/etc/svn-auth-file

  # only authenticated users may access the repository
  Require valid-user
</Location>    

Обновление (решение)

Я просто хотел обновить это фактическим решением на тот случай, если у кого-то возникнет та же проблема с совершенно бесполезными сообщениями об ошибках. Проблема была с частями apr и apr-util (как было предложено scherand). Я создавал копию обоих, используя пакет зависимостей subversion. OS X 10.6 также имеет свою собственную версию. Обе версии были 1.3.8. Очевидно, что мне нужно было использовать версии, которые использовались при установке Apache по умолчанию.

Итак, я удалил папки apr и apr-util из моей сборки subversion, чтобы убедиться, что я не собираю свою собственную копию этих файлов снова. Я снова собрал svn из исходного кода, на этот раз используя следующую конфигурацию:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl

После сборки я перезапустил apache и создал новый репозиторий SVN. Я смог проверить это, внести изменения и зафиксировать без каких-либо проблем. Затем я попробовал свои старые репозитории, и они тоже сработали.

Спасибо всем за помощь!

Answer 1

Я нахожусь здесь на очень тонком льду (409, будучи не очень конкретным), но я могу сформулировать два вопроса:

1. Есть ли какие-либо хуки до или после фиксации?
2. Включен ли " Автоверсия "?

Если есть какие-либо хуки, вы уверены, что они не содержат ошибок?Не могли бы вы отключить их для теста?Если Autoversioning не включен, вы можете попробовать включить его для теста?Это должно работать в соответствии с

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

при использовании mod_dav_svn (см. Ссылку на автоверсионирование выше).

Возможно, это поможет пролить свет на вашу проблему, и мы (и/ или Google :)) может взять его оттуда.

Кстати: вы публикуете журналы не с того же коммита, верно?Разница во времени будет огромной?!?

Редактировать: Извините, если вы нашли это давно, но я сделаю это: Не удалось MERGE ресурс на COMMIT (Apache 2.0.55) - это то, что Google нашел для меня:)

ОП пишет, что "Apache диктует версию APR для использования".Это означает, что вы должны ссылаться на правильную версию APR при компиляции SVN.Я установил SVN (v1.6.9) через MacPorts в моей системе (OS X 10.6).Я не использую WebDAV или Apache локально, но у меня установлен APR 1.3.12_1 (только для справки).ОП предлагает использовать --with-apxs=/path/to/bin/apxs при компиляции SVN, хотя я не уверен, применимо ли это к вашей ситуации (я начал догадываться давно, вы могли заметить:)).

Любой шанс проверить APR-version Apache ожидает от того, который использовался для сборки SVN (например, вы могли бы использовать sudo port installed apr, чтобы увидеть, какие APR-версии существуют в вашей системе, если вы используете MacPorts)?

Просто для справки:1037 * Создание Apache так, как вы этого хотите :

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

Answer 2

Сначала установите базовый уровень.В стандартной установке Snow Leopard (10.6.3) я сделал именно это.

Создано "/etc/apache2/other/svn.conf" с содержимым:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
    DAV svn
    SVNParentPath /usr/local/svn
    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /usr/local/svn/htpasswd
    Require valid-user
</Location>

Созданопапка subversion и репозиторий "test":

sudo mkdir /usr/local/svn
sudo svnadmin create /usr/local/svn/test
sudo chown -R _www:_www /usr/local/svn
sudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass

От обычного пользователя, домашний каталог:

macmini:~ jclark$ mkdir Checkout && cd Checkout
macmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/test
Authentication realm: <http://localhost:80> Subversion repository
Password for 'testuser':
Checked out revision 0.
macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txt
A         test.txt
Adding         test.txt
Transmitting file data .
Commited revision 1.
macmini:test jclark$

Теперь, если все это работает как надо, значит, у вас есть рабочий запас1.6.5 хранилище Subversion обслуживается Apache.Если это не так, то вы, скорее всего, либо смешиваете поставляемые Apple двоичные файлы / библиотеки svn с вашими собственными (macports и т. Д.) или , но есть проблемы с разрешениями. убедитесь, что вы используете двоичные файлы, предоставляемые Apple.Apple немного модифицирует источник, и я сталкивался с проблемами совместимости при смешивании «портов» с «запасом» в прошлом.Что касается разрешений, apache запускается как пользователь _www, group _www.Убедитесь, что все файлы и каталоги принадлежат как таковые, и не забывайте обновлять их всякий раз, когда вы используете svnadmin или что-то еще для непосредственной манипуляции с хранилищем svn.

Поскольку это работает, переместите 'svn2'вернитесь в репозиторий / usr / local / svn (если вы этого еще не сделали), выполните где-нибудь чистую проверку и попробуйте выполнить тестовый коммит.

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

sudo svnadmin upgrade /usr/local/svn/svn2
sudo chown -R _www:_www /usr/local/svn/svn2

Повторите проверку извлечения / фиксации.

В качестве крайней меры, сбросьте и снова загрузите хранилище.

sudo svnadmin dump /usr/local/svn/svn2 > /tmp/svn2.dump
sudo svnadmin create /usr/local/svn/svn3
sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dump
sudo chown -R _www:_www /usr/local/svn/svn3

Повторите проверку извлечения / фиксации,на этот раз с /svn/svn3.

Наслаждайтесь вашим исправленным хранилищем ... надеюсь:)

update

Возможно, ошибка в клиенте командной строки Subversion.После выполнения:

mkdir \!vcc && touch \!vcc/default
svn add \!vcc && svn commit -m 'test'
svn log

Обратите внимание, что вывод журнала svn (по крайней мере для меня) - ничто.Svn log от черепахи в порядке, что указывает на то, что сервер (как описано выше) работает правильно.

Другая вещь, которую нужно попробовать, - это доступ к хранилищу через «файл» вместо «http».Скопируйте весь репозиторий в свой домашний каталог или в другое место, где ваш пользователь является владельцем, а затем проверьте его (т. Е. Svn checkout / Users / Shared / svn / svn2) и попытайтесь зафиксировать.

Answer 3

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

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

Вторая идея - проверить совместимость рабочих версий svn copy-client-server-repository. Ребята из Subversion клянутся, что и 1.5 , и 1.6 не нарушают совместимость на уровне репозитория с 1.4 (хотя они делают это на рабочих копиях). Но не мешало бы проверить, что формат всего стека согласован. И пока вы это делаете, убедитесь, что созданные вами библиотеки Apache совместимы с Apache 2.2.11, который поставляется с 10.6 (опять же, они должны, но вы никогда не знаете)

И, наконец, удачи.

Answer 4

Это разрешило мне конфликт: я сделал резервную копию своих локальных файлов, затем вытащил все с сервера. Затем, когда я вставил и передал свои файлы резервных копий, ошибка конфликта 409 больше не появлялась.

С уважением, Kevin

Answer 5

chown -R apache:apache svn

chmod -R 770 svn

Answer 6

Вы пробовали Версии клиента SVN для OSX? Это не решение вашей проблемы на самом деле, но, возможно, альтернатива. У меня и моей команды были некоторые проблемы с тем, чтобы SVN и OSX правильно общались друг с другом, поэтому пошли искать альтернативных клиентов, и версии отлично сработали для нас.