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

Каковы некоторые из хороших систем управления версиями для аппаратных проектов? Есть ли эквиваленты Google Code, CVS и SVN? Подходят ли такие системы контроля версий для аппаратных проектов, включающих файлы печатных плат, схемы ... (даже код прошивки)?

По сути, все системы VCS могут корректно обрабатывать текстовые и двоичные файлы. Конечно, вы не можете объединить двоичные.

Так что, пока вы не используете устаревшие вещи, такие как CVS, вы будете хорошо работать с ЛЮБОЙ системой.

Я использовал Subversion с Altium раньше. Он работал успешно, но в то время отсутствие инструмента сравнения сделало его менее полезным, чем контроль версий с кодом. Я все еще думаю, что это стоило сделать, даже без возможности сравнения.

Для прошивки отлично подходят и Subversion, или Git. Если вы раньше не использовали Git, попробуйте сначала Subversion (хотя это усложнит изучение Git позже).

Altium недавно представил инструмент diff для схем и печатных плат, поэтому я ожидаю, что Subversion теперь будет великолепна по модулю обычного безумия, которое поставщики EDA могут встроить в свои продукты.

Я хотел попробовать это с новым инструментом сравнения; если я это сделаю, я постараюсь опубликовать ссылку на репо здесь в качестве примера.

Обновить

Я попробовал это, и я должен сказать, что я немного не в восторге от инструмента сравнения Altium. Это функционально, но изменения между оборотами доски настолько существенны, что это не так полезно, по крайней мере, для меня. Увидев это, я решил забыть об инструменте сравнения и просто использовать 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 для схематического захвата: он работает хорошо. Я должен сказать, что просмотрщик различий лучше, чем ничего не иметь, потому что мои файлы SchDoc являются двоичными, то есть невозможно сравнивать иначе! Я использую клиент SVN, интегрированный в Altium Designer, параллельно с TortoiseSVN без проблем. Клиент Altium немного ограничен с точки зрения возможностей SVN. Я делаю свои "метки" с черепахой.

Мое мнение основано на Altium Designer 10 build 27009 и версии 13.1 build 27559.

SVN, HG, и Git все работает просто отлично.

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

В прошлые выходные я был на Maker Faire в Сан-Матео и встретил несколько представителей новой (для меня) компании под названием Up-Verter . Они в основном строят электрический CAD-инструмент, который работает в «облаке» (то есть в вашем браузере) и концептуально построен на совместной работе, поэтому должен иметь дело со слиянием / различием и обычными версиями.

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

Я также поговорил с представителями Eagle в палатке Element 14, и они указали, что они переходят на формат XML, что является своего рода большим шагом к тому, чтобы сделать версионность схем и макетов более правдоподобной ... все интересные достижения в этой области !

Altium хорошие новости!

Altium добавил поддержку в версию Git control, как вы можете увидеть в Замечаниях по выпуску для Altium Designer .

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

Это действительно очень хороший вопрос. Поскольку ПЛИС попадают в категорию «аппаратного обеспечения», вас может заинтересовать структура проекта с управлением версиями, которую я предлагаю для проектов ПЛИС:

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

Я думаю, что идеи и концепции могут быть легко применимы к другим аппаратным проектам и вообще. (Комментарии к этому предложению очень приветствуются, кстати.)

Избегайте мерзости Он плохо обрабатывает большие репозитории. И ваши репозитории станут большими, если вы

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 для Оборудование с открытым исходным кодом - вызов для бета-пользователей

Об этом стоит подумать для любого описания оборудования. Как только будет принято удобочитаемое описание аппаратного обеспечения, любая современная система контроля версий (RCS) будет работать довольно хорошо. Схемы схем обычно полностью описываются файлами Gerber, UML описывает другие части, которые являются полностью ascii описаниями. Существуют менее стандартные форматы ascii для схем, механической разметки и т. Д. (Например, KiCAD).

Принятие является более практическим вопросом, оно требует признанного требования для хорошего контроля версий, в том числе значимых различий. Что также часто означает отказ от Word, Excel, PowerPoint и т. Д. Очень сложный аргумент против менеджеров и MBA, но, возможно, регулируемые отрасли, такие как Медицинское оборудование, Авиация и Военные, уже требуют хорошего контроля версий.

Как уже отмечали другие, большинство современных RCS используют двоичные файлы контроля версий, что очень полезно для архивации и идентификации версий, но любая система электронного документооборота (EDMS), например, Agile, может назначать номер редакции произвольному двоичному файлу. Скучно.

Несмотря на то, что Altium Vault не бесплатна и не содержит ошибок, она отлично справляется со своей задачей; Я могу легко откатиться к любой точке фиксации (как это делает любая VCS) очень легко.

В этой области, Altium является путь впереди премии (Mentor и Cadence) инструментов.

Я не работаю на Altium, но этот инструмент, несмотря на текущие проблемы, делает полное аппаратное управление версиями очень простым.