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

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

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

git?

И снова пишу - TortoiseHg.

+1

SVN
У Xilinx есть, до кучи, как цеплять разные системы

http://www.fpgadeveloper.com/2014/08/versi...o-projects.html

для вивадо всякие блок диаграммы заменяются тиклем

Используй git.

Про Гит уже писали?

TortoiseSVN. Всем устраивает.

Ребята, а вы в курсе, что tortoise - это клиент?

git, svn, hg (она же mercurial), - все позволяют работать. Лично мне по душе git, но если другие работают в svn или hg, то не наблюдал каких-то проблем, кроме того, что по-привычке можешь набрать команду из другой системы.

Другие клиенты под винду вряд ли кому-то известны.

Проблема-то в том, что софт очень своевольно обращается с файлами проекта - положить HDL из отдельного каталога под котроль версий проблемы никакой. Но когда начинаешь создавать ip-компоненты, блок-схемы уже ой. Файл проекта даже при отсутствии изменений тоже сам по себе обновляется (это все в виваде, в квартусе несколько построже, но тоже есть нюансы).

smartsvn
или
консольные команды svn.exe

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

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

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

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

Да нет, просто у нас бардак обыкновенный.

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

Теме самое место в разделе управления проектами.
Листаю страницы и вижу, не только в моей бывшей конторе с контролем версий трэш и угар был:
http://worldcrisis.ru/crisis/2859296

Это всё, конечно хорошо. Но представьте ситуацию, когда конструкторы железок работают в одной СКВ,
технические писатели в какой-нибудь шарепойнт кладут, печатные платы кладут в svn, плисоводы работают в git
а топологи интегральных схем в cliosoft sos например. И нужно стыковать передачу информации от одной системы к другой.
Причём иногда обмен должен быть двухсторонним.
И поработав админами в таких конторах, вы почувствуете как прекрасна жизнь простого юзера,
которому этого знать не надо. Нет единых стандартов. От этого вся беда.
Нет даже постоянного совета от предприятий, где осуществлялась бы координация по СКВ.
Каждый у себя в конторе изобретает велосипед и прячет как Смеагорл кольцо :-)

Добавлю свои 5 коп. на тему svn vs. git. На svn сидел довольно долго - порядка 12 лет. Перешёл в своё время на svn с cvs. По сравнению с cvs svn - это был, конечно, прорыв! Ушли в небытие геморрои с неатомарными комитами, липкими метками и прочими анахронизмами, процесс фиксации стал предсказуемым и стабильным.

Но на протяжении всего этого времени не покидало чувство, что чего-то не хватает, что нет какой-то свободы, что-ли, что каждый комит - это как штамп, высечка в граните... В итоге года 4 назад начал пошупать git/mercurial. Остановился на git. Не скажу, что сразу всё стало хорошо - потребовалось некоторое время (где-то с полгода), чтобы прочувствовать, понять его концепцию - достаточно сильно мешали стереотипы, выращенные на svn.

На основании личного опыта могу сказать, что svn по сравнению с git - это не система управления версиями, это скорее система автоматизированного архивирования. svn позволяет делать фиксации с комментариями, хранит это инкрементально в централизованном хранилище (репозитории). Она хорошо подходит для линейного процесса фиксации изменений - сделали что-то, зафиксировали. Но она очень плохо подходит для работы в стиле "а ну-ка попробую-ка я это или это". Для такого стиля очень нужна возможность легко создавать и сливать ветки. И она в git есть, а в svn нет. В svn все комиты летят в центральный реп и нет никакой возможности ими пилотировать - ни откатить, ни изменить.

Типовой пример. Всякий разработчик сталкивается с ситуацией, когда его проект достиг какого-то промежуточного итога: код стабильно собирается, предсказуемо работает. Можно двигаться дальше - добавлять новые фичи, но очень не хочется сломать то, что уже есть. Самый простой способ - делать архивы таких промежуточных точек, но это есть ни что иное, как попытка вести контроль версий вручную. Архивы плодятся, комментарии к ним теряются, сравнить две зафиксированные точки является довольно обременительной задачей... Собственно, с этого и начались системы управления версиями - та же древняя cvs поначалу представляла собой набор скриптов, который автоматизировал эти операции. svn довела реализацию этой модели до совершенства - фиксировать промежуточные состояния проекта стало удобно, безопасно и эффективно (благодаря дельтам).

К сожалению, модель с центральным репозиторием не очень хорошо подходит именно для версионирования кода, т.е. когда хочется легко и быстро создавать альтернативные ветки развития, не ломая и не теряя уже полученного. И с этой задачей хорошо справляется git. Например, вот достиг я такого вот промежуточного результата, теперь мне надо двигаться дальше - добавить какую-то фичу. Я не пилю код в стабильной ветке - в ней все комиты всегда рабочие (да, в них могут быть баги, как и везде, но они ненамеренные), код всегда собирается и фичи все допиленные, никаких полуразобранных состояний там не бывает - они только в фичебранчах (feature-branch). Фичебранчи, когда требуемый функционал достигнут, сливаются в стабильную ветку и удаляются. Стабильная ветка у нас называется develop.

Так вот, для новой фичи я завожу фичебранч:



(fb- означает feature branch)

и спокойно кромсаю код "по живому", не боясь ничего сломать или потерять. Если вдруг срочно понадобился стабильный вариант, просто откатываюсь на него:



Если допилил код в фичебранче, то сливаю его в стабильную (символ # - это типа комментарий, в реальной работе этого нет):


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

Отчётливо видно, что делалось (правую часть я для экономии обрезал, там даты и авторы комитов, т.ч. видно кто и когда внёс изменения).

Самое главное - это ощущение лёгкости процесса. Абсолютное отсутствие страха что-то сломать или потерять. Например, искромсал код на экспериментах до невосстановимого состояния - не беда:



Если эксперимент затягивается и хочется в его процессе тоже фиксировать - то создаём просто ещё ветку прямо на текущей:



и продолжаем хулиганить. Если результат оказался неудовлетворительным, просто откатываемся на предыдущую ветку:


не заботясь о мусорном коде - гит всё вернёт в нужное состояние.

Именно на гите я впервые прочувствовал совет делать т.н. "атомарные" комиты - т.е. такие, которые содержат набор изменений, касающихся только чего-то одного. Если в коде в результате правок появилось два и более логически развязанных изменения, то лучше фиксировать их разными комитами. В этом есть большой смысл. Например, возвращаясь к предыдущему примеру с экспериментальной веткой - вот наворотили там кода, поняли, что в общем-то тупик, но кое-что оказалось полезным и это кое-что неплохо бы взять с собой. Поскольку мы делали все комиты атомарными, то это кое-что оказалось зафиксированным отдельно от остальных правок. Теперь нам достаточно, откатившись на базовую ветку, выдернуть нужный комит в эту ветку:



Кстати, этот же подход неоднократно проявлял себя и полезной стороны и при коллективной работе. Реальный случай: мы с товарищем работали над прибором, я отвечал за железку, а он за хостовую часть. Доведя дивайс до рабочей кондиции, я передал его товарищу и продолжил работать над очередной фичей, а товарищ писал протокол управления прибором. В какой-то момент, он обнаружил баг со стороны дивайса - что-то там с таймаутом не срасталось. Потребовалось моё участие, а я уже в разгаре работы над новой фичей. Но ведь ему-то ведь меня ждать, когда я закончу с этой фичей, не с руки, приходится переключаться. Действия такие:


Работаем над багом, попутно находится ещё кое-что, что нуждается в правке, итого несколько комитов в этой багфиксной ветке. Закончили, потестировали - работает. Сливаем


После этого товарищ продолжает работать, я возвращаюсь к своей прерванной работе:


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


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

Вот всего этого нет в системах с центральным репозиторием. Там даже откатить комит уже проблема. Вести такую вольную работу с кодом тоже не получается. Любая фиксация оставляет неизгладимый след в репозитории. В гите очень просто можно поддерживать красивую историю развития проекта, когда видно, когда, что и кем делалось, видна этапность. Для этого помимо описанного выше есть другие способы влиять на вид - например git rebase (хотя тут надо пользоваться осторожнее). Красивая история - не фетиш, это один из способов поддерживать сопровождаемость проекта, когда сразу видны этапы работы.

Гит по духу напоминает язык программирования С. И в том, и в другом при неправильном использовании можно наворотить безобразий, но при правильном использовании это мощный инструмент.

Есть ещё немало очень "вкусных" возможностей гита - как, например, возможность поправить сделанный по ошибке комит или возможности по формированию данных комита - это когда, к примеру, текущее состояние проекта содержит несколько логически развязанных изменений, и можно их добавлять, отделяя друг от друга, создавая логически законченные целостные "атомарные" комиты. На svn комит нередко содержал в себе целый набор разнообразных правок и некоторые комментарии к комитам напоминали приличный по размеру changelog. Но там и смысла делать атомарные комиты немного, там вообще лёгкое версионирование практически нереально.

Реально впечатлился. Чувствую, в ближайшие дни, начну очередную попытку перехода с svn на git/mercurial

Господа, спасибо большое за ответы ! Скорее всего буду смотреть в сторону git, попробую дома с ним поиграться.

https://github.com/barbedo/vivado-git

как работает:
1. добавляются эти скрипты в автозапуск и ставится git
2. создаешь проект пустой с именем "vivado_project" в некой директории /PRJ
3. кидаешь имеющиеся сырцы в /PRJ/src
4. создаешь block_design новый не в проектной директории по умолчанию, а в этой /PRJ/src/ (надо не протупить при выборе)
5. рисуешь играешься с ним, добавляешь всякие корки
6. пишешь в TCL: cd /PRJ
7. git init
8. git add .
9. git commit
10. пишем название коммита
11. close_project делаем.
все. проект в локальном гите.

можно все удалить (в PRJ, разумеется не удалять директорию .git )
открыть консоль и там набить "git reset —hard" - будет восстановленно все на момент коммита

1. открываем вивадо
2. cd /PRJ
3. source ./vivado_project.tcl
4. проект создался

что не понравилось - dcp файлы лезут в git как маленькие, сложные проекты будет проблематично настроить на использование в таких условиях. возможно решит проблему .gitignore

© SoftFAN

Может уже не актуально, но пусть будет.
Азы пощупать можно тут.
https://try.github.io

Актуально. Спасибо !

Нет, тут конечно git не очень хорош. И это тот редкий исключительный случай когда недо-система svn оказывается в плюсе. Хорошо что git и hg умеют суб-репозитории svn - туда ему и дорога, чисто как вторичной системе для особых случаев, где первичным репозиторием должна быть нормальная система. Но мы ведь умеем читать название темы
В большинстве же случаев, где используют svn - он безобразен. Вот мне возражают дескать я svn не видел. Видел и пользовался много лет, и я знаю какая это дрянь на фоне божественного git/hg

Вас Эдди покусал или Самуилыч?
От задачи плясать надо, а не от того, что модно. Если маршрут проектирования можно построить так, что плюсы git/hg (да и DVCS вообще) могут активно использоваться, а минусы - не мешают, то, конечно, git/hg, а svn - убожество, которое нужно забыть. Если же маршрут выстроен так, что нужна линейная система (а это нередко так) - то svn может быть божественным, в сравнении с git/hg, которые обвешаны свистелками и перделками, которые только мешают.

Ну, я бы не сказал, что svn сильно лучше git'а в этом контексте. Специально проводил эксперимент: брал альтиумовский проект (схема и плата), делал простейшую правку - менял номинал (или типоразмер, не помню уже точно), сохранял и делал комит в svn и git. Размер изменяемых файлов был порядка 1 МБ (суммарно). И прирост размера репозитория в случае svn был где-то с полгига (не помню точно), а у git - полный гиг. Но! Дельта репозитория svn, которая содержала этот комит, почти не жалась ни rar'ом, ни 7zip'ом. А в случае git отлично себя показала команда:

git gc

(garbage collect)

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

А вообще, с системами управления версиями отлично уживается KiCad.