[Doka 1]

следующая проблема:

код создаётся и правится командой, притом функции оной более-менее чётко разделены:

* прототипирование и первичная отладка на ПЛИС (HDL syntax checker)

* синтез в Synopsys DC

* моделирование в NCsim

 

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

 

притом, задача не конкретно для HDL-кода. Это может быть любой код, обрабатываемый разнообразными САПР, которые в силу вольности трактовки стандарта (что в случае HDL имеется в явном виде для верилог), могут выдавать различный по успешности результат для одного и того же кода.

 

задача: иметь (и помещать) в хранилище только код, свободный от синтаксических/лексических ошибок.

в данный момент задача решается передачей отдельных файлов минуя хранилище (для пробного прогона на других EDA)

 

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

1) это всёже функциональное тестирование - и при редактировании кода для изменения функционала эти тесты работать перестанут.

2) как правило, разработчик пользуется только "своими" САПР и возможность прогнать код на всей линейке инструментов - отсутствует/затруднена.

 

PS: как вариант - редактирование комментариев уже совершённых в прошлом коммитов - добавление туда некоего специального тега (например в SVN такая возможность есть - правка комментариев существующих коммитов).

но может есть еще какие-то идеи?

[Harbour 0]

репозитарий должен содержать только рабочий и проверенный код, т.е. коммит происходит после того как _все_ стороны согласились с изменениями или новым кодом - см. "acked by" схему в linux. в своей локальной копии дерева они могут хранить/делать что угодно

[Doka 1]

Harbour

тут вот как раз и неудобство:

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

 

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

 

 

еще был бы признателен, если бы кто-нибудь дал дельную ссылку на описание методологии командной работы (помимо описанной в SVNbook)

[Harbour 0]

Увы svn как раз и есть то препятствие, которое не позволяет работать по такому принципу. можно создать конечно N веток для каждого разработчика и вручную ими керовать. Я использую git - у него распределенная схема хранения веток кода - на компе у каждого разработчика есть локальная копия основного дерева + своя ветка - менеджер проекта или следующий в цепочке тестер, получив по email уведомление об оконченном этапе, выкачивает с компа разраба changeset и в случае успеха передает дальше вплоть до коммита в основное дерево или отправляет замечания обратно разрабу. Таким образом разработчики сами взаимодействуют между собой наиболее оптимальным образом, в противном случае manager проекта рискует стать бутылочным горлышком.

Насчет сети не понял - достаточно модемного интернет соединения.

[DogPawlowa 0]

...

еще был бы признателен, если бы кто-нибудь дал дельную ссылку на описание методологии командной работы (помимо описанной в SVNbook)

Мда, к последнему пожеланию присоединяюсь.

 

А по поводу - "репозитарий должен содержать только рабочий и проверенный код"...

Это кто сказал? Тогда в репозитарии должна быть всегда только одна версия, не так ли? :)

 

ИМХО, наоборот, всегда нужно идти вперед, просто в комментах помечая не только то, что сделано, а то, что не сделано.

Например для программ на С.

Ver 2.45 Добавлена обработка бла-бла-бла. Протестировано под IAR. Не проверено под Codevision, ICC.

Ver 2.46 Fixed: Переменная ... под ICC обрабатывалась некорректно в функции...

ver 2.47 Проверено под IAR - OK.

 

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

И руководитель проекта должен рулить этим всем, я так представляю. Он и есть координатор разработчиков.

[Harbour 0]

Зависит от способа разработки - мне нравится иметь стабильную ветку проекта, которая

 

1. собирается без ошибок

2. прошла все созданные для текущего кода тесты

3. имеет реальные теги на которые можно лепить последующие патчи/доработки и bug-report'ы

 

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

[yes 5]

притом, задача не конкретно для HDL-кода. Это может быть любой код, обрабатываемый разнообразными САПР, которые в силу вольности трактовки стандарта (что в случае HDL имеется в явном виде для верилог), могут выдавать различный по успешности результат для одного и того же кода.

 

вроде бы совсем недавно вполне успешно решил такую проблему пользуясь svn (как раз таки для HDL)

 

подробно - у меня был код, где log2 задавался в виде констант, на радости от новых тулзов я позаменял его функцией,

через некоторое время выяснилось, что не все тулзы понимают эту замену.

 

я ответвил версию до смены log2 и приложил на эту версию все изменения с главной ветки (от +1 до HEAD) - все работает.

 

как могут здесь помочь распределенные системы - я не понимаю (только может тем, что более надежно делают операцию diff3 и помнят историю слияний)

 

в любом случае придется сливать изменения с "ущербной" ветки в основную и из основной в ущербную

 

--------

 

возможно таги облегчили бы жизнь, но таги как-то мутно реализованы в svn (типа как в cvs мутно реализованы ветки) и я пока не рискую ими пользоваться

 

btw: у меня есть проекты, где от svn/cvs не отказаться из-за организационных вопросов - поэтому приходится пользовать все подряд