¿Cómo organiza su repositorio de control de versiones?

Question

¿Cómo organiza su repositorio de control de versiones?

Primero, sé sobre esto: ¿Cómo organizaría un repositorio Subversion para proyectos de software internos? A continuación, la pregunta real: Mi equipo está reestructurando nuestro repositorio y estoy buscando consejos sobre cómo organizarlo. (SVN en este caso). Esto es lo que se nos ocurrió. Tenemos un repositorio, múltiples proyectos y múltiples svn:externals cross-references

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

Para borrar el vocabulario: Solución significa producto único, Proyecto es un Proyecto de Visual Studio (que resulta en una sola .dll o single .exe)

Así es como planeamos diseñar el repositorio. El problema principal es que tenemos múltiples Soluciones, pero queremos compartir Proyectos entre Soluciones. Pensamos que realmente no tiene sentido mover esos Proyectos compartidos a sus propias Soluciones, y en su lugar decidimos usar svn:externals para compartir Proyectos entre Soluciones. También queremos mantener un conjunto común de herramientas y bibliotecas de terceros en un solo lugar en el repositorio, y hacer referencia a ellas en cada Solución con svn: externos.

¿Qué opinas sobre este diseño? Especialmente sobre el uso de svn: externals. No es una solución ideal, pero teniendo en cuenta todos los pros y los contras, es lo mejor que se nos ocurrió. Cómo lo harías?

108

svn version-control repository projects-and-solutions

Author: Krzysztof Kozmic, 2008-10-21

Source

8 answers

Creo que Pragmatic Version Control usando Subversion tiene todo lo que necesita para organizar su repositorio.

3

Author: Fabio Gomes,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 18:21:30

Hemos configurado el nuestro para que coincida casi exactamente con lo que has publicado. Usamos la forma general:

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

Aunque supongo que no es tan completo como tu ejemplo, ha funcionado bien para nosotros y nos permite mantener las cosas separadas. Me gusta la idea de que cada usuario tenga una carpeta "Thrash" también - actualmente, ese tipo de proyectos no terminan en control de código fuente, y siempre he sentido que deberían.

3

Author: SqlRyan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 18:32:22

¿Por qué tenerlo todo en un repositorio? ¿Por qué no tener un repositorio separado para cada proyecto (me refiero a "Solución")?

Bueno, al menos me he acostumbrado al enfoque de un proyecto por repositorio. Su estructura de repositorio me parece demasiado complicada.

¿Y cuántos proyectos planeas poner en este gran repositorio? 2? 3? 10? 100?

¿Y qué haces cuando cancelas el desarrollo de un proyecto? Simplemente elimínelo del árbol del repositorio para que sea difícil encontrar en el futuro. ¿O dejarlo tirado para siempre? ¿O cuando desea mover un proyecto a otro servidor por completo?

¿Y qué hay del desorden de todos esos números de versión? Los números de versión de un proyecto van como 2, 10, 11, mientras que el otro va como 1, 3, 4, 5, 6, 7, 8, 9, 12...

Tal vez soy tonto, pero me gusta un proyecto por repositorio.

1

Author: Rene Saarsoo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 18:57:23

Creo que la principal desventaja de la estructura propuesta es que los proyectos compartidos solo se versionarán con la primera solución a la que se agregaron (a menos que svn:externals sea más elegante de lo que estoy imaginando). Por ejemplo, cuando se crea una rama para la primera versión de Solución2, Project1 no estar ramificado desde que vive en la Solución 1. Si necesita compilar desde esa rama en un momento posterior (QFE release), utilizará la última versión de Project1 en lugar de la versión de Project1 en ese momento de la rama.

Por esta razón, puede ser ventajoso poner los proyectos compartidos en una o más soluciones compartidas (y por lo tanto directorios de nivel superior en su estructura) y luego ramificarlos con cada versión de cualquier solución.

0

Author: C. Dragon 76,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 18:55:01

Para añadir al problema de la ruta relativa:

No estoy seguro de que sea un problema:
Solo tienes que checkout Solution1 / trunk bajo el directorio llamado "Solution1", lo mismo para Solution2: el objetivo de los 'directorios' que representan ramas es que no sean visibles una vez importados en un espacio de trabajo. Por lo tanto las rutas relativas son posibles entre la "Solución 1' (en realidad 'Solución 1/tronco') y 'Solución2' (Solución2/tronco).

0

Author: VonC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 18:58:42

RE: la ruta relativa y el problema del archivo compartido -

Parece que esto es específico de svn, pero eso no es un problema. Otra persona ya mencionó repositorios separados y esa es probablemente la mejor solución que se me ocurre en el caso de que tengas diferentes proyectos que se refieran a otros proyectos arbitrarios. En el caso de que no tenga archivos compartidos, la solución OP (así como muchas otras) funcionará bien.

Todavía estamos trabajando en esto y tengo 3 diferentes esfuerzos (diferentes clientes) que tengo que resolver ahora mismo, ya que me hice cargo de configurar un control de versiones inexistente o pobre.

0

Author: Tim,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-21 19:11:49

Tengo un diseño similar, pero mi tronco, ramas, etiquetas todo el camino en la parte superior. So: / trunk / main, / trunk/utils,/branches/ release/, etc.

Esto terminó siendo muy útil cuando queríamos probar otros sistemas de control de versiones porque muchas de las herramientas de traducción funcionaban mejor con el diseño básico SVN de libros de texto.

0

Author: Peter Mortensen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-11-26 17:23:19

score 93 · Accepted Answer

Si sigues mis recomendaciones a continuación (las tengo desde hace años), podrás:{[16]]}

Put coloque cada proyecto en cualquier lugar del control de código fuente, siempre y cuando conserve la estructura del directorio raíz del proyecto en down

Build construya cada proyecto en cualquier lugar en cualquier máquina, con un riesgo mínimo y una preparación mínima

Build construye cada proyecto completamente independiente, siempre y cuando tengas acceso a sus dependencias binarias ("biblioteca" local y " salida" directorios)

Build construir y trabajar con cualquier combinación de proyectos, ya que son independientes

Build construir y trabajar con múltiples copias / versiones de un solo proyecto, ya que son independientes

Avoid evite saturar su repositorio de control de código fuente con archivos o bibliotecas generadas

Recomiendo (aquí está la carne):

Definir cada proyecto para producir un único entregable primario, como an .DLL, .EXE, or .JAR (predeterminado con Visual Estudio).
Estructura cada proyecto como un árbol de directorios con una sola raíz.
Cree un script de compilación automatizado para cada proyecto en su directorio raíz que lo construirá desde cero, sin dependencias en un IDE (pero no evite que se construya en el IDE, si es posible).
Considere nAnt para proyectos. NET en Windows, o algo similar basado en su sistema operativo, plataforma de destino, etc.
Haga que cada proyecto se construya el script hace referencia a sus dependencias externas (de terceros) desde un único directorio local compartido de "biblioteca", con cada binario COMPLETAMENTE identificado por la versión: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.
Haga que cada script de compilación del proyecto publique el entregable principal en un único directorio de "salida" compartido local: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.
Haga que cada script de compilación del proyecto haga referencia a sus dependencias a través de rutas absolutas configurables y completamente versionadas (ver más arriba) en la "biblioteca" y " salida" directorios, Y NINGÚN OTRO LUGAR.
NUNCA permita que un proyecto haga referencia directa a otro proyecto o a cualquiera de sus contenidos allow solo permita referencias a los entregables primarios en el directorio "output" (ver arriba).
Haga que cada script de compilación de proyecto haga referencia a sus herramientas de compilación necesarias mediante una ruta absoluta configurable y completamente versionada: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.
Hacer que cada script de compilación de proyecto haga referencia al contenido de origen por una ruta absoluta relativa a el directorio raíz del proyecto: ${project.base.dir}/src, ${project.base.dir}/tst (la sintaxis varía según la herramienta de compilación).
SIEMPRE requiere un script de construcción de proyecto para hacer referencia a CADA archivo o directorio a través de una ruta absoluta configurable (arraigada en un directorio especificado por una variable configurable): ${project.base.dir}/some/dirs o ${env.Variable}/other/dir.
NUNCA permita que un script de construcción de proyecto haga referencia a NADA con una ruta relativa como .\some\dirs\here o ..\some\more\dirs, SIEMPRE use rutas absolutas.
NUNCA permita que un script de construcción de proyecto haga referencia a cualquier cosa que use una ruta absoluta que no tenga un directorio raíz configurable, como C:\some\dirs\here o \\server\share\more\stuff\there.
Para cada directorio raíz configurable al que hace referencia un script de construcción de proyecto, defina una variable de entorno que se utilizará para esas referencias.
Intente minimizar el número de variables de entorno que debe crear para configurar cada máquina.
En cada máquina, cree un script de shell que defina lo necesario variables de entorno, que son específicas de ESA máquina (y posiblemente específicas de ese usuario, si es relevante).
NO ponga el script de shell de configuración específico de la máquina en el control de código fuente; en su lugar, para cada proyecto, confirme una copia del script en el directorio raíz del proyecto como una plantilla.
REQUERIR que cada script de compilación del proyecto verifique cada una de sus variables de entorno, y abortar con un mensaje significativo si no lo son definido.
REQUIERA que cada script de compilación del proyecto verifique cada uno de sus ejecutables de herramientas de compilación dependientes, archivos de biblioteca externa y archivos entregables del proyecto dependientes, y cancele con un mensaje significativo si esos archivos no existen.
RESISTA la tentación de enviar CUALQUIER archivo generado al control de código fuente no sin entregables del proyecto, sin fuente generada, sin documentos generados, etc.
Si utiliza un IDE, genere cualquier control de proyecto archivos puede, y no los confirme al control de código fuente (esto incluye los archivos de proyecto de Visual Studio).
Establecer un servidor con una copia oficial de todas las bibliotecas y herramientas externas, para ser copiado / instalado en estaciones de trabajo de desarrolladores y máquinas de construcción. Haga una copia de seguridad, junto con su repositorio de control de código fuente.
Establecer un servidor de integración continua (build machine) sin herramientas de desarrollo.
Considere una herramienta para administrar sus bibliotecas y entregables externos, como Ivy (utilizado con Ant).
NO uses Maven initially inicialmente te hará feliz, y eventualmente te hará llorar.

Tenga en cuenta que nada de esto es específico de Subversion, y la mayor parte es genérico para proyectos dirigidos a cualquier sistema operativo, hardware, plataforma, lenguaje, etc. Usé un poco de sintaxis específica del sistema operativo y la herramienta, pero solo para ilustrar trust Confío en que se traducirá a su sistema operativo o herramienta de opción.

Nota adicional con respecto a las soluciones de Visual Studio: ¡no las ponga en control de código fuente! Con este enfoque, no los necesita en absoluto o puede generarlos (al igual que los archivos de proyecto de Visual Studio). Sin embargo, creo que es mejor dejar los archivos de la solución a los desarrolladores individuales para crear/usar como mejor les parezca (pero no registrados en el control de código fuente). Guardo un archivo Rob.sln en mi estación de trabajo desde el cual hago referencia a mi(s) proyecto (s) actual (es). Dado que mis proyectos son independientes, puede agregar / eliminar proyectos a voluntad (eso significa que no hay referencias de dependencias basadas en proyectos).

Por favor, no use elementos externos de Subversion (o similares en otras herramientas), son un anti-patrón y, por lo tanto, innecesarios.

Cuando implemente la integración continua, o incluso cuando solo desee automatizar el proceso de lanzamiento, cree un script para ello. Hacer un único script de shell que: toma los parámetros del nombre del proyecto (como se muestra en el repositorio) y el nombre de la etiqueta, crea un directorio dentro de un directorio raíz configurable, comprueba la fuente para el nombre del proyecto dado y el nombre de la etiqueta (construyendo la URL apropiada en el caso de Subversion) a ese directorio temporal, realiza una compilación limpia que ejecuta pruebas y empaqueta el entregable. Este script de shell debería funcionar en cualquier proyecto y debería ser revisado en el control de código fuente como parte de su proyecto "build tools". Su servidor de integración continua puede usar este script como base para construir proyectos, o incluso podría proporcionarlo (pero aún así es posible que desee el suyo propio).

@VonC: No quieres trabajar en todo momento con " ant.tarro " en lugar de "ant-a.b.c.d.jar" después de que te quemes cuando tu script de compilación se rompe porque sin saberlo lo ejecutaste con una versión incompatible de Ant. Esto es particularmente común entre Ant 1.6.5 y 1.7.0. Generalizando, siempre querrá saber qué versión específica de CADA componente se está utilizando, incluida su plataforma (Java A. B. C. D) y su herramienta de compilación (Ant E. F. G. H). De lo contrario, eventualmente encontrará un error y su primer GRAN problema será rastrear qué versiones de sus diversos componentes están involucrados. Simplemente es mejor resolver ese problema por adelantado.