Переміщення репортажу 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 містить всі залежності для проекту, включаючи деякі попередньо складені 100+ МБ файлів .lib та великі бібліотеки на зразок boost.

Це зручно мати все в одному репортажі SVN, так що (1) розробник повинен зробити лише одну перевірку, і (2) нам не потрібно відслідковувати, які версії залежностей нам потрібні для кожної версії збірки. З іншого боку, щоб перевірити це репо, потрібно певний час.

Що було б найкращим способом перемістити цю структуру проекту до git? Імовірно, найкраще виключити ThirdParty та, можливо, Інструменти з основного репортажу, але ми хотіли б, щоб ThirdParty легко завантажувався за один крок, і нам це подобається (і невідповідності версій між основною репо та ThirdParty / Tools були б поганими).

На даний момент мене не цікавить збереження історії, а лише з'ясування способів організації такого проекту.

Використовуйте належний інструмент для роботи. У Windows це означає

Використовуйте NuGet для сторонніх залежностей

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

Звичайно, ви можете використовувати рішення, яке просто використовує git (інший репо, підмодулі тощо), але це просто хаки. Якщо ви зробите це правильним способом, це швидко окупиться та залишить вас надійною системою.

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

Для інструментів можна використовувати підмодулі . Таким чином, ви можете зберігати їх у підкаталозі, як ви робите зараз, і використовувати окреме репо для їх версії. Це також означає, що ви можете клонувати (заряджати) інструменти та розробляти їх окремо, і що інші проекти можуть покладатися на ці репортажі - і на конкретні, зручні версії їх також.

Ви також можете використовувати підмодулі для сторонніх бібліотек, але якщо це можливо, я рекомендую використовувати для них менеджер залежностей.

Суб'єкти, які ви перетворюєте на сховища git, обов'язково є особами, які ви версії та філії; якщо SolutionFolder/Tools/Tool1відповідає одній такій речі, це рівень сутності. Це відбувається тому , що мерзотник стосується всього стану дерева каталогів бути versionable об'єкт, в той час як з SVN можна (навіть якщо не дуже хороша ідея) , щоб мати trunk, branchesі в tagsбудь-якому місці дерева.

Отримані артефакти не повинні зберігатися у сховищі, а також не повинні зберігатись у зовнішніх бібліотеках. Є кращі способи впоратися з цим. (Якщо ви працюєте з Java, подумайте про використання приватного сховища Maven; з ними порівняно просто працювати та інтегруватись із багатьма іншими речами.)

Якщо ви звикли до робочого процесу, в якому є все в одному репо, для зручності перевірки, подумайте про те, щоб створити сценарій, який встановлює натомість речі.

Якщо чесно, я нічого не змінив у ваших налаштуваннях. Це саме те, що ми робимо зараз. Я розмовляв із створенням окремого сховища git для роботи з власною стороною, що використовується третьою стороною, але я не думаю, що це важить до вартості переносу. Тепер будь-який розробник може просто оформити замовлення та розпочати роботу, не виконуючи жодних кроків із налаштування вручну. І я можу створити проект будь-який сервер / підлеглий. Якщо у вас не буде багаторепортажних спільних інструментів третього учасника, я б просто дотримувався вашої поточної установки.

Те, з чим я грав, - це налаштування інструментів третьої сторони в окремому репо. Тоді у мене був один простий пакетний скрипт, який читав текстовий файл з sha1 ref і перевіряв правильну версію. Це дозволило б мені мати різні версії третьої сторони для різних проектів. Цю ідею я отримав від інструмента побудови Facebook Buck. Але врешті-решт, багато розробників не люблять використовувати інструменти командного рядка (тут продається MS VC), тому я відмовився від ідеї.

Однією з головних причин, чому не завантажувати ваші треті сторони, коли вам потрібні (використовуючи NuGet), є те, що якщо вам потрібно довго підтримувати ваш продукт. У моїй галузі нам потрібно коли-небудь надавати оновлення для старих версій, які покладаються на старі конверти третьої сторони. Ми не хочемо витрачати багато часу, розбираючи, які ваги ми можемо оновити чи ні, а просто використовуємо ті, що використовуються у цій версії. А тепер уявіть, що ви використовуєте NuGet, ой ... остання версія лібу, яка вам потрібна, - 3,98, але вам потрібно 2,04 ..... як пояснити своєму начальнику, що вам потрібно витратити 2 місяці, щоб оновити стару версію, щоб мати можливість користуватися останніми лайками, коли він очікував невеликих змін!