version control - visual - ¿Argumentos a favor y en contra de incluir bibliotecas de terceros en el control de versiones?

stream based version control deals with

Question

He conocido a varias personas últimamente que dicen que las bibliotecas de terceros no pertenecen al control de versiones. Estas personas aún no han podido explicarme por qué no deberían hacerlo, así que espero que puedan venir a mi rescate :)

Personalmente, creo que cuando reviso el tronco de un proyecto, debería funcionar. No es necesario ir a otros sitios para encontrar bibliotecas. La mayoría de las veces, terminaría con varias versiones de la misma biblioteca de terceros para diferentes desarrolladores en ese momento, y en ocasiones con problemas de incompatibilidad.

¿Es tan malo tener una carpeta libs allí arriba, con bibliotecas "garantizadas para trabajar" a las que podría hacer referencia?

Answer 1

Definitivamente debería poner bibliotecas de terceros bajo el control de origen. Además, debes tratar de evitar confiar en cosas instaladas en la máquina del desarrollador individual. Este es el por qué:

• Todos los desarrolladores compartirán la misma versión del componente. Esto es muy importante.
• Tu entorno de construcción será mucho más portátil. Simplemente instale el cliente de control de origen en una máquina nueva, descargue su repositorio, compile y listo (en teoría, al menos :)).
• A veces es difícil obtener una versión antigua de alguna biblioteca. Manteniéndolos bajo su control de origen se asegura de que no tendrá tales problemas.

Sin embargo, no necesita agregar un código fuente de terceros en su repositorio si no planea cambiar el código. Tiendo solo a agregar binarios, pero me aseguro de que solo se haga referencia a estas bibliotecas en nuestro código (y no a las de Windows GAC, por ejemplo).

Answer 2

En SVN, hay un patrón que se usa para almacenar bibliotecas de terceros llamadas sucursales de proveedores . Esta misma idea funcionaría para cualquier otro sistema de control de versiones similar a SVN. La idea básica es que incluya la fuente de terceros en su propia rama y luego la copie en su árbol principal para que pueda aplicar fácilmente nuevas versiones sobre sus personalizaciones locales. También limpia las cosas por separado. En mi humilde opinión, es incorrecto incluir directamente las cosas de terceros en su árbol, pero una sucursal de proveedor logra un buen equilibrio.

Answer 3

Esto podría depender del idioma y / o entorno que tenga, pero para los proyectos en los que trabajo no coloco bibliotecas (archivos jar) en el control de código fuente. Es útil utilizar una herramienta como Maven que busca las bibliotecas necesarias para usted. (Cada proyecto mantiene una lista de los tarros requeridos, Maven los obtiene automáticamente de un repositorio común - http://repo1.maven.org/maven2/ )

Dicho esto, si no está utilizando Maven o algún otro medio de administración y búsqueda automática de las bibliotecas necesarias, por favor verifique su sistema de control de versiones. En caso de duda, sé práctico al respecto.

Answer 4

La forma en que he tendido a manejar esto en el pasado es tomar una versión precompilada de bibliotecas de terceros y verificar esto en el control de versiones, junto con los archivos de encabezado. En lugar de verificar el código fuente en el control de versiones, lo archivamos en una ubicación definida (disco duro del servidor).

Este tipo de te ofrece lo mejor de ambos mundos: un proceso de recuperación en 1 paso que obtiene todo lo que necesitas, pero no atasca tu sistema de control de versiones con un montón de archivos necesarios. Además, al obtener archivos binarios precompilados, puede omitir esa fase de compilación, lo que hace que sus compilaciones sean más rápidas.

Answer 5

La fuente del software de terceros no pertenece (excepto tal vez como referencia estática), pero el binario compilado no pertenece.

Si su proceso de compilación compilará un ensamblado / dll / jar / module, entonces solo mantenga el código fuente de terceros en el control de código fuente.

Si no lo compila, coloque el ensamblado binario / dll / jar / module en el control de origen.

Answer 6

Lo hacemos porque queremos haber probado una versión actualizada de la rama del proveedor antes de integrarla con nuestro código. Nos comprometemos a hacer cambios al probar nuevas versiones. Tenemos la filosofía de que todo lo que necesita para ejecutar la aplicación debe estar en SVN para que

1. Puedes poner en marcha nuevos desarrolladores
2. Todos usan las mismas versiones de varias bibliotecas.
3. Podemos saber exactamente qué código estaba actualizado en un momento dado, incluidas las bibliotecas de terceros.

Answer 7

Me gusta registrar los binarios de terceros en un directorio "lib" que contiene dependencias externas. Después de todo, desea realizar un seguimiento de versiones específicas de esas bibliotecas, ¿verdad?

Cuando compilo los binarios por mí mismo, a menudo verifico una copia comprimida del código junto con los binarios. Eso deja en claro que el código no está ahí para compilar, manipular, etc. Casi nunca necesito regresar y hacer referencia al código comprimido, pero un par de veces me ha resultado útil.

Answer 8

No, no creo que debas poner bibliotecas de terceros en el control de código fuente. La pista está en el nombre ''control de origen''.

Aunque el control de origen se puede usar para distribución y despliegue, esa no es su función principal. Y los argumentos de que solo debería poder revisar su proyecto y hacer que funcione no son realistas. Siempre hay dependencias. En un proyecto web, pueden ser Apache, MySQL, el mismo tiempo de ejecución de programación, por ejemplo Python 2.6. No apilarías todos esos en tu repositorio de código.

Las bibliotecas de código extra son exactamente las mismas. En lugar de incluirlos en el control de origen para facilitar la implementación, cree un mecanismo de distribución / distribución que permita obtener e instalar fácilmente todas las dependencias. Esto hace que los pasos para verificar y ejecutar su software sean como:

• Instalar VCS
• Código de sincronización
• Ejecute el script de configuración (que descarga e instala la versión correcta de todas las dependencias)

Para dar un ejemplo específico (y me doy cuenta de que esto está bastante centrado en la web), una aplicación web de Python puede contener un archivo Requirements.txt que dice:

simplejson == 1.2
django == 1.0
otra biblioteca == 0.9

Ejecutar eso a través de pip y el trabajo está hecho. Luego, cuando desee actualizar para usar Django 1.1, simplemente cambie el número de versión en su archivo de requisitos y vuelva a ejecutar la configuración.

Answer 9

No, no es un crimen de guerra tener un código de terceros en tu repositorio, pero me parece que eso trastorna mi sentido de la estética. Muchas personas aquí parecen ser de la opinión de que es bueno tener a todo su equipo de desarrollo en la misma versión de estas dependencias; Yo digo que es una responsabilidad. Usted termina dependiendo de una versión específica de esa dependencia, donde es mucho más difícil usar una versión diferente más adelante. Prefiero un entorno de desarrollo heterogéneo: lo obliga a desacoplar su código de las versiones específicas de las dependencias.

En mi humilde opinión, el lugar correcto para guardar las dependencias es en sus copias de seguridad en cinta y en su depósito en garantía, si tiene una. Si su proyecto específico lo requiere (y los proyectos no son todos iguales a este respecto), entonces también mantenga un documento bajo su sistema de control de versiones que enlace a estas versiones específicas.

Answer 10

Otra razón para ingresar en las bibliotecas a su control de código fuente que no he visto mencionada aquí es que le brinda la capacidad de reconstruir su aplicación a partir de una instantánea o versión específica. Esto le permite recrear la versión exacta en la que alguien puede informar un error. Si no puede reconstruir la versión exacta, corre el riesgo de no poder reproducir / depurar problemas.

Answer 11

Sí, deberías (cuando sea posible).

Debería poder tomar una máquina nueva y construir su proyecto con la menor cantidad de pasos posible. Para mi es:

1. Instalar IDE (por ejemplo, Visual Studio)
2. Instalar VCS (por ejemplo, SVN)
3. Revisa
4. Construir

Cualquier cosa más tiene que tener muy buena justificación.

Aquí hay un ejemplo: tengo un proyecto que usa el compresor YUI de Yahoo para reducir JS y CSS. Los archivos .jar de YUI entran en el control de código fuente en un directorio de tools junto con el proyecto. Sin embargo, el tiempo de ejecución de Java no se ha convertido en un requisito previo para el proyecto al igual que el IDE. Teniendo en cuenta lo popular que es JRE, parece un requisito razonable.

Answer 12

Si puedo salirme con la suya, los mantengo fuera de mi control de versiones y de mi sistema de archivos. El mejor caso de esto es jQuery, donde usaré la Biblioteca AJAX de Google y la cargaré desde allí:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>

Mi siguiente opción sería usar algo como Git Submodules . Y si ninguno de los dos es suficiente, terminarán en el control de versiones, pero en ese punto, es tan actual como tú ...