yuri.job 0 27 апреля, 2017 Опубликовано 27 апреля, 2017 · Жалоба Собственно имеется каденс, имеется некоторое количество библиотек, проектов, и, как назло несколько человек, кто с ними работает, я в их числе. собственно пока что есть у каждого работника своя библиотека и общие библиотеки, в которые постепенно переносятся и сортируются компоненты из "частных" библиотек неким человеком. так же есть проекты схем и плат. над каждой платой работает один человек, т.е. как бы схемы и платы у каждого свои. на общем серваке храним только релизы плат/схем. Хотелось бы, во первых иметь всетаки более бенее централизованное хранилище библиотек, чтобы каждыйчеловек мог библиотеки наполнять и у остальных они соответственно обновлялись и тп. т.е. некий репозиторий, из которого все равстет. это вроде бы сейчас худо бедно пытаемся на гите сделать. но я ума не приложу, как быть с хранением версий печатных плат, т.к. они у нас легко могут по несколько сот мегабайт весить. Может Форумчане ткнут меня носом в какую сторону копать и как делать контроль версий для печатных плат конкретно каденса. и еще хотел бы услышать, как другие, кто работает в каденсе, делают контроль версий. ЗЫ. извиняюсь за сумбур, засыпаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MikleKlinkovsky 5 27 апреля, 2017 Опубликовано 27 апреля, 2017 · Жалоба но я ума не приложу, как быть с хранением версий печатных плат, т.к. они у нас легко могут по несколько сот мегабайт весить. Может Форумчане ткнут меня носом в какую сторону копать и как делать контроль версий для печатных плат конкретно каденса. и еще хотел бы услышать, как другие, кто работает в каденсе, делают контроль версий. Ни одна система "контроля" не даст вам для файлов печатных плат того, что она даёт для исходников софта, пока её не встроят в сам CAD. И даже после этого это не даст преимуществ, т.к. "в заказ" не отправляют "ежедневные" релизы плат. IMHO, достаточно "идентификации" - ведения изменения (или ревизии). Если плату изготавливали, то надо хранить её проект (в этом изменении) "пожизненно" (до конца срока жизни проекта в этом изменении/ревизии). Например для ремонта/сапорта, внесения доработок. Для дальнейшего релиза копировать проект и менять изменение. И так с каждым изменением (ревизией) по которой есть задел или она в наличии у клиентов/заказчиков. Как хранить? Я, например, на сервере, в папках с номером изменения в названиях. Для простоты выравниваю номер изменения у всего по сборке (схема, плата, гербера, перечень, спецификация и пр.файлы), т.е. всего что храню в одной папке с проектом. Для экономии места не надо хранить документацию для разработчика в папках с проектом, в процессе разработки файлы документации рассовываются по папкам "библиотеки" (сторонней технической документации), а в компонентах/проекте проставляются гиперссылки для быстрого доступа и просмотра документа. Текущие преимущества: - простота бекапа, - простой удалённый доступ, - независимость от софта разработки (хоть их десять разных в проекте одновременно, включая механику и симуляторы), - независимость от конкретного разработчика и его персонального компьютера, когда нужно срочно внести внеочередное изменение или передать работу другому, - легкий текстовый поиск по файлам отчётов по всем проектам с помощью FAR манагера. чтобы каждыйчеловек мог библиотеки наполнять Каждый - это лишнее. Может привести к замусориванию и конфликтам дублирования. Лучше всего выделять сопровождение/пополнение библиотеки в отдельную задачу и поручать конкретному человеку/людям. Да и создание новых компонентов делегировать им же. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Карлсон 3 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Для ведения библиотек используем CIS и Git. Это позволяет почти избегать конфликтов и всегда есть возможность понять, где косяк и кто его допустил. Идеология такая, что для некоторого подмножества компонентов, объединенных общими свойствами (например, резисторы) заводится свой текстовый файл, который и является таблицей данных для CIS (без аксеса или экселя в качестве контейнеров). Поскольку все строки данных тупой текст, то изменения в таблице даются гиту легко. Проблемы могут возникать с бинарными файлами или с OLB библиотеками. В случае конфликта версий OLB файлов решили, что кому внести изменения проще (т.е. он их сделал меньше), тот и правит. Или же по договоренности, если всё печально. При этом, после того, как стали в обязательном порядке через общий чат уведомлять друг друга об обновлении базы, конфликты почти исчезли. Таким образом у каждого разработчика своя локальная версия репозитория. Общий лежит на сервере и никому кроме разработчиков не доступен. Для плат мы поначалу пытались прикрутить гит, но из-за недостатка времени и, видимо, недостатка понимания забросили эту идею. Сейчас платы делаются по версиям схемы и трассировки. Как готов релиз, его выкладываем на сервер в общий доступ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться