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

13

В настоящее время у моей компании есть решение 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 будет плохим).

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

IKH
источник
Эти размеры превышают размеры в репозиториях, включая историю, или это размеры локальной рабочей копии?
Док Браун
1
@DocBrown только локальная рабочая копия, не включает в себя историю.
Их

Ответы:

10

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

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

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

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

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

Уилберт
источник
NuGet поддерживает сборки из командной строки? Я всегда ищу портативную сборку, которую Дженкинс мог бы собрать и протестировать для себя. Поддерживает ли NuGet CI-серверы, такие как Jenkins?
Uncletall
Еще одна мысль, как долго вам нужно поддерживать свой продукт? Если вам необходимо оказывать поддержку в течение очень долгого времени, я не буду рассчитывать на правильную версию ваших сторонних библиотек, которая будет доступна в NuGet. Вы можете столкнуться с очень большими проблемами, полагаясь на такие инструменты, как NuGet, чтобы получить правильную комбинацию сторонних инструментов, даже через 2-3 года.
Uncletall
3
@uncletall: да, NuGet имеет полный интерфейс командной строки. И идея состоит в том, чтобы настроить локальный репозиторий NuGet, который может быть просто папкой в ​​общем сетевом ресурсе (называемой «feed», docs.nuget.org/docs/creating-packages/… )
Док Браун
Да, я предполагал, конечно, что вы используете локальное зеркало. Я обновлю ответ.
Уилберт
2
@ikh довольно просто и просто создавать пакеты nuget для внешних зависимостей. Мне потребовалось около половины дня, чтобы упаковать 9 зависимостей с 50 библиотеками, никогда прежде не делая этого.
Уилберт
5

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

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

Идан Арье
источник
4

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

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

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

Donal Fellows
источник
Какие есть варианты для управления внешними библиотеками? Мы работаем над Visual Studio с C ++ и C #, поэтому Maven не очень подходит. Основная проблема здесь в том, что наличие ThirdPartyпапки в репозитории чертовски удобно, и трудно найти хорошую альтернативу.
Их
2
@ikh: В среде Visual Studio для этого обычно используется Nuget, docs.nuget.org , который уже включен в VS 2012 и более новые версии.
Док Браун
2

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

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

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

uncletall
источник
3
Хотя я дал вам +1, так как «оставь все как есть» - это прагматичное решение, я думаю, что «множественные репо» могут быть не единственной проблемой. DVCS, такие как Git, поощряют иметь несколько локальных веток, и в каждой ветке полная локальная копия всего. Таким образом, это может привести к тому, что одна и та же большая сторонняя библиотека (как правило, одна и та же версия!) Несколько раз будет иметь локальную копию. Это может быть осуществимо в некоторых ситуациях, в других я могу себе представить, что это негативно скажется на производительности ветвления и слияния.
Док Браун
Насколько я знаю, ветвь - это очень дешевая операция в Git, которая только создает указатель и занимает почти нулевое пространство.
Uncletall
Если я чего-то не пропустил, ветки в Git "бесплатны". Я только что проверил мои .git / refs /head и все ветки представляют собой текстовые файлы размером 1 КБ, а .git / logs / refs / head содержит журналы, где для мастера самое большое - 11 КБ. Моя обычная структура проекта составляет около 500 МБ в коде, сторонние библиотеки и другие инструменты. Я очень рад принять удар в 1 КБ за создание ветки
uncletall
1
@MichaelT: само ветвление бесплатное, конечно, но я говорю о ситуации, когда у вас есть несколько рабочих копий разных веток на вашей локальной рабочей станции параллельно. И если вы проверяете комментарии ниже исходного вопроса, ОП ссылался на 3ГБ сторонних инструментов в качестве размера рабочей копии.
Док Браун