roboforum.ru

Антон, кстати приходи на презентаху мою, может тебе по работе пригодится

Компания «Тринити Урал» приглашает Вас принять участие в круглом столе
«Обзор актуальных решений по хранению данных-2011», который состоится 13 мая 2011 года с 10.00 до 13.00 в отеле Novotel по адресу: г. Екатеринбург, ул. Энгельса, 7 (конференц-зал «Яшма»).
Зарегистрироваться на мероприятие можно по телефону +7912 232 82 35, +7(343) 378 41 50
Участие в мероприятии бесплатное.
P.S. Будет демонстрироваться интерфейс и удаленного управления ресурсами Trinity NAS.

Вы рассматриваете проект, как законченный самодостаточный объект.
Если же смотреть "ширше", то сразу обнаружится, что отдельная плата OR, (например) самодостаточной ни разу не является - они только в комплексе живут, причем не только друг с другом, но и с комповыми утилитами, к примеру и т.п.

Поправил, например, протокол обмена или библиотеку печатных площадок под технологии конкретного производителя - и что, все проекты перетряхивать в десяти виртуалках?

тоже верно

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

• математика, алгоритмы (видимо документы источников, ссылки на работы и свои записки)
• код ПО (здесь нужен контроль версий больше других)
• электроника (схемы, файлы проектов моделирования и разводки).
• механика (CAD, результаты моделирования, чертежи, программы ЧПУ и тд)

в зависимости от проекта часть разделов может быть не заполнена.

В реале, там еще до фига добавится.
Например - это сами тулзы - компиляторы, программаторы, терминалки, КАДы и т.п. И тут нужен контроль версий самих тулзов и библиотек. Очень часто достаешь проект пятилетней давности и... оказывается, что пиндык.
Тулзы бывают общие для многих проектов, а бывают специальные - привязанные к проекту (ну, к примеру, утилитка для калибровки какого-нибудь компаса, рулилка конкретным манипулятором...)

Ну и огромное множество мелочей - начиная тупо со ссылок на форум и фоток, или ПДФ-ок и кончая, например, перепиской с заказчиком.

Отдельно выделятся документы (входные и выходные).

Ну, млин, довольно глупо же копировать пдфку про мегу88 в каждый проект. А с другой стороны, какая-нибудь экзотика вполне вероятно будет использоваться только в одном конкретном проекте.

И еще, если рассматривать долгоиграющие проекты, то нужно иметь не просто откат к ранней версии, а именно, доступ к разным версиям, чтобы и старые версии было можно поддерживать. Речь же идет о железках - вы не можете сказать клиенту: "ваша версия устарела, скачай новую". Вам ПРИДЕТСЯ поддерживать ВСЕ (ну условно) старые версии одновременно! Ветвление практически неизбежно.

Добавлено спустя 2 минуты 20 секунд:
В общем, я не вижу красивых простых решений... к сожалению

поддерживать все версии не проблема, любой снапшот (моментальный снимок, момент бакапа) можно сделать активным и продолжить с ним работу как с текущим проектом

они ветвиться будут - вот в чем проблема

да, это точно.
причем если в коде ветвления это нормально и решается,
то как разруливать ветвления в CAD ....

Поправил, например, протокол обмена или библиотеку печатных площадок под технологии конкретного производителя - и что, все проекты перетряхивать в десяти виртуалках?

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