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



source control visual studio (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.

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

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 #3

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ú ...


Answer #4

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 #5

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 #6

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 #7

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 #8

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 #9

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.





version-control