Системи управління версіями для апаратних проектів?

Які є хороші версійні версії для апаратних проектів? Чи є еквіваленти коду Google, CVS та SVN? Чи підходять такі системи управління версіями для апаратних проектів, що включають файли ПК, схеми .. (навіть код прошивки)?

В основному всі системи VCS можуть витончено обробляти текстові та бінарні файли. Звичайно, ви не можете об'єднати двійкові.

Тому поки ви не використовуєте застарілі речі, такі як CVS, ви будете добре з будь-якою системою.

Раніше я використовував Subversion з Altium. Він працював успішно, але на той час відсутність інструменту diff зробила його менш корисним, ніж управління версіями з кодом. Я все ще думаю, що це варто було робити навіть без різної спроможності.

Щодо прошивки, то Subversion або Git - це чудово. Якщо ви раніше не використовували Git, спершу спробуйте Subversion (хоча це пізніше ускладнить навчання Git).

Нещодавно компанія Altium представила різний інструмент для схем і друкованих плат, тому я очікую, що Subversion зараз буде чудовим, модульним звичним божевіллям, яке постачальникам EDA вдається вбудувати у свої продукти.

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

Оновлення

Я спробував це, і мушу сказати, що я трохи недоохоплений інструментом Altium diff. Це функціонально, але зміни між оборотами плати досить істотні, що це не так корисно, принаймні для мене. Побачивши це, я вирішив забути про інструмент diff і просто скористатися Github. Ось репо, якщо вас цікавить: https://github.com/rascalmicro/pcb

Я використовую VisualSVN Server + TortoiseSVN клієнт, і він працює чудово

Я використовую Google Code для розміщення Super OSD , мого проекту електроніки.

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

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

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

Чому б не просто скористатися Google Code або SVN-репо? Оскільки це система контролю ревізії. Немає певного використання для цього. Це просто неймовірно корисно для декількох розробників і моніторингу змін у вихідному коді.

Раніше я використовував Subversion з Altium.

Я використовую SVN з інтеграцією Altium для схематичного захоплення: він працює добре. Треба сказати, що переглядач diff краще, ніж нічого, тому що мої файли SchDoc є бінарними, тобто неможливо порівняти інакше! Я без проблем використовую клієнт SVN, інтегрований у Altium Designer, паралельно з TortoiseSVN. Клієнт Altium трохи обмежений з точки зору можливостей SVN. Я роблю свої "теги" з черепахою.

Моя думка заснована на програмі Altium Designer 10 build 27009 та версії 13.1 build 27559.

svn, hg і git - це все добре.

Не справжня система управління версіями, але Dropbox також обробляє версію файлів, і робить їх доступними для різних людей на різних ОС. - погана система контролю версій mans;)

У минулі вихідні я був у Maker Faire у Сан-Матео і зустрів кілька представників нової (для мене) компанії під назвою Up-Verter . Вони в основному будують електричний інструмент CAD, який працює в "хмарі" (тобто у вашому браузері) і концептуально побудований на основі співпраці, тому слід мати справу з об'єднанням / різницею та звичайними версіями версій.

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

Я також розмовляв з представниками Eagle в наметі Element 14, і вони вказали, що вони переходять до формату XML, що є великим кроком до того, щоб зробити версію схем і верстки більш правдоподібною ... всі цікаві досягнення на цьому фронті !

Альтій хороші новини!

Altium додав підтримку версії керування Git, як ви бачите у примітках до випуску для Altium Designer .

Щоб знати, як користуватися, ви можете скористатись цим посібником з управління версіями.

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

http://www.saardrimer.com/fpgaproj/

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

Уникайте git. Він не працює з великими сховищами добре. А ваші сховища отримають великі, якщо ви

1. Мають бінарні схематичні файли, які змінюються лише дещо, коли вони змінюються
2. Увімкніть трактувати двійкові файли як текст.

Для цього я використовую кілька репортажів Mercurial (HG) (по одному на проект), але, як зазнає більшість систем управління версіями, репости стають все більшими та більшими.

Спробуйте спробувати Кабана . Він розроблений з нуля для обробки величезних файлів і сховищ. Бінарні дані 100 Гб або більше - це не проблема.

Я просто хотів би додати посилання на HgInit, відмінний вступ до Mercurial, якщо ви вирішили пройти цей маршрут. Я особисто використовую Git, але вони дуже схожі за архітектурою (обидві є розподіленими системами управління версіями). Розподілений характер їх робить їх чудовими для роботи в добре «розподілених» колективах. :)

http://hginit.com/

Здається, OpenPLM пропонує деякі аспекти того, що ви шукаєте, хоча воно, схоже, не знаходиться в активному розвитку ( http://www.openplm.org/trac/discussion/topic/93 ).

Можливо, подивіться на https://discuss.erpnext.com/t/erpnext-git-github-for-open-source-hardware-call-for-beta-user-s/18006 ("ERPNext: Git / Github for Обладнання з відкритим кодом - виклик для бета-користувачів (ів) ")

Про це варто подумати для будь-яких описів апаратних засобів ascii. Після прийняття читаного людським описом апаратного забезпечення будь-яка сучасна система контролю ревізії (RCS) працює досить добре. Макети схеми, як правило, повністю описуються файлами Гербера, UML описує інші частини, які є повністю описами ascii. Менш стандартні формати ascii існують для схем, механічного планування тощо (наприклад, KiCAD).

Усиновлення є більш практичним питанням, воно вимагає визнаної вимоги щодо хорошого контролю за переглядом, включаючи змістовне розходження. Що також часто означає відмову від Word, Excel, PowerPoint тощо. Дуже важкий аргумент проти керівників та MBA, але, мабуть, регульовані галузі, такі як Медичні пристрої, Авіація та Військові, вже потребують належного контролю за переглядами.

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

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

У цій області, Altium є шлях попереду преміум (Mentor і Cadence) інструментів.

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