Система контроля версий для FPGA проектов., Какие на данный момент существуют системы контроля версий для FPGA ? Опции

[Flip-fl0p]

Приветствую Уважаемые посетители форума !
У начальства возникла идея внедрить на предприятии систему контроля версий для программистов и FPGA разработчиков.

На данный момент я работаю так:
1. В шапке каждого HDL файла указаны все изменения файла с описанием изменения, и датой внесения изменения.
2. Каждый день по выключению компьютера на сервер делается backup всех HDL файлов, констрейнов, настроек quartus (.QSF) и пр. файлов, отвечающих за создание проекта.
3. В отдельной папке с проектом храню все фотографии блок схем алгоритмов, диаграмм переходов автоматов, структурных схем(я их фотографирую, поскольку предпочитаю сначала все нарисовать на бумаге ручкой, а бумагу я быстро теряю).

Хотелось бы уточнить у знающих людей - а как правильно организовать такую систему применительно к проектам на ПЛИС ?

[AVR]

Приветствую Уважаемые посетители форума !
У начальства возникла идея внедрить на предприятии систему контроля версий для программистов и FPGA разработчиков.
Хотелось бы уточнить у знающих людей - а как правильно организовать такую систему применительно к проектам на ПЛИС ?

TortoiseHg (встроенный Mercurial в комплекте), можно git+GitLab
но THg(Mercurial) я предпочитаю гораздо сильнее

Вообще, проекты ПЛИС не очень хорошо ложатся для таких систем контроля версий лишь по простой причине того, что беспорядочно суют мусорные файлы и производные куда ни попадя. Хотя в последних версиях САПР с этим всё лучше и лучше. Но приходится осознанно вручную добавлять первичные файлы, у IP ядер добавлять только важное (а примеры и прочее не добавлять), и исключать производные и мусор.

Причем я использую функцию hg purge и git clean -f -d -x чтобы убрать все файлы не из проекта (почистить). Проект после таких действий должен полностью собираться и работать, а для этого нужно не забыть важные файлы и исключить лишние. Тут нужен опыт. Первое время даже важное будете забывать добавлять и при обмене кодом между ПК будут нерабочие проекты, так что про purge/clean пока забудьте.

P.S. Но я в шоке, что программисты работали без системы контроля версий. Вы там выпускники что ли?

[Koluchiy]

P.S. Но я в шоке, что программисты работали без системы контроля версий. Вы там выпускники что ли?

Иногда лучше без них, чем с ними. У нас вон как организовали всё это дело, так народ повадился менять чужие исходники, даже не уведомляя об этом хозяина.
Ну, типа, приходишь с утра, а проект, который вчера компилился и работал, уже даже не компилится, потому что кто-то чего-то жуй пойми зачем поменял без спросу.
И начинаешь смотреть, кто чего менял и инако хватать за руки.

Патамучта бардак везде, и дополнительные возможности по его распространению, попадающие не в те руки, могут привести не к тем последствиям, для которых СВНы придумывались.
Сейчас активно думаю в сторону разграничения прав доступа, но думаю что будет много крика про ущемление прав и невозможно работать.

[dxp]

Иногда лучше без них, чем с ними. У нас вон как организовали всё это дело, так народ повадился менять чужие исходники, даже не уведомляя об этом хозяина.
Ну, типа, приходишь с утра, а проект, который вчера компилился и работал, уже даже не компилится, потому что кто-то чего-то жуй пойми зачем поменял без спросу.
И начинаешь смотреть, кто чего менял и инако хватать за руки.

Патамучта бардак везде, и дополнительные возможности по его распространению, попадающие не в те руки, могут привести не к тем последствиям, для которых СВНы придумывались.

Это одна из проблем систем управления версий с центральным репозиторием. У систем с распределённым репозиторием главный реп - это ваш локальный и никто в него просто так не влезет. Всё, что туда попадает, вы контролируете, а чтобы не смешивалось, рулят ветки, которые, например, в git, реализованы очень эффективно.

[spectr]

Это одна из проблем систем управления версий с центральным репозиторием. У систем с распределённым репозиторием главный реп - это ваш локальный и никто в него просто так не влезет. Всё, что туда попадает, вы контролируете, а чтобы не смешивалось, рулят ветки, которые, например, в git, реализованы очень эффективно.

Вы пришли с утра на работу и, по-хорошему, вам надо запуллиться, дабы иметь актуальные исходники. И тут вдруг выясняется что ваш controller.v ночью подправил Вася Пупкин. Далее есть два варианта:
1. Если у Вас просто система контроля версий и всё.
Вы злитесь и идете бить лицо Василию, попутно ломая ноги PM-у. Утрированно, конечно, но смысл в том что вы не будете знать причину изменений в коде и потратите время на пересогласование актуального сорца.
Это, хотя и выстреливает очень редко, но методически - крайне плохо.

2. У Вас система контроля версий, которая не дает сделать коммит без подписи (возможно, содержащей определенные теги-метки).
Вася Пупкин, после правки вашего controller.v вынужден описать в коммите что он там наделал. Вы получаете уведомляшку, после этого автоматом создается тикет в code-review и команда (Вы в том числе) смотрит чо он там понаписал посреди ночи. И уже после этого PM или тимлид подтверждает коммит, перекидывая его в рабочую ветку. Примерно так.
Это, пожалуй, самый корректный вариант. Но он да, требует затрат на обучение всем этим CVS-ным штукам. Зато потом в репе всегда будет гарантированно собирающийся корректный актуальный проект.

Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.

[dxp]

Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.

Вы как будто не читали то, что я написал. Я разве что-то сказал против системы контроля версий? Я сказал лишь, что описанный сценарий может возникать в системах контроля версий с центральным репозиторием - например, Subversion.

В системах контроля версий с распределённым репозиторием (хотя название неудачное, правильнее это называть с локальным репозиторием) такой проблемы нет. Там сценарий будет такой (на примере git):

У меня на локальной машине есть проект под контролем, соответственно имеется локальный репозиторий. В нём я веду всю основную работу, а удалённый репозиторий (их, кстати, может быть сколько угодно) используется только для публикации кода и для синхронизации изменений. Для этого в нём публикуются только некоторые ветки (публичные).

Далее, [события по вашему примеру] пришёл я утром на работу, и могу спокойно продолжать и мне без разницы, что там кто-то накидал в удалённый реп. Если нужно вытянуть оттуда изменения, которые мне нужны прямо сейчас для работы - а это, кстати, я должен же как-то узнать, что там кто-то что-то нужное мне положил, т.е. если были изменения, то это уже не внезапная неожиданность, - я могу посмотреть, что там положили.

Технически я просто вытягиваю ветку из удалённого репа в локальный с помощью git fetch - при этом слияния с локальной веткой не происходит (если надо, чтобы произошло - например, я знаю, что там всё гуд, можно доверять, то делаю git pull). После этого я могу спокойно и комфортно смотреть все изменения - и кто их сделал, и когда, и какой коммент написал, и что за изменения (диффом). Если всё в норме, то делаю git merge. Если что-то не так, то зову причастных и разбираемся.

Ещё один момент. Даже если сразу сделать git pull и горбатые изменения слились в локальную ветку, то ничего тут страшного нет. Дело в том, что ветка, которая публикуется для обмена, не является текущей для разработки. Разработка у нас всегда ведётся в т.н. feature branches, которые потом сливаются в общую, после чего убиваются. Методика работы подробно описана тут. Поэтому горбатые изменения никогда не попадают в локальную рабочую ветку и там всё остаётся целостным. А слитую по ошибке локальную ветку можно тут же откатить.

Таким образом, никаких поломок и проблем нет в принципе. А если кто-то сливает шлак в публичную ветку, так это сразу видно без последствий для остальных, и с этим разгильдяем уже разбираются отдельно.

[AnatolySh]

Спрошу коротко:
читать здесь (ну и все содержательные посты в этой ветке),
ставить отсюда?