Almacenamiento de permisos de archivos en el repositorio de Subversion

Question

¿Cómo se almacenan los permisos de archivos en un repositorio? Algunos archivos deben ser de solo lectura para evitar que un programa de terceros los destruya, pero después de salir del repositorio están configurados para leer y escribir.

Miré en google y encontré un blog post from 2005 que indica que Subversion no almacena los permisos de archivos. Hay parches y scripts de gancho en la lista (solo existe una URL). Tres años después, ¿aún no almacena Subversion permisos de archivos y son los ganchos la única forma de hacerlo? (Nunca hice anzuelos y uso algo que es nativo de Subversion).

Answer 1

Una posible solución sería escribir un script que controle con el resto del código y que se ejecute como el primero paso de tu proceso de construcción

Este script se ejecuta a través de su copia de la base de código y conjuntos de permisos de lectura en ciertos archivos.

Lo ideal sería que el guión podría leer la lista de archivos de un archivo de entrada simple. Esto haría que sea fácil de mantener y fácil para otros desarrolladores entender qué archivos se marcan como de solo lectura.

Answer 2

Considere usar svn lock para no permitir que otros escriban en el archivo.

Answer 3

El bloqueo no resolvería este problema. El bloqueo impide que otros editen el archivo. Esta es una aplicación de terceros que se ejecuta como parte del proceso de compilación que intenta escribir en un archivo, cambiarlo, lo que rompe el proceso de compilación. Por lo tanto, debemos evitar que el programa cambie el archivo que simplemente marca el archivo como de solo lectura. Nos gustaría que esa información se guarde en el repositorio y se lleve a través de registros, sucursales, etc.

Answer 4

Graham, svn no permisos de almacén. Su única opción es envolver su llamada al svn en un script. La secuencia de comandos debe llamar al svn con sus argumentos, luego establecer los permisos a continuación. Dependiendo de su entorno, es posible que necesite llamar a su secuencia de comandos svn y modificar su PATH para asegurarse de que se llame.

Me gusta bastante la idea de morechilli de tener la lista de archivos y permisos registrados en el repositorio.

Answer 5

Creamos un archivo por lotes para que lo haga por nosotros. Preferirían apoyo real en la subversión, aunque ...

Answer 6

No hay forma nativa para almacenar los permisos de archivo en SVN.

Ambos asvn y the patch de esa publicación de blog parecen estar activos (y alojados en el repositorio SVN oficial), y eso es bueno, pero no creo que tengan ese manejo de metadatos en la versión central en cualquier momento pronto.

SVN ha tenido la capacidad de manejar symbolic links y executables especialmente durante un largo tiempo, pero tampoco funciona correctamente en Win32. No aguanto la respiración por otra característica no portátil (aunque no sería demasiado difícil de implementar sobre el sistema de metadatos ya existente.)

Consideraría escribir un script de shell para ajustar manualmente el archivo permisos, luego ponerlo en el repositorio.

Answer 7

SVN tiene la capacidad de almacenar metadatos (properties) junto con un archivo.Las propiedades son básicamente pares de clave/valor, sin embargo, hay algunas teclas especiales como 'svn: executable', si esta propiedad existe para un archivo, Subversion configurará el bit ejecutable del sistema de archivos para ese archivo al verificar el archivo. Aunque sé que esto no es exactamente lo que estás buscando, podría ser suficiente (fue para mí).

Existen otras propiedades para el final de línea (svn: eol-style) y el tipo de mime (svn: mime-type).

Answer 8

@morechilli:

La envoltura ASVN de mi anterior post y el blog en el post de la OP parece hacer lo que sugieres. Aunque almacena los permisos en las propiedades del repositorio de los archivos correspondientes a diferencia de un solo archivo externo.

Answer 9

This es el enlace actualizado para el parche SVN que maneja correctamente los permisos del archivo de estilo Unix. He probado en fedora12 y parece funcionar como esperaba:

Acabo de guardarlo/usr/bin/asvn y utilizar asvn en lugar del comando svn si necesito que los permisos se manejen correctamente.

Answer 10

Recomendaría generar un mapa de permisos utilizando la utilidad mtree (FreeBSD lo tiene de forma predeterminada), almacenar el mapa en el repositorio y, como se mencionó anteriormente, ejecutar una secuencia de comandos que restauraría los permisos de archivo correctos del mapa como primer paso del proceso de construcción.

Answer 11

Muchas respuestas han indicado que svn no almacena los permisos de archivos. Esto puede ser cierto, pero yo era capaz de resolver un archivo DLL y sin problema de permisos ejecutar simplemente estos pasos:

1. chmod 755 badpermission.dll
2. badpermission.dll mv ../
3. svn update
4. svn rm badpermission.dll
5. sVN badpermission.dll -m "Eliminar DLL para corregir los permisos"
6. ../badpermission.dll mv.
7. SVN añaden badpermission.dll
8. svn commit -m badpermission.dll "Agregar el archivo DLL de nuevo a corregir los permisos"
9. rm badpermission.dll
10. svn update
11. badpermission.dll se vuelva con permisos de ejecución

Answer 12

Dado que esto aún no se ha dicho completamente en las respuestas anteriores. Odio resucitar hilos zombie sin embargo.

Dado que la adición de soporte permiso para SVN tendría que dar cabida a múltiples sistemas operativos y tipos de permisos, NFS, POSIX, Arwed y RACF

Esto haría SVN hinchado, posiblemente en conflicto con tipos de permisos en conflicto como NFS y POSIX, o abrir posibles exploits/vulnerabilidades de seguridad.

Hay un par de soluciones. pre-commit, post-commit, start-commit son los más comúnmente utilizados, y son parte del sistema Subversion. Pero le permitirá controlar los permisos con el lenguaje de programación que desee.

El sistema que implementé es lo que llamo un empaquetador, que valida los archivos comprometidos de la copia de trabajo, luego analiza un archivo de metadatos, que enumera los permisos predeterminados para archivos/carpetas y cualquier cambio en ellos también deseo.

Owner, Group, Folders, Files 
default: <user> www-user 750 640 
/path/to/file: <user> non-www 770 770 
/path/to/file2: <user> <user> 700 700 

También puede ampliar esto y permitir que las cosas tales como movimiento automatizado, cambiar el nombre de ellos, el etiquetado de revisión por parte de los tipos, como alfa, beta, versión candidata, liberar

En cuanto a apoyar a los clientes a la comprobación de su repositorio con permisos adjuntos. Es mejor buscar crear un instalador de su paquete y ofrecerlo como un recurso.

Imagínese la gente que configura sus lugares de almacenamiento en un archivo ejecutable en el mismo conjunto con permisos de root: www-4777

usuario