следующая проблема:
код создаётся и правится командой, притом функции оной более-менее чётко разделены:
* прототипирование и первичная отладка на ПЛИС (HDL syntax checker)
* синтез в Synopsys DC
* моделирование в NCsim

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

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

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

понимаю, что в комплексе с системой контроля ревизий очень хорошо заиграет такая штука как регрессионные тесты, но есть два момента:
1) это всёже функциональное тестирование - и при редактировании кода для изменения функционала эти тесты работать перестанут.
2) как правило, разработчик пользуется только "своими" САПР и возможность прогнать код на всей линейке инструментов - отсутствует/затруднена.

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

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

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

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


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

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

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

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

ИМХО, наоборот, всегда нужно идти вперед, просто в комментах помечая не только то, что сделано, а то, что не сделано.
Например для программ на С.
Ver 2.45 Добавлена обработка бла-бла-бла. Протестировано под IAR. Не проверено под Codevision, ICC.
Ver 2.46 Fixed: Переменная ... под ICC обрабатывалась некорректно в функции...
ver 2.47 Проверено под IAR - OK.

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

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

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

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

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

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

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

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

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

--------

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

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