Git realiza confirmaciones muy lentas en una acción de Samba. ¿Qué puedo hacer para acelerarlo?

Question

Estoy ejecutando un repositorio de git en un servidor remoto. Lo tengo configurado un recurso compartido de samba en el servidor remoto para que pueda guardar mi código allí en lugar de en mi máquina local de Windows 7. Estamos tratando de analizar el uso de git, porque svn ha sido muy lento y poco confiable. El problema que estamos teniendo con git es que al hacer cualquier commit/clones/pulls en el samba share, ejecuta super super slow. Si hago un commit/clone/pull en un directorio local en mi máquina con Windows 7, funciona muy bien, pero necesitamos que el código esté en el servidor remoto. ¿Algunas ideas? Realmente podría usarlo.

Editar:

También debería mencionar que ya he corrió git gc --aggressive y no ha acelerado hacia arriba.

Answer 1

Git no está destinado a ser utilizado en esta configuración. Es como tener una Fórmula 1 y correr en un camino de tierra.

Git es un DVCS, o control de versión distribuida. En otras palabras, cada desarrollador obtiene un clon.

Lo que hay que hacer es configurar un servidor de repositorio git en esa máquina de samba y accede a la cesión temporal a través de http o ssh

Puede utilizar proyectos como GitBlit o mejor aún una cuenta en Github

Answer 2

I tuvo el mismo problema con el rendimiento de Git sobre las acciones de SMB. Desafortunadamente no puedo ejecutar el código de desarrollo en mi máquina local, entonces uso SMB para montar el directorio remoto y editar los archivos fuente usando un editor de texto apropiado en mi máquina local.

Como quiero algo de confort al comprometerme con el repositorio, prefiero un cliente GUI que se ejecute en mi máquina local. Sin embargo, con los problemas de rendimiento mencionados, esto es un poco complicado y lleva mucho tiempo.

Sin embargo: Encontré una pequeña y elegante solución. Antes de comprometerse nada al repositorio, saco una copia de las fuentes remotas a mi disco duro local utilizando rsync, así:

rsync -az --progress --exclude ".git" dev@my.devserver.com:/home/myapp/sourcecode /Devel/portal-mirror 

De esa manera se tarda menos de un segundo para hacer un total de 1-a-1 sincronización del estado remoto (vinculado esto a un atajo de teclado en mi aplicación Git) antes de hacer las diffs y commits. Funciona de maravilla. Después de confirmar y enviar al repositorio, acabo de hacer git reset --hard y git pull en el servidor de desarrollo para volver a sincronizar los cambios.

Answer 3

Estamos ejecutando la misma configuración con git y samba en combinación con php-storm. Está funcionando bastante bien. Solo cuando trato de usar "SourceTree" en nuestro gran proyecto, lleva años actualizar, porque (creo) git escanea todos y cada uno de los archivos para hacerlo.

Una cosa que intentó, y me dieron mejoras en el rendimiento de menor importancia fuera de él, era para ajustar el servidor Samba un poco:

archivo de configuración:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536 

encontró que la línea en la búsqueda de la samba acelerar.

Otra solución podría ser una sincronización 1 en 1 constante que se ejecuta todo el tiempo en el fondo como reemplazo de samba. Tal vez la rsync podría modificarse un poco para hacerlo.

Answer 4

Puede considerar invertir un poco el paradigma y hacer que el servidor web monte participaciones en las máquinas de los desarrolladores. De esta forma, toda la clonación/confirmación/codificación se realiza de forma local, pero el sitio de cada desarrollador simplemente se aloja en una ubicación compartida.

Ahora supongo que su servidor web está exponiendo el directorio raíz de cada sitio web como un recurso compartido de samba. Un desarrollador luego monta ese recurso compartido en su máquina local, clona un depósito y funciona fuera del recurso compartido. El rendimiento en ese caso va a ser pobre en el mejor de los casos, y también puede tener problemas con las solicitudes de bloqueo de rango de bytes (BRL) y demás.

En su lugar, una opción es clonar directamente en un directorio en la computadora de cada desarrollador y compartir ese directorio. El servidor web luego monta ese recurso compartido.

Por supuesto, idealmente, cada desarrollador debería ejecutar su propia instancia del servidor web, pero si estoy leyendo las preguntas correctamente, tal vez no sea una opción en este caso.