Перемещение репозитория SVN с несколькими гигабайтами в Git

В настоящее время у моей компании есть решение Visual Studio в репозитории SVN, которое организовано следующим образом:

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

Tool1 и Tool2 создаются независимо (имеют свои собственные решения), но создают исполняемые файлы, которые используются в основной сборке. Папка ThirdParty содержит все зависимости для проекта, включая некоторые предварительно скомпилированные файлы .lib объемом более 100 МБ и большие библиотеки, такие как boost.

Удобно иметь все это в одном репозитории SVN, так что (1) разработчик должен сделать только одну проверку, и (2) нам не нужно отслеживать, какие версии зависимостей нам нужны для каждой версии сборки. С другой стороны, требуется некоторое время, чтобы проверить этот репо.

Как лучше всего перенести эту структуру проекта в git? Предположительно, лучше всего исключить ThirdParty и, возможно, Tools из основного репо, но мы бы хотели, чтобы ThirdParty легко загружалась за один шаг, и нам нравится, что она версионируется (и несовпадение версий между основным репо и ThirdParty / Tools будет плохим).

На данный момент я не заинтересован в сохранении истории, просто в выяснении, как организовать такой проект.

Используйте подходящий инструмент для работы. В Windows это означает

Используйте NuGet для сторонних зависимостей

Таким образом, вы сохраняете сторонние зависимости версионным способом, но не будете переполнять свой репозиторий ненужными вещами. Оформление заказа происходит намного быстрее, и проект организован так, как и должно быть. Вы можете включить параметр в Visual Studio, чтобы он всегда автоматически загружал все зависимости.

Конечно, вы можете использовать решение, которое просто использует git (другое хранилище, субмодули и т. Д.), Но это просто хаки. Правильный подход быстро окупится и оставит вас с системой будущего.

Редактировать после комментариев: лучший способ использовать NuGet - это настроить локальный источник NuGet, либо на общем диске, либо на полном сервере Nuget. В любом случае установка не должна занять более нескольких минут. Таким образом, вы можете гарантировать, что все нужные вам пакеты всегда доступны, независимо от того, где они были созданы.

Вы можете использовать субмодули для инструментов. Таким образом, вы можете хранить их в подкаталоге, как сейчас, и использовать отдельное хранилище для управления версиями. Это также означает, что вы можете клонировать (извлекать) инструменты и разрабатывать их отдельно, и что другие проекты могут полагаться на эти репозитории - и на конкретные версии с возможностью их обновления.

Вы также можете использовать субмодули для сторонних библиотек, но если это возможно, я бы порекомендовал использовать для них менеджер зависимостей.

Объекты, которые вы превращаете в репозитории git, обязательно являются объектами, которые вы версии и ветвления; если SolutionFolder/Tools/Tool1соответствует одной такой вещи, это уровень сущности. Это происходит потому , что мерзавец касается всего состояния дерева каталогов быть versionable объект, в то время как с SVN можно (даже если не очень хорошая идея) , чтобы иметь trunk, branchesи в tagsлюбом месте дерева.

Производные артефакты не должны храниться в хранилище, как и внешние библиотеки. Есть лучшие способы справиться с этим. (Если вы работаете с Java, рассмотрите возможность использования частного репозитория Maven; с ними сравнительно легко работать, и он прекрасно интегрируется со многими другими вещами.)

Если вы привыкли к рабочему процессу, в котором есть все в одном репо, для простоты извлечения, подумайте о том, чтобы вместо этого иметь скрипт, который все настраивает.

Если честно, я бы ничего не изменил в вашей настройке. Это именно то, что мы делаем сейчас. Я поиграл с созданием отдельного репозитория git для обработки сторонней библиотеки, которую мы используем, но я не думаю, что это приводит к стоимости переносимости. Теперь любой разработчик может просто оформить заказ и начать работу без каких-либо шагов по ручной настройке. И я могу построить любой сервер / раб. Если у вас нет нескольких репозиториев с общими инструментами для трехсторонних участников, я бы просто придерживался ваших текущих настроек.

Я поиграл с игрой сторонних инструментов в отдельном репо. Затем у меня был один простой пакетный скрипт, который читал текстовый файл с ссылкой sha1 и проверял правильную версию. Это позволило бы мне иметь разные сторонние версии для разных проектов. Я получил эту идею от инструмента сборки Facebook Buck. Но, в конце концов, многие разработчики не любят использовать инструменты командной строки (здесь магазин MS VC), поэтому я отказался от этой идеи.

Одна из основных причин, по которой не нужно скачивать свои сторонние библиотеки, когда они вам нужны (с помощью NuGet), заключается в том, что вам нужно поддерживать свой продукт в течение длительного времени. В моей отрасли нам нужно когда-нибудь предоставлять обновления для старых версий, которые опираются на старые сторонние библиотеки. Мы не хотим тратить много времени на выяснение того, какие библиотеки мы можем обновить или нет, и просто использовать библиотеки, которые используются в этой версии. Теперь представьте, что вы используете NuGet, упс ... последняя необходимая вам версия библиотеки - 3.98, но вам нужно 2.04 ..... как объяснить вашему боссу, что вам нужно потратить 2 месяца, чтобы обновить старую версию, чтобы иметь возможность использовать последние библиотеки, когда он ожидал небольшого изменения!