.net - tutorial - tortoise svn server
¿Cuál es la forma óptima de organizar ensamblados.NET compartidos en SVN? (2)
Estamos comenzando un nuevo proyecto SOA con muchos ensamblados .net compartidos. El código para estos ensambles se almacenará en SVN.
En fase de desarrollo, nos gustaría ser capaces de codificar estos ensamblajes como una solución completa con la menor "fricción" de SVN posible.
Cuando el proyecto ingrese a más de un modo de mantenimiento, los ensamblajes se mantendrán en un nivel individual.
Sin hacer de las ramificaciones, el etiquetado y las compilaciones automatizadas una pesadilla de mantenimiento, ¿cuál es la mejor forma de organizar estas bibliotecas en SVN que también funciona bien con el IDE de VS 2008?
¿Configura Trunk / Branches / Tags en cada nivel de biblioteca y trata de espaguetizar todo junto de alguna manera en tiempo de compilación, o es mejor mantenerlo todo como un gran proyecto con código replicado aquí y allá por simplicidad? ¿Hay alguna solución usando externos?
Lo que hicimos con los ensambles compartidos durante la fase de desarrollo (en un proyecto que tuvo un montón de estos), es que los colocamos en un tipo de lugar de compartimiento de red (N Drive), y cada desarrollador hizo referencia a ellos desde allí.
Nuestro proceso de compilación siempre actualizará esta acción con las últimas versiones. De esta forma, los ensamblajes reales nunca tuvieron que mantenerse en control de fuente. Solo el código
Lo que hicimos en nuestra compañía fue configurar un repositorio de herramientas y luego un repositorio de proyectos . El repositorio de herramientas es un repositorio de Subversion, organizado de la siguiente manera:
/svn/tools/
vendor1/
too11/
1.0/
1.1/
latest = a copy of vendor1/tool1/1.1
tool2/
1.0/
1.5/
latest = a copy of vendor1/tool2/1.5
vendor2/
foo/
1.0.0/
1.1.0/
1.2.0/
latest = a copy of vendor2/foo/1.2.0
Cada vez que recibimos una nueva versión de una herramienta de un proveedor, se agrega bajo su proveedor, nombre y número de versión, y se actualiza la etiqueta ''más reciente''.
[Aclaración: este NO es un repositorio fuente típico: está destinado a almacenar versiones específicas de imágenes ''instaladas''. Por lo tanto, /svn/tools/nunit/nunit2/2.4 sería la parte superior de un árbol de directorios que contiene los resultados de instalar NUnit 2.4 en un directorio e importarlo al depósito de herramientas. Puede haber fuentes y ejemplos, pero el foco principal está en los ejecutables y bibliotecas que son necesarios para usar la herramienta. Si necesitáramos modificar una herramienta de proveedor, lo haríamos en un repositorio separado y publicaríamos el resultado en este repositorio. ]
Uno de los vendedores es mi empresa, y tiene una sección separada para cada herramienta, ensamblaje, lo que sea que entreguemos internamente.
El repositorio de proyectos es un repositorio estándar de Subversion, con troncos, etiquetas y ramas como normalmente se espera. Cualquier proyecto dado se verá así:
/svn/
branches/
tags/
trunk/
foo/
source/
tools/
publish/
foo-build.xml (for NAnt)
foo.build (for MSBuild)
El directorio de herramientas tiene un conjunto de propiedades Subversion svn: externals , que enlaza en la versión apropiada (ya sea una versión específica o ''última'') de cada herramienta o conjunto que necesita ese proyecto. Cuando CruiseControl.NET crea el proyecto ''foo'', la tarea de publicación completará el directorio ''publicar'' como el ensamblado ''foo'' y luego ejecutará los siguientes comandos de subversión:
svn import publish /svn/tools/vendor2/foo/1.2.3
svn delete /svn/tools/vendor2/foo/latest
svn copy /svn/tools/vendor2/foo/1.2.3 /svn/tools/vendor2/foo/latest
Los desarrolladores trabajan en sus proyectos de forma normal y dejan que la automatización de la construcción se encargue de los detalles. Una actualización de subversión normal extraerá las últimas versiones de herramientas externas, así como las actualizaciones del proyecto.
Si tiene mucha interdependencia con las herramientas, puede configurar CruiseControl.NET (a mano) para desencadenar compilaciones para proyectos subordinados cuando cambian sus dependencias, pero no hemos necesitado ir tan lejos todavía.
Nota: Todas las rutas del repositorio de Subversion se han acortado para mayor claridad. En realidad usamos Apache + SVN, y dos servidores por separado, pero debes adaptarlo como mejor te parezca.