Doka 4 4 июля, 2008 Опубликовано 4 июля, 2008 · Жалоба следующая проблема: код создаётся и правится командой, притом функции оной более-менее чётко разделены: * прототипирование и первичная отладка на ПЛИС (HDL syntax checker) * синтез в Synopsys DC * моделирование в NCsim и получается так что редактированный и проверенный на рабочем инструменте разработчика код, помещённый в хранилище как рабочий, вызывает появление ошибок (в данном случае рассматриваем только ошибки) при использовании другими разработчиками в других EDA. притом, задача не конкретно для HDL-кода. Это может быть любой код, обрабатываемый разнообразными САПР, которые в силу вольности трактовки стандарта (что в случае HDL имеется в явном виде для верилог), могут выдавать различный по успешности результат для одного и того же кода. задача: иметь (и помещать) в хранилище только код, свободный от синтаксических/лексических ошибок. в данный момент задача решается передачей отдельных файлов минуя хранилище (для пробного прогона на других EDA) понимаю, что в комплексе с системой контроля ревизий очень хорошо заиграет такая штука как регрессионные тесты, но есть два момента: 1) это всёже функциональное тестирование - и при редактировании кода для изменения функционала эти тесты работать перестанут. 2) как правило, разработчик пользуется только "своими" САПР и возможность прогнать код на всей линейке инструментов - отсутствует/затруднена. PS: как вариант - редактирование комментариев уже совершённых в прошлом коммитов - добавление туда некоего специального тега (например в SVN такая возможность есть - правка комментариев существующих коммитов). но может есть еще какие-то идеи? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 4 июля, 2008 Опубликовано 4 июля, 2008 · Жалоба репозитарий должен содержать только рабочий и проверенный код, т.е. коммит происходит после того как _все_ стороны согласились с изменениями или новым кодом - см. "acked by" схему в linux. в своей локальной копии дерева они могут хранить/делать что угодно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 4 5 июля, 2008 Опубликовано 5 июля, 2008 · Жалоба Harbour тут вот как раз и неудобство: фактически разработчик должен предоставить свою рабочую копию, минуя хранилище. (а, если взять случай, когда разработчики не находятся в пределах одной локальной сети - это не очень удобно. выходит нужен еще один репозитарий для простого обмена рабочими копиями разработчиков. ) в пределах локальной сети, конечно, такая система удобна - каждый разработчик должен иметь папки-рабочие_копии (по числу оставшихся разработчиков) и средства для оперативного синтаксического анализа кода. еще был бы признателен, если бы кто-нибудь дал дельную ссылку на описание методологии командной работы (помимо описанной в SVNbook) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 6 июля, 2008 Опубликовано 6 июля, 2008 · Жалоба Увы svn как раз и есть то препятствие, которое не позволяет работать по такому принципу. можно создать конечно N веток для каждого разработчика и вручную ими керовать. Я использую git - у него распределенная схема хранения веток кода - на компе у каждого разработчика есть локальная копия основного дерева + своя ветка - менеджер проекта или следующий в цепочке тестер, получив по email уведомление об оконченном этапе, выкачивает с компа разраба changeset и в случае успеха передает дальше вплоть до коммита в основное дерево или отправляет замечания обратно разрабу. Таким образом разработчики сами взаимодействуют между собой наиболее оптимальным образом, в противном случае manager проекта рискует стать бутылочным горлышком. Насчет сети не понял - достаточно модемного интернет соединения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 7 июля, 2008 Опубликовано 7 июля, 2008 · Жалоба ... еще был бы признателен, если бы кто-нибудь дал дельную ссылку на описание методологии командной работы (помимо описанной в SVNbook) Мда, к последнему пожеланию присоединяюсь. А по поводу - "репозитарий должен содержать только рабочий и проверенный код"... Это кто сказал? Тогда в репозитарии должна быть всегда только одна версия, не так ли? :) ИМХО, наоборот, всегда нужно идти вперед, просто в комментах помечая не только то, что сделано, а то, что не сделано. Например для программ на С. Ver 2.45 Добавлена обработка бла-бла-бла. Протестировано под IAR. Не проверено под Codevision, ICC. Ver 2.46 Fixed: Переменная ... под ICC обрабатывалась некорректно в функции... ver 2.47 Проверено под IAR - OK. И вперед, вперед, используя откаты только для кризисных случаев, сопоставления отличий и бэкапа, в конце концов. И руководитель проекта должен рулить этим всем, я так представляю. Он и есть координатор разработчиков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 8 июля, 2008 Опубликовано 8 июля, 2008 · Жалоба Зависит от способа разработки - мне нравится иметь стабильную ветку проекта, которая 1. собирается без ошибок 2. прошла все созданные для текущего кода тесты 3. имеет реальные теги на которые можно лепить последующие патчи/доработки и bug-report'ы иначе каша получается. что там у разработчиков на компе - это их личное дело. руководитель должен отслеживает изменения в стабильных ветках - если он еще будет заниматься обменом информацией между разработчиками, то получим испорченный телефон. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 18 декабря, 2008 Опубликовано 18 декабря, 2008 · Жалоба притом, задача не конкретно для HDL-кода. Это может быть любой код, обрабатываемый разнообразными САПР, которые в силу вольности трактовки стандарта (что в случае HDL имеется в явном виде для верилог), могут выдавать различный по успешности результат для одного и того же кода. вроде бы совсем недавно вполне успешно решил такую проблему пользуясь svn (как раз таки для HDL) подробно - у меня был код, где log2 задавался в виде констант, на радости от новых тулзов я позаменял его функцией, через некоторое время выяснилось, что не все тулзы понимают эту замену. я ответвил версию до смены log2 и приложил на эту версию все изменения с главной ветки (от +1 до HEAD) - все работает. как могут здесь помочь распределенные системы - я не понимаю (только может тем, что более надежно делают операцию diff3 и помнят историю слияний) в любом случае придется сливать изменения с "ущербной" ветки в основную и из основной в ущербную -------- возможно таги облегчили бы жизнь, но таги как-то мутно реализованы в svn (типа как в cvs мутно реализованы ветки) и я пока не рискую ими пользоваться btw: у меня есть проекты, где от svn/cvs не отказаться из-за организационных вопросов - поэтому приходится пользовать все подряд Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться