Система контроля версий для 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, реализованы очень эффективно.