Cosa ne pensi della gestione delle dipendenze basata su SCM (subrepository in mercurial, submodules in git)?
È sicuramente un buon modo per gestire le dipendenze? O decisamente cattivo modo?
Dovrei preferire qualche sistema di compilazione (ant / phing / rake) su sottoregiste?
Alcuni esempi particolari per avere un contesto:
Ho diverse applicazioni Web che condividono su componenti riutilizzabili, ad esempio plug-in jquery.
Se disponi di questa opzione, utilizza uno strumento dedicato invece di utilizzare SCM per questo. Ho scritto su questo su SO , ma l'argomento si riduce all'accoppiamento, in particolare accoppiamento troppo stretto . Lo sviluppo flessibile del software consiste nell'evitare un accoppiamento stretto a meno che non sia realmente necessario e sia i sottoregisti Mercurial che i sottomoduli Git introducono un accoppiamento molto stretto.
Inoltre, i sottorepos / sottomoduli introducono una maggiore complessità nel flusso di lavoro giornaliero. Se le persone hanno già familiarità con SCM, allora questo potrebbe essere accettabile. Ma ho visto molte organizzazioni dove tentano di introdurre i sottoprasi Mercurial e allo stesso tempo - ritengo che sia un errore poiché rende tutto ancora più complicato.
La Mercurial wiki ha una serie di raccomandazioni su come utilizzare i sottospos. Questi includono l'uso di un repository di shell sottile. Ciò evita di accoppiare i componenti insieme. Puoi lavorare in entrambi i subrepo secondo necessità e premere / tirare per aggiornarli. Qualche volta qualcuno (magari un ingegnere di costruzione, magari un server di integrazione continua) testerà le nuove configurazioni dei componenti. Se superano i test, viene eseguito un nuovo commit nel repository shell in modo che le persone abbiano una nuova base da utilizzare per il proprio lavoro.
Quando siamo passati da SVN a Kiln (Mercurial) un anno fa abbiamo anche reimplementato i nostri sottoregisti. Posso onestamente dire che vorrei non averlo fatto. I sottostanti diventano rapidamente una seccatura per gestire il loro aggiornamento quando cambiano le dipendenze. Ciò è particolarmente vero quando si tratta di librerie interne di "terza parte" che sono in fase di sviluppo attivo.
Attualmente stiamo gradualmente convertendo le nostre dipendenze in pacchetti NuGet creati e ospitati dal nostro server TeamCity.
Prima di poter consigliare i sottoregisti come scelta preferita, dovrei vedere una buona argomentazione a loro favore.
Uso Mercurial e utilizzo i sottoregisti per tutte le mie dipendenze (GLEW, GLM, Boost, Assimp, Bullet) ma non sono convinto che sia sempre una buona cosa. A volte penso che abbia più senso collegarsi solo a una biblioteca precostituita.
Per me, è bello essere in grado di creare e scorrere tutto il codice esterno che sto usando per il debugging, inoltre posso creare i miei rami personali per apportare modifiche personalizzate e ancora caricare gli aggiornamenti per i miei sottoregosti.
Tengo tutti i miei sottorepository in una directory Dipendenze appena sotto la radice del progetto, sebbene i documenti di Mercurial raccomandino un repository principale con il proprio progetto e qualsiasi dipendenza come sottoregiste.
git submodules sono grandi per questo. Ti consente di conservare tutto il codice in un unico pacchetto, aggiornarlo con semplicità, farlo su una base per progetto, senza preoccuparti degli altri e in pratica mantenere tutto sano.
Un paio di avvertimenti:
git pull && git submodule init && git submodule update --- questi devono essere parte del tuo flusso di lavoro STANDARD.
I sottomoduli sono difficili se le persone li stanno cambiando causando conflitti. Non troppo difficile, ma tutto quello che ottieni sono due SHA1 e devi scegliere il migliore, o unirli manualmente e aggiornare il repository di base.
Github è il posto ideale dove mettere tutte le tue cose git. Questa è solo una nota a margine, ma io uso un mix di repository pubblici per i sottomoduli open source e il riposo privato per il progetto principale.
Spero che questo aiuti!
Leggi altre domande sui tag git mercurial dependencies