Загадочная мистика с моделью сборки.

[Валерий Изранов]

Чувствуется что Олеся немного о другом написала.

[ITE]

прямо мистика и ужасы

[IgorT]

Мистическое шоу продолжилось. А может и не мистическое и не шоу. Надо определиться.
Значит так. Делал работу над моделью некой сборки... По окончанию раб.дня по честному сохранил свои файлы.
Утром открываю сборку, а там нету того, что вчера было сделано! Смотрю на время сохранения сборки. Оно на 20 минут позже, че я её сохранял вечером.
Оказывается, коллега задержался и сохранил главную сборку, куда входим мой узел уже после того, как я закрыл его у себя.
В результате мои файлы были перезаписаны. Хорошо, что делаю архиватором копию своих файлов и получилось восстановить.
Но это хорошо, что заметил. Иначе не известно к чему могло бы привести в дальнейшем отсутствие некоторых операций в моём узле.
Сталкивался кто с подобным? Системы управления проектами решают подобные конфузы?
Может быть достаточно установит различные права доступа к папкам?

[IgorT]

Ситуация повторилась.
То есть в подузле, входящим в некую сборку вновь пропала работа целого дня.
Есть предположение, что это неприятное явление связано с очерёдностью закрытия файлов. если головная сборка закрывается после закрытия входящих в неё подузлов, то иногда файлы подузлов перезаписываются и работа в них теряется. То есть надо следить, что бы главная сборка закрывалась первой, а потом входящие в неё узлы согласно вложенности.

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