1c нет файла контроля версий config txt
В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.
В чем проблема:
- Этот файл должен находиться под версионным контролем, так как в нем содержатся «общие» настройки. Ну и сама структура файла ценна.
- Каждый разработчик меняет уровень логирования под свои нужды и не хочет, чтобы эти изменения попадали в коммиты, и тем более в интеграционный репозиторий.
- В этом файле периодически меняются общие настройки, и разработчик хочет их получать (pull) и публиковать (commit)
- Хранить исходные тексты приложения и его настройку отдельно. Но жизнь боль, и не всегда это можно сделать. Причины на это разные: от технических до (
некомпетентных людей) административных. - Пошаманить с загрузкой конфигурации. Например, под версионным контролем хранить default.super.config, а super.config исключить. Приложение должно сначала грузить свойства из default.super.config, а потом, если он есть, из super.config. Причем значения из последнего перекрывают значения из дефолтного.
- Просто не добавлять изменения локального конфига в индекс.
Плюсы:- Простота.
- Если нужно закоммитить изменения в конфиге, то это делается по фрагментно (git add -p).
Минусы:- Не сделаешь git add.
- Постоянно «маячат» какие-то изменения. Разработчик каждый раз их анализирует, проверяя все ли закоммитил.
- Переключение (checkout) на ветку с другим конфигом возможно только с ключом -m или через stash (ключ -f убивает изменения в рабочей копии).
- Pull изменений конфига приводит к ошибке. Прежде чем получить изменения, локальные придется убрать на полку.
Исключить конфиг из-под версионного контроля.
Не сработает. Только untracked файлы можно исключать из-под версионного контроля.- Убедить git, что файл конфига не меняется. Как это сделать:
git update-index --assume-unchanged super.conf
Если конфиг меняется крайне редко, то --assume-unchanged выглядит подходящим решением. Иначе просто не обращал бы внимания на изменения.
Мы продолжаем развивать механизм выгрузки / загрузки конфигурации в файлы XML. Некоторое время назад мы уже рассказывали о том, что реализовали частичную загрузку конфигурации. Теперь мы реализовали обратную операцию – частичную (инкрементальную) выгрузку конфигурации.
В результате этих двух изменений групповая разработка больших конфигураций должна стать легче и быстрее.
Сценарии использования
Интересным моментом является то, что частичная выгрузка конфигурации в файлы XML предоставляет вам сразу несколько новых возможностей, которые отсутствовали ранее, или были сложны в реализации.
Оптимизация работы 1C:Enterprise Development Tools
Эта возможность не требует от вас каких-либо усилий, потому что реализуется на уровне платформы. Конечно же, инкрементальную выгрузку в файлы XML мы, прежде всего, задействуем в новой среде разработки. Это должно ускорить работу с большими конфигурациями, на которые эта среда и рассчитана. Благодаря тому, что теперь есть возможность выгружать только изменённые объекты, должны ускориться операции получения изменений из информационной базы.
Автоматическая модификация или контроль конфигурации
Существует целый ряд задач, когда выгрузка конфигурации в файлы XML используется для автоматической проверки конфигурации или для выполнения «регламентных» действий, не связанных с прикладной логикой. Это может быть, например, автоматизированная проверка конфигурации на соответствие стандартам разработки, принятым в компании. Или автоматическая модификация ролей для новых объектов.
Общим в этих задачах является то, что конфигурацию предварительно нужно выгрузить в файлы XML. А иногда ещё и загрузить обратно. И тут, конечно, инкрементальная выгрузка конфигурации позволит сэкономить значительное количество времени в цепочке выгрузка – обработка – загрузка.
Изменение логики выгрузки
Главное изменение заключается в том, что при выгрузке конфигурации в файлы XML теперь формируется (или обновляется) специальный служебный файл ConfigDumpInfo.xml, который называется файлом версий. Он хранится в каталоге выгрузки вместе с остальными файлами XML, и содержит информацию о формате выгрузки, о версии выгрузки, и о версиях всех объектов, которые были выгружены.
Таким образом теперь, проанализировав этот файл, платформа точно знает, какие версии каких объектов содержатся в выгрузке. На основании этой информации она выгружает только те объекты, которые были изменены по отношению к уже выгруженным.
На практике это выглядит следующим образом.
Если выгрузка выполняется в первый раз (или если в каталоге выгрузки отсутствует файл версий), то выполняется полная выгрузка, генерируется файл версий.
Если в каталоге выгрузки уже есть файл версий, то выгружаются только изменения конфигурации по отношению к файлу версий, файл версий обновляется.
В качестве примера фрагмент файла версий может выглядеть следующим образом:
Работа с системами контроля версий
- Получить обновления (Update) выгрузки конфигурации из системы контроля версий (если они есть);
- Выгрузить измененные объекты из локальной информационной базы, например, такой командой:
- Зафиксировать изменения (Commit) выгрузки конфигурации в системе контроля версий.
После этого другие разработчики смогут обновить (Update) свои копии XML выгрузки конфигурации.
Получение «патча» для конфигурации
И, наконец, последний сценарий использования частичной выгрузки конфигурации в файлы XML позволяет создавать своеобразные «патчи» из XML файлов конфигурации.
Например, есть конфигурация, которая хранится и распространяется в виде XML выгрузки. Известно, что эта конфигурация изменяется мало. В некоторый момент в конфигурации были выявлены ошибки.
Тогда прежде, чем исправлять ошибки, вы фиксируете (сохраняете) XML выгрузку, соответствующую этому состоянию конфигурации, как эталонную. После этого исправляете ошибки, и выгружаете только изменения, относящиеся к исправлению ошибок. Например, такой командой:
Здесь C:\xml_source\ConfigDumpInfo.xml это файл версий эталонной конфигурации, а C:\xml_patch – каталог, в который будут выгружены только те XML файлы, которые исправляют обнаруженные ошибки.
configDumpInfoForChanges это новый ключ, который позволяет указать конкретный файл версий, от которого нужно «отсчитывать» изменения.
Если же вы хотите не только выгрузить файлы, но и получить список измененных объектов, содержащихся в вашем «патче», то нужно выполнить такую команду:
Тогда информация об изменениях будет записана в файл C:\diff.txt.
По долгу службы наша контора обслуживает несколько организаций, которые для управленческого и бухгалтерского учета используют 1с.
1с, как известно, постоянно выпускает обновления для своих конфигураций.
Соответственно на обновление хотя бы 5 баз уходит приличное количество времени.
Рассказ о том, как добиться полной (кроме скачивания обновлений) автоматизации процесса средствами MSSQL далее.
Автоматизировать процесс начнем с «конца»
- В 1с обновление возможно только с определенной версии на определенную. Это связано с тем, что файлы обновления поставляются не в виде полного «слепка» конфигурации. А в виде изменений от эталонной версии.
- Так же в самом коде 1с есть предопределенные обработки, которые запускаются при переходе с одной версии на другую.
При создании класса надо передать MemoryStream binary data из таблицы _config.
Как видно в коде им можно парсить и конфигурации 7.7, предварительно распаковав.
Теперь до версии конфигурации можно добраться зная её «адрес»: Далее просто создаем пустую базу с версией «ВЕРСИЯ» и находи что её «адрес» (v8metadata)(((v8metadata)(((v8metadata)(this.array_data[3])).array_data[1])).array_data[1])).array_data[15].ToString();
Но где же здесь MSSQL?
Вот CLR функция, которая получит эти данные в самом MSSQL:
У нас есть отдельная БД, которая хранит в себе сервера и базы. Соответственно функция адаптирована под это.
А как определить какое обновление необходимо для данной конфигурации 1с?
При установке обновлении 1с можно использовать каталог обновлений на сервере. В каждом обновлении есть файл .mft вида:
Vendor=Фирма "1С"
Name=БухгалтерияПредприятия
Version=2.0.25.5
AppVersion=8.2
.
И файл UpdInfo.txt
Version=2.0.25.5
FromVersions=;2.0.24.10;
UpdateDate=11.07.2011
Это же всё, что нам надо.
Зная FromVersions и дату выхода обновления мы можем автоматически генерировать строку для запуска обновления 1с. (ссылка на параметры в начале топика)
Но тут появляется еще одна проблема — наличие пользователей в базе. 1с не обновляется. Пишем «выгонялку» пользователей (vbscript)
Одно из правил управления временем — Если есть человек, которому можно делегировать выполнение задачи — делегируй.
Предыстория
Как я докатился до того, что — Я, системный администратор! — стал задаваться вопросами работы 1С?
Тирада в моей оригинальной статье, которую вряд ли кто читал, касалась того, какие лентяи 1С разработчики, и сами производители 1С, что одни понаделали много функций, но другие недостаточно хорошо описали, третьи поленились разобраться, а свалили всю рутину на системных администраторов, которым делать-то нечего, кроме как за элитой IT подметать. Думаю, здесь никто меня не похвалит за такие рассуждения. Хотя и похвалы особо не ищу. Единственная цель — чтобы это пригодилось кому-то, кто правильный лентяй-админ, и не любит заниматься одним и тем же помногу раз. А теперь о том, как это было.
Я столкнулся с таким положением дел, что всем сотрудникам наши 1С разработчики добавляют базы ручками, присутствуя на рабочем месте сотрудника, либо просят это сделать нас удалённо, подключившись к рабочему столу пользователя и мышкакликанием все повторить.
Выглядит это так:
И не думайте, что в следующий раз, этот 1С разработчик скажет мне, что эту базу можно назвать именно также. Как следствие, у нас одна и та же база у разных сотрудников называлась по разному. Красота, не так ли?!
Ещё одна сторона этой проблемы в том, что Сотрудник должен быть на месте, компьютер включен, и у него должно быть время (5 мин), чтобы я мог всё это сделать. Если сотрудника нет на месте, то вы можете себе предположить, сколько от меня требуется трудозатрат, чтобы выловить этого сотрудника, согласовать с ним время и сделать это. А если этот сотрудник в удалённом офисе, на ноутбуке, и бывает в сети крайне редко, плюс разница поясов Владивосток — Москва, то это ещё добавляет остроты ощущений. Конечно, можно ещё ярлыком в почту бросить, но этим у нас 1С разработчики очень крайне редко пользуются — или не умеют, или не хотят, или за нас переживают, что без работы останемся, за что им отдельная благодарность и лучи поноса.
Баз у нас порядка пятнадцати. У каждой группы отдельный набор баз. А есть и такие, у кого строго индивидуальный список.
Следующая картина вам ещё больше понравится.
Поступает распоряжение от главы 1С'ников, что нужно трём отделам изменить базу, т.к. она переехала на другой сервер. Дальше не буду тратить буквы, т.к. всё что я описал выше множите на тридцать человек, двадцать из которых в другом офисе или даже другом городе. Классная задачка.
Не помню, сколько раз, я, таких суматох вынес, но было их больше десяти. После чего мне стало интересно, какие способы оптимизации этого процесса есть по unix-way'ю.
И стал я читать… Читал долго… Читал упорно… Документация 1С в справке мне совершенно не понравилась — написано так, как будто бы я уже это делал, поэтому большую часть идеи они оставляют между строк. Лучи поноса в написателей встроенной справки 1С. Как обычно это бывает, более-менее понятную инструкцию нашел на личном блоге, не помню уже кого.
Теория устройства конфигурационных файлов
В 1С организовано всё, что касается списков баз, в обычных текстовых, читаемых файлах с расширениями .cfg и .v8i, в кодировке utf-8. Так что, как вы наверняка догадываетесь, можно всё делать то же самое без отрыва пользователя, открывая файл по сети обычным текстовым редактором и правкой на прямую.
Расположение файлов на стороне пользователя
У пользователя на компьютере 1С 8.2 хранит фалы списков баз в каталогах:
Для Windows XP:
Профиль всех пользователей: С:\Documents and Settings\All Users\Application Data\1C\1CEstart\
Профиль пользователя: С:\Documents and Settings\%username%\Application Data\1C\1CEstart\
Для Windows 7:
Профиль всех пользователей: C:\ProgramData\1C\1CEStart\
Профиль пользователя: C:\Users\%username%\AppData\Roaming\1C\1CEStart\
Содержимое профиля пользователя — два файла: 1CEStart.cfg, ibases.v8i.
Содержимое директории профиля всех пользователей — один лишь, 1CEStart.cfg.
При запуске 1С берёт список баз к представлению в файле пользователя C:\Users\%username%\AppData\Roaming\1C\1CEStart\ibases.v8i, но предварительно читает настройки сначала из профиля всех пользователей C:\ProgramData\1C\1CEStart\1CEStart.cfg, а потом и из профиля пользователя C:\Users\%username%\AppData\Roaming\1C\1CEStart\1CEStart.cfg, и если в них есть ссылки на конфигурационные базы в сети, то добавляет их в этот файл.
Описание файла 1CEStart.cfg
В профиле всех пользователей конфигурационный файл C:\ProgramData\1C\1CEStart\1CEStart.cfg имеет следующее содержание:
Где:
InstalledLocation — содержит указание на каталог, в который выполнена установка 1С: Предприятие. По умолчанию это значение C:\Program Files (x86)\1Cv82.
CommonCfgLocation — указывает путь и имя общего конфигурационного файла. Допускается наличие нескольких строк с таким параметром.
CommonInfoBases — указывает путь и имя файла (.v8i) со списком общих информационных баз.
DistributiveLocation — содержит указание на каталог, в котором будет производится поиск новой версии для автоматической установки.
InstallComponents — В локальном конфигурационном файле (1CEStart.cfg) содержит перечень установленных компонент с признаком нужно установить компонету — 1, или нет — 0.
Возможны следующие компоненты параметра InstallComponents:
DESIGNERALLCLIENTS — все клиенты и конфигуратор.
THINCLIENT — тонкий клиент для клиент-серверного варианта работы.
THINCLIENTFILE — тонкий клиент с возможностью работы с файловыми информационными базами.
SERVER — сервер 1С: Предприятия. Если программа установки запускается из программы запуска, то сервер будет установлен как приложение.
WEBSERVEREXT — компоненты расширения для веб-сервера.
CONFREPOSSERVER — сервер хранилища конфигураций 1С: Предприятия.
SERVERCLIENT — компоненты для администрирования кластера серверов 1С: Предприятия.
CONVERTER77 — конвертер информационных баз из версии 1С: Предприятия 7.7.
LANGUAGES — список языков интерфейса для установки. Если указано несколько языков, они перечисляются через ”,”. Пример: LANGUAGES=RU,UK,BG
В профиле пользователя конфигурационный файл C:\Users\%username%\AppData\Roaming\1C\1CEStart\1CEStart.cfg первоначально пустой. Но, если какие-то настройки необходимо сделать индивидуально для конкретного пользователя, то писать именно в него, и тут уже его ключи настроек будут иметь больший приоритет, но не все. Это отдельный вопрос, им я не буду сейчас захламлять голову.
Описание файла ibases.v8i
Второй важный файл информационных баз, который находится в профиле самого пользователя — C:\Users\%username%\AppData\Roaming\1C\1CEStart\ibases.v8i. В него и собирается конечный список баз. Пример его содержимого:
Где:
[phonebook] – название базы 1С. Может быть как русскими буквами, так и английскими. Это то, что видит пользователь.
ID=34891493-907f-4783-8a37-3cbc092a989a — автоматически генерируемый уникальный код базы. Если у двух записей один и тот же ID, значит это одна база.
OrderInList=16640 — порядок в списке баз, когда базы представлены одним общим списком без подкаталогов; этот параметр из сетевого списка синхронизируется только в чистый ibases.v8i, если в ibases.v8i пользователя уже заполнен этой базой и этот параметр не будет перезаписываться, при его изменении в сети.
Folder=/ — задаёт место в дереве каталогов, если вид представления списка баз выставлен деревом; этот параметр имеет приоритет пользователя, и не меняется при изменении в сетевом конфиге.
OrderInTree=16640 — порядок в дереве, когда список баз представлен в виде иерархии подкаталогов; этот параметр имеет также приоритет пользователя, и синхронизируется только при первом добавлении базы, а далее подлежит изменению только локальным пользователем.
External=1 — внешняя подключаемая запись конфигурации или нет. Когда 0 тогда база присутствует только в этом файле. В данной ситуации эта запись импортируется из файла списка баз .v8i из сети. Это идентификатор, если это список баз расположенный в сети (расшаренный), то этот параметр можно вообще убрать из конфигурационного файла.
ClientConnectionSpeed=Normal — скорость соединения клиента. Опции могут быть “Nofmal” и “Low”. Логика ясна и без моих поиснений. Этот параметр интерактивный и при сетевом размещении синхронизируется при каждом запуске 1С.
App=Auto — тип соединения клиента. Бывает три типа:
— Auto — определяется сервером;
— ThinClient — тонкий клиент;
— ThickClient — толстый клиент.
Этот параметр интерактивный и синхронизируется при каждом запуске 1С.
WA=1 — этот параметр говорит о том, что система должна использовать windows авторизацию. Этот параметр интерактивный и синхронизируется при каждом запуске 1С.
Version=8.2 — используемая версия для этой базы. Если указать полностью конкретизируя какую платформу использовать, то будет использовать именно ту платформу, которую укажешь, как, например, во второй записи — Version=8.2.14.540. Этот параметр интерактивный и синхронизируется с сетевым конфигом при каждом запуске 1С.
Также есть ещё такой параметр как DefaultApp — тип соединения клиента по умолчанию, если в конфигурации для базы не задан, и DefaultVersion — используемая версия по умолчанию, если не задано в конфигурации для базы. Этот параметр пользовательский, и синхронизируется в чистый файл базы при первом запуске. Далее этим параметром управляет локальный пользователь.
Ссылки на конфигурационные файлы в сети
- либо в конфигурационном файле всех пользователей C:\ProgramData\1C\1CEStart\1CEStart.cfg, если мы хотим показать базы для всех пользователей компьютера;
- либо в конфигурационном файле конкретного пользователя C:\Users\%username%\AppData\Roaming\1C\1CEStart\1CEStart.cfg, если мы хотим показать базы только определённому пользователю на компьютере.
- либо CommonCfgLocation=\\server\1C\config\bases.cfg — указывает путь и имя общего конфигурационного файла. Допускается наличие нескольких строк с таким параметром. Название файла не играет принципиального значения, лишь бы расширение сохранялось;
- либо CommonInfoBases=\\server\1C\config\buh_bases.v8i — указывает путь и имя файла (.v8i) со списком общих информационных баз. Название файла не играет принципиального значения, лишь бы расширение сохранялось;
- или в комбинации и тот и другой, и помногу строк.
Идея использования возможностей
Идея заключается в том, чтобы делать правки с наименьшим количеством повторений. Если настройки базы или её расположение на сервере поменялось, то, исправив запись один раз в одном месте, мы получим актуальную информацию на всех компьютерах.
Для этого необходимо сделать шару в сети: \\server\1C\ . В этой шаре сделать, как минимум два каталога:
..\bases\
Листинг каталога:
В этом каталоге будут хранится файлы с расширением .v8i. Эти файлы будут иметь внутри себя настройки всего лишь одной базы для каждого файла. Причём указать следует только те параметры, настройки, которые критичны именно для этой базы, всё остальное автоматом подставится по умолчанию. Пример файла:
Следует избегать использования параметра ID , т.к. 1С разработчики используют для создания новой базы копипаст из имеющейся базы. А базы с одним ID будут конфликтовать.
..\groups\
Листинг каталога:
В этом каталоге будут храниться файлы с расширением .cfg. Эти файлы будут иметь внутри себя ссылки на базы в каталоге ..\bases\. Пример файла:
В это каталоге мы создаём индивидуальные для группы пользователей или же для конкретного пользователя списки баз. Именно на файлы из этой группы мы ссылаемся в конфигурационных файлах операционной системы пользователя.
При такой схеме мы выносим управление списками баз 1С пользователей в сеть для не администраторов. На сетевой каталог с конфигурационными файлами дать доступ 1С разработчикам и пусть играются как хотят.
А если необходимо изменить настройки какой-то базы, то мы правим её всего одни раз в файле \\server\1C\bases\base.v8i, и это отразится у всех пользователей, т.к. все пользователи смотрят информацию о базе именно в этом файле.
Формат конфигурационного файла программы запуска Файл расположен в каталоге %APPDATA%\1C\1CEStart
В конфигурационном файле содержится следующая информация:
- Версия платформы, которую нужно использовать по умолчанию;
- Расположение списков общих баз;
- Список каталогов с установленными версиями;
- Список каталогов с дистрибутивами;
- Расположение общего конфигурационного файла.
Файл представляет собой текстовый документ в кодировке UTF-16LE и содержит строки формата Параметр=Значение
Описание параметров DefaultVersion - определяет версию, используемую по умолчанию. Допускается наличие нескольких строк с таким параметром.
Пример 1: DefaultVersion=8.2-8.2.9.150
Данная строка означает, что при попытке запуска информационной базы с указанием версии 8.2 будет использоваться версия 8.2.9.150.
Пример 2: DefaultVersion=8.2.9-8.2.9.100
Данная строка означает, что при попытке запуска информационной базы с версией 8.2.9 будет использоваться версия 8.2.9.100.
CommonInfoBases - указывает путь и имя файла со списком общих информационных баз.
InstalledLocation - содержит указание на каталог, в который выполнена установка 1С:Предприятие. По умолчанию это значение C:\Program Files\1Cv82.
DistributiveLocation - содержит указание на каталог, в котором будет производится поиск новой версии для автоматической установки.
CommonCfgLocation - указывает путь и имя общего конфигурационного файла. Допускается наличие нескольких строк с таким параметром.
InstallComponents - В локальном конфигурационном файле (1CEStart.cfg) содержит перечень установленных компонент. Общий файл для всех пользователей компьютера находится в каталоге \Documents and Settings\All Users\Application Data\1C\1CEStart.
В общем конфигурационном файле (1CESCmn.cfg) содержит перечень компонент, которые необходимо установить (формируется администратором системы).
Содержит строку компонентов с признаком необходимости установки, разделенных пробелом:- 0 — не устанавливать,
- 1 — устанавливать.
Возможны следующие компоненты:
- DESIGNERALLCLIENTS — все клиенты и конфигуратор.
- THINCLIENT — тонкий клиент для клиент-серверного варианта работы.
- THINCLIENTFILE — тонкий клиент с возможностью работы с файловыми информационными базами.
- SERVER — сервер 1С:Предприятия. Если программа установки запускается из программы запуска, то сервер будет установлен как приложение.
- WEBSERVEREXT — компоненты расширения для веб-сервера.
- CONFREPOSSERVER — сервер хранилища конфигураций 1С:Предприятия.
- SERVERCLIENT — компоненты для администрирования кластера серверов 1С:Предприятия.
- CONVERTER77 — конвертер информационных баз из версии 1С:Предприятия 7.7.
- LANGUAGES — список языков интерфейса для установки. Если указано несколько языков, они перечисляются через ",". Перечень кодов языков локализации см. здесь.
Пример: LANGUAGES=RU,UK,BG
Пример параметра: InstallComponents=THICKCLIENT=0 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=1 LANGUAGES=RU,EN
В файле для всех пользователей 1CEStart.cfg могут быть указаны все настройки, аналогичного файлам пользователей, но интерактивные режимы редактирования настроек изменяют настройки в файле пользователя.
Инсталлятор записывает в All Users\Application Data\1C\1CEStart\1CEStart.cfg ключи InstalledLocation и InstallComponents.
При использовании настроек из общего конфигурационного файла и файла текущего пользователя, если ключ присутствует в обоих файлах:
Более высокий приоритет общего файла настроек для ключей: InstallComponents
Более высокий приоритет файла настроек текущего пользователя для ключей: DefaultVersion
UseHWLicenses
Остальные ключи, объединяются.
ConfigurationTemplatesLocation - указывает путь к каталогу шаблонов конфигураций. Может быть более одной записи.
Если параметр присутствует и в локальном и общем конфигурационном файле, то параметры анализируются в следующем порядке:- параметры DefaultVersion, InstallComponents в порядке описания в локальном файле, затем в порядке описания в общем файле;
- параметры InstalledLocation, DistributiveLocation, CommonInfoBases в порядке описания в общем файле, затем в порядке описания в локальном файле;
- параметры CommonCfgLocation только в локальном файле;
- параметр InstallComponents используется из общего файла (если указано) и замещает значение в локальном файле, если не указано — используется значение из локального файла.
UseHwLicenses - указывает необходимость поиска локального ключа защиты.
Пример параметра: UseHWLicenses=0 - поиск аппаратного ключа не выполняется
Пример конфигурационного файла:
Код
Интерактивная выгрузка
Этот сценарий позволяет вам в процессе разработки периодически сохранять конфигурацию в виде файлов XML. Раньше для больших конфигураций этот сценарий был практически неприемлем, потому что каждый раз выгружалась вся конфигурация. А это могло занимать много времени.
Теперь же полная выгрузка конфигурации потребуется вам только в первый раз. Дальше вы модифицируете конфигурацию и в некоторый момент просто вызываете диалог выгрузки, указываете каталог, и нажимаете ОК. В результате будут выгружены только те изменения, которые вы произвели в конфигурации с прошлой выгрузки в XML.
Контроль изменений в конфигурации
Этот сценарий удобен в том случае, когда над одной конфигурацией работают сразу несколько разработчиков. При этом имеется XML выгрузка, которая является эталонным состоянием конфигурации. Задача состоит в том, чтобы при каждом изменении конфигурации сохранять информацию о том, что изменилось. В этом случае разработчик может выполнить, например, такую команду:
В результате будет сформирован файл (C:\diff.txt), содержащий изменения конфигурации (-getChanges) относительно эталонной выгрузки(C:\xml). Если изменений нет, то файл diff.txt будет пустым.
getChanges это новый ключ, который позволяет вывести в указанный далее файл изменения текущей конфигурации относительно той выгрузки, каталог которой указан перед этим ключом.
Автоматическое обновление XML выгрузки
Это вариация предыдущего сценария, когда изменения, выполненные вами за день, автоматически сохраняются в XML выгрузке. Тут вам понадобится написать скрипт, который запускается после окончания рабочего дня, и выполняет, например, такую команду:
В результате в каталог выгрузки (C:\xml) будут сохранены только те изменения (-update), которые сделаны с момента предыдущей выгрузки, то есть в течение дня.
update это новый ключ, который позволяет обновить выгрузку, то есть выгрузить только те файлы, версии которых отличается от версий в каталоге выгрузки.
Читайте также: