Центральная БД предприятия Опции

[Nemod]

Хотим перейти на Orcad/Allegro.
Пока конечно мало о нем знаю (почитал по диагонали Kreig Mitzner и прочие доки).
Встал вопрос об организации центральной БД компонентов используемых в изделиях предприятия.
Как это лучше сделать для "Orcad Capture -> PCB Editor" Flow?
CIS я так понял это просто надстройка содержащая ссылки на файлы падстаков и OLB. И если это так то сложно его назвать базой данных, это просто представление данных которые валяются в виде файлов и редактирование происходит вообще не через него (может я чего-то не нашел).

Сейчас основная идея вынести файлы на сервер и там их редактировать, но возникает тогда проблема совместного доступа.
Т.е как разрешить конфликты совместного редактирования OLB файлов?
И есть ли возможность хранить данные как-то в другом виде например в БД в виде BLOB полей или таких же файлов но чтобы конфликты доступа разрешал сервер?

[lazarev andrey]

похоже, что помочь некому
или не так задали вопросы

[vitan]

или не так задали вопросы

Скорее это.
Вы сильно большой вопрос задали. Много писать не хочется. По частям спрашивайте лучше.

[lazarev andrey]

Скорее это.
Вы сильно большой вопрос задали. Много писать не хочется. По частям спрашивайте лучше.

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

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

что то опять получается много

мануалов толком нет или не там ищу

[vitan]

делается ли так вообще (правильно ли это)?

Делается. У нас я так и сделал. Только это вызывает необходимость координировать совместное использование общих ресурсов. У меня, например, это делается с помощью систем контроля версий и управления процессами, которые не привязаны к каким-либо САПР вообще.
Пользователям закрыт доступ к общим ресурсам иначе чем через контроль версий, а к некоторым ресурсам еще и процесс написан. Работает.

[Nemod]

Делается. У нас я так и сделал. Только это вызывает необходимость координировать совместное использование общих ресурсов. У меня, например, это делается с помощью систем контроля версий и управления процессами, которые не привязаны к каким-либо САПР вообще.
Пользователям закрыт доступ к общим ресурсам иначе чем через контроль версий, а к некоторым ресурсам еще и процесс написан. Работает.

Во. Можно поподробнее?
Я предполагал следующую схему:
1. Создать репозиторий на сервере SVN для библиотеки
2. Закоммитить туда каталог со всей фигней (футпринты, олбэшки и т д)
3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет).
4. Пользователь может локально внести изменения и закоммитить их затем на сервер.

Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??.
Нет ли проблем со служебными каталогами .svn (если кто-то использует subversion)?
Может лучше GIT?

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

[vitan]

3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет).

У меня есть отдельный каталог на сервере, в котором отражается текущее состояние репозитория. Каталог доступен только по чтению. Юзерам рекомендовано пользоваться им как основной центральной библиотекой. Но не запрещается пользоваться своими локальными.

Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??.

Это только кажется, что удобно. Вы что делаете, когда реально возникает конфликт в текстовом файле? Скорее всего, идете и на словах общаетесь со второй стороной. При этом действия обеих сторон не формализованы. Чтобы избежать в этом бардака, применяются системы контроля процессов.

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

Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка SVN.

[Nemod]

У меня есть отдельный каталог на сервере, в котором отражается текущее состояние репозитория. Каталог доступен только по чтению. Юзерам рекомендовано пользоваться им как основной центральной библиотекой. Но не запрещается пользоваться своими локальными.


Это только кажется, что удобно. Вы что делаете, когда реально возникает конфликт в текстовом файле? Скорее всего, идете и на словах общаетесь со второй стороной. При этом действия обеих сторон не формализованы. Чтобы избежать в этом бардака, применяются системы контроля процессов.


Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка SVN.

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

Была проблемма когда я запихал БД в свн. Central library воспринимал подкаталоги svn как часть этой библиотеки и выдавал всякую билеберду. DxDesigner/Expedition flow. EE 2005 вроде.

Про альтиум не знаю. Может быть. И что svn там не только для исходных текстов vhdl/c++ применяется?

В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc.

Кстати если порытся на сайте то можно и найти эти проблеммы совместимости svn и expedition http://electronix.ru/forum/index.php?showt...p;hl=Subversion

[vitan]

В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc.

А никто и не говорил, что надо svn применять для баз данных. Это надо применять для контроля версий угошников и футпринтов. А с БД работать через ODBC или еще какой интерфейс, это да.