Cómo gestionar las dependencies externas que se modifican constantemente

Nuestro desarrollo usa muchos códigos de código abierto y estoy tratando de descubrir cuál es la mejor forma de administrar estas dependencies externas.

Nuestra configuration actual:

  • estamos desarrollando para Linux y Windows
  • Usamos svn para nuestro propio código
  • las dependencies externas (boost, log4cpp, etc.) no se almacenan en svn. En su lugar, los puse en ./extern (o c: \ extern en windows). No quiero ponerlos en nuestro repository porque no podré actualizarlos de esa manera. Algunos de estos se actualizan constantemente.

Mis preguntas

  • ¿Qué hacer si necesito modificar un código externo? Actualmente he creado una carpeta en mi repository de svn llamada extern_hacks y ahí es donde pongo el código externo modificado. Luego enlace (o copio en Windows) los files a la estructura de directory externo. Esta solución es problemática ya que es difícil hacer un seguimiento de la copy de los files, y es muy difícil actualizarla desde svn cuando los files están ubicados en dos repositorys (los míos para los files modificados, y el repository original dice sourceforge)

  • ¿Cómo administrar versiones de dependencies externas?

Me interesa escuchar cómo otros lidian con estos problemas. Gracias.

Los guardo en svn y los administro como sucursales de proveedores . Mantenerlos sueltos externamente hace que sea muy difícil volver a una compilation anterior o corregir errores en una compilation anterior (especialmente si el error proviene de un cambio a la dependencia externa)

Mantenerlos en svn me ha ahorrado muchos dolores de cabeza, y también te permite get una nueva estación de trabajo capaz de trabajar en tu base de código rápidamente.

No entiendo por qué lo dices

No quiero ponerlos en nuestro repository porque no podré actualizarlos de esa manera. Algunos de estos se actualizan constantemente.

Realmente necesitas

  1. incluya dependencies externas en su control de origen y actualícelas periódicamente y luego pruebe, pruebe y pruebe.

  2. Coordine su process de compilation con las actualizaciones de las dependencies externas.

Si su código depende de algo, entonces realmente necesita tener control sobre cuándo se actualiza / modifica. Codificar en un espacio donde estas dependencies pueden actualizarse en cualquier momento es demasiado doloroso, ya que sin duda lo descubrirá. Yo personalmente prefiero la opción 1.

Cuando tuve que hacer algo como esto, agregué la fuente externa como externa y luego le apliqué un parche. El parche contiene mis modificaciones a la fuente externa. Entonces, en realidad solo controlo la versión de mis parches. La mayoría de las veces esto funciona, si no hay cambios "dramáticos" en el código externo.

¿Has considerado a Maven ? Es un sistema de compilation que tiene un excelente soporte para administrar dependencies. Para cada proyecto, puede especificar las dependencies requeridas en un file xml como parte de ese proyecto. Las bibliotecas externas se almacenan en un repository de dependencies (en nuestro caso, Artifactory ) que está separado de su sistema de control de versiones y puede ser simplemente una unidad de networking. También permite administrar diferentes versiones de proyectos.

Tendría cuidado al considerar a Maven porque:

  • es otro repository en un sistema donde ya tienes un repository con tu sistema actual de control de versiones;
  • it (Maven) se basa en el único "control de versión común" que tiene cada desarrollador, el sistema de files (lo que significa que no hay metadatos ni properties adjuntas al file, no existe un historial adecuado en términos de quién modificó qué y cuándo)

Ahora, al tratar con terceros, puede considerar tenerlos en su sistema de control de versiones, pero de una manera empaquetada : eso es de una manera muy compacta, con fonts y documentos comprimidos, para tener la menor cantidad posible de files .

De esta forma, administrará la implementación de esas (muchas) bibliotecas de terceros fácilmente, ya que la cantidad de files para implementar es baja.

Además, tenerlos bajo control de fuente te permite crear una twig (por ejemplo, una twig 'hack'), en la que almacenarás la versión empaquetada (o comprimida) de la biblioteca pirateada.

Lo que puede almacenar de forma externa es el set completo de files sin comprimir que representan esas bibliotecas, ya que no existe un desarrollo real en ellos, o simplemente un truco puntual: normalmente, su trabajo no es desarrollar bibliotecas existentes, sino usarlas ellos (incluso un poco modificados) para implementar más rápido algunas características de su proyecto.

Si necesita en algún momento comparar alguna versión pirateada con alguna versión oficial, simplemente sacará de svn el número de versión 'pirateado', descomprimirlo y compararlo con la versión oficial (y almacenada externamente) (con winmerge por ejemplo)