windows - toda - Concurrencia en un repositorio GIT en una carpeta compartida de red
omitir carpetas git (4)
¿Por qué molestarse? Git está diseñado para ser distribuido. Solo tenga un repositorio en cada máquina y use el mecanismo de publicación y extracción para propagar los cambios entre ellos.
Para fines de copia de seguridad, ejecute una tarea nocturna para copiar su repositorio al recurso compartido.
O bien, cree un repositorio cada uno en el recurso compartido y realice su trabajo desde ellos, pero utilícelos como repositorios distribuidos desde los cuales puede extraer conjuntos de cambios entre sí. Si utiliza este método, el rendimiento de las compilaciones, etc., se reducirá, ya que tendrá acceso constante a través de la red.
O bien, tenga repositorios distribuidos en sus propias computadoras y ejecute una tarea periódica para enviar sus confirmaciones a los repositorios en el recurso compartido.
Quiero tener un repositorio de git simple almacenado en un recurso compartido de red (Windows). Yo uso linux y tengo dicho recurso compartido de red montado con CIFS. Mi colega usa Windows XP y tiene el recurso compartido de red montado automáticamente (desde ActiveDirectory, de alguna manera) como una unidad de red.
Me pregunto si puedo usar el repositorio desde ambas computadoras, sin problemas de concurrencia.
Ya lo he probado, y por mi parte puedo clonar bien, pero tengo miedo de lo que pueda pasar si ambos accedemos al mismo repositorio (push / pull), al mismo tiempo.
En las preguntas frecuentes de git hay una referencia sobre el uso de sistemas de archivos de red (y algunos problemas con SMBFS), pero no estoy seguro de que la red / server / windows / linux esté bloqueado en algún archivo. ''t
Entonces, ¿alguien ha utilizado un repositorio git en un recurso compartido de red, sin servidor y sin problemas?
Gracias,
Alex
PD: quiero evitar usar un servidor http (o el demonio git), porque no tengo acceso al servidor con los recursos compartidos. Además, sé que podemos simplemente empujar / tirar de uno a otro, pero estamos obligados a tener el código / repo en el recurso compartido por razones de respaldo.
Actualizar:
Mis preocupaciones no son sobre la posibilidad de un fallo de la red. Aun así, tendríamos las sucursales requeridas localmente y podremos compilar nuestras fuentes.
Pero, generalmente nos comprometemos con bastante frecuencia, y necesitamos reajustar / fusionar a menudo. Desde mi punto de vista, la mejor opción sería tener un repositorio central en el recurso compartido (de modo que las copias de seguridad estén aseguradas), y ambos clonaríamos desde ese, y lo utilizaríamos para volver a armarlo.
Pero, debido al hecho de que lo estamos haciendo a menudo, me da miedo la corrupción de archivos / reposiciones , si sucede que ambos presionamos / tiramos al mismo tiempo. Normalmente, podríamos gritarnos cada vez que accedemos al repositorio remoto :), pero sería mejor tenerlo protegido por las computadoras / red.
Y es posible que GIT tenga un mecanismo interno para hacer esto (ya que alguien puede empujar a uno de tus repositorios, mientras trabajas en él), pero todavía no he encontrado nada concluyente.
Actualización 2:
El repositorio en la unidad compartida sería un repositorio simple, que no contiene una copia de trabajo.
Aparentemente se admite el uso de un repositorio de git central. La mayoría de los usos prescritos indican acceso ssh o http, ninguno de los cuales evita el acceso simultáneo al repositorio. Incluso si está haciendo un uso completamente distribuido, esta pregunta surge si más de dos colaboradores empujan al mismo repositorio en cualquier lugar. Hasta ahora, ninguna respuesta ha respondido a la pregunta. ¿El diseño de git le permite manejar N empujes simultáneos a una rama?
Git requiere un bloqueo de archivos mínimo, lo que creo que es la causa principal de los problemas al usar este tipo de recurso compartido en un sistema de archivos de red. La razón por la que se puede sacar esto es que la mayoría de los archivos en un repositorio Git, todos los que forman la base de datos de objetos, se nombran como un resumen de su contenido y se pueden inmutar una vez que se crean. Entonces, el problema de dos clientes que intentan usar el mismo archivo para un contenido diferente no surge.
La otra parte de la base de datos de objetos es más complicada: los refs se almacenan en archivos bajo el directorio "refs" (o en "empaquetado-refs") y estos sí cambian: aunque los archivos refs/* son pequeños y siempre se reescriben en lugar de siendo editado En este caso, Git escribe la nueva referencia en un archivo ".lock" temporal y luego le cambia el nombre sobre el archivo de destino. Si el sistema de archivos respeta la semántica O_EXCL , eso es seguro. Incluso si no, lo peor que podría pasar sería una carrera que sobrescriba un archivo de referencia. Aunque sería molesto encontrarlo, no debería causar la corrupción como tal: podría ser el caso de que presione el repositorio compartido, y ese impulso parece que tuvo éxito, mientras que, de hecho, lo hizo otra persona. Pero esto podría solucionarse simplemente tirando (fusionando los compromisos del otro tipo) y presionando nuevamente.
En resumen, no creo que la corrupción de la recompra sea un problema demasiado grande aquí; es cierto que las cosas pueden ir un poco mal debido a problemas de bloqueo, pero el diseño del repositorio de Git minimizará el daño.
(Descargo de responsabilidad: todo esto suena bien en teoría, pero no he realizado ningún martilleo simultáneo de un repositorio para probarlo, y solo lo comparto a través de NFS, no de CIFS)
Suena como si quisiera usar un sistema de control de versiones centralizado, por lo que la consulta para la copia de seguridad es satisfactoria. Quizás con xxx2git en el medio para que trabajes localmente.