Pull to refresh

Comments 76

Теперь туда же юнит тесты. Типа на точке а 5в, на точке б 0, тогда на точке в должно быть от 2.5 до 2.7.

Юнит не скоро, но DRC/ERC в web в роадмапе

Для человека, который вообще никогда не занимался железом (то есть меня): как так получилось, что файлы в проектах не хранятся в текстовом формате, который хорошо залезет в git? Ведь на скриншотах какие-то схемки.

Я знаю что KiCad генерирует текстовые файлы, но давайте представим как вы будете глазами сравнивать дифф этих файлов. Формат SVG тоже текстовый, но вряд ли кто-то сможет легко сможет сравнить две картинки смотря на текстовые исходники.

Доводилось вводить в графический pipeline(разработка игры/VR) использование SVG вместо бинарных векторных форматов — первое впечатление у дизайнеров действительно было жуткое — но через пару месяцев они привыкли — и открыли для себя, что случайно сохраннённые и закомиченные изменения в SVG прекрасно видны.

Собственно, по изменению исходных кодов программист тоже не всегда может сравнить две версии приложения — скорее направление, куда смотреть.
Ну, сравнительно небольшие диффы в схемоте вполне смотрибельны. С PCB нереально, но есть плагин, позволяющий получать визуальные диффы по схеме и плате.
Зачем в текстовом формате? Можно и в графическом сравнивать.
Например с помощью KiCad-Diff

image

git diff можно настроить, чтобы использовать сторонние утилиты для сравнения файлов. см документацию

Круто, не знал, спасибо. Но это в любом случае сильно много телодвижений, по сравнению с тем, чтобы просто посмотреть в браузере.

Все просто — не кодом единым, многие вещи просто нельзя адекватно представить в текстовом виде.

сложно в это поверить. Единственная разница — бинарные файлы пишутся/читаются быстрее.


А так любой уважающий себя софт имеет 2 версии файла — текстовую для системы контроля версий/ручных фиксов и бинарную для всего остального. Могу рекомендовать ознакомится с Autodesk(Alias/Wavefront) Maya — 25 лет у них все получается;)

Я раньше был инженером-конструктором, могу привести пример из своей области.
Деталь — это не набор точек, а последовтельность операций над деталью, примерно как гит. Все размеры динамические. При изменении одного размера перестраивается все дерево, все зависимые от него элементы, сотни и тысячи точек на результирущей моделе. Плюс там же идет чертеж этой детали, которые тоже пересчитывается. При изменении одного параметра дифф в текстовом виде будет на тысячи строк, т.е. полезность его стремится к нулю.
По поводу хранения этого в текстовом виде -одна деталь это по сути как микросервис, с десятками файлов, с гитом, каждая деталь станет отдельной папкой,-даже в маленьком проекте из 100 деталей это будет выглядеть как будто вы скачали 100 микросервсиов и пытаетесь с ними работать.
Плюс не представлю как это будет объем если хранить это в текстовом виде, а также скорость работы-все-таки парсить текст несколько дороже, а производительность для кадов до сих пор очень больной вопрос.

В DCC, к которым относится Maya, и в CAD, к которым относится близкий ей(и более раннему PowerAnimator) Alias(CAD) всё устроенно именно так, как вы говорите — пишется именно последовательность операций (и эти две софтины для разных рынков очень архитектурно близки «под капотом»).

А когда модель(деталь) закончена — она запекается(baking) — т.е. удаляется вся история и всё переводится в абсолютные значения (вам по САПР дожно быть тоже это знакомо — когда всё экспортится в тот же STL для последующего производства).
И вот этот результат лучше хранить в бинарном формате и передавать дальше по pipeline(на станки или в рендеринг/компоузинг). И да, после запечки, разумеется, будут те самые сотни тысяч точек на результирующей модели — но это уже финальная стадия.

upd: я не утверждаю, что все САПРы такую архитектуру имеют — тот же ранний AutoCAD for DOS — точно нет.
> Плюс не представлю как это будет объем если хранить это в текстовом виде

Текст очень неплохо сживается даже дохлым древним ZIP, а специальные форматы типа PPMd и того сильнее. Когда OpenOffice стал свои документы хранить в формате XML-ZIP, это смотрелось дикой ересью. Особенно выбор XML — это текстовый формат с дикой избыточностью. А сейчас даже Microsoft Office выкинул свои бинарные форматы и стал делать так же.
Заодно, кстати, сравните размеры одного и того же документа в виде файлов .DOC и .DOCX или .XLS и .XLSX

> также скорость работы-все-таки парсить текст несколько дороже

Скорость обычного жесткого диска на несколько порядков ниже скорости процессора. А сжатие текста, во всяком случае в случае MS Office, приводит к многократному уменьшению размера файла.

Т.е. в предположении, что файл данных читается/пишется целиком — мы получаем ускорение относительно большого бинарного файла. Медленный процесс — чтение с диска — ускоряется. А что во время чтения процессор занят больше обычного на распаковку и парсинг — так он всё равно бы простаивал зря.

Бесплатный бонус — защита от случайных повреждений. Если в бинарном файле поменять пару байт (сглючил диск, или память, или сеть при копировании), то обычная программа этого не заметит и будет работать с испорченными данными. А zip просто не распакуется и повреждённость данных будет замечена при первом же чтении.

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

> Деталь — это не набор точек, а последовтельность операций над деталью
> При изменении одного размера перестраивается все дерево

«Кто нам мешает — тот нам и поможет».

При просмотре разницы — просматривайте только разницу в истории операций и игнорируйте (вручную или программно) разницу в тех самых вычисленных точках.

Кстати, необходимо ли в исходном проекте хранить те самые вычисленные точки — это само по себе вопрос. Обычно же есть исходные материалы, и есть результат работы. Какой-нибудь «Аватар» — есть описание компьютерных сцен, а есть РЕЗУЛЬТАТ многочасового рендеринга, который мы смотрим в кинотеатрах. Первое для создателей сохранять надо обязательно, а вот второе — нет, второе уже отгружается потребителям, когда все изменения закончены.
Текст очень неплохо сживается даже дохлым древним ZIP, а специальные форматы типа PPMd и того сильнее.
Скорость обычного жесткого диска на несколько порядков ниже скорости процессора. А сжатие текста, во всяком случае в случае MS Office, приводит к многократному уменьшению размера файла.

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


При просмотре разницы — просматривайте только разницу в истории операций и игнорируйте (вручную или программно) разницу в тех самых вычисленных точках.

В моем представлении смотреть в каде все равно значительно проще. Соменваюсь что можно представить деталь видя изменения координат 20 точек и нескольких парметрах в операциях например гибки. Нередко бывало на сложных деталях я мог увидеть подходит ли изменение какого-то параметра только изменив и увидев как поедут все размеры на детале.


Кстати, необходимо ли в исходном проекте хранить те самые вычисленные точки — это само по себе вопрос. Обычно же есть исходные материалы, и есть результат работы. Какой-нибудь «Аватар» — есть описание компьютерных сцен, а есть РЕЗУЛЬТАТ многочасового рендеринга, который мы смотрим в кинотеатрах. Первое для создателей сохранять надо обязательно, а вот второе — нет, второе уже отгружается потребителям, когда все изменения закончены.

Ну по такой логике и гит концептуально неправильно работает-он хранит конечное состояние.

Git в этом смысле — «тупая обезьяна». Что дали — то и хранит. Ожидается, что человек сам себе не враг и бинарные кэши (.obj, .lib и т.д.) засовывать в DVCS-репозиторий не станет. Хотя бы потому, что удалить из DVCS-репозиториев информацию «нормальными способами» нельзя.

Но если засунуть — то будет хранить, неэффективно и возможно с частичным разрушением (настройки EOL Windows/Linux/MacOS)

> он хранит конечное состояние

Конечное состояние — это EXE ( elf, etc), которые запускается у пользователя.
А может быть даже не EXE, а установочный пакет (ISO, MSI, APK, ....)
Такое в Git'e не хранят, если на трезвую голову.

> чтобы обычный гит показывал диф. Поэтому в данном контексте зип == бинарный формат.

Если ради diff — то да, нужен текстовый формат.

Причём не просто текстовый, а разбитый на короткие строки (однострочный «лаконичный» xml или json тут хотя и текстовый формально, но всё равно не пойдёт).

Насколько понимаю, для этого придуманы git filters: плагины, которые разбирают файлы на набор удобных для diff'a текстовиков.

И думается мне, сделать в качестве входящего фильтра unzip плюс переработку xml (каждый тэг с новой строки) проще и надёжнее, чем «вскрывать» чей-то бинарный формат, с частичной (или отсутствующей) документацией, и в добавок который при обновлениях программы тоже может дополняться/изменяться.

Качественно — и так и так не очень удобно, и так и так в принципе возможно.
Количественно — варианты типа xml-zip проще и надёжнее.

> только изменив и увидев как поедут все размеры на детале

Но бывает и обратная задача. Когда нужно быстро сравнить «конкретную цифру». Например, у вас вдруг разъехалась схема, с которой вы много месяцев не работали, а тут вдруг «стряхнули пыль» — и нате. Вы определили, какая именно «строчка» файла породила эти изменения. Теперь, чтобы вам понять в какую сторону плыть, вам нужно быстро определить, кто когда и с какой целью эту строчку изменил. И вот тут легковесный просмотр diff'a в блокноте, занимающий долю секунды, гораздо удобнее любого многофункционального красивого просмотрщика, который будет загружаться секунд 5-10. А построчная аннотация (git blame) и того лучше.
В данном продукте, где практически вся информация в виде векторов и описания параметров, можно адекватно представить в виде текста.
Причина одна — клиенты(пользователи инженеры) не потребовали от производителей САПР такой функциональности.

В индустрии компьютерной графики(CG) к комбинации бинарного(для скорости, что было особенно акутуально для HDD/ранних сетей) и текстового(для системы контроля версий/парсинга) пришли давно (можно даже сказать, что всегда использовали эту комбинацию) — но там было намного более плотное взаимодействие пользователей и разработчиков. Например, Pixar — те же люди, что писали RenderMan — стали делать и мультики. Или использование Maya (как и её предшественника PowerAnimator) в сколько-нибудь сложных проектах в сравнении с 3DStudio Max в т.ч. обьясняется и возможностью сохранения в ASCII.
Потому что печатная плата — это больше рисунок, нежели текст. Каждый объект на ПП расположен в определённом месте, на определённом слое и имеет определённые параметры. Можно ли сгенерировать это текстом? — да, конечно. Можно ли это сравнить глазами так, чтобы стало ясно почему изменился тот или иной параметр или перенесли тот или иной объект? — нет.

Надо открывать обе версии паралелльно друг другу и сравнивать глазами ПП, а не их исходный текст.
И да, «мерджить» придётся вручную, потому что где-то перенесли track, где-то подправили маску, и после этого перезалили полигоны. И всё.

EDIT: Даже текстовый файл настроек проекта *.PrjPcb никто не будет сравнивать вручную, уж слишком много полей. Хотя, редактировать иногда приходится, когда тот или иной баг Алтиума не позволяет сделать то, что требуется.

Это еще и 3д модели всех компонентов.

STEP тоже текстовый — сравнивайте на здоровье /joke

zhovner простите за оффтоп: когда можно ожидать первые флипперы? Судя по отсутствию обзоров и распаковок в ютубе первая партия еще не дошла до адресатов?

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

Я правильно понял мораль: одновременное редактирование все там же невозможно («нужно согласовать работу»), а все остальное — навешанная сверху бижутерия?
одновременное редактирование все там же невозможно

Как вы представляете себе одновременное редактирование, например в Фотошопе? Да, мы все привыкли Googe Docs, но почему тогда с кодом мы так делаем? В общем я пока не представляю как можно было бы сделать одновременное редактирование одного файла в Altium.

У устройства есть множество независимых функциональных частей. На pcb есть разные части платы. В конце концов, чисто технически, схема состоит из кучи отдельных листов. Естественно какие-то операции невозможны при одновременной работе, но множество других — вполне могут быть параллельны. Спроектировать идеологию такой работы и реализовать — как раз достойная задача для разработчиков ПО. А не приделывание модных свистоперделок «Online», «365» и т.п.

Разные документы можно редактировать одновременно, посмотрите видео.

Allegro, например, позволяет работать разным инженерам над одной платой одновременно (задав границы редактирования для каждого). Про схемы не знаю. Кому нужно одновременно схемы править?
Правда я себе с трудом представляю, как такое выглядит не на демонстрациях, а в реальной разработке. Но раз такой функционал есть, значит он востребован. Иначе бы его не запилили.
Представьте, например, плату хотя бы уровня материнской для ПК или смартфона. Если при проектировании она поделена на функциональные блоки, каждый из которых разрабатывает отдельный инженер: один питание делает, другой RF часть и т.д. и это не противоречит здравому смыслу (т.е. распараллеливание работ реально позволяет сократить время разработки), — то смысл организовывать совместную работу есть. При этом разработчику может быть необходима возможность редактирования как схемы, так и топологии. Т.к. плата физически одна, то и проект в САПР для этой платы один и нужна возможность настроить правила доступа инженеров к одному проекту. Вполне может быть востребованная вещь, если проект достаточно объемный, сложный и организации процесса разработки (и его оптимизации) уделяется серьезное внимание.
Вот два инженера трассируют каждый свою часть — один питание, второй память. И вот нужно подвести питание к слоту памяти, а там второй инженер в это время бодается с дифпарами, волновым и все такое… Ах да, а перезаливку полигонов как разделить?
Правда я себе с трудом представляю, как такое выглядит не на демонстрациях, а в реальной разработке
На условной материнке функциональные модули достаточно сильны разнесены, например, PCIe, DDR и VRM априори будут расположены на разных участках платы, так что проблем с заданием ограничений нет.

Хотя на мелких проектах эта фича работает хуже, но кто-то покупает Cadence за 150+ к$ для мелких проектов?))

Вообще с кодом тоже делаем, просто за это приходится расплачиваться конфликтами позже.

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

При всей моей любви к альтиуму — он отстает лет так на 5 по своим возможностям и функционалу от более взрослых Cadence Allegro и Mentor Expedition. При этом лучше бы они нормальный Sigrity завезли, а не эти «фантики» с контролем версий, а так пока распылений ресурсов на не основной функционал для САПР.
А как часто вы сталкиваетсь на проектаз с необходимостью одновременной разводки платы?
Вот последнее время резко начал сталкиваться и каждый день, но это определенная специфика проектов и их возросшая сложность. А вот в своих силовушных проектах, где максимум 400-600 компонентов, особо нечего разводить в двоем, тоже самое во всяких IoT, автоматике и прочей мелочи.
В altium есть возможность редактировать топологию печатной платы одновременно нескольким инженерам. Плата как пазл разбивается на зоны ответственности, заключается некий контракт и можно работать одновременно. Редактирование принципиальных схем в таком случае можно производить заранее разбив весь проект на отдельные модули — листы. Например, модуль питания и его обвязка — один лист, контроллер — второй, схема радиосвязи (усилитель, антенна) — третий. Ве эти листы как отдельные блоки (черные ящики) со своими вводами и выводами соединяются на корневом листе проекта. Тогда никто не мешает каждому инженеру со своими зонами ответственности (питание, контроллер и связь) редактировать схемотехнику, каждый — на своем листе, одновременно.

В качестве альтернативы отмечу, что у Альтиума с некоторых пор есть какая-никакая интеграция с git'ом — например, диффы таки можно посмотреть:


Spoiler header

image


Но насколько я понимаю, мерджи делать будет почти невозможно, поэтому на мой взгляд вместо гита лучше подойдет (о боги!) SVN, поскольку в нем можно делать глобальный лок на редактирование.

Из текста не понятно может ли Altium, сравнив две топологии, показать разницу — перемещение дорожки или компонента?
В целом перемещение дорожки или компонента Altium не показывает. Изначально плата в Altiume разбивается на квадраты определённого размера — инженер сам выбирает какого. Если изменение затрагивает какой-то квадрат — то в коммите видно какой (он отмечается красным). А вот что конкретно в нём изменилось — нужно смотреть глазами, для этого есть возможность переключения между «было» и «стало».

Пока только между релизами, посмотрите видео (таймкод) https://youtu.be/FeSoRvQZSNQ?t=588


Скоро обещают графический дифф между коммитами. Уже есть в бете, но мы пока не пробовали.

Altium штука дорогая.
В Лондоне они наняли юридическую контору которая специализируется на ловле пиратов и нелегальных пользователей.
Работают очень эффективно, в самой программе встроены некие механизмы удаленного отслеживания.
Поэтому малейший отход от лицензии вызывает письма из Лондона.
Лицензию надо продлевать каждый год.
В этой связи вопрос: останется ли доступ к облакам, когда истечет срок годовой лицензии на сам Altium?
В этой связи вопрос: останется ли доступ к облакам, когда истечет срок годовой лицензии на сам Altium?

Да, доступ останется read only.

Продлевать надо только чтобы получать обновления. Но да, вопрос с Altium 365 остаётся открытым
А как программа сможет что-то отследить и «настучать», если закрыть ей доступ в интернет?
Возможно меня закидают камнями, но flipper zero выглядит как процесс ради процесса. вы просто кайфуете от работы, при этом само изделие до сих пор нельзя купить (только pre-order)

В целом, вся ваша деятельность выглядит как пример смузи-стартапа, которому очень повезло в плане денег и можно работать в удовольствие, совсем не заботясь о сроках и о коммерческой составляющей проекта
Возможно проблема задержек в дефиците компонентов.
Недавний пост в блоге Altium про это — resources.altium.com/p/state-electronics-industry-2021?utm_source=altium-designer-app&amp%3Butm_medium=referral&amp%3Butm_campaign=my-altium&amp%3Butm_content=article

В этом плане была бы очень полезна статья про ActiveBOM и как одним кликом в Altium проверить все компоненты на наличие в стоках и прогнозы на их наличие.
Я правильно понимаю, что вам не нравится то, что люди занимаются тем что им нравится и планируют еще и самоокупиться (заработать)?
Типа — на работе кайфуют? ух гааадыы…
А как должно и могло бы быть для абсолютно нишевого и нового продукта, на ваш взгляд? Ну, типа, как «правильно»?

Я просто вспоминаю как на новую Элиту бейкерствовал — так я игру даже и не ждал к примеру. Просто считай оплатил часы удовольствия из детства. А через пару лет приезжает почта — вот бета, вот ключ, лети.
Я если что, не бейкер флиппера. Но представить бейкерство в их пользу просто что бы люди так кайфующие от того что делают, продолжили этим заниматься — без проблем.

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

Работа над Flipper Zero — это процесс ради продукта. Каждый наш бэкер, вложившийся в наш проект, получит свой Флиппер, в этом и задумка. В этом и заключается вся суть краудфандинга.


Предзаказы мы запустили только по одной причине: тысячи опоздавших очень просили хотя бы какую-то возможность вписаться в затею.


Именно из-за нежелания выглядеть как машина по сбору денег мы отказались от идеи брать полную стоимость устройства на стадии предзаказа. Просим $10, потому что не просить ничего нельзя: нужно хоть немного минимизировать процент отказавшихся, ведь нам нужны более-менее точные планы на производство. Взамен, как и на Кикстартере, предлагаем значительную скидку.


Если кому-то не нравится платить без моментальной отдачи, можно дождаться выхода Флиппера в розничную продажу и купить по полной цене живое устройство, которое сразу отправится в доставку. Это примерно осень 2021.

можно работать в удовольствие, совсем не заботясь о сроках и о коммерческой составляющей проекта
Это называется «делать продукт как положено, а не как быстрее и дешевле». Всем бы так работать!
«делать продукт как положено, а не как быстрее и дешевле»
Граничные параметры должны быть в любом случае, иначе наступает ряд неприятных моментов… Во-первых, заявленные обещания оказываются не выполненными и бэкеры разочаровываются. Во-вторых, проектирование и производство это вещи весьма творческие и они могут продолжаться бесконечно, но делают все таки «продукт».

Если я правильно понимаю, то деньги собирали не на «мы будем разрабатывать», а на «мы сделаем для вас готовый продукт». Это немного разные подходы.

Так же не совсем понимаю дефицит каких именно компонентов там может быть то? Судя по техническому описанию проекта там не должно быть ни какой экзотики в принципе, а следовательно оно или закупается все таки или как минимум заменяется pin-to-pin аналогами. Вот лично я пока не замечаю дефицита тех же stm-ок, радиочипов и питальников на китайских фабах, по 200-500 штук так точно проблем нет закупить, чего хватит как минимум на 100-200 устройств для отгрузки.
Граничные параметры должны быть в любом случае
Бесспорно, definition of done — must have. Я бы даже сказал, с этого следует начинать )

Но определившись с требованиями и критериями, не следует гнаться за «time to market».
И экономить на всём подряд тоже не нужно.
Именно этот смысл я вложил во фразу «делать продукт как положено, а не как быстрее и дешевле».
И экономить на всём подряд тоже не нужно
А, во, теперь вашу мысль понял и поддерживаю)) Изначально просто читалось как: «Важен не результат, важен процесс»
При использовании Altium 365 используется сервер самой компании Altium?
Или есть возможность поднять все локально на своих серверах?
Altium 365 скорее выполняет роль суррогата.
Для настоящей командной работы в локалке у Altium есть NEXUS.
Но там цены похоже еще выше если даже команда Flipper его себе не может позволить.

Ещё у них есть (был) Vault, который потом стал Concord Pro (тот же А365, только локальный). А Nexus — это про автоматизацию процессов уже, а не только про совместное использование библиотек.

Altium 365 — это облачная платформа для разработки электроники, функциональность конфигурируется уровнем подписки (лицензии) more details https://www.altium.com/altium-365.
Для работы в локальной сети организации на данный момент есть 2 продукта:
1 — Altium ConcordPro — в котором реализованы основные возможности платформы по работе с библиотеками компонентов, проектами, web review, project history и тд more details https://www.altium.com/concord
2 — Altium NEXUS — решение для команд с формализованными процессами, по факту вся функциолнальность ConcordPro + управление процессами more details https://www.altium.com/altium-nexus
Ребят, вопрос на миллион, сколько стоит лицензия на Altium Designer 20?
Добрый день! На текущий момент актуальная версия Altium Designer 21, для определения стоимости нужны дополнительные параметры (так как для предприятий входящих в реестр СМП rmsp.nalog.ru стоимость ниже). Можете прислать в личку название компании?

а без дополнительных параметров сколько?

от 491 000 р до 755 000 р
Спасибо, вот теперь у меня есть финансовая цель, если я сделаю выбор в сторону вашей САПР.
Не, не для компании… Мне для себя, хочу изучать эту САПР на практике.

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

Ок. Предположим в СМП состоит компания. Микробизнес Сколько? Вот не понимаю я, почему так не любят крупные "серьезные" компании выставлять прайс. Хотя бы с пометкой *цены могут измениться в зависимости от...

Интересный опыт, спасибо что поделились!
Помимо всего связанного с Altium, понравилось наличие на hardware проекте тестировщика. Первый раз встречаю такое среди железячных компаний в статьях на Хабре. Наконец-то!
Но не написано как тестировщик строит свою работу…
Тестировщик сидит и нажимает кнопочку 10 000 раз, чтобы оценить ее ресурс)))
Это не тестирование… что то другое…
А если поставить омроновский микрик на миллион нажатий…
Если схема неправильно спроектирована (например, как некоторые ставят конденсатор параллельно кнопке или параллельно подтягивающему резистору для подавления дребезга) то омроны и 10 000 нажатий не проживут.
Это все миф, даже китайские тактовые кнопки переживают без проблем годы эксплуатации с тысячами нажатий при параллельно включенном кондере типа 1 мкФ. Да, это определенно не лучшая идея, но и не такой там ток разряда, чтобы ушатать контакты настолько быстро.
zhovner, вот Вам отличный повод для очередной статьи!

Про тестирование будет большая статья.

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

«очень легко» — это перебор.

Просто папки с законченными (выпущенными, зафиксированными, переданными в другой отдел, опубликованными, etc) версиями надо закрывать на запись. Хочешь поправить — делаешь копию и правишь в ней. Случайно поправить по месту не даст Windows/Linux.

Но это требует внимательной ручной работы: закрыть на запись можно просто забыть, ведь решение о фиксации версии обычно принимается несколькими людьми в течение нескольких дней, а не в одну секунду в одном месте. Опять же, можно письма «бегунки» делать, а закрыли ли вы папку у себя на диске, или ещё как. Но в общем, в текучке забыть и не сделать, в самом деле, вполне реально. Тем не менее, «очень легко» — это перебор.

Еще одна возможная проблема с подходом «много папок» — это многократный расход дискового пространства. Что может быть оправдано, если часто нужно именно заглядывать в «исторические» версии, например искать появление и эволюцию конкретной детали (файла, блоки информации в файле, etc).

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

С автоматизацией безусловно удобнее, но «ну ужас, да, но не ужас-ужас-ужас».
Кстати, про автоматизацию не сказали одну ключевую вещь: а именно гарантии того, что на компьютерах F.D. всегда есть минимум две полных копии всех файлов. Что если завтра Altium 365 по любой возможной и невозможной причине станет недоступен — работа не прервётся и всё файлы по прежнему будут доступны работникам, пусть и с меньшими удобствами.

В идеале, должна быть возможность разворчивания локальной службы Altium 365, «on premises». В этом, кстати, хорош Git/Mercurial/Bz2/Veracity: для них любая сетевая папка — уже полноценный репозиторий, и хранение своих исходники на битбакетах и гитхабах никак не противоречит одновременном хранению их же на файловых серверах компании.
Only those users with full accounts are able to leave comments. Log in, please.