¿Qué hacer con proyectos múltiples que dependen de la misma fuente?

Question

Esto es algo que he encontrado dos veces en el último mes y no estoy seguro de cómo expresarlo como una consulta de Google.

En realidad estoy usando SVN para todo esto, pero parece que esto debería ser un problema general de versiones.

Tenemos dos proyectos y uno de ellos depende de algunos de los códigos del otro. Debido a problemas de la API, no es pragmático tener alguna forma de vinculación entre los productos (y no quiero tener que configurar todas las máquinas que no codifican para que esto funcione).

Me imagino que si pongo una copia del código compartido en la estructura del directorio, terminaré sobrescribiendo todos los archivos de configuración que utiliza SVN. Esto significaría que la versión en los directorios del proyecto dependiente ya no podrá actualizarse.

Ex:

Proyecto # 1 tiene que usar el MyExampleClass clase, sin embargo, MyExampleClass es algo que se define como una parte de la necesaria y por el Proyecto # 2.

Answer 1

Mira en svn:externals

Answer 2

Ponga todos los archivos compartidos en una carpeta separada, ya sea en uno de los proyectos o en un uno por separado. Luego use externals para hacer referencia a esa carpeta. Mezclar archivos de diferentes lugares en la misma carpeta es una mala idea.

Answer 3

svn: externals le permitirá traer archivos en un nivel de directorio. Al igual que:

Proj1\ 
    File1 
    File2 

Proj2\ 
    File3 
    File4 

Luego, en Proj2 se puede svn: externos Proj1, y terminar con:

Proj2\ 
    Proj1\ 
    File1 
    File2 
    File3 
    File4 

Ahora bien, si usted quiere tener los archivos de 2 proyectos en 1 carpeta como:

Proj2\ 
    File1 <- from Proj1 
    File2 <- from Proj1 
    File3 
    File4 

Entonces, no creo que SVN lo respalde.

Sin embargo, he trabajado con otras herramientas de control de origen que le permitirían "vincular" un único archivo de un proyecto a otro en cualquier lugar que desee (Borland StarTeam en particular).

Answer 4

Hemos usado svn:externals apuntando al código compartido en práctica desde hace algunos años. Sin embargo, hemos tenido algunos problemas interesantes que probablemente debería considerar antes de usarlo. Esta es la estructura que tenemos:

root 
+---common 
| +---lib1 
| | \---trunk 
| |  +---include 
| |  \---src 
| \---lib2 
|  \---trunk 
|   +---include 
|   \---src 
+---proj1 
| \---trunk 
|  +---include 
|  | \---common 
|  \---src 
|   \---common 
\---proj2 
    \---trunk 
     +---include 
     | \---common 
     \---src 
      \---common 

Los directorios common tanto include y src en un proyecto contienen definiciones externas que tiran en las bibliotecas comunes:

c:\dev> svn pget -v svn:externals proj1\trunk\src\common 
Properties on 'c:\dev\proj1\trunk\src\common': 
    svn:externals : lib1 http://.../common/lib1/trunk/src 
        lib2 http://.../common/lib2/trunk/src 

El problema que se nos ha acabado es multifacético pero está relacionado con el etiquetado y la ramificación de nuestra fuente a medida que los proyectos cambian a lo largo del tiempo. La definición externa que mostró anteriormente tiene algunos problemas muy graves si usted quiere tener reproducibles construye:

1. Se refiere a un objetivo dinámico - trunk.
2. No se refiere a una revisión explícita.

Cuando se bifurca usando svn copy, los elementos externos se copian textualmente, ya que en realidad son solo propiedades asociadas al objeto. Algunos de los otros comandos svn (commit, checkout y export) realmente interpretan las propiedades. Cuando etiqueta un proyecto, realmente desea conservar el estado del proyecto para siempre. Esto significa que debe "anclar" los elementos externos a una revisión específica, por lo que debe cambiar la definición externa para hacer referencia explícita a la revisión que desee (por ejemplo, "lib1 -r42 http://.../common/lib1/trunk/src"). Esto resuelve una faceta del problema.

Si tiene que mantener varias ramas incompatibles del código común, entonces debe especificar qué rama desea explícitamente junto con (posiblemente) la revisión.

Huelga decir que esto puede ser un poco dolor de cabeza. Afortunadamente, alguien en el terreno de Subversion escribe el script svncopy.pl que automatiza parte de este lío. Todavía estamos (y hemos estado) luchando con algunas de las dificultades para respaldar esto en un producto desplegado en el campo con un montón de código compartido y un mandato de tres versiones diferentes en el campo en cualquier momento.

Si avanza por esta ruta, asegúrese de considerar cómo va a mantener los vínculos a medida que los proyectos crecen y cambian. Hemos descubierto que un poco de tiempo pensando en un proceso nos servirá de mucho.

Answer 5

Externos, pero no ser conscientes de este problema:

Subversion update externals to a date