контроль версий применительно к Cadence SPB 16.6, ткните пожалуйста носом, кто как делает, где почитать. Опции

[yuri.job]

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

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

это вроде бы сейчас худо бедно пытаемся на гите сделать.

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

ЗЫ. извиняюсь за сумбур, засыпаю.

[Mikle Klinkovsky]

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

Ни одна система "контроля" не даст вам для файлов печатных плат того, что она даёт для исходников софта, пока её не встроят в сам CAD. И даже после этого это не даст преимуществ, т.к. "в заказ" не отправляют "ежедневные" релизы плат.
IMHO, достаточно "идентификации" - ведения изменения (или ревизии).

Если плату изготавливали, то надо хранить её проект (в этом изменении) "пожизненно" (до конца срока жизни проекта в этом изменении/ревизии). Например для ремонта/сапорта, внесения доработок.

Для дальнейшего релиза копировать проект и менять изменение.
И так с каждым изменением (ревизией) по которой есть задел или она в наличии у клиентов/заказчиков.

Как хранить? Я, например, на сервере, в папках с номером изменения в названиях.
Для простоты выравниваю номер изменения у всего по сборке (схема, плата, гербера, перечень, спецификация и пр.файлы), т.е. всего что храню в одной папке с проектом.
Для экономии места не надо хранить документацию для разработчика в папках с проектом, в процессе разработки файлы документации рассовываются по папкам "библиотеки" (сторонней технической документации), а в компонентах/проекте проставляются гиперссылки для быстрого доступа и просмотра документа.

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

чтобы каждыйчеловек мог библиотеки наполнять

Каждый - это лишнее. Может привести к замусориванию и конфликтам дублирования.
Лучше всего выделять сопровождение/пополнение библиотеки в отдельную задачу и поручать конкретному человеку/людям.
Да и создание новых компонентов делегировать им же.

[Карлсон]

Для ведения библиотек используем CIS и Git. Это позволяет почти избегать конфликтов и всегда есть возможность понять, где косяк и кто его допустил.
Идеология такая, что для некоторого подмножества компонентов, объединенных общими свойствами (например, резисторы) заводится свой текстовый файл, который и является таблицей данных для CIS (без аксеса или экселя в качестве контейнеров).
Поскольку все строки данных тупой текст, то изменения в таблице даются гиту легко. Проблемы могут возникать с бинарными файлами или с OLB библиотеками. В случае конфликта версий OLB файлов решили, что кому внести изменения проще (т.е. он их сделал меньше), тот и правит. Или же по договоренности, если всё печально. При этом, после того, как стали в обязательном порядке через общий чат уведомлять друг друга об обновлении базы, конфликты почти исчезли.
Таким образом у каждого разработчика своя локальная версия репозитория. Общий лежит на сервере и никому кроме разработчиков не доступен.

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