Jump to content

    
Sign in to follow this  
Flip-fl0p

Система контроля версий для FPGA проектов.

Recommended Posts

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

 

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

# 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 все также.

Share this post


Link to post
Share on other sites
P.S. Но я в шоке, что программисты работали без системы контроля версий. Вы там выпускники что ли? :lol::biggrin:

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

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

И начинаешь смотреть, кто чего менял и инако хватать за руки.

 

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

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

Share this post


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

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

И начинаешь смотреть, кто чего менял и инако хватать за руки.

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

Share this post


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

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

И начинаешь смотреть, кто чего менял и инако хватать за руки.

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

1. Если у Вас просто система контроля версий и всё.

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

Это, хотя и выстреливает очень редко, но методически - крайне плохо.

 

2. У Вас система контроля версий, которая не дает сделать коммит без подписи (возможно, содержащей определенные теги-метки).

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

Это, пожалуй, самый корректный вариант. Но он да, требует затрат на обучение всем этим CVS-ным штукам. Зато потом в репе всегда будет гарантированно собирающийся корректный актуальный проект.

 

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

Share this post


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

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

 

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

 

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

 

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

 

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

 

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

 

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

Share this post


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

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

Я по этой боли в словах узнаю пользователя неполноценной недосистемы SVN.

Переходите на Mercurial/Git и наслаждайтесь нормальной работой.

 

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

Share this post


Link to post
Share on other sites
Стоп, а не работаете ли Вы случайно с убожеским архаичным SVN?

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

 

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

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

 

 

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

Share this post


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

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

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

Share this post


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

Выглядите не убедительно, и вот почему.

1. У вас нет ни одного довода отсталости SVN. А тем более - в рамках выстроенной работающей системы, где SVN полностью выполняет поставленные ей задачи.

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

 

Конкретно для FPGA:

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

 

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

В остальном - они будут работать одинаково. Если делать новую систему - да, hg, и git лучше, а если система уже есть, она работает и она отлажена, то менять без причин не нужно.

Share this post


Link to post
Share on other sites

Не сочтите за наброс, но:

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this