He leído algunas respuestas aquí que condenan el uso de svn: externals. Veo cómo pueden ser mal utilizados, y nos hace más dependientes de Subversion, pero realmente no veo a nuestro grupo alejarse de él en el corto plazo.svn externals ... sí o no?
De todos modos, aquí está mi dilema. Tenemos soluciones que hacen referencia a múltiples proyectos que se encuentran en su propia sección del repositorio. Muchos de estos proyectos se comparten entre múltiples soluciones, y tampoco queremos excluir el intercambio de nuestros proyectos. También tenemos varias dependencias de versión fija registradas en nuestro repositorio (marcos de prueba de unidades, bibliotecas, etc.).
me gustaría configurar varios espacios de trabajo '' que sólo utilizan los externos (en lo que se refiere a la subversión que serían sólo los directorios vacíos o contener tal vez un solo archivo de solución) para configurar soluciones para nuestros desarrolladores. Ver la mayoría de los proyectos por sí solos no será suficiente para construirlos, pero revisar su espacio de trabajo será suficiente para construirlo porque todas sus dependencias vendrán con él. ¿Alguien más ha implementado una solución similar, y svn: external sería una buena forma de hacerlo? ¿Qué palabras de precaución tienes para mí si avanzamos por este camino?
Básicamente la estructura se vería así (tronco/ramas/etiquetas omitidos por razones de brevedad):
/projects
/project1
/project2
/dependencies
/xUnit
/1.5
/1.4
/NHibernate
/2.1.0
/2.0.1
/workspaces
/project1
/project1 (external to ^/projects/project1)
/xUnit (external to ^/dependencies/xUnit/1.5)
/NHibernate (external to ^/dependencies/NHibernate/2.0.1)
/project2
/project2 (external to ^/projects/project2)
/xUnit (external to ^/dependencies/xUnit/1.4)
/NHibernate (external to ^/dependencies/NHibernate/2.1.0)
Tenga en cuenta que se ha movido el enlace de esa publicación de blog.Ahora está aquí: http://cobaltedge.com/svn-externals-are-evil-use-piston-or-braid – chrisrbailey