Хотелось бы поднять эту тему, думаю она актуальна для многих администраторов ИРБИСа.
ИРБИС - очень хорошая библиотечная система, многие ее достоинства с лихвой перекрывают некоторые недостатки. Но есть один недостаток, который меня, как человека администрирующего рабочие места с ИРБИС, немного напрягает. Немного, потому что я пытаюсь с ним смириться, но не достаточно немного, чтобы о нем молчать.

Суть: для пользователя системы (читай администратора) отсутствуют механизмы определения конкретной версии системы с точностью до обновления.
Дело в том, что версия 2012.1 или 2011.1 не отражает конкретного набора исполняемых файлов системы, ведь уже вышло несколько обновлений, каждое из которых чем-то да и отличается. Если возникают проблемы, то пользователь не всегда в состоянии определить из какого обновления ему достались исполяемые файлы. Максимум он способен указать 2012.1, потому что это видно в главном (или не всегда в главном) окне АРМа.

Предложение минимум: хотябы увеличивать последнее число главной версии при обновлении, например, 2012.2, 2012.5.
Предложение максимум: ввести в состав номера версии номер билда, отображать полный номер в диалоге "О программе", включить номер версии в качестве ресурса в исполяемый файл, чтобы в свойствах файла было видно его номер версии. Номер версии сделать, например, в формате 2012.1.45, где 45 - конкретный билд.

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

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

Вторая часть версирования касается текстовых файлов. Тут тяжелее всего. Иногда только дата позволяет определить, что новее.
Я понимаю, что ИРБИС система открытая, открытая в плане возможности адаптации и настройки под конкретные нужды библиотек. Причем адаптация может идти постоянно и так сказать "на лету". Но если используются стандартные форматы или справочники из дистрибутива и обновлений, то хотелось бы иметь возможность сравнения (или определения) их версий.
Например, было бы удобно иметь в виде комментария номер версии файла и дату его модификации (обновления) у разработчика.

Я понимаю, что моя просьба слишком глобальна, просто я привык работать с системами контроля версий (например, CVS, SVN, git) и полным автоматизированным контролем версий файлов исходных текстов (с использованием автоматического версирования исполяемых файлов и т.п.). Возможно, этим я избалован, но я был бы очень признателен, если бы хотябы что-нибудь из вышесказанного было бы принято и реализовано в ИРБИСе.

Спасибо.

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



Редактировано 1 раз. Последний раз 16.10.2013 12:59 пользователем Zmiter.

Вопрос сложный. Решить - нереально. Максимальное - версии запускаемых модулей и dll, остальное - всегда остается на совести конкретного администратора.
Дело в том, что после года-двух "извращений" над дистрибутивом ИРБИСа "от разработчика", появляется такое "собрание локальных технологий от местных идеологов библиотечного движения", что как версию дистрибутива не обзови, все равно не попадешь ни в какую.
Может стоит просто по дате изменения запускаемых файлов ориентироваться? У меня это проходит и работает уже много лет.

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