La mejor estrategia para ramificar el código SVN y mantener las references del proyecto de Visual Studio

Tenemos un proyecto principal de estudio visual almacenado en SVN utilizando la estructura estándar trunk / branches / tags. Sin embargo, este proyecto hace reference a proyectos externos fuera de esta estructura, por lo que cuando creamos una bifurcación de código, todas las references a los proyectos externos fallan ya que están un nivel fuera.

es decir. trunk / MyProjectCode se convierte en branches / MyFeatureBranch / MyProjectCode después de la bifurcación, por lo que debido a este nivel adicional de jerarquía, cualquier reference a proyectos externos falla.

¿Cuál es el mejor enfoque para crear twigs con la menor fricción posible? Podría escribir un guión que modifique todas las references del proyecto, o podría cambiar el layout de mi código local para que las twigs estuvieran en un nivel inferior al del tronco, por lo que una nueva twig estaría en el mismo nivel. ¿Alguna otra sugerencia / mejores prácticas?

Al realizar una salida desde Subversion, su directory de trabajo no tiene que reflejar la misma profundidad de directory que en el repository. Usando la línea de command por ejemplo:

  svn co svn: // proyecto del server / proyecto / troncal
 svn co svn: // server / proyecto / twigs / MyFeatureBranch project-feature 

De esta forma, tendrá dos directorys uno al lado del otro denominados project y project-feature . Esto debería evitar problemas con diferentes profundidades de directory y references de ruta relativas.

Sucistramos todo lo que pertenece a ese producto. Entonces, si hay 5 proyectos que son parte de él, ramificamos los 5 proyectos, para asegurarnos de que tenemos una copy completa de lo que esa twig va a usar. Si tiene problemas con las routes, le recomendamos que consulte un progtwig llamado Junction .

Lo que he hecho en el pasado es, para una tienda de desarrollo en desarrollo de muchos proyectos y muchas references comunes, mantener las references externas en una location compartida. Puede ser un recurso compartido de networking o una location acordada (absoluta) que todos tengan en su disco duro (estructurado como C: \ ShanetworkingLibs \ Library \ Version). Guardamos las shanetworkinglibs en un repository svn separado que todos tenían que verificar en la carpeta ShanetworkingLibs, y configuramos nuestras references a esta ruta absoluta.

Otra estrategia que he aplicado es lo que también se encuentra en muchos proyectos de código abierto: simplemente almacene las references junto con su proyecto. Por ejemplo, podría tener un tronco con subcarpetas src (para el código fuente) y lib (para references externas). Esta es probablemente una mejor práctica: todo lo que necesita hacer para build el proyecto (ya sea troncal o sucursal) es verificarlo y ejecutar su herramienta de compilation.

Otra opción más es usar la propiedad svn: externals. Con esta propiedad, puede asegurarse de que los files de otras ubicaciones en su repository (o de otros repositorys) se comprueben junto con su proyecto. Por experiencia, no lo recomiendo, pero es una opción. Lea sobre esto en el libro svn: http://svnbook.networking-bean.com/en/1.5/svn.advanced.externals.html

Tuvimos el mismo problema aquí y he pensado en editar los files .sln y .csproj. Reemplace las routes relativas por routes absolutas. Estaba un poco preocupado por hacer esto ya que VS mantiene estos files y lo que es detenerlo de deshacer esto y volver a routes relativas en algún momento en el futuro (cuando un desarrollador guarda el proyecto y lo registra, por ejemplo).

Esta mañana tuve un "momento de claridad" en mi viaje diario: a pesar de que estamos almacenando la sucursal en una carpeta de sucursales dedicada, ¿por qué tengo que comprobarlo en uno?

Entonces, en lugar de:

 C: |_ svnworkarea |_ project |_ branches |_ project-feature |_ source etc |_ trunk |_ source etc 

Ahora tengo:

 C: |_ svnworkarea |_ project |_ project-feature |_ source etc |_ trunk |_ source etc 

Como las carpetas de origen ahora están en el mismo nivel, las routes relativas son válidas y las references se cargan como se esperaba. El tronco aún está totalmente separado y es fácilmente identificable, mientras que las características del proyecto están identificadas por un nombre de carpeta significativo, por ejemplo, NewUIBranch.