История изменений

В чем заключается сопротивление?

Ну, конкретно git я не внедрял, но с Subversion попытка была. Судя по тому что SVN не взлетел, до git'а тем более не доросли.

Ну так вот, о сопротивлении. Конструкторы категорически отказывались, во-первых, знать как работает их основной инструмент (Solidworks), во-вторых, знать что-то помимо Solidworks'а, понимать как работает SVN, проводник Windows и прочее. Практически это выглядело так: конструкторы не отслеживали файлы каких деталей оказывались связаны с файлами каких сборок. Эти связи в Solidworks'е не тождественный связям деталей и сборок, и сам Solidworks отслеживает это дело не слишком хорошо, а может наоборот, слишком хорошо, но конструкторы всё равно не знали как. В результате можно было в сборке «Велосипед» поменять что-то в деталях «педаль» и «шатун», а изменялись при этом ещё файлы деталей «рама», «седельный штырь» и «цепь». Если с проектом в 1 момент времени работает 1 человек, качает себе с сервера всю папку с проектом, меняет что-то, потом целиком закачивает обратно, то всё как бы работает. Когда в SVN'е коммитишь только изменения файла педаль.sldprt и шатун.sldprt, то прочие файлы, которые изменились, не будут закоммичены, у тех кто сделает svn update файлы будут конфликтовать. Возможно Solidworks что-то упреждающе рассчитывает, например массу изделия, какие-нибудь геометрические параметры, но это неплохо бы знать конструкторам, и знать где это отключить.

Следующая проблема, использование чего-то момимо Solidworks'а. Конструкторы категорически отказывались понять, что их работа не только Solidworks, поэтому при оформлении коммита неплохо бы не только написать комментарий, но и посылать только значимые файлы (взаимодействие не только с другими конструкторами, но и наблюдение за проектом начальства), не коммитить всякие временные файлы, не коммитить файлы изменённые случайно. Не хотели разбивать свои действия на мелкие коммиты. Ещё проблема, можно открыть деталь, изменить, откатить изменение, сохранить. Вуаля, у нас изменённый файл. Коммитить его? Что важно, для человека эта деталь не изменилась, но не для Solidworks'а. И у кого-то сборка может не собраться из-за таких вот несовместимостей.

Я сейчас смутно помню тот ужас, несколько лет уже прошло. Там проблем целый клубок, PDM часть из них снимает, часть усугубляет. Например при использовании PDM'а изменение шатуна и педали не затронет раму и цепь. То есть один человек может себе забрать шатун и педаль, другой седельный штырь и седло, они будут одновременно работать и не мешать друг другу. Каким-то образом PDM глубоко встраивается в Solidworks (уверен это можно было бы найти в документации к Solidworks, но конструкторы хотели конструировать, а не знать как Solidworks обрабатывает их модели). Но при этом SWR PDM (и большинство других) не умеют работать с чем-то помимо Solidworks'а (Inventor/Компас/вставить нужное). То есть если изделие сколь-нибудь сложное, в проекте участвует ещё электронщик, дизайнер корпуса, дизайнер упаковки, копирайтер слоганов, писатель инструкции, то все эти люди пролетают мимо PDM, им там нет места. git в этом плане универсален, потому что работает с файлами. Если результат работы дизайнера или писателя может быть сохранён в файл, то они могут использовать git. Можно все файлы проекта держать вместе, не отрывать конструкцию от идеи, следить за синхронностью развития, например, конструкции и упаковки.

Но упирается всё равно всё не в ПО, а в людей. Руководство боялось надавить на конструкторов. А сделать надо был всего лишь одно: результаты их работы смотреть только в SVN, строго, всем, и руководству, и снабженцам (которые по чертежам заказывают разные штуки), и заводу (который по чертежам изготавливает), и инженерам (которые по чертежам собирают на месте). Не можешь закоммитить сборку так чтобы снабженцы потом могли её открыть? ССЗБ. Не пишешь комментарии так чтобы начальство понимало чем ты занимаешься? ССЗБ.

В чем заключается сопротивление?

Ну, конкретно git я не внедрял, но с Subversion попытка была. Судя по тому что SVN не взлетел, до git'а тем более не доросли.

Ну так вот, о сопротивлении. Конструкторы категорически отказывались, во-первых, знать как работает их основной инструмент (Solidworks), во-вторых, знать что-то помимо Solidworks'а. Практически это выглядело так: конструкторы не отслеживали файлы каких деталей оказывались связаны с файлами каких сборок. Эти связи в Solidworks'е не тождественный связям деталей и сборок, и сам Solidworks отслеживает это дело не слишком хорошо, а может наоборот, слишком хорошо, но конструкторы всё равно не знали как. В результате можно было в сборке «Велосипед» поменять что-то в деталях «педаль» и «шатун», а изменялись при этом ещё файлы деталей «рама», «седельный штырь» и «цепь». Если с проектом в 1 момент времени работает 1 человек, качает себе с сервера всю папку с проектом, меняет что-то, потом целиком закачивает обратно, то всё как бы работает. Когда в SVN'е коммитишь только изменения файла педаль.sldprt и шатун.sldprt, то прочие файлы, которые изменились, не будут закоммичены, у тех кто сделает svn update файлы будут конфликтовать. Возможно Solidworks что-то упреждающе рассчитывает, например массу изделия, какие-нибудь геометрические параметры, но это неплохо бы знать конструкторам, и знать где это отключить.

Следующая проблема, использование чего-то момимо Solidworks'а. Конструкторы категорически отказывались понять, что их работа не только Solidworks, поэтому при оформлении коммита неплохо бы не только написать комментарий, но и посылать только значимые файлы (взаимодействие не только с другими конструкторами, но и наблюдение за проектом начальства), не коммитить всякие временные файлы, не коммитить файлы изменённые случайно. Не хотели разбивать свои действия на мелкие коммиты. Ещё проблема, можно открыть деталь, изменить, откатить изменение, сохранить. Вуаля, у нас изменённый файл. Коммитить его? Что важно, для человека эта деталь не изменилась, но не для Solidworks'а. И у кого-то сборка может не собраться из-за таких вот несовместимостей.

Я сейчас смутно помню тот ужас, несколько лет уже прошло. Там проблем целый клубок, PDM часть из них снимает, часть усугубляет. Например при использовании PDM'а изменение шатуна и педали не затронет раму и цепь. То есть один человек может себе забрать шатун и педаль, другой седельный штырь и седло, они будут одновременно работать и не мешать друг другу. Каким-то образом PDM глубоко встраивается в Solidworks (уверен это можно было бы найти в документации к Solidworks, но конструкторы хотели конструировать, а не знать как Solidworks обрабатывает их модели). Но при этом SWR PDM (и большинство других) не умеют работать с чем-то помимо Solidworks'а (Inventor/Компас/вставить нужное). То есть если изделие сколь-нибудь сложное, в проекте участвует ещё электронщик, дизайнер корпуса, дизайнер упаковки, копирайтер слоганов, писатель инструкции, то все эти люди пролетают мимо PDM, им там нет места. git в этом плане универсален, потому что работает с файлами. Если результат работы дизайнера или писателя может быть сохранён в файл, то они могут использовать git. Можно все файлы проекта держать вместе, не отрывать конструкцию от идеи, следить за синхронностью развития, например, конструкции и упаковки.

Но упирается всё равно всё не в ПО, а в людей. Руководство боялось надавить на конструкторов. А сделать надо был всего лишь одно: результаты их работы смотреть только в SVN, строго, всем, и руководству, и снабженцам (которые по чертежам заказывают разные штуки), и заводу (который по чертежам изготавливает), и инженерам (которые по чертежам собирают на месте). Не можешь закоммитить сборку так чтобы снабженцы потом могли её открыть? ССЗБ. Не пишешь комментарии так чтобы начальство понимало чем ты занимаешься? ССЗБ.

В чем заключается сопротивление?

Ну, конкретно git я не внедрял, но с Subversion попытка была. Судя по тому что SVN не взлетел до git'а тем более не доросли.

Ну так вот, о сопротивлении. Конструкторы категорически отказывались, во-первых, знать как работает их основной инструмент (Solidworks), во-вторых, знать что-то помимо Solidworks'а. Практически это выглядело так: конструкторы не отслеживали файлы каких деталей оказывались связаны с файлами каких сборок. Эти связи в Solidworks'е не тождественный связям деталей и сборок, и сам Solidworks отслеживает это дело не слишком хорошо, а может наоборот, слишком хорошо, но конструкторы всё равно не знали как. В результате можно было в сборке «Велосипед» поменять что-то в деталях «педаль» и «шатун», а изменялись при этом ещё файлы деталей «рама», «седельный штырь» и «цепь». Если с проектом в 1 момент времени работает 1 человек, качает себе с сервера всю папку с проектом, меняет что-то, потом целиком закачивает обратно, то всё как бы работает. Когда в SVN'е коммитишь только изменения файла педаль.sldprt и шатун.sldprt, то прочие файлы, которые изменились, не будут закоммичены, у тех кто сделает svn update файлы будут конфликтовать. Возможно Solidworks что-то упреждающе рассчитывает, например массу изделия, какие-нибудь геометрические параметры, но это неплохо бы знать конструкторам, и знать где это отключить.

Следующая проблема, использование чего-то момимо Solidworks'а. Конструкторы категорически отказывались понять, что их работа не только Solidworks, поэтому при оформлении коммита неплохо бы не только написать комментарий, но и посылать только значимые файлы (взаимодействие не только с другими конструкторами, но и наблюдение за проектом начальства), не коммитить всякие временные файлы, не коммитить файлы изменённые случайно. Не хотели разбивать свои действия на мелкие коммиты. Ещё проблема, можно открыть деталь, изменить, откатить изменение, сохранить. Вуаля, у нас изменённый файл. Коммитить его? Что важно, для человека эта деталь не изменилась, но не для Solidworks'а. И у кого-то сборка может не собраться из-за таких вот несовместимостей.

Я сейчас смутно помню тот ужас, несколько лет уже прошло. Там проблем целый клубок, PDM часть из них снимает, часть усугубляет. Например при использовании PDM'а изменение шатуна и педали не затронет раму и цепь. То есть один человек может себе забрать шатун и педаль, другой седельный штырь и седло, они будут одновременно работать и не мешать друг другу. Каким-то образом PDM глубоко встраивается в Solidworks (уверен это можно было бы найти в документации к Solidworks, но конструкторы хотели конструировать, а не знать как Solidworks обрабатывает их модели). Но при этом SWR PDM (и большинство других) не умеют работать с чем-то помимо Solidworks'а (Inventor/Компас/вставить нужное). То есть если изделие сколь-нибудь сложное, в проекте участвует ещё электронщик, дизайнер корпуса, дизайнер упаковки, копирайтер слоганов, писатель инструкции, то все эти люди пролетают мимо PDM, им там нет места. git в этом плане универсален, потому что работает с файлами. Если результат работы дизайнера или писателя может быть сохранён в файл, то они могут использовать git. Можно все файлы проекта держать вместе, не отрывать конструкцию от идеи, следить за синхронностью развития, например, конструкции и упаковки.

Но упирается всё равно всё не в ПО, а в людей. Руководство боялось надавить на конструкторов. А сделать надо был всего лишь одно: результаты их работы смотреть только в SVN, строго, всем, и руководству, и снабженцам (которые по чертежам заказывают разные штуки), и заводу (который по чертежам изготавливает), и инженерам (которые по чертежам собирают на месте). Не можешь закоммитить сборку так чтобы снабженцы потом могли её открыть? ССЗБ. Не пишешь комментарии так чтобы начальство понимало чем ты занимаешься? ССЗБ.