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

Question

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

Все, казалось, работало нормально, пока я на самом деле не пытался что-то совершить. Everytime я пытаюсь совершить изменения, я получаю следующее сообщение:

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 или что-то особенное и не завершает работу в новом репозитории, поэтому я знаю, что это не проблема с моими старыми репозиториями.

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

Update
Я попытался добавить к моему автоматическое управление версиями файла 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>  

Update (Solution)

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

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

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

Answer 1

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

1. Существуют ли какие-либо до или после совершения крючки на месте?
2. «Autoversioning» включен?

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

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

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

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

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

Edit: Извинения, если вы обнаружили, что давно, но я дам ему выстрелили: Could not MERGE resource on COMMIT (Apache 2.0.55) является то, что Google нашел для меня :)

ОП там пишет, что «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)?

Просто для справки отрывок из Building Apache the Way You Want It:

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

создал папку подрывной и хранилище "тест":

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 reposito ry служил apache. Если это не так, то вы, скорее всего, или смешаете яблоко, поставляемое с svn binaries/libs со своим собственным (macports и т. Д.) или, есть проблемы с разрешениями. Сделайте конечно вы используете двоичные файлы, предоставленные яблоком. 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.

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

обновление

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

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

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

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

Answer 5

chown -R apache:apache svn 

chmod -R 770 svn 

Answer 6

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

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