svn update no funciona en post commit

Estoy tratando de implementar un gancho post-commit para actualizar una copy de trabajo. Por lo que puedo entender, el enganche post commit se está ejecutando (escribí algo en un file para verificarlo) pero el command de actualización no se ejecutó.

Al principio lo hice

cd /home/user/working/copy svn update 

pero eso no funcionó, entonces leí que tienes que dar el path completo a svn:

 cd /home/user/working/copy /usr/bin/svn update 

pero aún así no funcionó.

Cambié los permissions a 777 y ejecuté el script en un entorno vacío … y funciona.

  #! / bin / bash
 / usr / bin / svn update / inicio / usuario / trabajo / copy 

El código anterior debería funcionar como un enganche post-commit.

Agregue –username & –password options si es necesario.

Editar:

Ver http://subversion.tigris.org/faq.html#website-auto-update

El progtwig server que realiza la confirmación (svnserve o apache) es el mismo progtwig que ejecutará la secuencia de commands post-commit hook. Eso significa que este progtwig debe tener los permissions adecuados para actualizar la copy de trabajo.

Si la 'copy de trabajo' que debe actualizarse es propiedad del mismo usuario, entonces NO debe preocuparse por el nombre de usuario y la contraseña.

Las preguntas frecuentes de Subversion sugieren el uso de Setuid con el siguiente progtwig C.

 #include <stddef.h> #include <stdlib.h> #include <unistd.h> int main(void) { execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/", (const char *) NULL); return(EXIT_FAILURE); } 

La copy de trabajo está en el directory de inicio de un usuario. Si el server SVN se ejecuta como un usuario diferente, digamos "svnserver", la secuencia de commands post-commit se ejecutará como "svnserver". Tiene sentido que un usuario no pueda modificar o leer los files de otro usuario a less que la configuration de permissions en los files sea tal que esto esté permitido.

No debe compartir copys de trabajo entre varios usuarios . Si realmente debe, entonces simplemente dar permiso de lectura / escritura a cada usuario no es suficiente. También deberá asegurarse de que ninguno de los usuarios cree files a los que no puedan acceder otros usuarios. Para lograrlo, necesitaría escribir scripts de envoltura para los commands de svn que configuran la umask adecuada, o dar a todos los usuarios involucrados la capacidad de actuar como un usuario específico a través de sudo .

Si no usa la copy de trabajo usted mismo, puede cerrar la copy de trabajo al usuario que ejecuta la secuencia de commands hook

También me encontré con el mismo problema e intenté (incluido el de las preguntas frecuentes oficiales) todo el método sin suerte

por supuesto, también ejecuto chmod -R y chown -R www-data: www-data según sea necesario cada vez.

En la mayoría de los casos, se ejecuta el command de actualización, no hay ningún error de permiso, no aparece ningún otro post de error, pero la copy de trabajo no se actualiza.

finalmente los pasos a continuación me funcionan bien:

en ejecución de gancho post-commit

 export LC_CTYPE=en_US.UTF-8 cd [/working-copy-folder/] # heading tail slash /usr/bin/svn checkout [source path] 

una vez, luego actualice el enlace post-commit para

 export LC_CTYPE=en_US.UTF-8 cd [/working-copy-folder/] /usr/bin/svn update 

ahora está funcionando, y estoy demasiado cansado para encontrar la causa raíz. pasó todo el día en solo 'svn update'

La solución final que obtuve trabajando fue una mezcla de algunas de las respuestas que obtuve. Mi server tenía Apache ejecutándose como nadie, así que hice que la copy de trabajo no fuera propiedad de nadie ni del grupo UserName y luego lo modifiqué a 775. De esta forma, el gancho funcionará y también el nombre de usuario también tendrá permiso para actualizar files por FTP.

La respuesta de wcoenen está definitivamente en el path correcto. La forma más fácil de evitar este problema sería agregar el usuario SVN a su grupo. Digamos que su gancho post-commit es propiedad del usuario someUser y group someUser. Agregar el server SVN al grupo someUser, y cambiar el script de hook post-commit para que sea ejecutable por grupo, resolvería su problema.

Espero que tenga sentido: P

Este script es mejor porque solo actualiza los files necesarios … http://vidax.net/blog/en/2010/03/subversion-post-commit-hook/

Creo que el postcompromiso en realidad se ejecuta antes de que el compromiso se haga visible. Es extraño, pero digamos que cometiste la revisión 30. La post-confirmación aún vería 29 como la última revisión. Una vez que finalice el script de post-commit, verás 30 como la revisión principal.

Podría estar equivocado. Esto es estrictamente de memory. Algo para intentar al less.