реклама на сайте
подробности

 
 
3 страниц V  < 1 2 3 >  
Reply to this topicStart new topic
> Система контроля версий для FPGA проектов., Какие на данный момент существуют системы контроля версий для FPGA ?
x736C
сообщение Apr 27 2018, 11:16
Сообщение #16


Профессионал
*****

Группа: Участник
Сообщений: 1 258
Регистрация: 3-03-06
Пользователь №: 14 942



Использую 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 все также.
Go to the top of the page
 
+Quote Post
Koluchiy
сообщение Apr 27 2018, 11:31
Сообщение #17


Знающий
****

Группа: Свой
Сообщений: 955
Регистрация: 12-04-09
Из: Москва
Пользователь №: 47 543



Цитата(AVR @ Apr 27 2018, 14:58) *
P.S. Но я в шоке, что программисты работали без системы контроля версий. Вы там выпускники что ли? lol.gif biggrin.gif

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

Патамучта бардак везде, и дополнительные возможности по его распространению, попадающие не в те руки, могут привести не к тем последствиям, для которых СВНы придумывались.
Сейчас активно думаю в сторону разграничения прав доступа, но думаю что будет много крика про ущемление прав и невозможно работать.
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 27 2018, 11:45
Сообщение #18


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



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

Настраивайте сервер, чтобы не принимал коммиты без определённых тэгов в соообщении. По этим тегам сервер может отослать e-mail либо мейнтейнеру, либо в CRM-систему. Это вот то, что прямо даже не заморачиваясь работает.
Go to the top of the page
 
+Quote Post
dxp
сообщение Apr 28 2018, 04:34
Сообщение #19


Adept
******

Группа: Свой
Сообщений: 3 434
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(Koluchiy @ Apr 27 2018, 18:31) *
Иногда лучше без них, чем с ними. У нас вон как организовали всё это дело, так народ повадился менять чужие исходники, даже не уведомляя об этом хозяина.
Ну, типа, приходишь с утра, а проект, который вчера компилился и работал, уже даже не компилится, потому что кто-то чего-то жуй пойми зачем поменял без спросу.
И начинаешь смотреть, кто чего менял и инако хватать за руки.

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

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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 28 2018, 05:29
Сообщение #20


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



Вас страшно читать. Вы специально используете инструмент неправильно, а потом заявляете, что это проблема инструмента.
Go to the top of the page
 
+Quote Post
spectr
сообщение Apr 28 2018, 06:10
Сообщение #21


Местный
***

Группа: Свой
Сообщений: 280
Регистрация: 10-12-04
Из: Earth
Пользователь №: 1 437



Цитата(dxp @ Apr 28 2018, 07:34) *
Это одна из проблем систем управления версий с центральным репозиторием. У систем с распределённым репозиторием главный реп - это ваш локальный и никто в него просто так не влезет. Всё, что туда попадает, вы контролируете, а чтобы не смешивалось, рулят ветки, которые, например, в git, реализованы очень эффективно.


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

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

Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.
Go to the top of the page
 
+Quote Post
dxp
сообщение Apr 28 2018, 09:09
Сообщение #22


Adept
******

Группа: Свой
Сообщений: 3 434
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(spectr @ Apr 28 2018, 13:10) *
Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.

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

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

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

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

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

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

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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
AnatolySh
сообщение Apr 29 2018, 13:22
Сообщение #23


Частый гость
**

Группа: Свой
Сообщений: 92
Регистрация: 20-01-06
Из: Зеленоград
Пользователь №: 13 407



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


--------------------
WMBR
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 29 2018, 14:23
Сообщение #24


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



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

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

и т.п. Зависит от ОС
Go to the top of the page
 
+Quote Post
AVR
сообщение Apr 29 2018, 17:52
Сообщение #25


фанат Linux'а
*****

Группа: Свой
Сообщений: 1 273
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008



Цитата(Koluchiy @ Apr 27 2018, 14:31) *
Иногда лучше без них, чем с ними. У нас вон как организовали всё это дело, так народ повадился менять чужие исходники, даже не уведомляя об этом хозяина

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

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


--------------------
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 29 2018, 18:10
Сообщение #26


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



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

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

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

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


Ну и поговорка про "дай дураку стеклянный хер..." вспоминается.
Go to the top of the page
 
+Quote Post
AVR
сообщение Apr 30 2018, 07:14
Сообщение #27


фанат Linux'а
*****

Группа: Свой
Сообщений: 1 273
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008



Цитата(one_eight_seven @ Apr 29 2018, 21:10) *
А заявлять, что-то навроде "да тут вам всё надо переделать", - даже не разобравшись в вопросе - это удел людей недалёких

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


--------------------
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 30 2018, 08:08
Сообщение #28


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



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

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

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

И что тут может предложить тот же git? Возможность чаще коммитить в локальный репозиторий? - ну да, прикольно, но не более того, правда, для этого есть git svn, и мы получаем локальные прелести git'а с удалённым svn (я, например, не стесняюсь этим пользоваться). Ну и несколько дополнительных команд и то, что люди по-первости будут забывать про git push, ограничиваясь git commit.
В остальном - они будут работать одинаково. Если делать новую систему - да, hg, и git лучше, а если система уже есть, она работает и она отлажена, то менять без причин не нужно.
Go to the top of the page
 
+Quote Post
dvladim
сообщение Apr 30 2018, 13:43
Сообщение #29


Знающий
****

Группа: Свой
Сообщений: 652
Регистрация: 24-01-07
Из: Воронеж
Пользователь №: 24 737



Не сочтите за наброс, но:
А если все файлы бинарные и их нужно версионизировать, иметь информацию кто, когда и что менял. Возможность поднять файл от нужной даты. Что тогда - git столь же хорош, что и svn? Все это с учетом того что последняя ревизия весит порядка 10 Гб, а весь около 50-100.
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение Apr 30 2018, 13:56
Сообщение #30


Знающий
****

Группа: Участник
Сообщений: 870
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



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

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

Go to the top of the page
 
+Quote Post

3 страниц V  < 1 2 3 >
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 19th June 2018 - 02:02
Рейтинг@Mail.ru


Страница сгенерированна за 0.01084 секунд с 7
ELECTRONIX ©2004-2016