101 votos

¿Cómo organizar tu repositorio de control de versiones?

Primero, yo sé acerca de esto: http://stackoverflow.com/questions/51217/how-would-you-organize-a-subversion-repository-for-in-house-software-projects A continuación, el real pregunta: Mi equipo es la reestructuración de nuestro repositorio y estoy en busca de pistas sobre cómo organizar. (SVN en este caso). He aquí lo que ocurrió. Tenemos un repositorio, varios proyectos y varias svn:externals referencias cruzadas

\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
\thrash /*each member of the team has thrash 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

Borrar el vocabulario: Solución de producto único, el Proyecto es un Proyecto de Visual Studio (que se traduce en una sola .dll o .exe único)

Esa es la forma en que va a diseñar el repositorio. El principal problema es, que tenemos múltiples Soluciones, pero queremos compartir Proyectos entre las Soluciones. Pensamos que no hay un punto de verdad en el movimiento de los Proyectos compartidos a sus propias Soluciones, y en su lugar se decidió utilizar svn:externals para compartir Proyectos entre las Soluciones. También queremos mantener conjunto común de herramientas y la 3ª parte de las bibliotecas en un lugar en el repositorio, y a ellos se hace referencia a ellos en cada una de las soluciones con svn:externals.

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

77voto

Rob Williams Puntos 6316

Si usted sigue mis recomendaciones a continuación (que tengo desde hace años), usted será capaz de:

- poner a cada proyecto en cualquier lugar en el control de origen, siempre que mantenga la estructura del directorio raíz del proyecto, en bajada

-- construir cada proyecto en cualquier lugar en cualquier máquina con el mínimo de riesgos y de la mínima preparación

-- construir cada proyecto totalmente independiente, siempre y cuando usted tiene acceso a su binario dependencias (local de la "biblioteca" y la "salida" de los directorios)

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

-- construir y trabajar con múltiples copias o versiones de un único proyecto, ya que son independientes

-- evite abarrotar el repositorio de control de origen con los archivos generados o bibliotecas

Yo recomiendo (aquí está la carne de res):

  1. Definir cada proyecto para producir un único principal entregable, como un .DLL, .EXE, o .JAR (predeterminado con Visual Studio).

  2. La estructura de cada proyecto como un árbol de directorios con una sola raíz.

  3. Crear una generación automática de secuencia de comandos para cada proyecto en su directorio raíz que se va a construir a partir de cero, SIN que dependan de un IDE (pero no impedir que se está construyendo en el IDE, si es factible).

  4. Considere la posibilidad de nAnt para .NET proyectos en Windows, o algo similar, basados en su sistema operativo, plataforma de destino, etc.

  5. Hacer de cada proyecto el script de compilación de referencia externo (3ª parte) las dependencias de un único local compartido "biblioteca" del directorio, con cada una de estas binarias PLENAMENTE identificados por la versión: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.

  6. Hacer de cada proyecto el script de compilación de publicar la primera tarea para un solo local compartido "salida" directorio: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.

  7. Hacer de cada proyecto el script de compilación de referencia de sus dependencias a través de la configurable y totalmente versionados rutas absolutas (ver arriba) en la "biblioteca" y la "salida" de los directorios, Y NO se DONDE mas.

  8. NUNCA permita que un proyecto de referencia directamente a otro proyecto o de cualquiera de sus contenidos-sólo se permiten referencias a la primaria de los productos en la "salida" de la guía (véase más arriba).

  9. Hacer de cada proyecto el script de compilación de referencia necesario construir herramientas configurable y totalmente versionada de la ruta de acceso absoluta: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.

  10. Hacer de cada proyecto el script de compilación de referencia el contenido de la fuente por una ruta absoluta relativa al directorio raíz del proyecto: ${project.base.dir}/src, ${project.base.dir}/tst (sintaxis varía según la herramienta de construcción).

  11. SIEMPRE requiere de un proyecto de construir la secuencia de comandos para hacer referencia a CADA archivo o directorio a través de un absoluto, configurable ruta (arraigada en un directorio especificado por una variable configurable): ${project.base.dir}/some/dirs o ${env.Variable}/other/dir.

  12. NUNCA permita que un proyecto de construir la secuencia de comandos para hacer referencia a CUALQUIER cosa con una ruta relativa como .\some\dirs\here o ..\some\more\dirs, SIEMPRE utilizar rutas absolutas.

  13. NUNCA permita que un proyecto de construir la secuencia de comandos para hacer referencia a CUALQUIER cosa usando una ruta de acceso absoluta que no tiene un configurables directorio raíz, como C:\some\dirs\here o \\server\share\more\stuff\there.

  14. Para cada uno configurable directorio raíz que se hace referencia por un proyecto de script de compilación, definir una variable de entorno que se utilizará para las referencias.

  15. Intento de minimizar el número de variables de entorno debe crear para configurar cada máquina.

  16. En cada máquina, crear un script de shell que define las variables de entorno necesarias, que es específico para QUE la máquina (y, posiblemente, específica para ese usuario, si resulta pertinente).

  17. NO ponga la máquina específica de la configuración de la secuencia de comandos de shell en el control de origen; en su lugar, para cada proyecto, de cometer una copia de la secuencia de comandos en el directorio raíz del proyecto como una plantilla.

  18. EXIGIR a cada proyecto de construir la secuencia de comandos para comprobar cada una de sus variables de entorno, y abortar con un mensaje significativo si no están definidos.

  19. EXIGIR a cada proyecto de construir la secuencia de comandos para comprobar cada uno de sus dependientes herramienta de construcción de ejecutables externos de la biblioteca de archivos, y dependiente de la prestación del proyecto archivos y anular con un mensaje significativo si esos archivos no existen.

  20. RESISTIR la tentación de cometer CUALQUIERA de los archivos generados en el control de código fuente--sin resultados del proyecto, ninguna fuente generado, no genera docs, etc.

  21. Si usas un IDE, generar cualquier proyecto de control de archivos se puede, y no comprometen a control de origen (esto incluye los archivos de proyecto de Visual Studio).

  22. Establecer un servidor con una copia oficial de todas las bibliotecas externas y herramientas, para ser copiado/instalado en estaciones de trabajo de desarrollo y construir máquinas. Para ello, junto con su repositorio de control de origen.

  23. Establecer un servidor de integración continua (construir la máquina) con NINGUNA de las herramientas de desarrollo de ningún tipo.

  24. Considerar una herramienta para la gestión de sus bibliotecas externas y resultados, tales como la Hiedra (usado con Ant).

  25. NO utilizar Maven--inicialmente te hacen feliz, y, finalmente, hacer llorar.

Tenga en cuenta que nada de esto es específico de la Subversión, y la mayoría es genérico para proyectos dirigidos a cualquier sistema operativo, el hardware, la plataforma, el lenguaje, etc. Hice uso de un bit del sistema operativo y la herramienta de sintaxis específica, pero sólo para la ilustración--confío en que usted va a traducir a su sistema operativo, o herramienta de elección.

Nota adicional acerca de soluciones de Visual Studio: no los pone en control de código fuente! Con este enfoque, no es necesario o que puede generar (como el proyecto de Visual Studio de archivos). Sin embargo, creo que es mejor dejar los archivos de la solución a los desarrolladores a crear/usar como mejor les parezca (pero no se registran en el control de código fuente). Yo llevo Rob.sln archivo en mi estación de trabajo desde la que hago referencia en mi actual proyecto(s). Desde mis proyectos, todo independiente, puedo agregar/eliminar proyectos a voluntad (que significa que no hay proyecto basado en la dependencia de referencias).

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

Al implementar la integración continua, o incluso si sólo se desea automatizar el proceso de liberación, crear una secuencia de comandos. Hacer un único script de shell que: toma los parámetros del proyecto nombre (como aparece en el repositorio) y el nombre de la etiqueta, crea un directorio temporal dentro de un configurables directorio raíz, verifica la fuente para el nombre del proyecto y nombre de la etiqueta (por la construcción de la URL apropiada en el caso de Subversion) para que el directorio temporal, realiza una compilación limpia que ejecuta pruebas y los paquetes de la entrega. Esta secuencia de comandos de shell debe trabajar en cualquier proyecto y deberá ser verificada en el control de código fuente como parte de su "herramientas de construcción" del proyecto. Su servidor de integración continua puede utilizar esta secuencia de comandos, como fundamento para la construcción de los proyectos, o incluso podría proporcionar (pero aún podría querer su propio).

@VonC: Usted NO quiere trabajar en todo momento con "ant.jar" en lugar de "ant-a.b.c.d.jar" después de quemarse cuando el script de compilación se rompe porque, sin saberlo, se ejecutó con una versión incompatible de la Hormiga. Esto es particularmente común entre la Hormiga 1.6.5 y la versión 1.7.0. Generalizando, SIEMPRE quieres saber qué versión específica de CADA componente se utiliza, incluyendo su plataforma (Java A.B.C.D) y su herramienta de construcción (Ant E.F.G.H). De lo contrario, es muy probable que encontrar un bug y su primer GRAN problema va a ser el seguimiento de lo que las versiones de sus diversos componentes. Es simplemente mejor para resolver el problema de frente.

3voto

SqlRyan Puntos 14999

Hemos creado el nuestro hasta casi coincidir exactamente con lo que usted ha publicado. Utilizamos 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 su ejemplo, ha funcionado bien para nosotros y nos permite mantener las cosas separadas. Me gusta la idea de que cada usuario tiene un "Thrash" de la carpeta, así como en la actualidad, los tipos de proyectos no se terminan en el control de código Fuente, y siempre me he sentido que se debe.

2voto

Fabio Gomes Puntos 2627

Yo creo que la Pragmática de la Versión de Control de uso de Subversion tiene todo lo que necesitas para organizar tu repositorio.

0voto

C. Dragon 76 Puntos 5066

Creo que la principal desventaja de la estructura propuesta es que los proyectos compartidos sólo serán versionados con la primera solución que se han añadido (a menos que svn:externals es más elegante 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 Solution1. Si usted necesita para construir a partir de esa rama en un momento posterior (QFE de liberación), se utilizará la última versión de Project1 en lugar de la versión de Project1 en el momento de la rama.

Por esta razón, puede ser ventajoso para poner los proyectos compartidos en una o más soluciones compartidas (y por lo tanto los directorios de alto nivel en su estructura) y, a continuación, rama con cada lanzamiento de cualquier solución.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X