Mercurial: Repository granulari Vs repository di grandi dimensioni e strumenti di terze parti condivisi nel controllo di versione

Question

Scenario: Vari prodotti costituivano combinazioni dei progetti più piccoli. Alcune versioni differenti di ciascun prodotto in dev, release e maintennace (bug/patch/versioni minori).

La maggior parte del team utilizza vari strumenti e librerie di terze parti per dev e release (i due comuni sono XUnit per dev e AutoMapper nel prodotto). Sono fan della versione che controlla questi strumenti/librerie dove ha senso.

Non riesco a capire il modo migliore per organizzare la struttura in modo mercuriale. Nello stile SVN centrale, organizzerei avendo gli strumenti di terze parti come propri progetti e poi avendo piccole build per i progetti che avrebbero afferrato l'output degli altri progetti, e quindi un progetto di rilascio che sarebbe stato costruito da i progetti costruiti. Tutto sarebbe in una gerarchia,

(ramo dev)

Root/dev/ProjectX/ 
Root/dev/ProjectY/ 
Root/dev/ThirdParty/XXX -- could be a 3rd party lib 
Root/dev/ThirdParty/YYY -- could be a 3rd party lib 

(ramo 1)

Root/release1/ProjectX/ 
Root/release1/ProjectY/ 
Root/release1/ThirdParty/XXX 
Root/release1/ThirdParty/YYY 

(ramo 2)

Root/release2/ProjectX/ 
Root/release3/ProjectY/ 
Root/release2/ThirdParty/XXX 
Root/release2/ThirdParty/YYY 

ecc

Ecco che arriva il problema, a causa del modo in cui lo sviluppatore Mantenere le loro macchine aggiornate (usando il gestore di pacchetti NUGET) le voci di terze parti devono essere tutte nella cartella ThirdParty per assicurarsi che gli sviluppatori non debbano avere più copie di queste librerie per ogni progetto.

mia domanda è questa:

se attuano mercuriale dovrebbe attuare una strategia simmilar (big pronti contro termine) e il clone/filiale qui o dovrebbero rompere il repository dire a livello di progetto e il clone/ramo questi. In quest'ultimo caso avrebbero un ramo di prodotto/versione/repo? So che preferirebbero un modello distribuito se funzionasse meglio a lungo termine, anche se inizialmente il dolore di apprendere un nuovo flusso di lavoro è difficile.

Ho letto http://nvie.com/posts/a-successful-git-branching-model/ e un numero di articoli ma non sono ancora sicuro su come organizzarlo.

Answer 1

Fondamentalmente, si effettua un repository separato per ciascun prodotto, ogni progetto e ogni libreria di terze parti e quindi li si combina come appropriato in subrepositories. Sul vostro server centrale (o server), probabilmente istituire una struttura di pronti contro termine nudi come questo:

products/ProductA/ 
      ProductB/ 
      ProductC/ 
    projects/ProjectA/ 
      ProjectB/ 
      ProjectC/ 
thirdparty/ThirdPartyA/ 
      ThirdPartyB/ 
      ThirdPartyC/ 

In questo modo si ha esattamente una copia di ogni repo sul server centrale. Non è necessario creare repository separati per ciascun ramo, poiché Mercurial può contenere più filiali in un repository.

Quindi, quando qualcuno controlla un Prodotto nel proprio repository locale, si utilizza il meccanismo del sottorepo per controllare anche gli alberi di lavoro per i progetti appropriati e le librerie di terze parti. Sul disco locale, la struttura sarà simile a questa:

ProductA/ 
     ProjectA/ 
     ProjectB/ 
     ThirdParty/ 
        ThirdPartyC/ 

Questo aspetto diverso rispetto al server centrale perché non si dispone di alberi di lavoro, solo puntatori nelle subrepos.