Reparando un repositorio git que se desacelera debido a los grandes archivos binarios

Question

Tenemos un repositorio git que contiene código fuente y binarios. El repositorio desnudo ahora ha alcanzado ~ 9GB, y la clonación lleva años. La mayor parte del tiempo se gasta en "control remoto: Compresión de objetos". Después de comprometerse con una nueva versión de uno de los binarios más grandes, una búsqueda lleva mucho tiempo, también pasó la compresión de objetos en el servidor.

Después de leer git pull without remotely compressing objects sospecho que la compresión delta de archivos binarios es lo que también nos duele, pero no estoy 100% seguro de cómo solucionarlo.

¿Cuáles son los pasos exactos para arreglar el repositorio desnudo en el servidor? Mi opinión:

• Añadir entradas como '* .zip -delta' para todas las extensiones que quiero en .git/información/atributos
• Run 'git rehacer', pero con qué opciones? ¿Volvería a empaquetar todo y me dejaría un repositorio donde nunca se ha realizado una compresión delta en los tipos de archivos especificados?
• Ejecute 'git prune'. Pensé que esto se hizo automáticamente, pero ejecutarlo cuando jugué con un clon desnudo de dicho repos redujo el tamaño en ~ 2GB
• Cloné el repositorio, agregué y cometí un .gitattributes con las mismas entradas que agregué en .git/info/atributos en el informe vacío

¿Estoy en algo?

Actualización:

Algunos resultados de las pruebas interesantes sobre esto. Hoy comencé un clon desnudo del repositorio problemático. Nuestro servidor no tan poderoso con 4 GB RAM se quedó sin memoria y comenzó a intercambiar. Después de 3 horas, me rendí ...

Luego, en su lugar cloné un repo al desnudo de mi copia de trabajo actualizada. La clonación de esa entre estaciones de trabajo tomó ~ 5 minutos. Luego lo empujé al servidor como un nuevo repositorio. La clonación que repo tomó solo 7 minutos.

Si interpreto esto correctamente, un repo lleno mejor funciona mucho mejor, incluso sin deshabilitar la compresión delta para archivos binarios. Supongo que esto significa que los pasos anteriores son, de hecho, lo que quiero hacer a corto plazo, pero además necesito saber cómo limitar la cantidad de memoria que se permite usar git para empaquetar/comprimir en el servidor, así puedo evitar el intercambio.

En caso de que importe: el servidor ejecuta git 1.7.0.4 y las estaciones de trabajo ejecutan 1.7.9.5.

Actualización 2:

hice los siguientes pasos en mi TestRepo, y creo que lo haga la oportunidad de hacerlo en el servidor (después de una copia de seguridad)

• uso de la memoria límite cuando el embalaje objetos

  git config pack.windowMemory 100m
  paquete git config.packSizeLimit 200m

• compresión delta Desactivar para algunas extensiones

  eco '* .tar.gz -delta' >> información/atributos
  echo '* Tar.bz2 -delta' >> info/atributos
  echo '* .bin -delta' >> información/atributos
  echo '* .png -delta' >> información/atributos

• repositorio de volver y recoger la basura

  git embalar -a -d -F --window memoria 100m --max paquete de tamaño 200m
  git gc

Actualización 3:

Algunos efectos secundarios inesperados después de esta operación: Issues after trying to repack a git repo for improved performance

Answer 1

Debe usar un mecanismo diferente para almacenar los archivos binarios grandes, si se generan a partir de algo que simplemente no podría almacenarlos, solo el código que los genera, de lo contrario, sugiero moverlos a un único directorio y administrarlos con rsync o svn dependiendo de sus necesidades.

Answer 2

Mientras sus preguntas le preguntan sobre cómo hacer su repos actual más eficiente, no creo que eso sea factible.

seguir los consejos de la gente:

1. mover sus grandes binarios de tu repositorio
2. Mueva su entorno de desarrollo de una imagen de máquina virtual a: https://www.virtualbox.org/
3. uso de este script Python para limpiar tu repositorio de esas grandes manchas binarias (lo utilicé en mi repositorio y funcionó muy bien) https://gist.github.com/1433794