реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> контроль версий применительно к Cadence SPB 16.6, ткните пожалуйста носом, кто как делает, где почитать.
yuri.job
сообщение Apr 27 2017, 02:08
Сообщение #1





Группа: Новичок
Сообщений: 4
Регистрация: 27-05-16
Из: 188660, Россия, Ленинградская область, Всеволожский район, поселок Бугры.
Пользователь №: 91 936



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

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

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

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

ЗЫ. извиняюсь за сумбур, засыпаю.
Go to the top of the page
 
+Quote Post
Mikle Klinkovsky
сообщение Apr 27 2017, 17:18
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 938
Регистрация: 10-10-05
Из: 54°36'41.81" 39°43'6.90"
Пользователь №: 9 445



Цитата(yuri.job @ Apr 27 2017, 05:08) *
но я ума не приложу, как быть с хранением версий печатных плат, т.к. они у нас легко могут по несколько сот мегабайт весить. Может Форумчане ткнут меня носом в какую сторону копать и как делать контроль версий для печатных плат конкретно каденса. и еще хотел бы услышать, как другие, кто работает в каденсе, делают контроль версий.

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

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

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

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

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

Цитата(yuri.job @ Apr 27 2017, 05:08) *
чтобы каждыйчеловек мог библиотеки наполнять

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


--------------------
Подвиг одного - это преступление другого! (с) Жванецкий
Go to the top of the page
 
+Quote Post
Карлсон
сообщение May 19 2017, 11:34
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 157
Регистрация: 29-09-06
Из: Москва
Пользователь №: 20 800



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

Для плат мы поначалу пытались прикрутить гит, но из-за недостатка времени и, видимо, недостатка понимания забросили эту идею. Сейчас платы делаются по версиям схемы и трассировки. Как готов релиз, его выкладываем на сервер в общий доступ.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 27th May 2017 - 02:33
Рейтинг@Mail.ru


Страница сгенерированна за 0.01526 секунд с 7
ELECTRONIX ©2004-2016