2011-08-03 9 views
8

Tengo un proyecto que está diseñado para varios sistemas operativos (Linux y Windows por ahora, tal vez OS X) y procesadores. Para este proyecto tengo un puñado de dependencias de biblioteca, que son varoniles pero tengo un par de internas, en forma de fuente que compilo (compilación cruzada) para cada combinación de procesador de sistema operativo posible en mi contexto.Administración de dependencias de biblioteca usando git

La mayoría de las bibliotecas externas no se cambian muy a menudo, sólo tal vez en el caso de una corrección de errores local o alguna característica \ corrección de errores implementado en una versión más reciente Creo que puede beneficiarse del proyecto. Las bibliotecas internas cambian con bastante frecuencia (ciclos de 1 mes) y son provistas por otro equipo en mi compañía en forma binaria, aunque también tengo acceso al código fuente y si necesito que se solucione un error puedo hacerlo y generar nuevos binarios. para mi uso hasta el próximo ciclo de lanzamiento. La configuración que tengo en este momento es el siguiente (sólo sistema de archivos):

-- dependencies 
    | 
    -- library_A_v1.0 
    | 
     --include 
    | 
     --lib 
    | 
    -- library_A_v1.2 
    | 
     --include 
    | 
     --lib 
    |  
    -- library_B 
    | 
     --include 
    | 
     --lib 
    | ... 

Las bibliotecas se mantienen en un servidor y cada vez que hago una actualización tengo que copiar los nuevos archivos binarios y archivos de cabecera en el servidor. La sincronización en el lado del cliente se realiza utilizando una utilidad de sincronización de archivos. Por supuesto, cualquier actualización de las bibliotecas debe anunciarse a los demás desarrolladores y todos deben recordar sincronizar su carpeta de "dependencias".

No hace falta decir que no me gusta mucho este esquema. Así que estaba pensando en poner mis bibliotecas bajo control de versiones (GIT). Constrúyelos, empaquételos en tgz \ zip e introdúcelos en el repositorio. Cada biblioteca tendría su propio repositorio de git para poder etiquetar fácilmente \ branch las versiones ya usadas y probar nuevas versiones de drive. Una "secuencia" de datos para cada biblioteca que podría obtener, combinar y actualizar fácilmente. Me gustaría tener lo siguiente:

  • deshacerse de este sistema de archivos normal forma de mantener las bibliotecas; en este momento, las carpetas separadas se guardan y administran para cada sistema operativo y cada versión y, a veces se desincronizan, lo que da como resultado un lío

  • más control sobre él, para poder tener un historial claro de las versiones de las libs utilizamos para qué versión de nuestro proyecto; al igual que lo que podemos obtener de git (VCS) con nuestro código fuente

  • ser capaz de etiquetar \ ramas las versiones de las dependencias que estoy usando (para todas y cada una de ellas); Tengo mi etiqueta/bifurcación v2.0.0 para library_A de la cual normalmente la tomo para mi proyecto pero me gustaría probar la versión 2.1.0, así que solo la construyo, la presiono en el servidor en una rama diferente y llamo mi script de compilación con esta dependencia particular apuntando a la nueva rama

  • tienen scripts de compilación más simples: simplemente extraiga los orígenes del servidor, extraiga las dependencias y compile; que permitiría también utilizar diferentes versiones de la misma biblioteca para diferentes combinaciones procesador de OS (más que a menudo es necesario que)

He intentado encontrar algunas alternativas a la solución directa basada git, pero sin mucho éxito - como git-annex, que parece demasiado complicado para lo que estoy tratando de hacer.

Lo que estoy enfrentando ahora es el hecho de que parece haber una opinión muy fuerte en contra de poner archivos binarios bajo git o cualquier VCS (aunque técnicamente también tendría archivos de cabecera, también podría empujar la estructura de carpetas que describí directamente a git para no tener el tgz \ zip, pero todavía tendría los binarios de las bibliotecas) y que algunos de mis colegas, impulsados ​​por esa fuerte opinión compartida, están en contra de este esquema de cosas.Entiendo perfectamente que git rastrea el contenido y no los archivos, pero hasta cierto punto también seguiré el contenido y creo que definitivamente será una mejora con respecto al esquema actual de cosas que tenemos ahora.

¿Cuál sería la mejor solución para esta situación? ¿Conoces alguna alternativa al esquema de cosas basado en git (VCS)? ¿Sería tan monstruoso tener mi esquema bajo git :)? Por favor, comparta sus opiniones y especialmente su experiencia en el manejo de este tipo de situaciones.

Gracias

+0

Mejor que lo que hace mi empresa: utiliza PDMWorks para el control de cambio de versión binaria. Ya sabes, justo al lado de dibujos mecánicos y documentos de palabras. UGH. – Nate

Respuesta

2

Una alternativa, que todavía follwo su proyecto, sería utilizar git-annex, lo que permitiría realizar un seguimiento de los archivos de cabecera, mientras se mantiene binarios almacenados en otro lugar.
Luego cada repositorio de git se puede agregar como submodule a su proyecto principal.

+0

Ya lo he visto. No parece encajar demasiado bien con mis necesidades. No estoy seguro de que separar los encabezados de los binarios sea una buena idea, ya que dependen uno del otro: las nuevas versiones de las bibliotecas pueden agregar a la API y traer nuevas versiones de los encabezados a la imagen. Me gustaría mucho no separarlos. – celavek

+0

@celavek: no se separarán, lógicamente. Se verán como parte del mismo repo de Git. Solo el gran contenido binario en sí mismo se almacenará en otro lugar. Pero desde la perspectiva de un cliente de Git, todos están en el mismo repositorio. – VonC

+0

De hecho, lógicamente estarán separados pero git-annex no parece permitir mantener múltiples versiones de las bibliotecas. Parece que terminaré usando algo así como el mismo enfoque basado en carpetas que estoy usando ahora. ¿Puedo ramificar y etiquetar usando git-annex? No parece ser así desde la documentación ... Voy a mirar más lejos, pero parece que no proporciona lo que realmente quiero. – celavek

Cuestiones relacionadas