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

[x736C]

Использую git и два файла.

Файл исключений .git\info\exclude (спасибо des00 за статью):

CODE

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

.spc_builder
db
dk_devkit
docs
incremental_db
simulation
tmp
work
rtl/openmsp430
*.bat
*.bak
*.csv
*.dpf
*.qarlog
*.qip
*.rpt
*.s
*.smsg
*.done
*.qdf
*.txt

Иногда файл clean.bat в корне проекта.

Код

rmdir /s /q db
rmdir /s /q increment_db
rmdir /s /q incremental_db
del /q *.rpt
del /q *.summary
del /q *.smsg
del /q *.done
del /q *.qdf
del /q /s *.bak

Подозреваю, что для Xilinx все также.

[Koluchiy]

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

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

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

[one_eight_seven]

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

Настраивайте сервер, чтобы не принимал коммиты без определённых тэгов в соообщении. По этим тегам сервер может отослать e-mail либо мейнтейнеру, либо в CRM-систему. Это вот то, что прямо даже не заморачиваясь работает.

[dxp]

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

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

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

[one_eight_seven]

Вас страшно читать. Вы специально используете инструмент неправильно, а потом заявляете, что это проблема инструмента.

[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]

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

[one_eight_seven]

ставить отсюда?

Не обязательно. Иногда достаточно

Код

dnf install git

и т.п. Зависит от ОС

[AVR]

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

И что??? Разве это проблема? Стоп, а не работаете ли Вы случайно с убожеским архаичным SVN?
Я по этой боли в словах узнаю пользователя неполноценной недосистемы SVN.
Переходите на Mercurial/Git и наслаждайтесь нормальной работой.

P.S. Уничтожайте SVN везде где увидите, по имя общего блага. Я серьезно. Мне доводилось бороться с апологетом SVN в одной конторе, я уничтожил его фактами и демонстрацией перед аудиторией простоты и возможностей таких систем как Mercurial (и Git). Никто назад не захотел.

[one_eight_seven]

Стоп, а не работаете ли Вы случайно с убожеским архаичным SVN?

Даже если с SVN, то это тоже не проблема.

P.S. Уничтожайте SVN везде где увидите, по имя общего блага. Я серьезно.

Сейчас приходится работать и с SVN в том числе, даже предлагать перейти на hg/git не собираюсь, ибо работает и работает хорошо. А заявлять, что-то навроде "да тут вам всё надо переделать", - даже не разобравшись в вопросе - это удел людей недалёких.


Ну и поговорка про "дай дураку стеклянный хер..." вспоминается.

[AVR]

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

Перед любой компанией рано или поздно встает выбор отказа от несовременных технологий производства, устаревших методологий, не удовлетворяющих современным реалиям. При том что старые технологии продолжают работать, при том очень хорошо.
Это как устаревшие технологии выплавки стали, производства цемента, старые технологии дорожного строительства. Да работают они. Но "удел недалеких людей" под предлогом "работает же" оставаться на отсталом Так что приберегите диагнозы.

[one_eight_seven]

Но "удел недалеких людей" под предлогом "работает же" оставаться на отсталом wink.gif Так что приберегите диагнозы.

Выглядите не убедительно, и вот почему.
1. У вас нет ни одного довода отсталости SVN. А тем более - в рамках выстроенной работающей системы, где SVN полностью выполняет поставленные ей задачи.
2. Вы ничего не знаете о том, есть ли причины смены системы контроля версий. И это не "работает же". И именно об этом я и писал, когда говорил про недалёкость безапелляционных утверждений о том, что "надо менять в любом случае".

Конкретно для FPGA:
Дизайн делают одни люди, верификацию - другие, прототипируют - третие, а софт для всего этого пишут четвёртые. И коммит любых из них достаточно часто "сломает" рабочую систему всех, кто "справа" (реже, коммиты тех, кто "справа" сломают код тех, кто слева, но такое тоже иногда бывает). И это правильно, потому что оно и должно сломать.

И что тут может предложить тот же git? Возможность чаще коммитить в локальный репозиторий? - ну да, прикольно, но не более того, правда, для этого есть git svn, и мы получаем локальные прелести git'а с удалённым svn (я, например, не стесняюсь этим пользоваться). Ну и несколько дополнительных команд и то, что люди по-первости будут забывать про git push, ограничиваясь git commit.
В остальном - они будут работать одинаково. Если делать новую систему - да, hg, и git лучше, а если система уже есть, она работает и она отлажена, то менять без причин не нужно.

[dvladim]

Не сочтите за наброс, но:
А если все файлы бинарные и их нужно версионизировать, иметь информацию кто, когда и что менял. Возможность поднять файл от нужной даты. Что тогда - git столь же хорош, что и svn? Все это с учетом того что последняя ревизия весит порядка 10 Гб, а весь около 50-100.

[one_eight_seven]

Возможность поднять файл от нужной даты. Что тогда - git столь же хорош, что и svn?

Нет. В этом случае git хуже.