Cómo administrar dependencias externas que se modifican constantemente

Question

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

Nuestra configuración actual:

• estamos desarrollando para Linux y Windows
• Nos Use SVN para nuestro propio código
• dependencias externas (impulso, log4cpp, etc) no se almacenan en el SVN. En su lugar, los puse en ./extern (o c: \ extern en windows). No quiero ponerlos en nuestro repositorio porque no podré actualizarlos de esa manera. Algunos de estos se actualizan constantemente.

Mis preguntas

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

• Cómo para administrar versiones de dependencias externas?

Me interesa escuchar cómo otros tratan estos problemas. Gracias.

Answer 1

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

Mantenerlos en svn me ha ahorrado muchos dolor de cabeza, y también le permite obtener una nueva estación de trabajo capaz de trabajar en su base de código rápidamente.

Answer 2

No entiendo por qué dices

no quiero ponerlos en nuestro repositorio porque no voy a ser capaz de actualizar esa manera. Algunos de estos se actualizan constantemente.

que realmente necesita para

1. incluyen dependencias externas en el control de código fuente y actualizar periódicamente y luego TESE, prueba, prueba.

2. Coordine su proceso de compilación con las actualizaciones para las dependencias 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 dependencias pueden actualizarse en cualquier momento es demasiado doloroso, ya que sin duda lo descubrirá. Personalmente prefiero la opción 1.

Answer 3

¿Has considerado Maven?Es un sistema de compilación que tiene un excelente soporte para administrar dependencias. Para cada proyecto, puede especificar las dependencias requeridas en un archivo xml como parte de ese proyecto. Las bibliotecas externas se encuentran en un repositorio de dependencias (en nuestro caso Artifactory), esto es independiente de su sistema de control de versiones y puede ser solo una unidad de red. También permite administrar diferentes versiones de proyectos.

Answer 4

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.

Answer 5

Me gustaría tener cuidado teniendo en cuenta Maven porque:

• es otro repositorio en un sistema en el que ya tiene un repositorio con su sistema de control de versión actual;
• (Maven) se basa en el único "control de versión común" que tiene cada desarrollador, el sistema de archivos (lo que significa que no hay metadatos ni propiedades adjuntas al archivo, no cuenta el historial adecuado en cuanto a quién y cuándo)

Ahora cuando se trata de terceros, se puede considerar que tiene en su sistema de control de versiones, pero de una manera empaquetado: es decir de una manera muy compacta, con fuentes y documentación con cremallera, con el fin de tener la menor cantidad posible de archivos.

De esta manera, se va a controlar el despliegue de los (muchos) las bibliotecas de terceros fácilmente ya que el número de archivos de desplegar es baja.

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

Lo que puede almacenar de forma externa es el conjunto completo sin comprimir de archivos que representan esas bibliotecas, ya que no existe un desarrollo real en ellas, o simplemente un truco puntual: normalmente, su trabajo no es desarrollar bibliotecas existentes , pero para usarlos (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 el oficial (y almacenado externamente) versión (con winmerge, por ejemplo)