Verschieben eines SVN-Repos mit mehreren GB nach Git

Derzeit verfügt mein Unternehmen über eine Visual Studio-Lösung in einem SVN-Repository, das wie folgt organisiert ist:

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

Tool1 und Tool2 werden unabhängig voneinander erstellt (haben ihre eigenen Lösungen), produzieren jedoch ausführbare Dateien, die im Haupt-Build verwendet werden. Der ThirdParty-Ordner enthält alle Abhängigkeiten für das Projekt, einschließlich einiger vorkompilierter LIB-Dateien mit mehr als 100 MB und großer Bibliotheken wie boost.

Es ist praktisch, alles in einem SVN-Repo zu haben, damit (1) der Entwickler nur einmal auschecken muss und (2) wir nicht nachverfolgen müssen, welche Versionen von Abhängigkeiten für jede Version des Builds benötigt werden. Auf der anderen Seite dauert es eine Weile, um dieses Repo zu überprüfen.

Was wäre der beste Weg, um diese Projektstruktur auf git umzustellen? Vermutlich ist es am besten, ThirdParty und möglicherweise Tools vom Haupt-Repo auszuschließen, aber wir möchten, dass ThirdParty in einem Schritt einfach heruntergeladen werden kann, und wir möchten, dass es versioniert wird (und Versionsinkongruenzen zwischen dem Haupt-Repo und ThirdParty / Tools wären schlecht).

An diesem Punkt bin ich nicht daran interessiert, die Geschichte zu bewahren, sondern nur herauszufinden, wie man ein solches Projekt organisiert.

Verwenden Sie das richtige Werkzeug für den Job. In Windows bedeutet das

Verwenden Sie NuGet für Abhängigkeiten von Drittanbietern

Auf diese Weise behalten Sie die Abhängigkeiten von Drittanbietern versioniert bei, aber Sie werden Ihr Repository nicht mit unnötigen Dingen überladen. Das Auschecken geht viel schneller und das Projekt ist so organisiert, wie es sein sollte. Sie können eine Option in Visual Studio aktivieren, damit immer alle Abhängigkeiten automatisch heruntergeladen werden.

Natürlich können Sie eine Lösung verwenden, die nur Git verwendet (ein anderes Repo, Submodule usw.), aber das sind nur Hacks. Wenn Sie es richtig machen, macht es sich schnell bezahlt und Sie erhalten ein zukunftssicheres System.

Nach Kommentaren bearbeiten: Die beste Möglichkeit, NuGet zu verwenden, besteht darin, eine lokale NuGet-Quelle entweder auf einem freigegebenen Laufwerk oder auf einem vollständigen Nuget-Server einzurichten. Das Setup sollte in beiden Fällen nicht länger als ein paar Minuten dauern. Auf diese Weise können Sie sicherstellen, dass alle benötigten Pakete immer verfügbar sind, unabhängig davon, woher sie stammen.

Sie können Submodule für die Werkzeuge verwenden. Auf diese Weise können Sie sie wie bisher in einem Unterverzeichnis speichern und ein separates Repo für die Versionierung verwenden. Das bedeutet auch, dass Sie die Tools klonen (auschecken) und separat entwickeln können und dass andere Projekte auf diese Repos angewiesen sind - und auf bestimmte, udateable Versionen davon auch.

Sie könnten auch Submodule für die Bibliotheken von Drittanbietern verwenden, aber wenn möglich, würde ich empfehlen, für diese einen Abhängigkeitsmanager zu verwenden.

Die Entitäten, die Sie in Git-Repositorys umwandeln, müssen die Entitäten sein, die Sie versionieren und verzweigen. Wenn dies SolutionFolder/Tools/Tool1einer solchen Sache entspricht, ist dies die Ebene der Entität. Dies liegt daran , git den gesamten Zustand des Verzeichnisbaums in Bezug auf die versionierbar Entität zu sein, während mit svn es möglich ist (auch wenn keine gute Idee) ein haben trunk, branchesund tagsüberall innerhalb des Baumes.

Abgeleitete Artefakte sollten weder im Repository noch in externen Bibliotheken aufbewahrt werden. Es gibt bessere Möglichkeiten, damit umzugehen. (Wenn Sie mit Java arbeiten, ziehen Sie die Verwendung eines privaten Maven-Repository in Betracht. Es ist vergleichsweise einfach, mit diesen zu arbeiten, und sie lassen sich gut in viele andere Dinge integrieren.)

Wenn Sie an einen Workflow gewöhnt sind, in dem alles in einem Repo enthalten ist, können Sie auch ein Skript verwenden, das stattdessen die Einstellungen vornimmt.

Um ehrlich zu sein, würde ich an Ihrem Setup nichts ändern. Genau das machen wir jetzt. Ich habe versucht, ein separates Git-Repository einzurichten, um die von uns verwendete Third-Party-Bibliothek zu verwalten, aber ich glaube nicht, dass dies die Portabilitätskosten belastet. Jetzt kann jeder Entwickler einfach auschecken und loslegen, ohne manuelle Einrichtungsschritte ausführen zu müssen. Und ich kann jedes Build-Server / Slave-Projekt erstellen. Wenn Sie keine Multi-Repos haben, die die Thridparty-Tools teilen, würde ich einfach bei Ihrem aktuellen Setup bleiben.

Ich habe damit gespielt, dass ich die Tools von Drittanbietern in einem separaten Repo eingerichtet habe. Dann ließ ich mit einem einfachen Stapelskript eine Textdatei mit einem sha1-Verweis lesen und die richtige Version auschecken. Dies würde mir erlauben, verschiedene Versionen von Drittanbietern für verschiedene Projekte zu haben. Ich habe diese Idee vom Facebook Buck Build Tool. Aber am Ende verwenden viele Entwickler keine Kommandozeilen-Tools (MS VC-Shop hier), deshalb habe ich die Idee aufgegeben.

Ein Hauptgrund, warum Sie Ihre Drittanbieter-Bibliotheken nicht herunterladen sollten, wenn Sie sie benötigen (mit NuGet), ist der, dass Sie Ihr Produkt für längere Zeit unterstützen müssen. In meiner Branche müssen wir manchmal Updates für alte Versionen bereitstellen, die auf alten Drittanbieter-Bibliotheken basieren. Wir möchten nicht viel Zeit damit verbringen, herauszufinden, welche Bibliotheken aktualisiert werden können oder nicht, und nur die in dieser Version verwendeten Bibliotheken verwenden. Stellen Sie sich nun vor, Sie verwenden NuGet, oops ... die neueste Version der von Ihnen benötigten Bibliothek ist 3.98, aber Sie benötigen 2.04 ..... wie Sie Ihrem Chef erklären können, dass Sie 2 Monate benötigen, um die alte Version zu aktualisieren, um in der Lage zu sein die neuesten Bibliotheken zu benutzen, wenn er eine kleine Veränderung erwartet hatte!