Grande layout del progetto: aggiunta di nuove funzionalità su più sottoprogetti

Question

Grande layout del progetto: aggiunta di nuove funzionalità su più sottoprogetti

#1 da (7 voti)
#2 da (2 voti)

13

Voglio sapere come gestire un grande progetto con molti componenti con il sistema di gestione del controllo della versione.

Nel mio attuale progetto ci sono 4 parti principali.

Web
Server
Console di amministrazione
Platform.

La parte web e server utilizza 2 librerie che ho scritto. In totale ci sono 5 repository git e 1 repository mercurial. Lo script di costruzione del progetto si trova nel repository della piattaforma. Automatizza l'intero processo di costruzione.

Il problema è quando aggiungo una nuova funzionalità che riguarda più componenti che devo creare un ramo per ciascun repository interessato. Implementa la funzione. Uniscilo indietro. Il mio istinto è "qualcosa non va".

Quindi dovrei creare un singolo repository e mettere lì tutti i componenti? Penso che la ramificazione sarà più facile in quel caso. O faccio solo quello che sto facendo adesso. In tal caso, come risolvo questo problema di creazione di un ramo su ciascun repository?

version-control branching merging configuration-management

posta Shiplu Mokaddim 11.06.2013 - 20:15

fonte

2 risposte

Leggi altre domande sui tag version-control branching merging configuration-management

Perché i caratteri di punteggiatura nella tabella ASCII sono ovunque? Che cos'è una Comonad e come sono utili?

score 7 · Answer 1

Nella situazione che descrivi, non ottieni alcun beneficio dall'avere più repository, ma hai un costo: non puoi eseguire il rollback a una versione precedente di un repository e avere la certezza che il tuo sistema continuerà lavorare. Questo perché il tuo codice è strettamente collegato ai repository. Poiché la fiducia nella capacità di eseguire il rollback è uno dei principali vantaggi del controllo del codice sorgente, questa non è la situazione in cui desideri essere.

La soluzione è definire la struttura del repository basata sull'accoppiamento del codice al suo interno: se il componente del progetto A condivide solo interfacce stabili con il componente del progetto B, allora possono essere collocati in repository separati. In caso contrario, dovrebbero essere collocati nello stesso repository. Un layout di repository più granulare rifletterà una migliore architettura di sistema fattorizzata.

score 2 · Answer 2

Se ciascuno dei tuoi repository è costituito da progetti o librerie stand-alone, direi che non c'è nulla di intrinsecamente sbagliato nel dover creare branch di feature su ciascun repository quando si aggiungono nuove funzionalità che attraversano trasversalmente i progetti. Essendo stand-alone, ognuno può essere versionato in modo indipendente e puoi deprecare le vecchie API.

Ma nel tuo caso particolare, sembra che i tuoi repository non stiano raggruppando il tuo codice in modo efficace. Se le modifiche al codice in un repository richiedono modifiche agli altri (deprecazione a parte), l'accoppiamento è troppo stretto o i repository devono essere riorganizzati.

Se tutti i repository fanno veramente parte dello stesso progetto (non possono stare da soli) allora forse dovresti avere solo 1 repository. (O forse 2: il progetto principale e uno per funzionalità generiche / standardizzate.)