¿Esquema de control de versión anidada?

Question

Buscando sugerencias sobre cómo hacer un mejor seguimiento de la estructura de este proyecto en algún tipo de control de versión (git o svn, preferentemente):

El proyecto es para un servicio web que tendrá múltiples versiones del código "core", y los usuarios pueden crear su instancia del servicio web con el "núcleo" que deseen (de las versiones disponibles). De esta forma, las versiones de desarrollo/beta existirán en el mismo servidor que las versiones estables.

Por lo tanto, existen varios "núcleos" que existen, y es probable que sean versiones/etiquetas/ramas diferentes en el control de versiones. Pero luego está la interfaz web general que los une, que debe ser su propio proyecto de control de versión adicional para esos archivos web.

Desde un punto de vista de la estructura, se vería algo como:

/-+ 
    | 
    +--index.php 
    +--engine/ 
    | | 
    | +--1.0-stable/ 
    | | | 
    | | +--feature.php 
    | +--2.0-beta/ 
    |  | 
    |  +--feature.php 
    +--main.css 
    +--main.js 

Así, el index.php, main.css y main.js son parte de su propio "proyecto" que es la interfaz web, mientras que 2.0-beta es un desarrollo separado branch, cuyas actualizaciones eventualmente se fusionarán en una rama 2.0-stable, y cualquier revisión a feature.php en la rama 1.0 en necesitaría fusionarse en el archivo 2.0 feature.php también.

¿Puedo crear repositorios dentro de repositorios? ¿Cómo se manejaría esto mejor?

Answer 1

Si su estructura de directorios no tiene que verse así, tendría dos repositorios: uno para el motor y otro para la infraestructura. El repo de motor tiene dos (o más) ramas y cada una de estas ramas tiene el repositorio de infraestructura como un submódulo (para git, o svn: externals si fue con SVN).

De esta manera, podría trabajar normalmente en las ramas del motor, pero los cambios en la infraestructura se comparten. Por supuesto, nada le impide crear más ramas de infraestructura más adelante, si es necesario.

Answer 2

Tal vez submodules funcionaría para ese caso de uso.

Answer 3

No necesita crear repositorios dentro de repositorios. De hecho, si usa subversion, por ejemplo (en git es similar), cuando quiere crear una rama puede hacerlo copiando (svn cp). Subversion hace copy-on-write (o copia en la modificación), por lo que puede trabajar en directorios separados que se mantendrán separados. Luego puede fusionar los cambios en cada rama (subdirectorio).

Answer 4

Evite la bola grande de barro^H^H^Hcode. Use una rama separada para cada línea de código que desee implementar. Si planea migrar los cambios entre sucursales, es la mejor manera, ya que podrá administrar los cambios entre confirmaciones para cada rama por separado.

El código común se puede mantener en la bifurcación predeterminada (principal o troncal, dependiendo de su scm de elección).

Debe usar el despliegue automático desde scm, luego puede configurarlo para que despliegue solo las ramas seleccionadas.

Answer 5

Mi corazonada es que unir el marco común muy de cerca con las versiones separadas causará dolores de cabeza. Quizás esto funcionaría mejor:

/-+ 
    | 
    +--discovery/ 
    | | 
    | +--index.php 
    | +--main.css 
    | +--main.js 
    +--engine/ 
    | 
    +--1.0-stable/ 
    | | 
    | +--feature.php 
    +--2.0-beta/ 
     | 
     +--feature.php 

La sección de descubrimiento administraría una lista de versiones del motor y su estado actual. Cada versión del motor sería completamente independiente.No existe un vínculo directo entre la sección de descubrimiento y las implementaciones del motor, solo es una forma de publicitar qué versiones se están ejecutando actualmente.

Las implementaciones del control de versiones serían bastante estándar para el directorio de cada versión del motor.