Otro enfoque que puede tomar para esto es usar la propiedad Subversion externals para poder administrar su código, ya sea en repositorios separados o en un único repositorio. La ventaja es que simplemente puede actualizar las URL en cuestión cuando necesite una nueva versión del código compartido en su solución.
Nota: No recuerdo a Jack sobre la solución de Visual Studio y la organización del proyecto; Han pasado al menos 5 años desde que hice cualquier desarrollo de Windows. Dicho esto, esta discusión es aplicable independientemente del diseño del archivo/directorio. Voy a hacer uno y por favor solo ajústelo a su situación real.
Supongamos que tiene un gran repositorio que tiene todos sus proyectos relacionados en él. Si crees que no es necesariamente escalable, te sugiero echar un vistazo al Apache projects SVN setup; ellos tienen todos los proyectos en un repositorio. Tomando una página de la ASF, vamos a empezar por la estructura del repositorio de la siguiente manera:
/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches
/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches
/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches
/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches
Hasta el momento esto es sólo un diseño estándar SVN; cada entidad más o menos independiente tiene su propia área del repositorio para jugar. Ahora, supongamos que ha estado desarrollando lejos en el SharedClassLib y está hasta la versión 2.0.0, y en SharedWebService está en la versión 1.2.5. La estructura de directorios se verá algo como:
/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0
/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5
Las otras etiquetas son sólo para ilustración del hecho de que su desarrollo ha estado marchando en el tiempo y que ha tenido varias versiones.
Ahora, de vuelta en SolutionA, tiene un proyecto LocalClassLibrary y un proyecto LocalWebApp.Estos proyectos son estrictamente parte de esta solución y no se comparten fuera de esta solución. Tomar una puñalada en una estructura de directorios, el tronco podría ser algo como:
Por lo tanto, nuestro problema es, ¿cómo podemos llegar al SharedClassLib y SharedWebService en nuestra SolutionA? Mediante el uso de elementos externos de Subversion. Primero lea la página web externals, luego regrese aquí.
Para hacerte la vida un poco más fácil, te sugiero crear un archivo svn.externals en tu directorio de soluciones para establecer la propiedad svn: externals si estás haciendo esto desde la línea de comandos. Si está utilizando alguna otra herramienta, solo tenga en cuenta que en este caso, necesitará agregar varias líneas. El archivo se verá así:
SharedClassLib http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService http://your.svn.server/SharedWebService/tags/1.2.5
Editar 1: En este punto, se puede ver que las direcciones URL que usted se refiere son completamente calificado. Lo que significa que pueden ser repositorios separados, y no tienes que usar el diseño que he descrito aquí. Además, si se encuentra en una etapa intermedia en su desarrollo y necesita la última versión de desarrollo de su código compartido, use una URL como http://your.svn.server/SharedClassLib/trunk. Sin embargo, en algún momento, querrá establecer una versión de sable del código externo antes de etiquetar y lanzar su solución.
Editar 2: Tenga en cuenta que esta es la sintaxis svn pre-1.5. Ha cambiado un poco en 1.5
Haga un svn propset svn:externals -F svn.externals . en su directorio de soluciones, luego svn commit && svn update. En este punto, svn completará su copia de trabajo con el contenido de esas URL. Su copia de trabajo sería algo como:
./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>
Cuando tenga que traer nuevas versiones de los proyectos compartidos, actualice la propiedad svn: externos adecuadamente. Tenga en cuenta que hay algunas advertencias sobre este enfoque y se detallan en la documentación de SVN Externals. Principalmente, no planeas ser capaz de hacer cambios en ./SolutionA/SharedClassLibrary y esperar que los cambios sean mágicamente recogidos cuando realizas una confirmación en la Solución A.
Ahora está listo para lanzar SolutionA al mundo. Basta con crear la etiqueta apropiada (copia SVN) del tronco al directorio etiquetas:
/SolutionA/tags/1.0.0
Ahora su SolutionA tendrá su propio código en la correcta etiqueta/versión, y está utilizando la versión correcta de los proyectos compartidos para ese lanzamiento.
Obviamente, la misma discusión se aplica a SolutionB.
No he trabajado con SVN desde hace tiempo, así que mis disculpas si he entendido algo de lo anterior un poco mal.
Pero cuando agrego nuevas características a mis proyectos dll compartidos que están separados de las soluciones (tiene su propio repositorio) mientras desarrolla otras necesidades de proyecto, el resto de los proyectos principales no tendrán las nuevas características. Quiero mantener cada proyecto actualizado pero compatible con los proyectos principales. – uzay95
De hecho, este es un problema si los proyectos dependientes están en otro repositorio. Si estos proyectos estuvieran en el mismo repositorio, podría etiquetarlos juntos. Mi respuesta se basa en la recomendación de que todos sus proyectos relacionados estén dentro del mismo repositorio. Si esto no es posible, puede haber una forma aceptada de hacerlo, como usar svn: extern (ver: http://svnbook.red-bean.com/en/1.0/ch07s03.html) pero aunque no tengo experiencia directa con esto, tengo la impresión de que es algo que solo debería usarse por necesidad. – Derrick