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

Question

Solía ​​usar SVN 1.4 en OS X Leopard y todo estaba bien. Hace un par de semanas instalé una nueva copia 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 copia con 1.6.6. Estoy usando el servidor de Apache incorporado y solo estoy alojando repositorios localmente.

Todo parecía funcionar bien hasta que realmente intenté confirmar algo. Cada vez que intento de cometer un cambio, aparece el siguiente mensaje:

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

Esto sucede con mis viejos repositorios, así que creé un par de otras nuevas. 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. registra

El error de Apache lo siguiente para cada fallidos comprometerse:

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

Y desde el registro 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, el commit que realmente hace confirmar los cambios, pero la copia de trabajo doesn No veo eso y todo se torce.

He intentado buscar 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 repositorio, así que sé que no es un problema con mis viejos repositorios.

Cualquier ayuda sería muy apreciada.

actualización
He intentado añadir autoversionado a mi archivo svn.conf. Esto es lo que dice mi archivos:

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 (Solución)

Sólo quería actualizar esto con la solución real en cualquier caso más está teniendo el mismo problema con los mensajes de error no valen para nada. El problema fue con las partes apr y apr-util (como se sugirió el esquema). Estaba construyendo una copia de ambos usando el paquete de dependencias 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 instalación apache predeterminada.

Así que eliminé las carpetas apr y apr-util de mi compilación de subversión, para asegurarme de que no estaba construyendo mi propia copia de estas de nuevo. Construí SVN fuente de nuevo, esta vez utilizando la siguiente configuración:

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

Después de construir de nuevo, me reinicia Apache, y ha creado un nuevo repositorio SVN. Pude comprobarlo, hacer cambios y comprometerme sin problemas. Luego probé mis viejos repositorios y esos también funcionaron.

¡Gracias a todos por la ayuda!

Answer 1

estoy en hielo muy delgada aquí (409 siendo no muy específico) pero soy capaz de formular dos preguntas:

1. ¿Hay cualquier pre o post-commit ganchos en su lugar?
2. ¿Está habilitado el "Autoversioning"?

Si hay ganchos, ¿está seguro de que no contienen ningún error? ¿Podrías deshabilitarlos para una prueba? Si la autoevaluación no está habilitada, ¿podría intentar habilitarla para una prueba? Esto debería funcionar en la línea de

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

cuando se utiliza mod_dav_svn (ver enlace a autoversionado arriba).

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

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

Editar: Disculpas si usted encontró que hace mucho tiempo pero voy a darle un tiro: Could not MERGE resource on COMMIT (Apache 2.0.55) es algo que Google ha encontrado para mí :)

El PO no escribe que "Apache dicta la versión de APR usar". Esto significa que debe hacer referencia a la versión APR correcta al compilar 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 referencia). El OP sugiere usar --with-apxs=/path/to/bin/apxs al compilar SVN, aunque no estoy seguro de si esto se aplica a su situación (comencé a adivinar hace mucho tiempo, es posible que note :)).

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

Sólo como referencia un extracto de Building Apache the Way You Want It:

apxs es una utilidad independiente para módulos que compilan dinámicamente sin la necesidad de utilizar el script configure o tienen el código fuente de Apache disponible. Sin embargo, necesita los archivos de encabezado de Apache, que se copian en la ubicación definida por --includedir cuando Apache está instalado. Sin embargo, es importante utilizar un apxs que se creó con las mismas opciones de configuración que Apache; de lo contrario, hará suposiciones erróneas sobre dónde se encuentran varias ubicaciones de instalación de Apache .

Answer 2

¿Has probado Versions 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.

Answer 3

Tengo dos ideas de dónde puede estar escondido el problema, que por supuesto son conjeturas descabelladas, así que ten cuidado.

Por un lado, puede ser solo un problema de permisos de archivos.Lo sé, suena tonto, pero tal vez haya algún archivo de configuración, o un enganche como el esquema sugerido, o incluso alguna carpeta dentro de la estructura del repositorio que quedó ilegible por la actualización a 10.6 o cuando se compila la nueva versión svn, entonces Verificaría eso dos veces.

La segunda idea es comprobar 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 repositorio con 1.4 (aunque lo hacen en copias de trabajo). Pero no estaría de más comprobar que el formato de toda la pila 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, pero nunca se sabe)

Y, por último, buena suerte.

Answer 4

Primero establezca una línea base. En una instalación 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> 

Creado carpeta de la subversión y el repositorio de "prueba":

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 usuario normal, directorio de inicio:

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 usted tiene un depósito de trabajo de 1,6.5 subversion servido por apache. Si no fue así, entonces es muy probable que estés mezclando los binarios/libs svn suministrados por Apple con los tuyos (macports, etc.) o. Hay problemas de permisos. Haga seguro está utilizando los binarios 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 permisos, apache se ejecuta como usuario _www, grupo _www. Asegúrese de que todos los archivos y directorios sean de su propiedad, y no olvide actualizarlos cada vez que use svnadmin o alguna otra cosa para manipular directamente el repositorio svn.

Dado que está funcionando, mueva su repositorio 'svn2' de nuevo a/usr/local/svn (si no lo ha hecho ya), haga una comprobación limpia en alguna parte y pruebe una confirmación de prueba.

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

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

Repita la comprobación de comprobación/confirmación.

Como último recurso, vuelque y cargue el depósito de nuevo.

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 comprobación de comprobación/confirmación, esta vez con/svn/svn3.

Disfrute de su repositorio fijo ... con suerte :)

actualización

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

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

Observe que la salida de svn log (al menos para mí) no es nada. El registro de Svn de tortuga está bien, lo que indica que el servidor (como la configuración anterior) está funcionando correctamente.

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

Answer 5

chown -R apache:apache svn 

chmod -R 770 svn 

Answer 6

Esto resolvió el conflicto para mí: he hecho una copia de seguridad de mis archivos locales, entonces sacó todo lo desde el servidor. Luego, cuando inserté y empujé mis archivos de respaldo, el error de conflicto 409 no apareció nuevamente.

Saludos, Kevin