Il controllo delle versioni per più istanze di un codice di sviluppo

Question

Lavoro in un laboratorio di ingegneria, non un laboratorio di informatica. Come tale, il nostro software in-house non è il prodotto consegnabile. Al contrario, il software in-house è utilizzata per analizzare i problemi di ingegneria, e noi fornire i risultati.

In questo modo il controllo di versione un inferno. O forse dovrei semplicemente dire che il "tronco e il ramo" standard struttura ad albero di controllo di versione non sembra applicare. Sto sperando che qualcuno può suggerire un modo migliore di fare le cose.

Per esempio, ogni progetto di ingegneria richiede l'aggiunta di file caso specifico di input, file di runtime, e file di post-processing. Nessuno di questi appartengono realmente in tronco, perché non sono in generale, ma ogni nuovo progetto ha bisogno di questi file. Abbiamo provato a mettere i modelli in tronco, ma non c'era migliori pratiche chiaro quanto a quando i modelli dovrebbero essere uniti in su.

Allo stesso modo, il codice in-house è in continua evoluzione, come si aggiungono nuove funzionalità. Molti di questi dovrebbe essere fusi in tronco in modo che saranno disponibili per applicazioni future. Tuttavia, ci sono anche un bel paio di hack caso specifico, che il tronco non ha bisogno di vedere.

Come dovremmo organizzare questo pasticcio? Ovviamente, il più semplice e meglio è.

Answer 1

Abbiamo davvero provare per i nostri progetti di tenere separati:

• file sorgente (gestiti in qualsiasi VCS di vostra scelta, come SVN)
• i file di configurazione (specifici per una squadra o di un ambiente)

I rami sono per sforzo di sviluppo e quelle "file di input, file di runtime, e post-elaborazione dei file" si evolveranno al proprio ritmo.

Per quel tipo di file quello che siamo riusciti in un VCS sono:

• Modelli
• script in grado di prendere tale modello e generare il (privato, come in non di versione) file di configurazione con i valori giusti in esso.
  I valori provengono da un altro referenziale, come un database, in cui le squadre (o gli amministratori ambiente) li possono aggiornare a piacimento, senza alcuna preoccupazione per cassa / check-in / merge.
  Tale banca dati può quindi essere di versione nei propri VCS, se necessario (si veda questo domanda SO per esempio, o, in alternativa, che uno )

Answer 2

In ingegneria di controllo di versione è spesso sottovalutata che è indispensabile per ripristinare dati impostazioni per esperimenti di ripetizione. Per l'adozione generale di facile utilizzo, per lo più orientata Gui, strumenti aiutano molto.

Sfruttando il controllo di versione con il monitoraggio problema che riguarda le questioni di codice impegna aumenta la produttività enormemente.

Per quanto riguarda la struttura del repository, almeno guardando la sovversione, non ci sono solo le convenzioni ma non rigide regole imposte dallo strumento. Cosa ne dite di un albero chiamato 'tronco', dove viene gestito tutto il 'codice comune'.

Per ogni operazione di ingegneria v'è una filiale creata. Che non è altro che un 'cartella del progetto' con il controllo di versione. Il codice sorgente rilevante per altri progetti saranno fusi di nuovo al tronco.