Estoy desarrollando algunas bibliotecas de clases con un equipo distribuido. Usamos Subversion para nuestro control de fuente. Uno de los desarrolladores quiere asignar sus directorios bin y obj al repositorio, que nunca ha sido una práctica estándar para mí. ¿Cuál es la mejor práctica? ¿Cuáles son los pros y los contras?¿Debo agregar binarios compilados a mi repositorio Subversion?
Seguramente no debería agregar ningún archivo compilado a la rama principal. No puede compararlos con las herramientas habituales y ralentizarán todo.
En las versiones de las versiones de las versiones, puede incluirlas para tener los archivos compilados originales, por lo que no habrá ninguna diferencia porque el compilador haya cambiado o algo así.Pero lo más probable es que tenga todas las versiones binarias almacenadas en otro lugar y Subversion no es realmente el lugar correcto.
También excluimos esos archivos ya que "contaminan" de alguna manera sus cambios a lo largo del tiempo. Por lo tanto, en cada confirmación tendrá un montón de otros archivos modificados, pero solo estará interesado en su código fuente que cambió y no en los archivos compilados.
así que imagina que está intentando comprobar lo que salió mal en la revisión XYZ y que se ve en los cambios de la siguientes ...
A.dll
B.dll
c.dll
d.cs
e.dll
... ... ...
pero sólo está interesado probablemente en la fuente, por lo que esas versiones de archivos que no sean contaminantes no tiene mucho sentido, también porque no se puede ya que lo que cambió el interior de los binarios de todos modos ..
No enviamos archivos bin y obj, ya que se crean al compilar, por lo que no es necesario. No sé si esa es una mejor práctica, más una opinión personal.
Supongo que puede tener una carpeta separada para "dlls completados" o algo así si se trata de una versión finalizada de un dll ??
Veo por qué podría querer comprometer los contenedores, por ejemplo, si tiene versiones diferentes de una aplicación que necesita mantener que requieren versiones específicas de los archivos DLL. Pero incluso en ese caso, siempre puedes construir nuevos contenedores de una etiqueta/rama.
En cuanto a la comisión de los archivos OBJ, no se me ocurre ninguna buena razón para hacer eso ..
Mi regla es que se excluyen todos los archivos generados.
Lo mismo para mí, con la única excepción del proyecto web. Dado que algunos de los archivos DLL pueden no ser su código y el sitio no funcionará directamente fuera de la fuente. Los proyectos web no tienen un mecanismo de referencia para configurar el proyecto fresco, es un dolor en el culo que busca dependencias. –
En cuanto a los proyectos web, ¿no podría usar los archivos .refresh? Apuntan a la DLL real, por lo que si obtiene una copia nueva del origen del repositorio e incluye archivos .refresh, se compilará bien. –
No agregaría librerías compiladas al control de fuente a menos que no tenga el código fuente.
Por ejemplo:
tercio del partido Bibliotecas/controles para los que no tengo la fuente = ir en control de código fuente bajo algún tipo de carpeta "Dependencias".
Todas las bibliotecas que escribimos = Solo la fuente está en el repositorio, nunca los binarios.
A menos que exista un buen motivo que haya omitido mencionar, entonces no, no agregue los directorios de su bin al control de código fuente. No veo ninguna buena razón para enviar sus directorios obj.
Normalmente, nunca enlace el directorio bin al sistema de control de fuente. El motivo es que debe ser reproducible automáticamente y, por lo tanto, no hay ningún valor para agregar los dlls generados al control de origen.
Lo mismo ocurre con los archivos de origen generados, pero hay una excepción: si lleva tiempo o si tiene que tener una infraestructura para generar los archivos de origen, entonces los agrego al control de origen.
Cuando desee administrar diferentes versiones, el enfoque de sucursal sería mi favorito.
Intento no almacenar ningún binario en nuestro sistema de control de fuente, ni siquiera en las bibliotecas donde no tenemos la fuente. Tener los binarios en el repositorio abota el repositorio y hace que los registros sean lentos.
Usamos Maven para construir nuestros proyectos de Subversion. En Maven, todos los binarios que necesita tu aplicación (pero no creados por tu aplicación) se almacenan fuera de la subversión en lo que se denomina un repositorio de Maven. Maven usa convenciones para adjuntar una "versión" a los archivos binarios utilizados por las aplicaciones. Estos archivos son compartidos fácilmente por las aplicaciones y los desarrolladores (1 copia para todos).
El único caso en el que he visto que tiene valor es en una aplicación de n niveles donde algunos binarios se distribuyen de un nivel a otro.
Por ejemplo, parte del código representa objetos comunes utilizados por todos los niveles. Entonces, cada nivel es realmente su propio subproyecto que utiliza los objetos comunes a los que se hace referencia como binarios, pero trabajar en ese nivel solo depende solo del binario. En ese caso, aunque en el proyecto como un todo, el código fuente está allí, de hecho, un binario es una parte del proyecto, como una biblioteca de terceros en cierto modo.
En ese caso, puede tener sentido asegurarse de que el nivel continúe compilando exitosamente congelando la versión correcta del binario en el control de fuente, y no siempre construyendo desde la fuente.
Dicho esto, la vida será mucho más fácil si puede anular ese paradigma e incluir todas las dependencias en la compilación de cada nivel. Tener los archivos binarios de una parte del proyecto detrás de la fuente en otra no es bonito y puede llevar al desastre.
No enviamos carpetas bin u obj, y solíamos crear una nueva carpeta en la raíz del repositorio llamada library y colocamos allí todos los archivos dll importantes, como las herramientas de terceros usadas, por ejemplo ajaxtoolkit, fckeditor , .... y otros archivos dll vemos que es importante para este proyecto.
Bueno, juguemos a la defensa del diablo ... aquí hay un caso para almacenar archivos DLL en un repositorio.
La empresa A tiene más de 6 equipos en cualquier momento dado. La mayoría de estos equipos desarrollan al menos una parte de su producto en C#. Dada la naturaleza específica de la empresa A, las clases estándar de DateTime no tienen suficiente funcionalidad, por lo que han desarrollado sus propias clases derivadas de DateTime, que están disponibles en una DLL.
Cada uno de los 6+ grupos tiene su propio directorio en el repositorio y la mayoría requiere las DLL de DateTime, por lo que tienen una copia de las DLL compiladas en cada directorio de producto y solo insertan nuevas copias en un directorio cuando hay nuevas funcionalidad disponible que requiere el proyecto en ese directorio.
¿Hay alguna otra solución que ofrezca las siguientes ventajas ?: 1) Impide que los desarrolladores tengan la verificación de dos directorios para trabajar en un único proyecto. (En la vida real hay más de dos, pero por el bien de este ejemplo, vamos a llamarlo dos.) 2) Impide que QA tenga que volver a probar todos los productos cuando solo un producto necesita cambiar las clases DateTime.
Deben incluirse las bibliotecas personalizadas a las que hace referencia el proyecto, pero son diferentes de los archivos generados de las carpetas bin/obj. Idealmente, debería mantener bibliotecas personalizadas en una carpeta "libs" que se incluye con el proyecto. –
¿Por qué quiere enviar sus directorios bin y obj? ¿Tiene una buena razón? – Grant
Véase también http://stackoverflow.com/questions/709372/alternative-to-binaries-in-subversion –