SVN, Samba y Enlaces Simbólicos. ¿Cómo hacer que todos jueguen juntos?

Tengo un proyecto de website bajo control de versión que se basa en files de un directory no versionado en el mismo server a través de Enlaces simbólicos.

Actualmente estoy almacenando los enlaces simbólicos en el repository. La idea es que si alguien revisa una copy de trabajo en el mismo server, puede editar y probar la copy de trabajo del proyecto antes de volver a enviarlo al repository.

Cuando finalizan la copy de su copy de trabajo, configura con éxito los enlaces simbólicos para que todo el sitio funcione durante la testing.

Los usuarios que trabajan en el proyecto son usuarios de Windows, de modo que he configurado un recurso compartido de samba en el server y luego los he asignado a unidades de networking en Windows. Las personas pueden editar sus copys de trabajo directamente en el server a través de resources compartidos de networking y luego probarlas en el browser web antes de volver a enviar sus cambios al repository a través de TortoiseSVN.

El problema

El problema que tengo es que Samba resuelve los enlaces simbólicos como se esperaba, pero cuando un usuario intenta enviar sus cambios al depósito, TortoiseSVN piensa que los files vinculados son parte del proyecto y trata de asignar los files destino al repository y no a los enlaces simbólicos sí mismos.

Traté de desactivar el soporte de enlace simbólico en samba, lo que significa que los files vinculados no se pueden resolver, ya que realmente no quiero que las personas tengan acceso a los files vinculados ni tampoco quiero importar los files vinculados en el repository. El problema con esto es que obtengo Can't stat '\\webserver\projects\working\project\symlinked_file.php'. Access is denied Can't stat '\\webserver\projects\working\project\symlinked_file.php'. Access is denied

Además del problema de enlace simbólico, todo lo demás funciona al 100% a la perfección. Los usuarios pueden consultar proyectos de sitios web en su máquina y trabajar en ellos (pero no pueden probarlos) o consultarlos en su espacio en el server web de desarrollo y trabajar en ellos y probarlos completamente. Así que no quiero cambiar el process del flujo de trabajo, solo necesito una solución al problema del enlace simbólico.

Muchas gracias.

Decidí eliminar los enlaces simbólicos del repository. Luego creé un script bash que solicita al usuario crear los enlaces simbólicos en su copy de trabajo. Tenía que asegurarme de que desactivé la opción de follow symlinks Samba para evitar que TortoiseSVN intente agregar los files vinculados al repository.

También debe tenerse en count que cuando el usuario realiza una confirmación utilizando TortoiseSVN, mostrará los enlaces en el logging de cambios, pero no se verificarán y, por lo tanto, no se agregarán al repository. Solo necesitas ignorarlos.

¿Podría utilizar los enlaces simbólicos de UNIX junto con los enlaces simbólicos NTFS para mantener la compatibilidad con Windows? O bien, siempre puede versionar los otros files y usar svn: externals para vincularlos.

Aight, después de ir a través de varias opciones, esto es lo que terminé con: El problema es que Windows no sabe acerca de los enlaces simbólicos, pero Tortoise tampoco los destruye en las cajas de Windows. La solución es permitir que las personas hagan las compras en el compartimiento de Windows, y luego de eso, encontrar la manera de volver a agregar los enlaces simbólicos.

Por supuesto, simplemente sobrescribirlos no es una opción, ya que Tortoise se quejará de files / directorys cambiados, etc. Queremos dejarlos solos. Para un server web con imágenes estáticas / otros resources en un directory enlazado, un Alias simple en la configuration de Apache funcionaría, pero desafortunadamente, nuestra base de código también incluye código por enlace simbólico.

En debian, unionfs-fuse resolvió esos problemas. La receta que parece funcionar aquí:

  • Crear loggings base en algún lugar en el server de Linux (svnroots).
  • Crea un directory en el que vamos a crear una 'superposition' (cadáver).
  • Busque en el directory svn-checkouts los enlaces simbólicos y recíclelos en el canal:

.

 for file in `find $DEVPATH/svnroots/ -type l`;do path=`dirname $file | sed "s,$DEVPATH/svnroots,$DEVPATH/carcass,g"` mkdir -p $path path=$path/`basename $file`; ln -s `readlink $file` $path; done 
  • Cree los directorys deseados (con los files de personas de su recurso compartido, pero los enlaces simbólicos almacenados en subversión:

.

 for user in ${windowsusers[@]}; unionfs-fuse -o cow,allow_other,suid,uid=33,gid=33 $DEVPATH/carcass=ro:$DEVPATH/$user/=rw $DEVPATH/correct_dirs/$user done 

Leer / escribir en ese directory irá al directory de usuarios, el directory de carcasa es de solo lectura pero está superpuesto en el directory de usuarios, lo que da como resultado enlaces simbólicos correctos. Los scripts son lo suficientemente fáciles para volver a ejecutar los enlaces simbólicos: cambios en la subversión (y no se necesita un reassembly: los cambios en el cuerpo se reflejan directamente en los cables correctos).