Перейти к содержанию
    

контроль версий применительно к Cadence SPB 16.6

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

IMHO, достаточно "идентификации" - ведения изменения (или ревизии).

 

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

 

Для дальнейшего релиза копировать проект и менять изменение.

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

 

Как хранить? Я, например, на сервере, в папках с номером изменения в названиях.

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

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

 

Текущие преимущества:

- простота бекапа,

- простой удалённый доступ,

- независимость от софта разработки (хоть их десять разных в проекте одновременно, включая механику и симуляторы),

- независимость от конкретного разработчика и его персонального компьютера, когда нужно срочно внести внеочередное изменение или передать работу другому,

- легкий текстовый поиск по файлам отчётов по всем проектам с помощью FAR манагера.

 

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

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

Лучше всего выделять сопровождение/пополнение библиотеки в отдельную задачу и поручать конкретному человеку/людям.

Да и создание новых компонентов делегировать им же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для ведения библиотек используем CIS и Git. Это позволяет почти избегать конфликтов и всегда есть возможность понять, где косяк и кто его допустил.

Идеология такая, что для некоторого подмножества компонентов, объединенных общими свойствами (например, резисторы) заводится свой текстовый файл, который и является таблицей данных для CIS (без аксеса или экселя в качестве контейнеров).

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

Таким образом у каждого разработчика своя локальная версия репозитория. Общий лежит на сервере и никому кроме разработчиков не доступен.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...