Spostamento di un repository SVN multi-GB su Git

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

Utilizza NuGet per le dipendenze di terze parti

In questo modo, si mantengono le dipendenze di terze parti in un modo con versione, ma non si gonfierà il repository con cose non necessarie. I checkout sono molto più veloci e il progetto è organizzato come dovrebbe essere. È possibile abilitare un'opzione in Visual Studio in modo da scaricare sempre automaticamente tutte le dipendenze.

Ovviamente puoi usare una soluzione che usa solo git (un altro repo, sottomoduli, ecc.), ma sono solo degli hack. Farlo nel modo giusto ti ripaga velocemente e ti lascia con un sistema a prova di futuro.

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

Puoi usare submodules per gli strumenti. In questo modo puoi tenerli in una sottodirectory come fai adesso, e usare un repository separato per metterli in versione. Ciò significa anche che potresti clonare (verificare) gli strumenti e svilupparli separatamente, e che altri progetti potrebbero fare affidamento su tali repository e su versioni specifiche e udibili anche di questi.

Potresti anche utilizzare i sottomoduli per le librerie di terze parti, ma se possibile, ti consiglio di utilizzare un gestore delle dipendenze per questi.

Le entità che si trasformano in repository git sono necessariamente le entità che si versione e succursale; se SolutionFolder/Tools/Tool1 corrisponde a una di queste cose, questo è il livello di entità. Questo perché git considera l'intero albero della directory come entità versionable, mentre con svn è possibile (anche se non è una buona idea) avere un trunk , branches e tags ovunque all'interno dell'albero .

Gli artefatti derivati non dovrebbero essere tenuti nel repository, né le librerie esterne. Ci sono modi migliori per gestirli. (Se stai lavorando con Java, considera l'utilizzo di un repository Maven privato, sono relativamente facili da utilizzare e si integrano bene con molte altre cose.)

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

Per essere onesti non cambierei nulla nel tuo setup. È 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 penso che sopporti i costi della portabilità. Ora qualsiasi sviluppatore può effettuare il checkout e iniziare senza dover eseguire alcuna procedura di impostazione manuale. E ogni build server / slave può costruire il progetto. A meno che tu non abbia più repository che condividono gli strumenti di thridparty, mi limiterei a seguire la configurazione corrente.

Ciò su cui ho giocato era la creazione degli strumenti di terze parti in un repository separato. Poi ho avuto un semplice script batch leggere un file di testo con un ref sha1 e controllare la versione corretta. Questo mi permetterebbe di avere diverse versioni di terze parti per diversi progetti. Ho avuto questa idea dallo strumento di creazione Buck di Facebook. Ma alla fine molti sviluppatori non amano usare gli strumenti a riga di comando (negozio MS VC qui) quindi ho rinunciato all'idea.

Una delle ragioni principali per non scaricare le librerie di terze parti quando le richiedi (usando NuGet) è che se hai bisogno di supportare il tuo prodotto per un lungo periodo di tempo. Nel mio settore, abbiamo bisogno di fornire aggiornamenti per vecchie versioni che si basano su vecchie librerie di terze parti. Non vogliamo dedicare molto tempo alla selezione di quali librerie possiamo aggiornare o meno e utilizzare solo le librerie libere come quelle utilizzate in quella versione. Ora immagina di usare NuGet, oops ... l'ultima versione della lib richiesta è 3.98 ma hai bisogno di 2.04 ..... come spiegare al tuo capo che devi passare 2 mesi per aggiornare la vecchia versione per poter usare le ultime librerie quando si aspettava un piccolo cambiamento!