Бінарні файли в контролі джерел

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

Основні аргументи, які я бачу проти цього, - це здуття БД управління джерелами, відсутність різних бінарних файлів ( див. Попередні запитання з цього приводу) . Це проти можливості перевіряти, створювати, знаючи, що ви маєте точну екологію, яку передбачив попередній розробник, і без вишукування відповідних файлів (із конкретними версіями не менше!)

Ідея ВЕРСІЙНОГО КОНТРОЛЮ (неправильне: контроль джерела) полягає в тому, щоб ви могли прокрутити історію, відновити ефект змін, побачити зміни та чому зроблено. Це цілий ряд вимог, деякі з яких потребують двійкових речей, а деякі - ні.

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

Перевірка ланцюгів інструментів на контроль версій - це біль, різні утиліти жахливі (якщо взагалі є), але альтернативи немає. Якщо ви хочете, щоб ланцюжок інструментів збереглася для хлопця, який приходить подивитися на ваш код через 5 років, щоб зрозуміти, що він робить, то у вас немає вибору: у вас ОБОВ'ЯЗКОВО мати також ланцюжок інструментів під контролем версій.

Протягом багатьох років я виявив, що найпростіший спосіб зробити це - створити ZIP або ISO зображення інсталяційного компакт-диска та перевірити це. Коментований коментар повинен бути конкретним номером версії інструментальної ланцюга. Якщо gcc або подібне, з’єднайте все, що ви використовуєте, у великий ZIP і зробіть те саме.

Самий крайній випадок, який я робив, - це Windows XP Embedded, де «ланцюжок інструментів» - це запущена програма Windows XP VM, яка включала (тоді ще) SQL Server і стек файлів конфігурації разом із сотнями і сотнями файлів патчів. Встановлення всієї партії та її актуалізація зазвичай займає близько 2-3 днів. Зберегти це для нащадків означало перевірку ЦІЛЬКОГО ВМ в контролі версій. Бачачи, що віртуальний диск складався з приблизно 6 x 2 Гб зображень, він насправді вийшов досить добре. Звучить на вершині, але це полегшило життя людині, яка пішла за мною і повинна була ним користуватися - через 5 років.

Резюме: Контроль версій - це інструмент. Використовуйте це, щоб бути ефективним, не зациклюйтесь на таких речах, як значення слів, і не називайте це "контролем над джерелами", оскільки його більше, ніж це.

Ніл Форд стверджує в програмі «Продуктивний програміст», що слід зберігати двійкові файли в контролі джерел:

Навіщо вести бінарні файли? Сьогодні проекти залежать від кількості зовнішніх інструментів та бібліотек. Скажімо, ви використовуєте одну з популярних рамок журналу (наприклад, Log4J або Log4Net). Якщо ви не будуєте бінарні файли для цієї бібліотеки журналів як частину свого процесу збирання, вам слід тримати її в контролі версій. Це дозволяє продовжувати розробляти програмне забезпечення навіть у тому випадку, коли рамки чи бібліотека, про яку йде мова, (або, що більше ймовірно, вносить промінні зміни в новій версії). Завжди тримайте весь Всесвіт, необхідний для створення вашого програмного забезпечення для контролю версій(мінус операційна система, і навіть це можливо при віртуалізації; див. "Використання віртуалізації" далі в цьому розділі). Ви можете оптимізувати збереження бінарних файлів, зберігаючи їх у контролі версій та на спільному мережевому диску. Таким чином, вам не доведеться з ними погоджуватися щогодини, але вони врятуються у випадку, якщо вам доведеться щось перебудувати через рік. Ніколи не знаєш, чи потрібно буде щось перебудувати. Ви будуєте його, поки воно не спрацює, а потім забудете про нього. Паніка викликає усвідомлення того, що потрібно щось перебудовувати з двох років тому і не мати всіх частин.

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

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

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

В принципі, я вдячний таборі "перевірити все, що потрібно для створення джерел контролю", але управління залежностями розвинулося досить небагато за останні кілька років, використовуючи такі інструменти, як Maven, Ivy та NuGet.

Також на практиці я знаходжу перевірку у бінарних файлах, щоб створити ряд неприємних побічних ефектів. Наприклад, Git / Mercurial насправді не налаштовані, і Subversion і Perforce можуть змусити вас отримати гайки під час об'єднання гілок, що містять бінарні файли.

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

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

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

Контроль джерел призначений для джерел. Джерела - це те, чого ви не можете створити з інших речей. Деякі файли, які вважаються джерелами, є двійковими файлами.

У моєму VCS перевірено чимало бінарних файлів, але кожен - це одиниця випуску якогось продукту, який я не писав і не підтримую. Це може бути щось на кшталт GNU ccRTP, який випускається у вигляді стисненого тарболу. Цей тарбол є моїм джерелом, і він перевіряється разом із будь-якою інфраструктурою, що мені потрібна, щоб перетворити його на готовий продукт (в моєму випадку Makefile та RPM-специфікація) за один автоматичний крок. Коли є нова версія ccRTP, я ставлюся до нового tarball як до зміненого джерела: він переходить до перевіреної копії, збирається, перевіряється та повертається до VCS. Я робив те ж саме з комерційними продуктами, які не постачаються з джерелом (компілятори, бібліотеки тощо), і це працює так само. Замість unpack-configure-compile-package це просто unpack-package. Програмне забезпечення, яке створює нічні, не "make і отримати готову продукцію.

Більшість VCS мають функції, які полегшують роботу з людським читанням, і простіше зберігати, але говорити, що вони не підходять для бінарних файлів, насправді не відповідає дійсності, якщо бінарні файли повертаються непоміченими. Те, як VCS має внутрішню справу з бінарними файлами, повністю залежить від того, чи варто було б постаратися, щоб її автори намагалися зберігати лише різниці. Особисто я вважаю, що зберігання повних копій ccRTP-дистрибутива на 600K в поп - це більше, ніж компенсовано можливістю тегувати його версію разом з усіма іншими моїми джерелами.

Це нагадує мені проблему "банки в сховищі", яку якись час тому мав Java. Люди, що будують додатки Java, використовувались для підштовхування своїх залежностей (бінарних файлів jar) у сховища. Всі були задоволені цим, адже у нас у вас би було побудова системи та дискового простору «одним клацанням милі» - це дешево, тому кому все одно. Тоді прийшов Мейвен, і ви могли позбутися всього цього бінарного супроводу, а з локальним сховищем, що зберігається лише в кеші, все ще підтримується побудова бал-проф. Тим не менш, у вас є система побудови "одним клацанням", але управління джерелом не повинно переміщуватися навколо бінарних файлів, які там не мають сенсу.

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

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

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

Отже, покладіть його, якщо це джерело. Не робити, якщо ні.

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

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

Дивіться цю тему в блозі від Дерека Гріра на цю тему.

Я працюю над проектом з двома різними етапами побудови

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

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

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

Вам потрібно зберегти все необхідне для відновлення конкретних версій продукту в якийсь момент майбутнього.

Однак вам не потрібно тримати все в контролі джерел.

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

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

Дуже хаос у моїй свідомості зареєструвати бінарний SCM. У мене був дуже складний проект, який має багато залежностей від бібліотек третьої частини. Принципи, які ми прийняли:

1. Весь вихідний код керується за допомогою SCM
2. Усі залежності управляються за допомогою Айві, який має велику інтеграцію затемнення.

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

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

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

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

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