Контроль версий, мерж/пул-реквесты и работа в команде

[kichay.d]

Всем доброго дня.

Заинтересовал меня вопрос об организации командной работы над проектом, представленным в виде G-кода. Предположим:
1. Проект представляет из себя набросок алгоритма в виде некоторой шаренной библиотеки (dll/so), функии которой подключают в какой-то конечный продукт на стадии обкатки алгоритмов.
2. Обкаткой алгоритмов занимается несколько человек одновременно, среди них есть как новички, так и бывалые.
3. Внутри команды хотелось бы обсуждать применяемы решения, критиковать их итд...

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

Как я понимаю, для нахождения diff старой и новой версии внутри VI нужно:
1. Графическое представление объектов на диаграмме со связями как-то представить в виде кода (получить, например, UML Component Diagram в формате yaml)
2. Получить классический "текстовый" diff для текстового представления
3. Перестроить VI так, что бы каждое изменение полученное по diff было внесено в case структуру управляемую константой boolean (что бы можно было листать кейсы и смотреть, что было, и что стало)

В связи с моим предположением у меня вопросы:
1. Есть ли что-либо готовое со сторона NI для командной работы?
2. Есть ли вариант экспорта VI в какой-либо документированный формат?
3. Есть ли какие либо варианты импорта в LabVIEW из документированных форматов?

[Kosist]

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

Если нужна аналогия git - гросто используйте git. Git - это софт для контроля версий. Плюс, в зависимости от git сервера, можно добавить "плюшки" для более удобного ведения разработки.

1. Графическое представление объектов на диаграмме со связями как-то представить в виде кода (получить, например, UML Component Diagram в формате yaml)
2. Получить классический "текстовый" diff для текстового представления
3. Перестроить VI так, что бы каждое изменение полученное по diff было внесено в case структуру управляемую константой boolean (что бы можно было листать кейсы и смотреть, что было, и что стало)

UML генератор есть, но он подходит для ООП-шных проектов. Логические связи внутри виаек им не построить.
В уже есть тула для графического сравнения кода Compare VIs и Merge VIs. Также, есть статьи на форумах/блогах, как их интегрировать в git клиент.
По своему опыту скажу - помогают слабо. Успех совместной работы над проектом - это умение разбить код на отдельные блоки, которые не связаны между собой. Таким образом, можно смело редактировать виайки не боясь конфликтов. А уже за связку компонентов отвечать должен один разработчик. Шансы создать конфликты есть, но потом они довольно малы, и конфликты можно решить проще.
3 пункт - вообще непонятен, и если даже будет реализован, внесет хаос. Структурируйте код правильно, и будет счастье. Если нужно временно скипать код - используйте Disable Structure, или Conditional Disable Structure.

1. Есть ли что-либо готовое со сторона NI для командной работы?
2. Есть ли вариант экспорта VI в какой-либо документированный формат?
3. Есть ли какие либо варианты импорта в LabVIEW из документированных форматов?

1. У NI продукта такого нет. Git в помощь.
2. Можно написать свой парсер виайки в другой формат. Но вопрос - зачем? Все кейсы все равно покрыть будет очень тяжело, и в итоге такой парсер не будет использоваться.
3. Готовых решений нет. Опять же, можно писать свою тулу - но это долго, нудно, и тяжело.

Я работал в комманде, и мы делали маленькие и большие проекты, активно используя git. При правильном построении кода, соблюдении принципов SOLID - проблем нет. Поверьте, пункты 2 и 3 Вам не нужны для работы.