¿Mejores prácticas para desarrollar y usar bibliotecas comunes en el control de versiones?

Question

Siempre me he preguntado cómo una biblioteca común desarrollada activamente utilizada en dos o más proyectos debe almacenarse en control de versiones. Me imagino que se puede manejar de forma diferente a una biblioteca de terceros, ya que es más probable que una biblioteca interna obtenga correcciones urgentes que se deben distribuir a muchos de los proyectos en control de versiones.

¿Deberían importarse sus archivos binarios en los proyectos que lo utilizan a medida que se actualizan (más o menos como una biblioteca de terceros), o podría verificarse su código fuente junto con los proyectos? ¿Es posible tener referencias a otras rutas controladas por versiones en Subversion u otros sistemas de control de versiones?

Estoy trabajando en un proyecto ahora que tiene bibliotecas comunes que residen en otras partes de Subversion (y se usan en muchos proyectos) registradas con el proyecto, por lo que los cambios realizados en este proyecto no se reflejan en su "real "repositorio. Voy a sugerir algunos cambios a esto, pero me gustaría algunas ideas sobre cuál es la mejor práctica para manejar estas bibliotecas comunes.

Answer 1

Como ya se ha mencionado, SVN's externals es una buena forma de hacerlo. A través de ellos puede hacer referencia a otras partes de su repositorio (u otros repositorios, también, FTM). Un proyecto puede hacer referencia al jefe de algún otro proyecto (biblioteca) o alguna rama o etiqueta. Los dos últimos contribuyen a la estabilidad, el primero para estar siempre al día con la biblioteca.

He visto varios esquemas a lo largo de esta línea usando CVS (no hay elementos externos aquí, por lo que se deben ejecutar scripts que se deben ejecutar) y SVN. En la empresa que estoy trabajando ahora tenemos diferentes carpetas de primer nivel para proyectos y bibliotecas compartidas. Los proyectos pueden referir las bibliotecas. En el tronco del proyecto, estas referencias externas generalmente se refieren a las cabezas de las bibliotecas, en las etiquetas y los proyectos de ramas se refieren a las etiquetas de las bibliotecas (o, a veces, a las ramas).

Answer 2

Si utilizo Subversion, utilizaría svn:externals, lo que le permite crear dependencias de un repositorio de Subversion a otro.

Answer 3

Subversion le permite tener referencias a otras rutas, mediante el uso de la propiedad svn:externals.

Dicho esto, a menudo querrá tener un poco más de control sobre el estado de un proyecto que simplemente "tomar lo que esté en el encabezado de la biblioteca compartida". En ese caso, sugeriría comprometer el binario compilado de la biblioteca en cada uno de los otros proyectos que lo usa. De esta forma, tiene control sobre la implementación de la biblioteca para cada uno de sus clientes.

Answer 4

Sí.

Separa las "sub-bibliotecas" reutilizables en proyectos separados temprano y con frecuencia.

Mire las prácticas de código abierto: la mayoría de las cosas son muchos pequeños proyectos que se unen.

Crea muchos proyectos pequeños.

Evitar el control de binarios. Nuevamente, siga las prácticas de código abierto. Mantenga la fuente en subversión.

Cree los binarios y colóquelos en un directorio "proyecto compartido" separado de la fuente.

Answer 5

La herramienta adecuada para manejar este problema es Maven. Originalmente desarrollado para Java, puede ser utilizado para cualquier lenguaje de programación existente.

Maven crea un repositorio en su computadora donde residen todos los módulos. También puede crear un repositorio de módulos público, permitiendo que otras personas descarguen módulos desde allí.

Cada módulo tiene una lista de dependencias que se resuelven automáticamente (leer descargadas). En la etapa de compilación del proyecto, un complemento apropiado para su lenguaje de programación pondrá todas las dependencias en lugares específicos para hacer que el código fuente las vea.

Maven es una gran herramienta multifuncional, pero es muy difícil de dominar, eso es lo único negativo.

Answer 6

Mantenemos el código de las bibliotecas comunes en SVN en sus propias carpetas de proyectos. También asignamos los binarios a otra carpeta de "proyecto" llamada Dependencias. Usamos svn: externals para traer las referencias necesarias a los proyectos.

Answer 7

Ni siquiera entiendo la pregunta. Si foo depende de libbar, ¿por qué quieres conservar la fuente de libbar en el VCS de foo? Usted vincula con libbar o importa el módulo de barra, si corresponde para el idioma. ¿Por qué querrías confundir el árbol fuente para tu proyecto? Mi "hola, mundo!" proyecto depende de libc. Así que mi "hola, Dolly!" proyecto. Ninguno de los proyectos mantiene la fuente de libc en su base de código. Hacerlo sería una locura. ¿Por qué tratar las bibliotecas internas de forma diferente a las bibliotecas de terceros a este respecto? En resumen, la mejor práctica es: no lo hagas. Si su biblioteca tiene arreglos urgentes que necesitan propagarse a sus proyectos, entonces use enlaces dinámicos.