Чи є гарною практикою зберігати рамкові режими роботи під контролем джерел?

Я знаю, що багато програмних магазинів тримають двійкові файли під контролем джерел . Однак наш магазин прийшов для зберігання цілих фреймворків у сховищі: DirectX runtime, CUDA, nVidia Optix, будь-що інше.

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

Я ніколи не бачив такої схеми використання. Ви вважаєте це гарною практикою?

[EDIT:] У мене немає проблем із джерелами, що контролюють джерело, ізольованих сторонніх бінарних файлів. Питання стосується цілих циклів виконання, які зазвичай складаються з 10+ двійкових файлів. Як крайній приклад, візьміть Windows SDK (який ми не зберігаємо у сховищі, слава богу, але я не бачу різниці в принципі).

Бінарні файли, як правило, не підходять для системи управління версіями, оскільки:

• вони не користуються функціями контролю версій (злиття, відмінність)
• вони збільшують розмір репо ...
• ... що важливо, оскільки ви не можете легко видалити версію з VCS (VCS створені для зберігання історії), на відміну від сховищ артефактів, таких як Nexus , які є простими спільними каталогами (легко очистити: cd+ rm!)
• на них слід посилатися у VCS як текст , декларація шляху + версії: ви можете зберігати відповідну історію таким чином , записуючи будь-яку зміну бінарної версії як зміну цього текстового файлу (наприклад, pom.xml, якщо ви використовуєте Nexus наприклад)

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

Крім того, налаштування навколишнього середовища дещо відрізняється від розробки. Ми в основному розробляємо в Python, і він має інструмент під назвою virtualenv, який дозволяє створити легке ізольоване середовище (включаючи бібліотеки) для проекту. Коли ми перевіряємо наші джерела, у нас є сценарій налаштування, який будує цей virtualenv. Використовуючи маніфест, це вказує, які версії бібліотек потрібні та інші подібні речі. Нічого з цього не контролюється версіями. Лише сценарій налаштування є.

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

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

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

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

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

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

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

Для цього є вагома причина, а саме те, що у вас є все необхідне в одному місці, без зовнішніх залежностей.

Це набагато важливіше, ніж ви можете подумати. Це, по суті, гарантує, що ви не покладаєтесь на артефакт на сервері постачальників, який може піти через кілька років, оскільки у вас все є вдома.

Щодо набряку сховища. Це лише проблема, якщо ваш VCS зберігає повну локальну копію (git робить це, cvs не робить), оскільки клонування та / або оновлення буде повільним. Натомість у вас будуть копії на кожній машині розвитку, що може врятувати вашу компанію, якщо ваша центральна схема резервного копіювання з якихось причин вийде з ладу через якийсь день.

Це питання пріоритету чи політики. Поки рішення обдумане, я б із цим добре.