[hwd]

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

но... этот подход плох по следующим причинам:
1. если мне нужно обновить какой-то плагин или шаблон, то я не могу это сделать до тех пор, пока все пользователи, загрузившие этот плагин, не завершат сеансы своей работы, или до тех пор, пока пользователи, создавшие чертёж, на основании шаблона, не сохранят его под некоторым именем.
2. для dotnet-плагинов НА КАЖДОМ КОМПЬЮТЕРЕ я должен С ПРАВАМИ АДМИНА один раз вызвать некоторую команду, с определёнными параметрами, дабы фрэймворк позволил запускать плагин, расположенный не на локальной машине (это зашито в политику безопасности фрэймоворка - он сеть воспринимает как источник угрозы).
3. Временами права, назначенные в п.2 почему-то перестают работать. Повторная инициализация прав не даёт результата. Приходится давать права с др. уровнем доступа. Но это не дело, ибо х.з. когда и почему могут отвалиться права и с этим уровнем доступа.
Поясню на конкретном примере:
Если изначально это:
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe" -m -ag 1.2 -url "file://\\hyprostroy/dfs/SystemFolder/tools/AutoCAD tools/AcadPlagins/*" FullTrust
давало нужное разрешение, и всё прекрасно запускалось, то на некоторых машинах, разрешение вдруг ни с того ни с сего переставало работать. повторный запуск выше приведённой строки положительного результата не давал. Но если её немного изменить, запустив такой вариант:
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe" -m -ag 1 -url "file://\\hyprostroy/dfs/SystemFolder/tools/AutoCAD tools/AcadPlagins/*" FullTrust
всё снова начинает работать. Не хочется ждать, когда и для "1" перестанет работать...
Если дотнет библиотеки будут расположены на локальной машине, то проблемы пунктов 2 и 3 автоматом отпадают.
4. Временами юзеры сталкиваются с тем, что в чертеже вдруг шрифты начинают отображаться неверно - показывают симплекс, вместо нужного. Оно и понятно: симплекс установлен как используемый по умолчанию. В таком случае я советую перегрузить автокад. Как правило это помогает, но бывали неоднократные случаи, когда симплекс видимо насильно прописывался в свойствах примитивов, хотя в их свойствах фигурирует нужный мне текстовый стиль, а тот имеет нужный шрифт. Думаю, что проблема отображения шрифтов связана с перебоями в сети. Но то, что временами шрифт не удавалось вернуть обратно - это очень хреново. Т.о. делаю вывод, что шрифты лучше хранить на локальной машине.

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

я написал код, который это выполняет, протестировал, на небольших объёмах данных - остался доволен результатом. Но, как оказалось - рано радовался:
У меня в репозитории имеется два каталога, в которых хранятся файлы шрифтов и штриховок...
Это маленькие файлы, но их ОЧЕНЬ много:
Шрифтов - 334 шт.
Штриховок - 677 шт.

Синхронизацию файлов я произвожу путём сверки их хешей по алгоритму MD5. При таком количестве файлов синхронизация занимает от 20 сек до почти минуты... Это слишком долго. Кроме того, порой синхронизация не удаётся, т.к. может вылететь такое сообщение:

Сообщение от Обнаружено событие ContextSwitchDeadlock Message: CLR не удалось перейти из COM-контекста 0x183f18 в COM-контекст 0x183da8 за 60 секунд. Наиболее вероятно, что поток, владеющий контекстом/апартаментом назначения, находится в режиме ожидания или выполнения очень длительной операции без прокачки сообщений Windows. Обычно эта ситуация отрицательно влияет на производительность и даже может привести к зависанию приложения или чрезмерному расходованию памяти. Чтобы избежать этой проблемы, все потоки однопоточного апартамента (STA) должны использовать примитивы ожидания для прокачки (например, CoWaitForMultipleHandles) и периодически прокачивать сообщения во время длительных операций.

Т.о. и второй мой вариант меня не устраивает... Я подумал о третьем варианте:

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

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

т.о. если кратко, то мне нужно придумать, как решить приведённые мною выше 4 пункта. Пока что я думаю реализовать два репозитория (серверный и локальный) и выполнить механизм синхронизации. Но подводные камни этого решения я указал выше. Может у кого-то есть более лучшая идея? буду признателен за неё.

[Дима_]

Сообщение от hwd я написал код, который это выполняет, протестировал, на небольших объёмах данных - остался доволен результатом... ... Шрифтов - 334 шт. Штриховок - 677 шт. ... Синхронизацию файлов я произвожу путём сверки их хешей по алгоритму MD5. При таком количестве файлов синхронизация занимает от 20 сек до почти минуты... Это слишком долго.

Все то-же самое, но использовать 1 за'zip'ованный архив - при запуске - проверяешь его md5 - не совпал со своим - перезагрузка, распаковка.

[hwd]

Сообщение от Дима_ использовать 1 за'zip'ованный архив

Сиба, попробую сегодня.

[Лиспер]

Дополнительно: почему бы не объединить все штриховки в общий файл acadiso.pat?

[hwd]

Сообщение от Лиспер почему бы не объединить все штриховки в общий файл acadiso.pat?

так и сделаю - солью программно в один файл и назову acadiso+.pat

[ShaggyDoc]

Да, уж - "горе от ума"
Решение размещать все локально - правильное. Я давно к нему пришел.

Но далее:

1. Зачем автоматически синхронизировать локальный репозиторий с серверным? Да еще при каждом запуске Автокада? Где гарантия, что на сервере библиотеки "правильно исправлены"? Да и зачем все это непрерывно править? Это никогда к хорошим результатом не приводило.

А правильный путь известен - периодическое обновление по инициативе администратора.

2. Зачем при синхронизации сверять хэши? Да просто заменяйте файлы (можно только обновленные). Разумеется те, которые юзерам запрещено изменять.

3. Зачем столько файлов шрифтов и штриховок? Шрифтов - 334 шт!
Штриховок - 677 шт! Кому столько надо? Да не более 5 шрифтов достаточно, чтобы обеспечить "полную демократию". А кому нужны столько штриховок? Вот у меня в ruCAD все мыслимые (предусмотренные стандартами) штриховки, включая топографию, занимают 39 кб в одном файле и он не пополнялся уже лет 10.

То же, наверное, и с другими библиотечными элементами...

[Дима_]

Вариант второй - пользователь вначале грузит только для чтения xml (БД? - не суть) - где расписаны сетевые пути файлов настроек и в соответствии с ним идет конфигурация автокада - надо поменять - сделал новый каталог - переправил xml, а через недельку старый стер. Тогда и репризиторий не нужен.

[hwd]

Сообщение от ShaggyDoc 1. Зачем автоматически синхронизировать локальный репозиторий с серверным? Да еще при каждом запуске Автокада? Где гарантия, что на сервере библиотеки "правильно исправлены"?

Дело в том, что на мой взгляд (с позиции администратора CAD), гораздо удобней, когда администратор внеся изменения в репозиторий на сервере, не будет думать о том, что теперь нужно дать команду локальным машинам синхронизироваться с сервером. Если изменения применяются на локальных машинах автоматически - на мой взгляд это очень удобно.

Сообщение от ShaggyDoc Да и зачем все это непрерывно править? Это никогда к хорошим результатом не приводило.

Непрерывно править никто и не будет. Я не так часто выполняю обновления на сервере. Если библиотека будет "исправлена неправильно", то я её либо вовсе исключу из серверного репозитория (в этом случае при запуске автокада она будет удалена и с локальных машин), либо заменю её на более "правильную", если такая версия имеется на руках. Кроме того мой сериализатор не занимается бездумным, полным копированием с сервера всего подряд: его задача - приводить локальный репозиторий в полное соответствие серверному (с минимальными затратами), удаляя лишнее, добавляя недостающее и изменяя обновлённое (чтобы как можно меньший объём информации гонять по сети), но никак не перезаписывая всё подряд (имхо - затратно).

Сообщение от ShaggyDoc А правильный путь известен - периодическое обновление по инициативе администратора.

Абсолютно согласен, поэтому у меня администратор имеет возможность управления процессом синхронизации. Вот фрагмент из общего конфигурационного файла:

  <!--Каталоги, которые необходимо синхронизировать между собой.-->
  <Synchronization SendRegistrationInfo="true" SynchronizeWithServer="true" SendSynchronizationInfo="true" StartingLoader="true">
    <!--Каталог, в котором содержится информация, специфичная для конкретной версии AutoCAD-->
    <SynchDir>
      <!--Каталог-источник-->
      <SourceDir>%GPSM.ServerDir%\%GPSM.AcadDirName%\etc</SourceDir>
      <!--Целевой каталог-->
      <TargetDir>%GPSM.LocalCommonDir%\%GPSM.AcadDirName%\etc</TargetDir>
    </SynchDir>
    <!--Каталог, в котором содержится информация, используемая в любой версии AutoCAD-->
    <SynchDir>
      Каталог-источник
      <SourceDir>%GPSM.ServerDir%\Common</SourceDir>
      Целевой каталог
      <TargetDir>%GPSM.LocalCommonDir%\Common</TargetDir>
    </SynchDir>   
  </Synchronization>

В приведённом выше фрагменте, если атрибуту SynchronizeWithServer назначить значение false - синхронизация не будет производиться.

Сообщение от ShaggyDoc 2. Зачем при синхронизации сверять хэши? Да просто заменяйте файлы (можно только обновленные). Разумеется те, которые юзерам запрещено изменять.

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

Сообщение от ShaggyDoc 3. Зачем столько файлов шрифтов и штриховок? Шрифтов - 334 шт! Штриховок - 677 шт! Кому столько надо? Да не более 5 шрифтов достаточно, чтобы обеспечить "полную демократию". А кому нужны столько штриховок? Вот у меня в ruCAD все мыслимые (предусмотренные стандартами) штриховки, включая топографию, занимают 39 кб в одном файле и он не пополнялся уже лет 10. То же, наверное, и с другими библиотечными элементами...

Да честно говоря... Я как плюшкин насобирал их, дабы не было проблем с теми чертежами, которые нам присылают (часто забывают приложить нестандартный шрифт, если он используется). И штриховки насобирал всё до кучи...

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

Сообщение от Дима_ Вариант второй - пользователь вначале грузит только для чтения xml (БД? - не суть) - где расписаны сетевые пути файлов настроек и в соответствии с ним идет конфигурация автокада - надо поменять - сделал новый каталог - переправил xml, а через недельку старый стер. Тогда и репризиторий не нужен.

По сути у меня так и сделано - в xml-файле можно изменить путь, указав иной каталог репозитория, но в этом случае не решаются проблемы из пунктов 2,3 и 4.

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

Такой подход однозначно на несколько порядков увеличит скорость синхронизации. Нужно посмотреть сколько времени уйдёт на распаковку - это самое узкое место в данном подходе...

Сейчас буду пробовать. Всем спасибо за идеи и замечания!

[gomer]

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

[Vildar]

Сообщение от ShaggyDoc Решение размещать все локально - правильное. Я давно к нему пришел.

Можно основные моменты. Почему?
Или, если в "Сапр на базе" этот момент разжеван, тогда не надо, посмотрю сам.

Добавлено
Интересуют файлы: шаблонов dwt, стандарта dst, подшивки dst, палитр инструментов atc, плоттеров pc3 + pmp, стилей печати ctb + stb, блоки для палитр инструментов, типы линий lin и их форм shx.
Вот эти файлы настроек, сильно хочется хранить на сервере, и прописать в профиле акада к ним пути. Так проще будет контролировать их, вносить изменения.
При локальном хранении - придется обегать всех пользователей и проверять/обновлять.

Про расположение своих dll, склоняюсь к локальной загрузке их в акад, и организации обновления с сервера. Детальной реализации нет.
Эта тема убеждает поступить именно так. Спасибо Андрею )

[Дима_]

Сообщение от hwd Нужно посмотреть сколько времени уйдёт на распаковку - это самое узкое место в данном подходе...

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

[hwd]

>gomer
В рамках организации существует "Стандарт по работе с AutoCAD". Администратор CAD формирует серверный репозиторий так, чтобы он был заточен под максимально удобную работу в соответствии с требованиями указанного документа. Плодить версии - имхо не есть хорошо. Решение об обновлении принимает администратор CAD. Если такое решение принято - оно будет выполнено сразу для всех пользователей. "Мусора" (с) в чертежах не будет, т.к. они просто обязаны создаваться в соответствии с требованиями обозначенного выше стандарта.
На сервере существует HelpDesk, на который пользователи могут отправлять замечания/пожелания по работе GPSM.CAD.

Демократии не будет.
Если бы была возможность запретить пользователю загрузку плагинов не из репозитория - я бы и это сделал. Хотите использовать в своей работе стороннюю библиотеку? Через браузер оставьте заявку в HelpDesk (размещён на сервере) о том, что есть такой-то полезный модуль, делает то и то. Администратор CAD просмотрит этот модуль, сообщит о вашем предложении группе наиболее продвинутых пользователей (являющихся своего рода назначенной комиссией) и если те согласятся, что модуль действительно интересен - он будет добавлен в серверный репозиторий и станет доступным сразу для всех пользователей. Параллельно будет добавлена информация в справку по GPSM.CAD о добавленном модуле и его функционале.

DotNet программистам: если кого интересует тема упаковки/распаковки - здесь выложена интересная библиотека. В архиве имеется и файл справки, в котором определены разделы C# и VB.NET с подробными примерами кода.
Очень удобная штука (имхо).

[CB]

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

Это скорее всего правильно.

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

Почему бы в автозагрузку не поставить прогу, которая обновляла с сервера на локальном компьютере репозиторий только при загрузке/перезагрузке компа...

[hwd]

Сообщение от CB Почему бы в автозагрузку не поставить прогу, которая обновляла с сервера на локальном компьютере репозиторий только при загрузке/перезагрузке компа...

Думал над таким вариантом - не понравился. Предположим добавили в репозиторий библиотеку, разослали по почте сообщение, в котором предлагается опробовать её в работе. Пользователи начали пробовать, обнаружили ошибку, сообщили об этом админу CAD. Тот вытащил "кривую софтину" из репозитория. Юзер работает в той же сессии в автокаде и может продолжать испытывать последствия тестированной библиотеки. Причём чтобы она более не мешала - её нужно выгрузить. Что проще, перезапустить автокад, или перезапустить перемещаемый профиль пользователя windows? имхо гораздо проще перегрузить автокад.

[gomer]

Сообщение от hwd Демократии не будет.

А если мне не нужна в данный момент какая-то библиотека? или часть библиотек? Кто-то делает КМ, кто-то КМД, КЖ, АС... ЗАчем обновляться если все и так работает хорошо... Стандарты стандартами... это должно быть глубже... а каие библиотеки мне загружать я хочу решать сам...хоть с локальной, хоть с сетевой машины...

[hwd]

Сообщение от gomer А если мне не нужна в данный момент какая-то библиотека? или часть библиотек? Кто-то делает КМ, кто-то КМД, КЖ, АС... ЗАчем обновляться если все и так работает хорошо... Стандарты стандартами... это должно быть глубже... а каие библиотеки мне загружать я хочу решать сам...хоть с локальной, хоть с сетевой машины...

Есть несколько конфигурационных файлов:
1. общий конфигурационный файл.
2. конфигурационный файл конкретной доменной группы.
3. конфигурационный файл конкретного пользователя.

(1) влияет на всех доменных пользователей. В нём так же прописана загрузка тех модулей, которые нужны всем пользователям.
(2) влияет на пользователей конкретной доменной группы. В нём так же перечисляется набор модулей, которые должны грузиться всем членам этой доменной группы.
(3) - это настройки пользователя. В этом файле юзер указывает, какие библиотеки должны грузиться (помимо тех, что обозначены в (1) и (2)).

Загрузчик грузит библиотеки последовательно: сначала обозначенные в (1), затем обозначенные в (2) и наконец - в (3).
Но требование стандарта - разрешается загружать только то, что существует в рамках репозитория.
Т.о. никто не запрещает вам настраивать загрузку (точнее её часть) в соответствии с вашим желанием.

файл (2) может править руководитель этой группы.

[Александр Ривилис]

Сообщение от CB Почему бы в автозагрузку не поставить прогу, которая обновляла с сервера на локальном компьютере репозиторий только при загрузке/перезагрузке компа...

Именно так я и поступил. И кроме того вывел на рабочий стол ярлык на эту прогу (точнее она сама создает ярлык на рабочем столе на саму себя при первом запуске). Так что теперь достаточно выйти из AutoCAD, клацнуть по ярлыку и готово.

[Vildar]

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

[hwd]

Сообщение от Александр Ривилис Именно так я и поступил. И кроме того вывел на рабочий стол ярлык на эту прогу (точнее она сама создает ярлык на рабочем столе на саму себя при первом запуске). Так что теперь достаточно выйти из AutoCAD, клацнуть по ярлыку и готово.

Я указал, почему этот вариант мне не нравится.
Ещё ситуация:
работает за компьютером бабулька. Клацнула ваш ярлык обновления и затем клацнула ярлык автокада. Одно приложение синхронизирует данные с сервером, а другое, в это же время грузит данные в AutoCAD. Если синхронизатор не успеет сделать своё дело до того, как автокад начнёт грузить плагины, мы с большой долей вероятости получим Exception, когда синхронизатор попытается перезаписать библиотеку, уже загруженную в AutoCAD.

[gomer]

Сообщение от hwd Есть несколько конфигурационных файлов: 1. общий конфигурационный файл. 2. конфигурационный файл конкретной доменной группы. 3. конфигурационный файл конкретного пользователя. (1) влияет на всех доменных пользователей. В нём так же прописана загрузка тех модулей, которые нужны всем пользователям. (2) влияет на пользователей конкретной доменной группы. В нём так же перечисляется набор модулей, которые должны грузиться всем членам этой доменной группы. (3) - это настройки пользователя. В этом файле юзер указывает, какие библиотеки должны грузиться (помимо тех, что обозначены в (1) и (2)). Загрузчик грузит библиотеки последовательно: сначала обозначенные в (1), затем обозначенные в (2) и наконец - в (3).

Вы все с ног на голову перевернули... так жить нельзя... каждому юзеру нужно определеннное количество настроек, он их определяет в (3), остальные являются "по умолчанию"... для системы нужны все поэтому недостающие она должна брать из (2) и (1) по очереди... Такая система более гибкая... хотя, не скрою, возможно, в таком случае вероятность поломки выше... в принципе хватило бы только 3 + кнопка "вернуть как было"
Или так... на локальной машине профиль пользователя и клиент загрузчик... все...
клиент загружает в акад то, что написано в пользовательском профиле, (по необходимости докачивает с сервера или синхронизирует локальный "репозиторий")...
программа-сервер управляет "репозиторием" на сервере... и не касается локальных машин...
В таком случае юзера можно и отфутболить... а сервер не зависнет... и шустрее работать будет
Это и есть демократия... вот написал... и подумал... что гдетто я это встречал уже..

[hwd]

Сообщение от gomer каждому юзеру нужно определеннное количество настроек, он их определяет в (3), остальные являются "по умолчанию"... для системы нужны все поэтому недостающие она должна брать из (2) и (1) по очереди... Такая система более гибкая... хотя, не скрою, возможно, в таком случае вероятность поломки выше...

Ну перечислили вы мои три пункта в обратном порядке, а разница-то в чём? Грузить сначала с (1), потом с (2), потом с (3) или наоборот: грузить с (3) потом с (2), потом с (3) - разницы никакой. Тем более, что загрузка начинается только после того как будет составлен полный список загружаемых файлов (собранный из всех трёх конфигурационных файлов) и отброшены дублирующиеся записи.
И какая тут "вероятность поломки"? Которая к тому же почему-то выше (этого вообще не понял)...

Сообщение от gomer Или так... на локальной машине профиль пользователя и клиент загрузчик... все... клиент загружает в акад то, что написано в пользовательском профиле, (по необходимости докачивает с сервера или синхронизирует локальный "репозиторий")... программа-сервер управляет "репозиторием" на сервере... и не касается локальных машин... В таком случае юзера можно и отфутболить... а сервер не зависнет... и шустрее работать будет Это и есть демократия... вот написал... и подумал... что гдетто я это встречал уже..

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

Сообщение от gomer Вы все с ног на голову перевернули... так жить нельзя...

Без комментариев...

[gomer]

Сообщение от hwd Под словом "сервер" я понимаю не дохлый x386, поэтому он однозначно не зависнет.

Подсервером я понимаю программу, а не железо, вне зависимости от платформы...

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

Тогда не задавайте глупых вопросов...

зы

Сообщение от hwd Ну перечислили вы мои три пункта в обратном порядке, а разница-то в чём? Грузить сначала с (1), потом с (2), потом с (3) или наоборот: грузить с (3) потом с (2), потом с (3) - разницы никакой. Тем более, что загрузка начинается только после того как будет составлен полный список загружаемых файлов (собранный из всех трёх конфигурационных файлов) и отброшены дублирующиеся записи.

Если настроить (3) как нужно (2) и (1) можно не проверять... это экономит время...

Сообщение от hwd Которая к тому же почему-то выше (этого вообще не понял)...

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

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

[Pastor]

А почему нельзя без всяких MD5-хэшев просто сравнивать время последней модификации файла на сервере и файла в локальном кэше.?

[hwd]

Сообщение от gomer Если настроить (3) как нужно (2) и (1) можно не проверять... это экономит время...

доступ на запись к (1) имеет только админ. каждый руководитель группы имеет доступ на запись к (2) именно этой группы. Доступ на запись в (1) имеет только пользователь, являющийся его владельцем. Имхо - это правильное разделение "территории". Если всё будет в одном файле (согласно вашему заявлению) - разграничения прав доступа не получится (вариант с шифрованием разделов в теле xml-файла не рассматриваю, хотя, при желании, можно воспользоваться X.509).

Сообщение от gomer Тогда не задавайте глупых вопросов...

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

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

Какой юзер? Куда ткнёт? Хватит ерунду писать.

Сообщение от Pastor А почему нельзя без всяких MD5-хэшев просто сравнивать время последней модификации файла на сервере и файла в локальном кэше.?

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

[Дима_]

Сообщение от hwd Сравнение хешей - самый надёжный способ проверки файлов на идентичность

ну не считая сравнения целиком

[ShaggyDoc]

Вообще не понимаю, что такое администратор САД??? Вот Администратор сети - понимаю, а САД не понимаю... Да юзеру о вас 100 лет не знать и он будет работать... Он и в голом акаде будет работать... А если все работа будет двумя кнопками делаться, то он и вовсе себя не нужным почувствует и обозлится на вас.

Администратор CAD - чрезвычайно необходимая фигура. Замечательно, что у hwd это есть. Именно он и должен обеспечить, чтобы у юзеров всё было "двумя кнопками". Это не "администратор сети" (сисадмин) - у того совсем другие задачи и он может вообще мало чего понимать в AutoCAD - для него это "процесс". Но системный администратор и администратор САПР должны тесно взаимодействовать.

Серьезное проектирование можно сравнить с конвейерным производством. Там нет места кустарям-одиночкам. Все должны работать по единым стандартам предприятия, с едиными программами, библиотеками. Нету здесь места "демократии". Такие порядки, конечно не нравятся "слесарям-интеллигентам" наподобие незабвенного В.М. Полесова.

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

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

При синхронизации надо использовать ZIP, причем с небольшим сжатием (средним). Даже если вообще не сжимать, то операции упаковки-распаковки занимают времени намного меньше, чем при множестве файлов. Ведь каждый файл надо записать в таблицу, присвоить атрибуты и прочее. Это независимо от организации самого процеса. Попробуйте хотя бы синхронизировать с помощью TotalCommander - разница очевидна.

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

Можно основные моменты. Почему? Или, если в "Сапр на базе" этот момент разжеван, тогда не надо, посмотрю сам.

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

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

Такое надо искоренять, но не в моей власти у всех пользователей ruCAD. Этим как раз и должны заниматься администраторы САПР. Поэтому в итоге всё значительно упростил, оставил локальную работу.

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

[hwd]

Сообщение от Дима_ ну не считая сравнения целиком

Я никому не навязываю проверку идентичности именно с помощью сверки хешей по алгоритму MD5, это лично мой выбор и данный способ меня устраивает. Если вам больше нравится побитовая сверка файлов - сверяйте, дело ваше. Да и вообще топик-то не на эту тему

Сообщение от ShaggyDoc При синхронизации надо использовать ZIP, причем с небольшим сжатием (средним). Даже если вообще не сжимать, то операции упаковки-распаковки занимают времени намного меньше, чем при множестве файлов. Ведь каждый файл надо записать в таблицу, присвоить атрибуты и прочее. Это независимо от организации самого процеса. Попробуйте хотя бы синхронизировать с помощью TotalCommander - разница очевидна.

Спасибо. Сегодня реализую это. О результатах (скорости синхронизации) отпишусь.

Offtop: п.с. Плохо, что в AutoCAD 2009 нельзя использовать .Net Framework 4.0 - можно было бы с помощью PLINQ раскидать процесс синхронизации не только по разным потокам, но и по процессорам - прирост в скорости был бы значительный... (((

[Дима_]

Сообщение от hwd Я никому не навязываю проверку идентичности именно с помощью сверки хешей по алгоритму MD5,

Да пошутил я, конечно правильней по хешу.

[Pastor]

Сравнение хешей - самый надёжный способ проверки файлов на идентичность. Это не так затратно по ресурсам и времени, как вы можете подумать

Всё познаётся в сравнении. Может проверка времени последней модификации окажется еще мене затратной? А вдруг, в разы менее затратной?

[hwd]

Сообщение от Pastor Всё познаётся в сравнении. Может проверка времени последней модификации окажется еще мене затратной? А вдруг, в разы менее затратной?

Можете не гадать, а попробовать, если у вас есть такое желание.
Дело ведь не только в скорости, но и в достоверности проверки.

[Pastor]

Можете не гадать, а попробовать, если у вас есть такое желание.

А разве я автор темы? И если вы уже пробовали и знаете результат, то почему об этом нельзя просто сказать, без наездов.

Дело ведь не только в скорости, но и в достоверности проверки.

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

[Александр Ривилис]

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

Тут есть нюансы и с логикой работы, и с синхронизацией времени PC<->сервер.

[hwd]

Сообщение от Pastor Если файл на сервере модифицирован позднее, чем тот же файл, имеющийся на локальной машине, то значит требуется его скопировать и провести замену. Проблем с достоверностью не вижу.

А если новый файл оказался "кривым" и следует откатиться к прежней версии?

Сообщение от Pastor А разве я автор темы? И если вы уже пробовали и знаете результат, то почему об этом нельзя просто сказать, без наездов.

Я не "наезжаю" - выше уже писал, что отдаю предпочтение сравнению хешей по MD5, а сравнение дат модификации мне не интересно, поскольку не считаю его достаточно надёжным (имхо).

[Pastor]

А если новый файл оказался "кривым" и следует откатиться к прежней версии?

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

[zamtmn]

hwd
Рассмотрите возможность применения для синхронизации какой либо системы контроля версий, например SVN. Это конечно лишняя зависимость, но вопросы типа кривых файлов и времени модификации отпадут сами собой

[hwd]

Сообщение от zamtmn hwd Рассмотрите возможность применения для синхронизации какой либо системы контроля версий, например SVN. Это конечно лишняя зависимость, но вопросы типа кривых файлов и времени модификации отпадут сами собой

Интересная тема, почитаю, спасибо!

[ShaggyDoc]

Системы контроля версий чрезвычайно полезная вещь, но для разработчиков.

Заменять что-то "автоматом" у конечных пользователей я не советую. Непременно будет выясняться, что в новых версиях появились какие-то ошибки, не замеченные автором. Одно заработало лучше, а другое перестало. Авторы всегда неправильно тестируют свою работу - подходят с позиции доказать, что работает. А у юзеров свой подход, они выявляют множество ошибок. Потому каждая программа и имеет несметное количество промежуточных версий. И про каждую авторы думали, что вот эта - окончательно вылизана.

Я бы советовал иметь одного доверенного юзера-тестировщика. Вот с ним можно и синхронизировать. А уж когда и через него отработано - всем другим. Но по-простому, не заморачиваясь сравнениями. Заменять всё, за исключением файлов, специально предназначенных для пользовательских настроек.

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

[hwd]

Сообщение от ShaggyDoc Но по-простому, не заморачиваясь сравнениями. Заменять всё, за исключением файлов, специально предназначенных для пользовательских настроек. Да и здесь путь известный - создание инсталлятора, который, при необходимости, будет делать и обновления. Он знает, как это делать, надо только в сценарии задать, и не тратить силы на изобретения. Вот инсталлятор может и в сети лежать. А наличие разных версии инсталляторов позволяет и откатить установленное до любого уровня.

Честно говоря, изначально я надеялся, что сверка хешей поможет сэкономить время, т.к. придётся копировать не всё подряд, а лишь выборочные файлы. Но пока что результаты моих тестов сводятся к тому, что банальная замена всего подряд (распаковывая из несжатого zip-архива) выполняется быстрее. (((
Здесь выложил один из тестов. Результат не порадовал...
ShaggyDoc, я так понял, что ваш инсталлятор заменяет абсолютно всё, а не выборочные файлы?
Пожалуй да, с инсталлятором и заменой всего - самый простой и надёжный вариант будет. И всё же мне жаль, что идея с проверкой хешей не подошла... (((

[ShaggyDoc]

Но пока что результаты моих тестов сводятся к тому, что банальная замена всего подряд (распаковывая из несжатого zip-архива) выполняется быстрее

Ну так я сразу так советовал.

я так понял, что ваш инсталлятор заменяет абсолютно всё, а не выборочные файлы?

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

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

[hwd]

Если кому интересно - алгоритм решения по синхронизации локального репозитория с серверным, а так же пример его использования - здесь и здесь.