Nant: Cómo estructurar svn: externals para comstackr bibliotecas de classs que hacen reference a dll's de terceros

Estoy usando subversion y nant (y visual studio IDE)

He estado siguiendo la estructura de proyecto sugerida en http://blog.jpboodhoo.com/NAntStarterSeries.aspx, que aboga por directorys de subversión autónomos en los que un desarrollador puede realizar un pago e inmediatamente crear un proyecto en un solo paso.

Mi estructura de repository es como:

/Repo /MainProject /trunk /doc <-- documentation /lib <-- binary-only DLLs /src <-- source code for MainProject /tools <-- holds tools like nant, nunit, etc ... /ClassLibrary1 /trunk /doc /lib /src /tools ... /ClassLibrary2 /trunk /doc /lib /src /tools 

Lo que no está claro es cómo estructurar un proyecto que tiene bibliotecas de classs que a su vez hacen reference a los dll de biblioteca de terceros.

Actualmente, tengo un proyecto principal con un directory de trabajo como

Ejemplo:

 /MainProject /build /lib /src /MainProject /ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src /ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src /tools ... 

Al build MainProject, compilo las bibliotecas de class y el dll de salida a la carpeta de compilation. Sin embargo, las propias bibliotecas de class tienen DLL de solo binary de terceros a los que hacen reference.

Mis preguntas son para build el proyecto principal. De alguna manera, tengo que get las DLL de terceros de las bibliotecas de classs en el resultado de compilation. ¿Cómo puedo hacer eso?

Pensamientos: 1. ¿Debo save copys de estos dlls de terceros en la carpeta lib de MainProject? 2. ¿O debería mi svn: reference externa ser el tronco del proyecto de la biblioteca de la class en lugar del src para que pueda acceder a la carpeta lib de la biblioteca de la class? 3. ¿Debo usar la característica de subversión 1.6 de svn: externos a files individuales?

Personalmente traigo el tronco de las bibliotecas referencedas. (En realidad, traigo la raíz de una label, pero eso está al lado del punto).

Si conserva una copy por separado de los dll requeridos, entonces realmente no está permitiendo que la biblioteca referenceda determine lo que necesita para sí misma porque toda esa lógica está duplicada en el proyecto. Lo mismo sucede si usa references externas múltiples o externals de file para traer el código y el dll.

Mi principio aquí es que la biblioteca sabe lo que necesita, una sola reference externa a la biblioteca puede get esa biblioteca y todo lo que necesita.

De esta manera, si cambias las references de la biblioteca, puedes estar seguro de que todos y cada uno de los proyectos solo recogerán eso. (Si el IDE no lo admite, ese es el problema del IDE, no del subverion). También puede estar seguro como proyecto de que si cambia la versión de la biblioteca a la que está apuntando, también obtendrá automáticamente las references correctas, y no necesita ir a fallas de compilation para resolver lo que salió mal .

  1. ¿Debo save copys de estos dlls de terceros en la carpeta lib de MainProject? Prefiero almacenar cualquier biblioteca externa en un directory binary bajo el tronco pero al lado de la fuente … o llamarlo references, dependencies, etc. Esto luego permite que cualquier desarrollador obtenga lo último y todo lo que se necesita se networkingucirá. No necesita ser parte del proyecto per se. Solo necesita ser accesible cuando se realiza la compilation.

  2. ¿O debería mi svn: reference externa estar en el tronco del proyecto de biblioteca de class en lugar del src para poder acceder a la carpeta lib de la biblioteca de class? No prefiero este enfoque, ya que hace que el process de conseguir un nuevo desarrollador sea más complicado. Creo que una asamblea puede ir a su propio repository cuando tiene un nivel de importancia para sí mismo. Pero nunca haría reference a su salida. Debe tener un process de compilation alnetworkingedor que promueva un mecanismo para "implementar" el resultado en el directory de references o dependencies anterior. Sin embargo, la automation de la implementación así podría estar plagada de problemas. Sería mejor si la asamblea tuviera su propio process a su alnetworkingedor. Y cuando se lanzara una nueva versión del ensamble, sería adoptada manualmente por un desarrollador en el proyecto que la necesitaba. Luego podrían probarlo, aceptarlo y colocarlo en su process de construcción. Obviamente, si ese ensamblaje cambia a diario, es posible que se requiera cierta automation.

  3. ¿Debo usar la function subversión 1.6 de svn: externals a files individuales? No. Prefiero mantener un proyecto / solución como una entidad autónoma. Tener tiendas de campaña repartidas por todo el lugar hace que las dependencies sean más dolorosas. Mantenga los silos tan duros como sea posible … traiga cosas nuevas de la manera más manual posible … o tan manuales como lo permita la frecuencia que cambian las cosas.

Tuve una necesidad similar y encontré una respuesta breve y dulce en la documentation de TortoiseSVN:

http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html