Spostamento di un repository SVN multi-GB su Git

Attualmente la mia azienda ha una soluzione Visual Studio in un repository SVN organizzato come segue:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1 e Tool2 sono compilati in modo indipendente (hanno le proprie soluzioni), ma producono file eseguibili utilizzati nella build principale. La cartella ThirdParty contiene tutte le dipendenze per il progetto, inclusi alcuni file .lib precompilati da oltre 100 MB e librerie di grandi dimensioni come boost.

È conveniente avere tutto in un repository SVN in modo che (1) lo sviluppatore debba effettuare un solo check-out e (2) non abbiamo bisogno di tenere traccia delle versioni delle dipendenze di cui abbiamo bisogno per ogni versione della build. D'altro canto, ci vuole un po 'di tempo per controllare questo repository.

Quale sarebbe il modo migliore per spostare questa struttura del progetto su git? Presumibilmente è meglio escludere ThirdParty e possibilmente Strumenti dal repository principale, ma vorremmo mantenere ThirdParty facilmente scaricabile in un solo passaggio, e ci piace che sia versione (e le discrepanze tra la versione del repository principale e ThirdParty / Tools sarebbero cattive).

A questo punto non sono interessato a preservare la storia, ma solo a capire come organizzare tale progetto.

Utilizzare lo strumento adeguato per il lavoro. In Windows, ciò significa

Utilizzare NuGet per dipendenze di terze parti

In questo modo, mantieni le dipendenze di terze parti in modo versionato, ma non gonferai il tuo repository con elementi non necessari. I checkout sono molto più veloci e il progetto è organizzato come dovrebbe essere. È possibile abilitare un'opzione in Visual Studio in modo che scarichi sempre automaticamente tutte le dipendenze.

Ovviamente puoi usare una soluzione che usa solo git (un altro repository, sottomoduli ecc.), Ma sono solo degli hack. Farlo nel modo giusto ti ripagherà rapidamente e ti lascerà con un sistema a prova di futuro.

Modifica dopo i commenti: il modo migliore per utilizzare NuGet è configurare un'origine NuGet locale, su un'unità condivisa o un server nuget completo. L'installazione non dovrebbe richiedere più di qualche minuto in entrambi i modi. In questo modo, puoi garantire che tutti i pacchetti di cui hai bisogno siano sempre disponibili, indipendentemente da dove siano stati originati.

È possibile utilizzare i sottomoduli per gli strumenti. In questo modo è possibile tenerli in una sottodirectory come si fa ora e utilizzare un repository separato per il controllo delle versioni. Ciò significa anche che è possibile clonare (checkout) gli strumenti e svilupparli separatamente e che altri progetti potrebbero fare affidamento su tali repository e anche su versioni specifiche e udibili di essi.

Puoi anche usare i sottomoduli per le librerie di terze parti, ma se possibile consiglierei di usare un gestore delle dipendenze per quelli.

Le entità che trasformi in repository git sono necessariamente le entità che versione e ramo; se SolutionFolder/Tools/Tool1corrisponde a una di queste cose, questo è il livello di entità. Questo perché git considera l'intero stato dell'albero delle directory come entità versionabile, mentre con svn è possibile (anche se non una buona idea) avere un trunk, branchese tagsovunque all'interno dell'albero.

Gli artefatti derivati ​​non devono essere conservati nel repository, né le librerie esterne. Ci sono modi migliori per gestirli. (Se lavori con Java, considera l'utilizzo di un repository Maven privato; sono relativamente facili da lavorare e si integrano perfettamente con molte altre cose.)

Se sei abituato a un flusso di lavoro che ha tutto in un repository per facilitare il checkout, considera invece di avere uno script che imposta le cose.

Ad essere sincero, non cambierei nulla nella tua configurazione. È esattamente quello che stiamo facendo ora. Stavo giocando con la creazione di un repository git separato per gestire la libreria di terze parti che usiamo, ma non credo che sia all'altezza dei costi di portabilità. Ora qualsiasi sviluppatore può semplicemente effettuare il checkout e iniziare senza eseguire alcuna procedura di configurazione manuale. E ogni server / slave di build posso costruire il progetto. A meno che tu non abbia più repository che condividono gli strumenti di tridparty, rimarrei semplicemente con la tua configurazione attuale.

Ciò con cui ho giocato è stato l'impostazione degli strumenti di terze parti in un repository separato. Poi ho avuto un semplice script batch di leggere un file di testo con un riferimento sha1 e verificare la versione corretta. Ciò mi consentirebbe di avere diverse versioni di terze parti per diversi progetti. Ho avuto questa idea dallo strumento di creazione di Buck di Facebook. Ma alla fine a molti sviluppatori non piace usare gli strumenti da riga di comando (negozio MS VC qui), quindi ho rinunciato all'idea.

Uno dei motivi principali per cui non scaricare le librerie di terze parti quando è necessario (utilizzando NuGet) è che se è necessario supportare il prodotto a lungo. Nel mio settore, a volte dobbiamo fornire aggiornamenti per vecchie versioni che si basano su vecchie librerie di terze parti. Non vogliamo passare molto tempo a sistemare quali librerie possiamo aggiornare o meno e utilizziamo solo le librerie utilizzate in quella versione. Ora immagina di usare NuGet, oops ... l'ultima versione della lib che richiedi è 3.98 ma hai bisogno di 2.04 ..... come spiegare al tuo capo che devi spendere 2 mesi per aggiornare la vecchia versione per poter usare le ultime librerie quando si aspettava un piccolo cambiamento!