Concurrencia en un repository de GIT en una carpeta compartida de networking

Quiero tener un repository de git al descubierto almacenado en un recurso compartido de networking (de Windows). Yo uso linux, y tengo dicho recurso compartido de networking montado con CIFS. Mi colega usa Windows XP, y tiene la networking compartida montada (de algún modo, ActiveDirectory) como una unidad de networking.

Me pregunto si puedo usar el repository de ambas computadoras, sin problemas de simultaneidad.

Ya he probado y, por mi parte, puedo clonar bien, pero tengo miedo de lo que podría pasar si ambos accedemos al mismo repository (push / pull), al mismo time.

En las preguntas frecuentes de git hay una reference sobre el uso de filesystems de networking (y algunos problemas con SMBFS), pero no estoy seguro de si la networking / server / windows / linux ha realizado algún locking de files. Estoy bastante seguro de que no hay 't.

Entonces, ¿alguien ha usado un git repo en una networking compartida, sin un server y sin problemas?

Gracias,
Alex

PD: quiero evitar el uso de un server http (o el git-daemon), porque no tengo acceso al server con los resources compartidos. Además, sé que podemos simplemente empujar / tirar de uno a otro, pero estamos obligados a tener el código / repository en el recurso compartido por razones de respaldo.

Actualizar:

Mis preocupaciones no son sobre la posibilidad de una falla de networking. Aun así, tendríamos las sucursales requeridas localmente, y podremos comstackr nuestras fonts.

Pero, por lo general, nos comprometemos bastante a menudo y necesitamos volver a fusionar / combinar a menudo. Desde mi punto de vista, la mejor opción sería tener un repository central en el recurso compartido (para que las copys de security estén aseguradas), y ambos clonaríamos a partir de ese, y lo usaríamos para volver a establecer la base.

Pero, debido al hecho de que estamos haciendo esto a menudo, me da miedo la corrupción de files / repositorys , si sucede que ambos empujamos / tiramos al mismo time. Normalmente, podríamos gritarnos cada vez que accedemos al repository remoto :), pero sería mejor tenerlo asegurado por las computadoras / networking.

Y, es posible que GIT tenga un mecanismo interno para hacerlo (ya que alguien puede presionar uno de sus repositorys, mientras trabaja en él), pero todavía no he encontrado nada concluyente.

Actualización 2:

El repository en el disco compartido sería un repository simple, que no contiene una copy de trabajo.

Git requiere un locking mínimo de files, que creo que es la principal causa de problemas cuando se utiliza este tipo de recurso compartido a través de un sistema de files de networking. La razón por la que puede salirse con la suya es que la mayoría de los files en un repository de Git — todos los que forman la database de objects — son nombrados como un resumen de su contenido, e inmutables una vez creados. Entonces, no aparece el problema de que dos clientes intenten usar el mismo file para diferentes contenidos.

La otra parte de la database de objects es más complicada: los refs se almacenan en files bajo el directory "refs" (o en "packed-refs") y cambian: aunque los files refs/* son pequeños y siempre se reescriben en lugar de siendo editado En este caso, Git escribe la nueva reference en un file temporal ".lock" y luego lo renombra sobre el file de destino. Si el sistema de files 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 file de reference. Aunque esto sería molesto de encontrar, no debería causar corrupción como tal: podría ser el caso de que presione para el repository compartido, y ese empujón parece que tuvo éxito mientras que de hecho lo hizo otro. Pero esto podría resolverse simplemente tirando (fusionándose con los compromisos del otro) y empujando nuevamente.

En resumen, no creo que la corrupción repo sea un problema demasiado grande aquí; es cierto que las cosas pueden salir un poco mal debido a problemas de locking, pero el layout del repo de Git minimizará el daño.

(Descargo de responsabilidad: todo esto suena bien en teoría, pero no he hecho ningún martillo simultáneo de un repository para probarlo, y solo los comparto con NFS, no con CIFS)

¿Por qué molestarse? Git está diseñado para ser distribuido. Simplemente tenga un repository en cada máquina y use el mecanismo de publicación y extracción para propagar sus cambios entre ellos.

Para fines de copy de security, ejecute una tarea nocturna para copyr su repository al recurso compartido.

O bien, cree un repository cada uno en el recurso compartido y haga su trabajo con ellos, pero utilícelos como repositorys distribuidos desde los cuales puede extraer los sets de cambios. Si usa este método, el performance de hacer comstackciones disminuirá ya que accederá constantemente a través de la networking.

O bien, tiene repositorys distribuidos en sus propias computadoras y ejecuta una tarea periódica para enviar sus confirmaciones a los repositorys en el recurso compartido.

Al parecer, se admite el uso de un repository central de git. La mayoría de los usos prescritos indican acceso ssh o http, ninguno de los cuales evita el acceso simultáneo al repository. Incluso si está haciendo un uso completamente distribuido, esta pregunta surge si más de dos queueboradores presionan al mismo repository en cualquier lugar. Hasta el momento, ninguna respuesta ha respondido a la pregunta. ¿El layout de git le permite manejar N empujes simultáneos a una twig?

Suena como si quisiera utilizar un sistema de control de versiones centralizado, por lo que la consulta de respaldo está satisdate. Tal vez con xxx2git en el medio para que pueda trabajar a nivel local.