¿Cómo se soluciona un error de conflicto SVN 409?

Solía ​​usar SVN 1.4 en OS X Leopard y todo estaba bien. Hace un par de semanas instalé una nueva copy de OS X 10.6. La versión de SVN que viene con Snow Leopard es 1.6.5. Seguí adelante y construí mi propia copy con 1.6.6. Estoy usando el server incorporado de apache y solo estoy alojando repositorys localmente.

Todo parecía funcionar bien hasta que realmente intenté comprometer algo. Cada vez que trato de hacer un cambio, recibo el siguiente post:

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

Esto sucede con mis viejos repositorys, así que creé algunos nuevos. El mismo trato. También traté de usar la versión 1.6.5 que viene con el sistema … lo mismo. Finalmente, intenté actualizar al último SVN estable (1.6.9) y todavía tengo el mismo problema.

El error de Apache registra lo siguiente para cada confirmación fallida:

 [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 occurnetworking 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] 

Y desde el logging de acceso:

 ::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 

Curiosamente, la confirmación realmente compromete los cambios, pero la copy de trabajo no lo ve y todo se torce.

Intenté search en Google todas las variaciones que se me ocurren para este problema, pero los resultados de la búsqueda son bastante inútiles. No estoy usando TortoiseSVN ni nada especial y comete errores en un nuevo repository, así que sé que no es un problema con mis viejos repositorys.

Cualquier ayuda sería muy apreciada.

Actualizar
He intentado agregar la autoversión a mi file svn.conf. Esto es lo que dicen mis files:

 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> 

Actualización (Solución)

Solo quería actualizar esto con la solución real en caso de que alguien más esté teniendo el mismo problema con los posts de error completamente inútiles. El problema fue con las partes apr y apr-util (como se sugirió el esquema). Estaba construyendo una copy de ambos usando el package de dependencies de subversión. OS X 10.6 también tiene su propia versión. Ambas versiones fueron 1.3.8. Aparentemente, sin embargo, necesitaba usar las versiones que estaba usando la installation apache pnetworkingeterminada.

Entonces, eliminé las carpetas apr y apr-util de mi compilation de subversión, para asegurarme de que no estaba comstackndo mi propia copy de estas de nuevo. Construí svn desde el origen de nuevo, esta vez usando la siguiente configuration:

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

Después de volver a comstackr, reinicié Apache y creé un nuevo repository svn. Pude comprobarlo, hacer cambios y comprometerme sin problemas. Luego probé mis viejos repositorys y esos también funcionaron.

¡Gracias a todos por la ayuda!

Aquí estoy muy delgado (409 no es muy específico) pero puedo formular dos preguntas:

  1. ¿Hay algún gancho antes o después de la confirmación?
  2. ¿ Está habilitada la " Autoversión "?

Si hay ganchos, ¿estás seguro de que no contienen ningún error? ¿Podrías deshabilitarlos para una testing? Si la autoevaluación no está habilitada, ¿podría intentar habilitarla para una testing? Esto debería funcionar a lo largo de las líneas de

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

cuando se usa mod_dav_svn (ver Enlace a Autoversión arriba).

Tal vez esto ayude a arrojar algo de luz sobre su problema y nosotros (y / o Google :)) podríamos tomarlo desde allí.

Por cierto: los loggings que publicaste no son del mismo compromiso, ¿verdad? La diferencia de time sería enorme?!?

Editar: disculpas si lo encontraste hace mucho time, pero voy a intentarlo : no se pudo fusionar el recurso en COMMIT (Apache 2.0.55), algo que Google encontró para mí 🙂

El OP allí escribe que "Apache dicta la versión de APR a usar". Esto significa que debe hacer reference a la versión APR correcta al comstackr SVN. Instalé SVN (v1.6.9) a través de MacPorts en mi sistema (OS X 10.6). No uso localmente WebDAV o Apache, pero tengo la APR 1.3.12_1 instalada (solo como reference). El OP sugiere utilizar --with-apxs=/path/to/bin/apxs al comstackr SVN, aunque no estoy seguro de si esto se aplica a su situación (comencé a adivinar hace mucho time, es posible que note :)).

¿Alguna posibilidad de que pueda verificar la versión APR que Apache espera contra la utilizada para build SVN (por ejemplo, podría utilizar el sudo port installed apr para ver qué versiones APR viven en su sistema si está utilizando MacPorts)?

Solo como reference, un extracto de Building Apache the Way You Want It :

apxs es una utilidad independiente para comstackr modules dinámicamente sin la necesidad de usar el script de configure o tener el código fuente de Apache disponible. Sin embargo, necesita los files de encabezado de Apache, que se copyn en la location definida por --includedir cuando Apache está instalado. Sin embargo, es importante usar un apxs que se haya creado con las mismas opciones de configuration que Apache ; de lo contrario, hará suposiciones erróneas sobre dónde se encuentran las diversas ubicaciones de installation de Apache.

Tengo dos ideas de dónde se puede esconder el problema, que por supuesto son conjeturas salvajes, así que ten cuidado.

Por un lado, puede ser solo un problema de permissions de files. Lo sé, suena tonto, pero tal vez haya algún file de configuration, o un enganche como el esquema sugerido, o incluso alguna carpeta dentro de la estructura del repository que quedó ilegible ya sea por la actualización a 10.6 o al comstackr la nueva versión svn, entonces Verificaría eso dos veces.

La segunda idea es verificar la compatibilidad de las versiones de svn working copy-client-server-repository. Los chicos de subversión juran que tanto 1.5 como 1.6 no rompen la compatibilidad en el nivel de repository con 1.4 (aunque lo hacen en copys de trabajo). Pero no estaría de más comprobar que el formatting de toda la stack sea consistente. Y mientras lo hace, asegúrese de que las bibliotecas de Apache que compiló sean compatibles con Apache 2.2.11 que viene con 10.6 (de nuevo, deberían hacerlo, pero nunca se sabe)

Y finalmente, buena suerte.

Primero establece una línea de base. En una installation en stock de Snow Leopard (10.6.3) aquí está exactamente lo que hice.

Creado "/etc/apache2/other/svn.conf" con contenido:

 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> 

Carpeta de subversión creada y "testing" de repository:

 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 

Desde el usuario normal, directory particular:

 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$ 

Ahora, si todo eso funcionó como debería, entonces tiene un repository de subversión stock stock 1.6.5 servido por apache. Si no fuera así, es muy probable que estés mezclando los binarys / libs svn suministrados por Apple con los tuyos (macports, etc.) o que hay problemas de permissions. Asegúrate de estar usando los binarys provistos por Apple. Apple modifica ligeramente la fuente y he tenido problemas de compatibilidad al mezclar 'puertos' con 'stock' en el pasado. En cuanto a los permissions, apache se ejecuta como usuario _www, grupo _www. Asegúrese de que todos los files y directorys sean de su propiedad, y no olvide actualizarlos cada vez que use svnadmin o alguna otra cosa para manipular directamente el repository svn.

Como eso está funcionando, vuelva a mover su repository 'svn2' a / usr / local / svn (si aún no lo hizo), haga un checkout limpio en alguna parte y pruebe un commit de testing.

Si aún tiene problemas, intente actualizar el repository.

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

Repita la testing de pago / confirmación.

Como último recurso, descargue y cargue el depósito nuevamente.

 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 

Repita la testing de pago / confirmación, esta vez con / svn / svn3.

Disfruta de tu repository fijo … con suerte 🙂

actualizar

Puede haber un error en el cliente de la línea de command de subversión. Después de hacer:

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

Tenga en count que la salida de svn log (al less para mí) no es nada. El logging de Svn de tortuga está bien, lo que indica que el server (como la configuration anterior) está funcionando correctamente.

Otra cosa que debes probar es acceder al repository a través de 'file' en lugar de 'http'. Copie el repository completo en su directory de inicio o en algún lugar donde su usuario sea el propietario, luego verifíquelo (es decir, svn checkout / Users / Shanetworking / svn / svn2) e intente confirmarlo.

¿Has probado Versiones el cliente SVN para OSX? No es una solución a su problema realmente, pero tal vez una alternativa. Mi equipo y yo tuvimos algunos problemas para que SVN y OSX se comuniquen entre ellos de forma adecuada, así que buscamos clientes alternativos y las versiones nos funcionó muy bien.

 chown -R apache:apache svn chmod -R 770 svn 

Esto me solucionó el conflicto: hice una copy de security de mis files locales y luego saqué todo del server. Luego, cuando inserté y empujé mis files de respaldo, el error de conflicto 409 no apareció nuevamente.

Saludos, Kevin