In questo momento usiamo un sistema molto semplice per il controllo della versione. Abbiamo un repository principale completamente piatto per la nostra intera linea di prodotti. Man mano che il nostro codebase cresce e aggiungiamo altri prodotti alla linea di prodotti, questo inizia a presentare alcuni seri inconvenienti. Ci piacerebbe allontanarci da questo, specialmente con uno stile piatto, ma ci sono problemi apparentemente fondamentali con un approccio strutturato, quindi sarebbe bello sapere come le altre persone gestiscono queste situazioni comuni:
-
Il tuo codice ha più file duplicati in posizioni separate. Ad esempio, hai:
./somedir/source1.c ./someotherdir/source1.c
Tutte le istanze di source1.c sono uguali, quindi quando qualcuno cambia source1.c , non dovrebbero dover apportare la stessa modifica a ogni source1.c in ogni posizione in cui esiste. Questo è il tipo in cui funziona un sistema piatto, ma indica la struttura (con somedir e someotherdir devono essere creati per creare la struttura file corretta.
-
D'altra parte, se hai qualcosa di simile:
./somedir/config ./someotherdir/config
dove entrambe le istanze di configurazione sono uniche e condividono solo un nome file. Questo presenta un grosso problema in un sistema piatto, si finisce per fare qualcosa come tenerli in un repository piatto con nomi univoci e quindi rinominarli mentre si ricrea la struttura del prodotto. Sembra che sia qui che un file system strutturato renderebbe le cose più semplici, perché non ci sarebbe alcuna relazione intrinseca tra ./somedir/config e ./someotherdir/config .
Forse mi sto avvicinando a questo con un'idea fondamentalmente errata degli idiomi standard, ma come sono sicuro che tutti voi sapete, quando state apportando grandi cambiamenti a una base di codice esistente, deve essere più una transizione che un lancio -questa situazione-via-e-inizio-inizio.