dxp 34 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба V tom to i delo chto sources eto eshe ne vse. S 18 MB u menja lichno net problem. Nu a source files mogno manipulirovat' chem komu udobnej. Prosto ja hotel skazat' chto arhive vsego proecta vse ravno nugen. Esli ja naprimer beru chej-to proekt, to luchshe chto-by byl ZIP, chem prosto sources. 18 мег получаются из 50 кил. А из 500 кил сорцов сколько балласта выйдет? Да в этом копаться потом замучаешься. Если надо репорты и/или еще какие файлы - пожалуйста, помещайте их под контроль версий. Но зачем тащить мегатонны cdb файлов, которые нагенерил Квартус? Это просто туча бинарных файлов, ревизировать которые нет никакого смысла. 18 мегов, конечно, нынче не страшно. И 25 и 50 и даже 100 мегов. Если это действительно полезная информация. И если нужно сохранить ее один раз на проект. А теперь представте, что у меня основной "ствол" проекта и 4 "ветки". И на каждый коммит будет 18 мегов. За пару недель на болванку наберется. Такие объемы уже просто неудоно манагить - вставь болванку, распакуй, просмотри, убедись, что не то открыл, повтори для всех остальных копий. Или в случае с репозиторием - переключить на нужную ревизию и вуаля. А на болванку лезть только когда репозиторий грохнулся, что, согласитесь, не частое дело. Не, оба пути я проходил, правда, на программерских проектах. Системы контроля версий рулят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Короче, эксперименты показали следующее: выявлен ряд файлов, которые надо держать под контролем, чтобы сохранялись настройки (и прочее). Результат: Типы файлов, которые нужно помещать под контроль версий ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (кроме исходных текстов) ~~~~~~~~~~~~~~~~~~~~~~ Synplify: *.prj - project *.sdc - constrains Quartus: *.qpf - project *.qws - workspace *.qsf - settings *.srf - message manager *.cdf - programmer *.stp - logic analyzer Active-HDL: *.aws - workspace *.adf - project compile.cfg - compilation support compilation.order - compilation support Если есть какие-то еще соображения (чего-то не хватает, что-то лишнее), изложите, плиз? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vetal 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба А результат работы фиттера(на 20`000-30`000LUT) уже ничего не стоит? Это часы напряженной работы компа и цена их будет повыше исходников. Для квартуса желательно отдельно от исходников создавать *.qar со всеми необходимыми файлами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба А результат работы фиттера(на 20`000-30`000LUT) уже ничего не стоит? А что есть результат работы фиттера? pof? sof? Ну, и сохраняйте их, если очень надо, но для этого не нужно версии проекта применять - есть стабильная прошивка, если она представляет ценность сама по себе, сохраните ее отдельно. Но это не причина тащить мегатонны cdb-файлов. Это часы напряженной работы компа А сорцы - это часы, дни и недели напряженной работы человека и рабочее время человека куда дороже, чем компьютера, который можно на ночь оставить, чтобы он фиттил себе на здоровье. и цена их будет повыше исходников. Ну, это кому как. По мне так ценней исходников ничего быть не может - они есть продукт интеллектуального труда человека, который (труд) не поддается ни формализации, ни четкому определению его стоимости. Исходники - первичное, остальное - производное, получается из них механически. В любом случае стоимость производного вполне четко поддается определению - в часах работы компьютера, например. Если эта стоимость такова, что имеет смысл держать прошивку отдельно, пожалуйста, ничего этому не противоречит. Но это не относится к системам контроля версий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vetal 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба о это не причина тащить мегатонны cdb-файлов. Прибегает человек и просит инвертировать сигнал(или внести незначительные изменения), а я ему: приходи через пару дней!!! Исходники - первичное, остальное - производное, получается из них механически. При разработке ПП главное - схема, остальное можно повторить:):):) *.DB тоже важны, особенно при болчной компиляции/фиттере. Я за то, что результаты квартуса необходимо хранить целиком. Проект ценен целиком. На одну болванку можно запихать от 4 до 8 Gb прожектов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
disel 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Я использую monotone - прост как танк, есть под win/linux. А что такое monotone? Можно ссылку? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kyb 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Короче, эксперименты показали следующее: выявлен ряд файлов, которые надо держать под контролем, чтобы сохранялись настройки (и прочее). Результат: Типы файлов, которые нужно помещать под контроль версий ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (кроме исходных текстов) ~~~~~~~~~~~~~~~~~~~~~~ Synplify: *.prj - project *.sdc - constrains Quartus: *.qpf - project *.qws - workspace *.qsf - settings *.srf - message manager *.cdf - programmer *.stp - logic analyzer Active-HDL: *.aws - workspace *.adf - project compile.cfg - compilation support compilation.order - compilation support Если есть какие-то еще соображения (чего-то не хватает, что-то лишнее), изложите, плиз? :) Вопрос между прочим. Неужели указанные средства не позволяют пользоваться скриптами? Они как раз самое оно для контроля версий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 14 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Вопрос между прочим. Неужели указанные средства не позволяют пользоваться скриптами? Они как раз самое оно для контроля версий. Вы не поверите, но проекты Quartus и Synplify --- это и есть tcl-скрипты. Или имелось в виду другое? Во всем солидарен с dxp. :cheers: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба о это не причина тащить мегатонны cdb-файлов. Прибегает человек и просит инвертировать сигнал(или внести незначительные изменения), а я ему: приходи через пару дней!!! Как раз нет! При отсутствии системы контроля версий придется вспоминать, к какой ревизии относится эта просьба - проинвертировать сигнал, ведь мы тут уже дальше ушли. Склонировать весь толстый проект. Завтра он придет и попросит еще что-то сделать - еще один клон. Послезавтра - еще. И т.д. А тут я просто "ветку" в репозитории заведу от ревизии, которую ему надо и все. Если есть вероятность, что он еще придет не раз, то я не буду просто прибивать рабочую копию - в ней все базы остаются. Когда изменения закончатся, тогда и удалю, закоммитив все изменения. И всегда смогу к этому вернуться. Исходники - первичное, остальное - производное, получается из них механически. При разработке ПП главное - схема, остальное можно повторить:):):) А что, Вы размещение на кристалле в ПЛИС руками делаете? Если руками, то конечно - это ценная работа. Хотя и в случае ручного размещения все эти вещи ложатся в скрипты, которые используются компилятором/фиттером. Ессно, что эти вещи надо тоже сохранять - это продукт ручного труда человека, как исходные тексты HDL-описаний, файлы констрейнов и проектов. Т.ч. аналогия с разводкой ПП - мимо. :) *.DB тоже важны, особенно при болчной компиляции/фиттере. Я за то, что результаты квартуса необходимо хранить целиком. Проект ценен целиком. Тогда еще надо туда же и сам Квартус класть - чтобы версия и сервиспаки были к месту. А то поставите новую версию и получите несовместимость. А так, если надо откатиться на какую-то ревизию, ставите старый Квартус (сервиспаки, если надо) и им работаете. :) Не, это не наш путь. Я полагаю, что грамотное входное описание должно ложиться на любые версии одинаково хорошо, т.е. зависимость от версии инструментария должна быть нулевой или близкой к нулю. На одну болванку можно запихать от 4 до 8 Gb прожектов. Дело не только в объеме, но и в удобстве работы. Скажите, Вы пробовали пользоваться системами контроля версий? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vetal 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Я пробовал ими пользоваться, но пришел к выводу, что для меня лучше зипа и даты_времени в имени файла - нет. что он еще придет не раз, И не раз, и даже не два. Тогда еще надо туда же и сам Квартус класть - чтобы версия и сервиспаки были к месту. А то поставите новую версию и получите несовместимость. А так, если надо откатиться на какую-то ревизию, ставите старый Квартус (сервиспаки, если надо) и им работаете. (IMG:style_emoticons/default/smile.gif) Почти так. Рабочие версии квартуса не удаляются. При использовании sopc builder у меня нет уверенности, что все компоненты из предыдущей версии перейдут в новую и без изменений или удалений, а при перетаскивании не возникнет конфликта. Если сделано для определенной версии квартуса, то на ней и заканчивается. Исходники - одна песня, а проекты на базе своего и чужого - другая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kyb 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Сохранение проектов в виде текта самое удачное решение; еще бы при выпуске релизов система контроля сама подставляла бы номер версии в удобном для синтеза виде. CVS этого делеать не умеет. Может другие умеют? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
maior 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Послушал я вас тут, послушал - и остался при своем мнении: простой бэкап версий решает ВСЕ проблемы, никакой CVS не нужен! И даже вреден. Особено если разработчик на проекте - один человек (а иначе в FPGA бывает редко). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Послушал я вас тут, послушал - и остался при своем мнении: простой бэкап версий решает ВСЕ проблемы, никакой CVS не нужен! И даже вреден. Особено если разработчик на проекте - один человек (а иначе в FPGA бывает редко). Бекап решает не ВСЕ проблемы, а только часть. Он не решает проблем автоматизации работы, управления версиями (выбор версии, переключение на нее), удобства и безопасности. Этак можно сказать, что, дескать, нафиг всякие С/С++ - простой ассеблер решает все проблемы. :) Аналогия близкая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LeonY 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Особено если разработчик на проекте - один человек (а иначе в FPGA бывает редко). А если не один - а именно так и бывает сегодны в больших FPGA, при том в разных концах земного шара Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 6 июня, 2006 Опубликовано 6 июня, 2006 · Жалоба Послушал я вас тут, послушал - и остался при своем мнении: простой бэкап версий решает ВСЕ проблемы, никакой CVS не нужен! И даже вреден. Особено если разработчик на проекте - один человек (а иначе в FPGA бывает редко). Наиболее частое заблуждение. Никакие записки/комменты и архивы не заменяют автоматизированные средства ведения версий. Для меня проект без ведения версий - безликий, плоский, одноразовый/мертвый. Практикую cvs/svn 5 лет единолично и в коллективе, под ним все чем занимаюсь: исходники, документация, конфиги систем и т.п., печатные платы... Ведение версий необязательно если проект одноразовый и ни с чем не связан - сделал и забыл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
