Schema di controllo della versione nidificato?

Question

Cercare suggerimenti su come tracciare meglio questa struttura di progetto in una sorta di controllo di versione (git o svn, preferibilmente):

Il progetto è per un servizio Web che avrà più versioni del codice "core", e gli utenti possono creare la loro istanza del servizio web con qualsiasi "core" che desiderano (delle versioni disponibili). In questo modo, le versioni di sviluppo/beta esisteranno sullo stesso server delle versioni stabili.

Quindi esistono più "core" che esistono e probabilmente saranno versioni/tag/rami diversi nel controllo della versione. Ma poi c'è l'interfaccia web globale che li collega insieme, che deve essere il suo progetto di controllo della versione aggiuntivo, per quei file web.

Dal punto di vista struttura, sarebbe simile:

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

Così, il index.php, main.css e main.js fanno parte del proprio "progetto", che è l'interfaccia web, mentre 2.0-beta è uno sviluppo separato ramo, i cui aggiornamenti verranno infine uniti in un ramo 2.0-stable e qualsiasi aggiornamento rapido a feature.php nel ramo 1.0 in dovrà essere unito al file 2.0 feature.php 2.0.

Posso creare repository all'interno di repository? Come sarebbe meglio gestirlo?

Answer 1

Se la struttura della directory non deve apparire in questo modo, avrei due repository: uno per il motore e uno per l'infrastruttura. Il repository engine ha due (o più) rami e ciascuno di questi rami ha il repository dell'infrastruttura come sottomodulo (per git o svn: esterno se si è passati con SVN).

In questo modo, è possibile lavorare normalmente sui rami del motore, ma i cambiamenti nell'infrastruttura sono condivisi. Naturalmente, in questo momento nulla ti impedisce di creare più rami di infrastruttura, se necessario.

Answer 2

Forse submodules funzionerebbe per tale caso d'uso.

Answer 3

Non è necessario creare repository all'interno di repository. Infatti, se si utilizza la sovversione, ad esempio (in git è simile), quando si desidera creare un ramo è possibile farlo copiando (svn cp). Subversion fa copia su scrittura (o copia su modifica), quindi puoi lavorare in directory separate che verranno mantenute separate. Quindi puoi unire le modifiche in ogni ramo (sottodirectory).

Answer 4

Evitare la grande palla di fango^H^H^Hcode. Utilizzare un ramo separato per ogni riga di codice che si desidera distribuire. Se prevedi di migrare le modifiche tra filiali, è il modo migliore, perché sarai in grado di gestire le modifiche tra i commit per ciascun ramo separatamente.

È possibile mantenere il codice comune nel ramo predefinito (master o trunk, in base alla scelta scelta).

È consigliabile utilizzare la distribuzione automatica da scm, quindi è possibile configurarlo in modo tale da distribuire solo i rami selezionati.

Answer 5

La mia impressione è che l'accoppiamento della struttura comune troppo da vicino con le versioni separate causerà mal di testa. Forse questo funzionerebbe meglio:

La sezione di rilevamento gestiva un elenco di versioni del motore e il loro stato corrente. Ogni versione del motore sarebbe completamente autonoma.Non esiste un collegamento diretto dalla sezione di rilevamento alle distribuzioni del motore, è solo un modo per pubblicizzare quali versioni sono attualmente in esecuzione.

Le distribuzioni dal controllo di versione sarebbero quindi abbastanza standard per la directory di ciascuna versione del motore.