control de fuente construyendo una rama

Question

Actualmente estoy evaluando diferentes soluciones de control de fuente para el trabajo y tengo algunas preguntas sobre la ramificación.

Tengo conocimientos básicos de cómo realizar bifurcaciones, pero no estoy seguro de cómo nuestra máquina de compilación (CruiseControl.net) puede obtener una bifurcación para compilarla.

Tenemos muchos proyectos, todos los cuales dependen de otros proyectos (hay otros para):Utilidades > Acceso a datos > Lógica empresarial > GUI común > (Sitio web | Clientes de escritorio)

¿Cómo estructuramos el repositorio? (Vault si eso hace alguna diferencia) para que la máquina de construcción pueda:

1. construir el baúl
2. Construya la rama 'más reciente'

Una estructura de carpetas aproximada y/o una explicación sobre cómo llegar desde el control de crucero sería genial.

gracias

Editar:

Para agregar algo de claridad, pretendemos usar el tronco para el desarrollo y luego usar una rama para cada versión.

Answer 1

La solución propuesta por Mark funciona bien si los proyectos tienen diferentes ciclos de lanzamiento (Proyecto 1 tiene versión 1.0 mientras Proyecto 2 ya está a 1,1). Si todos sus proyectos son inter-dependientes, me gustaría empezar con una estructura simple

My Big Project
  | 
  +-- trunk
  |     |
  |     +-- utils
  |     |
  |     +-- data
  |     |
  |     +-- business
  |     |
  |     +-- gui (web)
  |     |
  |     +-- gui (swing)
  | 
  +-- branches
  | 
  +-- tags

De esta manera, usted puede estar seguro de haber ramificado todo (todo el código) cuando se hace una rama / etiqueta. De lo contrario, siempre se corre el riesgo de perderse un proyecto cuando el etiquetado.

Su servidor de compilación simplemente revisar el tronco (con todo) o una etiqueta / rama (también con todo) y construir / instalar la liberación.

Una vez que el paquete de utilidades es estable, siempre se puede "actualizar" a un proyecto de hermanos y utilizar Maven / Ivy para gestionar la dependencia.

Answer 2

¿Qué quieres decir con "última rama"?Las ramas deben usarse para un desarrollo extendido fuera del tronco; el tronco debe siempre contener el último código de producción.

Cada proyecto debe tener trunk y branches carpetas:

Project 1
  |-> trunk
  |-> branches
Project 2
  |-> trunk
  |-> branches
    etc.

Su máquina de compilación puede luego acceder a cualquier troncal o rama localmente a donde quiera (para sus proyectos de interconexión tendrá que configurarlo para que funcionen las rutas de directorio relativas).En pseudoguión:

checkout project1/trunk /builds/project1
build /builds/project1

y

checkout project1/branches/myBranch /builds/project1
build /builds/project1

Answer 3

Sólo para aclarar cómo se usarían las etiquetas y ramas en el esquema de Vladimir.Digamos que la versión 1.x de su producto está retirada, la versión 2.1 ya está disponible y usted está trabajando en la versión 3.0:

trunk <- you're working on version 3.0 here
 project1
 project2

branches
 ReleaseBranch-1.0
 ReleaseBranch-2.0 <-- fixes to version 2.1 (the current production version) get committed here, then merged into the trunk

tags
 Release-1.0 <-- a copy of the source that was used to build version 1.0
 Release-1.1
 Release-1.2
 Release-2.0
 Release-2.1

En su servidor de integración/construcción continua, necesitará 2 procesos:

• uno que apunte al maletero en su sistema de control de versiones
• uno que apunte a ReleaseBranch-2.0 en su sistema de control de versiones

El libro Control de versiones pragmático con Subversion está diseñado para Subversion, pero explica cómo organizar un repositorio como se describe anteriormente.