svn externals ... sí o no?

Question

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.

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) 

Answer 1

SVN Externals are Evil; Use Piston or Braid parece típica del campo anti-externa. Y el póster tiene un punto.

Creo que un mejor criterio es:

• Use referencias externas de proyectos internos que se pueden cambiar; y
• Use vendor branches para repositorios externos sobre los que no tiene control.

Parece que los problemas con svn externals provienen de personas que los utilizan como un sustituto de las sucursales de los proveedores. He visto a muchas personas quejándose de ellos en el contexto de complementos de Rails de terceros.

Por lo tanto, en su caso, suponiendo que estos proyectos son todos "internos", entonces creo que un svn externo es un enfoque perfectamente válido.

Answer 2

Definitivamente estoy de acuerdo con la respuesta anterior. Desde mi experiencia con Externals es una solución excelente para módulos de infraestructura y bibliotecas "internas" siempre que establezca los externos a etiquetas específicas de la biblioteca y no a su troncal.

No entendí exactamente por qué desea utilizar el espacio de trabajo que está completamente basado en elementos externos y no agrega los elementos externos directamente al proyecto en sí. Mi enfoque es que cualquier proyecto que cree en el SVN debe ser "construible" cuando se haya extraído.

En mi enfoque de su repositorio debe ve así:

/dependencies 
    /xUnit 
      /tags 
       /1.5 
       /1.6 
      /trunk 
    /NHibernate 
      /tags 
       /2.1.0 
       /2.0.1 
      /trunk 
/projects 
    /project1 
      /tags 
       /1.0 
        /sources 
        /xUnit(externals to /dependencies/xUnit/tags/1.5) 
        /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
      /trunk 
       /sources 
       /xUnit(externals to /dependencies/xUnit/tags/1.6) 
       /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
    /project2 
      /tags 
       /1.0 
        /sources 
        /xUnit(externals to /dependencies/xUnit/tags/1.6) 
        /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
      /trunk 
       /sources 
       /xUnit(externals to /dependencies/xUnit/tags/1.6) 
       /NHibernate(externals to /dependencies/NHibernate/tags/2.1.0) 

Answer 3

Si su svn:externals hacen referencia únicamente a las bibliotecas 3 ª parte, ¿por qué no sólo tiene que utilizar un repositorio Maven/Ivy? Estos son para el mundo de Java y no sé sus colgantes de .Net, pero estoy bastante seguro de que existen.

Solo uso svn:externals para compartir archivos Ant antib, hasta que les dé la posibilidad de cargarlos desde un archivo jar.