Как вы исправляете ошибку конфликта SVN 409

Я использовал 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 (как предполагалось). Я создавал копию обоих с использованием пакета зависимостей 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-репо. Я смог проверить это, внести изменения и совершить без каких-либо проблем. Затем я попробовал свои старые репозитории, и они тоже работали.

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

Ответ 1

Здесь я на очень тонком льду (409 не очень конкретный), но я могу сформулировать два вопроса:

  • Есть ли какие-либо блокировки до или после фиксации?
  • " Autoversioning" включен?

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

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

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

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

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

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

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

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

Только для справки выдержка из Создание Apache так, как вы этого хотите:

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

Ответ 2

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

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

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

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

Ответ 3

Сначала установите базовый уровень. На складе 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 binaries/libs со своими собственными (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

Повторите тест checkout/commit.

В качестве последнего средства сбросьте и снова загрузите репозиторий.

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

Повторите тест checkout/commit, на этот раз с /svn/svn 3.

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

Обновление

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

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

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

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

Ответ 4

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

Ответ 5

chown -R apache:apache svn

chmod -R 770 svn

Ответ 6

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

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