Come applicare DRY ai file condivisi dai repository?

Question

Come applicare DRY ai file condivisi dai repository?

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Ho alcuni file che sono usati in molti dei miei repository:

functions.sh , libreria di shell per stampare ad esempio un messaggio di avviso / errore colorato o la documentazione di un file di script.
%codice%; uno standardizzato che installa il file Makefile in $(CURDIR)/[dirname].sh e fa riferimento a uno script di test.
$(PREFIX)/[dirname] .
%codice%; Ad esempio, i comandi Makefile stampano tutte le definizioni delle variabili in% genLICENSE.

Questi sono più o meno stabili, e alcuni sono usati probabilmente in una dozzina di repository. Ho pensato a come mantenere questo ASCIUTTO , ma nessuna delle opzioni finora sembra soddisfacente:

Continua a farlo ora, creando una copia per ogni nuovo repository. Questo mantiene il codice insieme a tutte le sue dipendenze (evitando bug quando la soluzione generale non è abbastanza generale), ma le modifiche che sono applicabile in più posti devono essere applicati separatamente in ciascuno.
Aggiungi un eseguibile a ciascuno dei repository a scarica i file necessari. Ciò significa che gli sviluppatori e gli utenti finali dovranno eseguire un comando extra per ottenere tutti i file rilevanti e interromperà la possibilità per gli sviluppatori di modificare e tools.mk / Makefile dei file inclusi.
Utilizza commit o equivalente. Ciò mantiene almeno i repository connessi, ma nel caso Git sembra che sia limitato a "una sottodirectory dedicata", quindi nessun file di livello superiore, e nessun mix con i file di repository principali che appartengono alla stessa directory. Questo potrebbe essere aggirato con i collegamenti simbolici, ma questa è una brutta soluzione per l'ovvia situazione ideale.

La soluzione ideale dovrebbe:

Comunicare con il repository corretto quando si esegue un'operazione su un file.
Consenti include nelle stesse directory della directory padre .
Un solo, semplice comando dovrebbe essere sufficiente per aggiornare l'intero repository e tutto include, indipendentemente da quante o quanto profondamente annidate.
Consenti include nella directory di primo livello .
Non incorre significativi vincoli di utente o sviluppatore (deve essere online durante l'installazione) o lavoro extra (eseguendo un comando di "pre-installazione" separatamente dal comando "install").
Permetti di includere "cherry-picking" di file . Ad esempio, molti progetti potrebbero aver bisogno di un diverso push , e uno dei quali non utilizzato è solo brutto (e diventerebbe più brutto con l'aggiunta di altri file).

Questo tipo di cose è possibile con il software attuale?

version-control dry

posta l0b0 19.01.2012 - 13:09

fonte

3 risposte

Leggi altre domande sui tag version-control dry

Come gestire le variabili durante l'estrazione di metodi in metodi più piccoli? Modelli per il mantenimento dello stato del modello in tempo reale

score 1 · Answer 1

In SVN il concetto si chiama "rami del venditore", ovvero pensi ai tuoi file condivisi più o meno allo stesso modo in cui pensi a una libreria di terze parti che stai utilizzando. Fai una copia di sola lettura dei file esterni sul tuo repository e usali. ma non cambiarli mai: ciò si verifica solo quando importi nuovamente i file del fornitore.

Se si apportano modifiche a un file condiviso in un progetto, è possibile (ramificandolo all'interno del repository). Quando ricevi una nuova importazione, devi unire nuovamente le modifiche.

score 1 · Answer 2

Se i file stessi messi insieme sono indipendenti (piuttosto auto-dipendenti), ha senso averli in un repository separato e trattarli come un progetto di dipendenza per un repository. Ciò ridurrà al minimo i file di copia.

Tuttavia, dall'esempio che hai dato - questi sono cose come Makefile, la licenza ecc. non sono moduli completi da soli. Se li tenga separati, questa sarà un'amalgama casuale e non ti aiuterà tanto quanto il dolore che ti metterà dentro.

Inoltre, visti gli stessi esempi, anch'io non vedo che sia un grande esercizio di risparmio di risorse. Quindi, nel complesso, non vedo molto valore in questi esercizi.

Non sto dicendo nulla contro DRY come principio; ma ASCIUTTO o NON SECCO - avrà qualche significato qui?

score 0 · Answer 3

Un'opzione consiste nell'avere un repository separato per i file shard e quindi tutti i repository che utilizzano quei file da un fork o da unire nel repository di file condiviso.

Ecco un esempio con Mercuiral. Supponiamo di avere un repo shared con i file condivisi e un repo project che ha un progetto che utilizza i file condivisi. Per ottenere i file condivisi nel repository project , eseguo i seguenti comandi dal repository project :

hg pull -f /path/to/shared/repo
hg merge
hg ci -m "merged shared repo"

Ciò estrae e unisce tutto dal repository shared nel repository project . Posso anche apportare eventuali modifiche ai file uniti dal repository shared (ad esempio una specifica regola makefile) e tali modifiche rimarranno locali al project repo.

Ora dì che ho aggiornato il repository shared con alcune nuove funzionalità o correzioni di bug e voglio includerlo nel mio repository project . Quindi dal project repo ho semplicemente eseguito

hg pull /merge/to/shared/repo
hg merge
hg ci -m "merged updated shared files"

E ho le versioni aggiornate. Non è stato necessario alcun flag -f sul pull questa volta poiché i repository sono ora correlati.

Per git i comandi sono quasi identici. Per unire il repository shared con il repository project , eseguo semplicemente

git fetch /path/to/shared
git merge FETCH_HEAD

git supporta anche i repository remoti rendendolo così che non devo inserire /path/to/shared ogni volta che vuoi unire. Posso aggiungere shared come repo remoto con

git remote add shared /path/to/shared

Poi ogni volta che voglio unirmi con esso, inserisco

git fetch shared
git merge shared/master

Dove master è il nome del ramo nel shared repo.

Sebbene questo non sia un singolo comando, non penso che due comandi siano così cattivi (la forma di commit mercural non conta: P). Inoltre consente di selezionare facilmente i file "cherry-pick" poiché i file uniti da shared sono come qualsiasi altro file tracciato nel repository project . Il lato negativo è che non supporta il requisito 1. Se cambio i file del repository condiviso nel repository project , queste modifiche non si rifletteranno nel% repo shared . Invece devo cambiarli nel repository shared e unire le modifiche in.