В 1С есть замечательная возможность выгрузки конфигурации в текстовые файлы. Универсальность такой выгрузки в том, что мы получаем в текстовом файле полную информацию о формах, объекта и др. и можем ее анализировать любым внешним редактором.
Как проще и нагляднее сравнить выгруженные в xml управляемые формы и структуры метаданных объектов.
Последнее время в работе с 1С я полностью перешла на сравнение конфигураций через текстовые файлы в Гит. Это оказалось гораздо удобнее, чем стандартное сравнение через хранилище. Основная проблемы была с управляемыми формами. Обычные формы ssf замечательно сравниваются через v8reader, управляемые приходилось сравнивать как текст. Стандартная выгрузка не очень наглядна, хоть и позволяет отследить изменения. Попробовав разные варианты, в конце концов остановилась на варианте преобразования xml-файла через xsl-шаблон + специализированная внешняя утилита для сравнения ExamXML.
Сначала о том, как это выглядит, потом как настроено.
В качестве Git-клиента у меня прижился Git Extensions. Он достаточно легкий, понятный и удобный. Для преобразования 1С-хранилища в Гит-репозиторий прижился Gitter — конфигурация с инфостарта, которая периодически проверяет новые изменения в 1с-хранилище и перекидывает их в Гит.
После синхронизации Гит-репозитория с 1С-хранилищем для сравнения конфигураций просто выбираем версии, которые хотим сравнить -> выбираем сравниваемый файл -> правый клик -> открыть в инструменте сравнения (либо просто F3). Все картинки в статье кликабельные.
Для примера сравним форму элемента справочника «Номенклатура» в УТ11.1.7 и УТ 11.1.9. У утилиты есть 2 режима сравнения «показывать весь файл» и «показывать только изменения».
Думаю, не нужно особо разбираться в xml, чтобы по этим картинкам увидеть отличия.
-у элемента «Наименование» убрали обработчик «НаименованиеПриИзменении»;
-у группы «ГруппаКартинка» установили ширину 48;
-добавили новую страницу «СтраницаРабота»;
-добавили элемент «РейтингПродаж»;
-команду «Выбрать из присоединенных файлов» переименовали в «Из присоединенных файлов»;
Пример сравнения структуры метаданных справочника «Номенклатура» можно посмотреть в скриншотах.
Удобства сравнения через xml в том, что xml-выгрузка содержит абсолютно всю информацию о форме или объекте. Т.е. мы на одном экране видим все изменения элементов, их свойств, команд, обработчиков и т.д.
Черным цветом указаны совпадающие элементы, зеленым — отличающиеся, красным — отсутствующие во втором файле. Причет, если в ветке есть отличия, то зеленым будет отмечена вся ветка до самого верха. Благодаря этому, даже в свернутом дереве мы видим, в каких ветках есть отличия.
По умолчанию сопоставляются элементы с одинаковым наименованием на одном уровне иерархии. Т.е. если изменено имя элемента либо элемент вынесен на другой уровень (например, перенесли во вложенную группу), то утилита автоматически его не сопоставит а отметит, что в одной папке элемент удалили, в другой добавили новый. Однако можно их сопоставить вручную. Выбираем соответствующий элемент в обоих файлах -> правый клик -> compare element. При этом утилита их отметит как один элемент и сравнит все вложенные уровни.
Из полезных фич можно отметить возможность игнорирования каких-либо атрибутов или элементов. Например, при добавлении элемента в форму, в xml для остальных элементов может сбиться номер элемента id. В этом случае индексы элементов будут разные, хоть и сами элементы одинаковые. Для того, чтобы эти отличия не мешали сравнению, становимся на любой элемент с атрибутом id -> правый клик -> ignore elements -> указываем, какие атрибуты хотим игнорировать для данного элемента или вцелом для файла.
Теперь о том, как это работает:
К сожалению, выгружаемый стандартно xml-файл не очень удобен для анализа из-за большого количества информации. Поэтому перед сравнением он преобразуется xsl-шаблоном для удобного просмотра. Шаблон выкидывает все пустые элементы, заменяет в элементах названия с типа элемента на имя элемента, сокращает по возможности глубину вложенности элементов, выкидывая все лишнее. В результате размер файла уменьшается примерно в 2 раза.
Преобразованный файл отдается утилите сравнения ExamXML.
Что в файлах:
sample.zip архив для того, чтобы понять, удобно ли такое сравнение лично вам:
— пример выгрузки из УТ11.1 формы элемента «Номенклатура». Версия файлов из релизов 11.1.7 и 11.1.9.
— Два варианта xml-файлов (до и после преобразования шаблоном).
— Сам шаблон form1c.xsl для преобразования. Можно самостоятельно внести любые изменения на свое усмотрение (вернуть то, что я выкинула, преобразовать свойства дополнительно). Для преобразования xml через xsl шаблон рекоммендую простой и удобный стандартный Notepad++.
-утилита ExamXML. Утилита, к сожалению, платная, хоть и не дорогая. Бесплатно проработает 30 дней, дальше либо покупать, либо менять на что-то другое.
diff1cXML.zip — готовый вариант для подключения к Гит. Для использования необходимо разархивировать в каталог c:cmd (или любой другой, поменяв соответственно пути в скрипте) и настроить вызов скрипта diff-1c-xml.js как внешнего инструмента сравнения для файлов с расширением xml. Сам скрипт является модификацией скрипта diff-1c-cf.js из проекта v8Diff, использующего v8Reader и описанного в статье Системы контроля версии и 1С, подключается полностья аналогично подключению v8Reader через v8Diff. Структура файлов и пример настройки на скриншотах.
При необходимости можно использовать скрипт и без Git, просто запуская из командной строки «diff-1c-xml.js form1.xml form2.xml». Параметры скрипта — пути к файлам, выгруженным из конфигуратора режимом «Конфигурация» -> «Выгрузить конфигурацию в файлы»
v8xsl.epf Простенькая утилитка для преобразования xml-файлов по xsl-шаблонам. Удобна для отладки xsl-шаблонов. Выбираем файлы, нажимаем «Преобразовать». Также позволяет сразу из обработки вызвать любую внешнюю утилиту для сравнения преобразованных файлов.
Внешний вид и пример настройки:.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Хороший обзор. Попробую использовать.
По поводу сравнилок XML — мне нравится Altova DiffDog. Но тоже не бесплатная.
(2) AlX0id, Пробовала. Именно она у меня стояла перед ExamXML еще без xsl-преобразования. В принципе понравилась, но при большом количестве изменений перемешивала элементы и сравнение выходило совершенно неинформативное.
Еще из тех, что понравились, Liquid XML Diff.
Но все равно пока остановилась на ExamXML. Наиболее удобная лично для меня. Более четко показывает структуру и отображение намного компактнее.
(0) спасибо за рекламу V8Reader, но честно говоря, скрипт diff-1c-cf.js входит в проект v8Diff (, ), разработка . А статья (и подход) у Вас отличные!!!!! Спасибо!!!!!
(4) bambr1975, Спасибо, поправила описание. Когда себе настраивала, скачивала с разных мест и комбинировала под себя. Сейчас все в голове комплексно воспринимается. Иногда путаю, что из какого проекта.
Хорошая статья с подробным описанием методов сравнения управляемых форм по XML. Прямо как сравнение и объединение конфигураций.
Наверное, может пригодится для более детального поиска различий при поиске глюков, где обычное сравнение и объединение в конфигураторе не справляется?
Или когда программная генерация управляемой формы из кода в платформе 1С 8.3?
Какое практическое применение этой технологии?
(6) kostyaomsk, Основное применение это сравнение конфигураций.
Сравнение через XML показывает те изменения, которые при стандартном сравнении не видны.
Ну и из того, что было лично для меня даже более важным, оно намного быстрее, чем сравнение через хранилище. Мы мгновенно сравнивать любые версии любых релизов.
Интересная статья. Давно уже смотрю в сторону Гита, но руки никак не доходят разобраться во всем этом, чтобы начать… Теперь, пожалуй, ознакомлюсь….
(3)
Попробую и ExamXML..
Вопрос по поводу использования гита — насколько он оправдан при поддержке больших конфигураций (УПП, сильно доработанные УПП, ERP)? Или применим только к небольшим конфам?
(9) AlX0id, У меня сейчас в хранилище 4 ветки разных модификаций УТ (типовые УТ 11.0, УТ11.1 + 2 наши модификации).
Удобно, что можно сравнить любую версию с любой.
Работает очень быстро.
УПП примерно того же объема по количесву кода. как УТ11.
ERP, думаю, примерно в 2раза больше по объему, чем УТ11.
Думаю, тоже проблем не будет.
Количество доработок вообще не важно.
Подробное сравнение ролей на управляемых формах в этой публикации тоже участвует?
(11) ZhokhovM, Если мы говорим о доступе к элементам по ролям, то в XML это обычные элементы, подчиненные самому элементу.
Приложила картинку для той же формы элемента номенклатуры, что на скриншотах и в sample.zip.
Если есть изменения, то будут подсвечиваться.
Если про роли вцелом, то это отдельные XML-файлы. В принципе тоже аналогично сравниваются.
Немного непонятно, гиттер выгружает все изменения в гит, не используя стандартную выгрузку конфигурации в xml-файлы?
(12) я имел в виду роли через «Общие», чтоб сравнивать шаблоны ограничений.
(13) AlexanderKai, Гиттер переносит изменения из 1С-Хранилища в Гит-Репозиторий.
Как именно он это делает для данной статьи не важно. Но вообще сам механизм подробно описан в
Кратко алгоритм следующий:
1. Гиттер обращается к 1с-хранилищу «Хранилище, у меня последняя версия №Х, есть ли что-то после нее?»
2. Если есть, то для каждой новой версии Гиттер выполняет набор действий.
2.1. Запустить конфигуратор промежуточной базы.
2.2. В промежуточную базу загружаем нужную версию хранилища.
2.3. Из промежуточной базы выгрузить xml-файлы конфигурации в папочку на диске.
2.4. Дальше Гиттер обращается к Гит «Гит, я там новые файлики положил в папочку. Их поместил в 1с-хранище Иванов в 12.05. Отметь у себя.»
2.5. Гит анализирует файлики, сверяет со своей последней версией, сохраняет изменения и данные о том, кто и когда эти изменения внес.
(15)
А счастье было так близко 🙂
Выгрузка в xml файлы долгий процесс.
(14) ZhokhovM, Технически каждая роль это отдельный xml-файл.
Можно сравнивать полностью аналогично формам. Картинка в приложении.
(16) AlexanderKai, В данном случае время абсолютно не принципиально. Выгрузка полностью автоматическая. Работает сама по себе, никакого вмешательства не требует.
(17)
А как процесс разработки выглядит?
(17)
Еще вопрос — были ли проблемы с тем, что 1С некорректно выгружает xml? Менялся ли формат от версии к версии?
(19) AlexanderKai, 1с корректно выгружает в xml, а вот обратно иногда не корректно.
Да формат меняется, начиная от детских ошибок в схеме метаданных, поменялось название элемента было «lement», стало «element», заканчивая каждый раз новые uuid в mxl макетах.
Каждый выход 8.3.5 подразумевает, что у вас скорей всего изменится все представлении метаданных, т.к. то обязательный null добавят, то еще какое-нибудь описание метаданного изменять с «по-умолчанию» на auto или наоборот.
(18) AlexanderKai, Процесс разработки абсолютно стандартный. Захватываем файлы в 1с-хранилище -> меняем -> помещаем обратно. Гит исключительно сравнивалка версий.
(19) AlexanderKai, С некорректной выгрузкой не сталкивалась. Принципиальных проблем вроде не было. Иногда всплывают лишние различия.
При первой полной выгрузке/загрузке поменяласть часть хелпов (файлов справки). Сначала не поняла, в чем проблема, так как конфигуратор при сравнении .cf файлов просто показал, что документы отличаются без возможности увидеть отличия. Формат html немного оптимизировался, повыкидывалась часть лишних тегов.
Еще из того, что мешает, иногда проскакивают отличия в именах атрибутов в языке вида «СписокРасширеннаяПодсказка» вместо «СписокExtendedTooltip», «СписокСтрокаПоиска» вместо «СписокSearchString». Насколько я понимаю, зависит от языка базы у разработчика.
В УТ11 попался один отчет, в котором при каждой выгрузке новый идентификатор
Report.СравнительныйАнализПоказателейРаботыМенеджеров.Template.СравнительныйАнализМенеджеров.Template.xml
Пришлось убрать из сравнения через .gitignore
(21)
Report.СравнительныйАнализПоказателейРаботыМенеджеров.Template.СравнительныйАнализМенеджеров.Template.xml
у меня таких 10 штук, написал скрипт, который парсил diff для mxl файлов и если отличается только uuid, то игнорируем помещение, точнее revert для такого файла.
Для правильной установки языка базы данных, запускайте всегда с ключами /Len и /LVen(LU) не помню точно, надо посмотреть в своих скриптах, тогда не будет проблем с языком выгрузки.
(22) pumbaE,
Настроила в конфигураторе: Сервис -> Параметры -> Запуск 1С-Предприятия -> Дополнительные -> Язык интерфейса и код локализации «ru». Вроде сейчас все последние изменения файлов выгружаются корректно на русском. Проблема только при сравнении старых с новыми.
(23) я больше все таки склоняюсь к en варианту, т.к. запускается у меня как на linux так и на windows, в частности docker и там не всегда имеет смысл ставить локали, а единый стандарт подразумевает, что у себя не забудем при новом разворачивании поменять настройки базы и команду запуска, т.к. сразу вылезет множество различий.
хм, разве gitter не создает новую базу под cf для возможности выгрузки? Имхо на этапе создания базы, загрузки надо указывать правильную локализацию создания базы данных.
(10)
Там просто доработки заключаются в том, что добавленных документов и справочников сотни.. Думаю, это как раз важно )
А сколько по времени у вас занимает выгрузка в XML, если не секрет?
(24) pumbaE, Мне как-то русский удобнее. Думаю, не принципиально, какой именно. Главное, чтобы одинаковый. Так же можно забыть и ключи настроить. Ну и у меня только Виндовс везде.
По Гиттеру, там в настройках указывается для каждой конфигурации, какую именно промежуточную бузу использовать.
(25) AlX0id, Пока сами не проверите, по именно вашей базе никто не подскажет.
По длительности не засекала, но судя по времени создания первого и последнего файла в папке выгрузки для УТ11.
12 минут, 19491 файлов, 1.2Гб.
(26)
Ну естественно, что я про ваши конфы спрашиваю )) Спасибо )
(25) AlX0id, поделюсь своим опытом.
У меня 7-12 минут, но это RAM драйв для темповых папок, куда 1с много чего пишет.
Выгрузка из хранилища оптимизирована с помощью tool1cd, т.к. в случаи блокировки по хранилищу, выгрузка версии из хранилища бывает доходит до получаса, поэтому используется tool1сd.
Для УТ 2.3(она же УТ 10.2) размер git хранилища на 5000 коммитов 300 метров, против 850 метров файла базы хранилища 1с, скорость в git сравнения, естественно, значительно больше.
Порядок цифр по синхронизации:
раз в 5 проверка изменений в хранилище, 15 мин на получении версии в хранилище, раз в 5 минут привязка в redmine версии хранилища(git) с задачей. Каждый коммит запускает тест, на проверку обновления базы данных, фиксируется время обновления(а вдруг, кто-то на 4 часа положить базу, случайно своим обновлением), проверка синтаксического контроля с проверкой «server, клиент, внешнее соединение», проверка на дубляж кода (добавился новый или нет копипаст), естественно запуск тестов с помощью xddUnitFor1c (тесты запускаю только ключевые). В результате в течении дня после коммита разработчиком через 40 минут, можно сказать можем мы накатывать обновление или нет в рабочую базу. (дополнительно проверяется обмен РИБ, проходят ли обмены, регистрируются ли ключевые документы, подходят ли правила конвертации для обмена и не сломается ли обмен)
А ночью запускается полное тестирование, занимает примерно 4-5 часов.
В redmine проводиться code-review изменений разработчиков и соответствующие задачи. В git по факту при простейшем варианте существует две ветки master и develop, master — это то что базе, develop то что разрабатывается, так же есть еще 2 ветки, которые переодически с помощью выгрузки поставки получают последние обновления из master.
В УТ11 попался один отчет, в котором при каждой выгрузке новый идентификатор
Report.СравнительныйАнализПоказателейРаботыМенеджеров.Template.СравнительныйАнализМенеджеров.Template.xml
у меня таких 10 штук, написал скрипт, который парсил diff для mxl файлов и если отличается только uuid, то игнорируем помещение, точнее revert для такого файла.
Мы обнаружили, что именно при выгрузке на тексты в 8.3 меняются те макеты, в которых есть диаграммы Ганта или различные объекты/рисунки, например, объект штрихкод размещен в макете.
Женя, поделись скриптом, мы как задумались сегодня о реализации подобной фичи.
Жду ответа.
Кроме упомянутого Гиттера есть наш с pumbaE боевой проект , в котором также решено много задач по синхронизации с Гит.
Об этом мы уже не один раз рассказывали, в т.ч. и на конференциях Инфостарт.
да ладно…
(7) еще такой вопрос. Если есть сильно убитая конфигурация с большим количеством изменений (подозреваю повреждена конфигурация поставщика). Там и обычные и управляемые формы. По обычным формам предложенная Вами технология может подойти. Новая технология, конечно, хороша, но нужно время для анализа и изучения. Я с вопросом о том есть ли универсальность у обработки по виду форм (или только УНФ)?
(32) kostyaomsk, Данная статья исключительно про сравнение полученных при выгрузке конфигурации xml-файлов.
С обычными формами ситуация немного другая. Они стандартно выгружаются в файлы с расширением .Form и очень удобно сравниваются через v8reader. В обычных конфигурациях также черех v8reader удобно сравниваются макеты .mxl.
Т.е. первым этапом просто настраивается выгрузка конфигураций и хранение в Гит. Потом для разных типов файлов настраивается просмотр различными средствами и при выборе команды сравнения Гит-клиент автоматически вызывает утилиту сранения для данного вида файлов.
У меня сейчас:
.Form, .mxl — v8reader (обычные формы и макеты)
.xml — xsl+ExamXML (управляемые формы, структуры документов и справочников)
.txt — DiffMerge (общие модули, модули объектов, форм….)
Если Гит не используется, то можно просто выгрузить 2 конфигурации в отдельные папки сравнивать файлы этими же утилитами. Это менее удобно, так как нет автовыбора утилиты и второго файла, но тоже возможно.
Попробуйте просто выгрузить свою конфигурацию в файлы и просмотреть визуально на сами файлы. Многие вопросы отпадут.
врядли буду использовать, но статья несомненно полезная!
А обратное XSL-преобразование есть? Чтобы потом собрать можно было конфигурацию из файлов?
(35) Magister, обратного нет.
Многое выбрасывается при преобразовании. Т.е. остается в основном то, что нужно для визуального сравнения.
Чисто теоретически можно сделать преобразования в 2 стороны, но это сложнее.
На текущий момент удобнее сравнивать через xml, но изменения в конфигурацию вносить все равно конфигуратором.
Скажите пожалуйста, как получить описание форм, как на картинках?
Нужно это сделать программно
(36) Скажите пожалуйста, как получить описание форм, как на картинках?
Нужно это сделать программно
(37) bukashchik@rambler.ru, а что значит получить описание форм программно?
Т.е. что именно хотите получить на выходе?
Для выгрузки файлов программно в XML достаточно запустить конфигуратор с параметром /DumpConfigToFiles.
В этом случае он выгрузит конфигурацию в файлы и закроется автоматически.
Дальше уже просматриваете файлы любым XML-просмоторщиком.
Я(39) Спасибо за ответ.
Вообще, я хочу дернуть веб-сервис и получить описание форм — что-то вроде того что у Вас на картинках )
Как это можно сделать?)
(39) Спасибо за ответ.
Вообще, я хочу дернуть веб-сервис и получить описание форм — что-то вроде того что у Вас на картинках )
Как это можно сделать?)
(40) bukashchik@rambler.ru, Если код будет выполняться изнутри 1С, то логичнее анализировать не XML-выгрузку, а саму форму.
Т.е. просто получаете форму и обходите ее реквизиты. И уже их в виде дерева отдаете на сторону.
Тут скорее стоит ориентироваться на работу с формой аналогично этой обработке
Там как раз справа отображается дерево элементов формы.
(42) А из какого места в 1с можно получить описание любой формы объекта конфигурации 1С?
Дело в том, что ни из Общего модуля, Справочника, Документа и т.д. мне не удалось этого сделать, «ПолучитьФорму» возвращает Неопределено. А вот из Обработки удалось.
У меня вот такая ф-ция:
Функция GetFormInfos() Экспорт
mForm=Справочники[«имяСправочника»].ПолучитьФорму(«ФормаЭлемента»);
ИЛИ
mForm=Документы[«имяДокумента»].ПолучитьФорму(«ФормаЭлемента»);
//получаем описание формы
fName=mForm.Наименование;
fTitle=mForm.Заголовок;
…
//получаем описание элементов формы
controls=mForm.ЭлементыФормы;
…
КонецФункции
В итоге мне нужно, чтобы веб-функция дергала ф-цию общего модуля, а та возвращала описание форм.
Вызвать в общем модуле функцию GetFormInfos из Обработки мне пока не удается, т.к. она должна быть «&НаКлиенте», из-за чего общий модули говорит, что не видит ее…
Уж не знаю что делать…
(43) bukashchik@rambler.ru,
Нужно обращаться к метаданным, а не к объектам.
Метаданные.Справочники.Валюты.Формы.ФормаЭлемента
Обращаться с сервера откуда угодно.
(44) Дело в том, что через метаданные практически ничего содержательного не доступно, описания элементов формы вообще нет.
(45) bukashchik@rambler.ru, Да, действительно.
В метаданных нет элементов форм.
Они есть только в созданном объекте формы.
Объект формы можно создать только с клиента.
Скажите для чего это сравнение нужно. Просто любопытно.
(47) ИНТЕГРА, Не совсем поняла вопрос.
1. Зачем вообще сравнивать конфигурации?
Чтобы видеть, кто что поменял.
2 Зачем сравнивать через Гит, а не через стандартное сравнение?
Чтобы иметь возможность мгновенно сравнить любые версии любых конфигураций. Например, прошлый свой релиз с текущим рабочим вариантом, текущий с конфигурацией поставщика. Чтобы быстро просмотреть весь перечень изменении любого коммита хранилища. Текстовое сравнение показывает больше, чем обычное.
3. Зачем преобразовывать выгруженные структуры форм через xsl?
Чтобы выкинуть незначащую информацию.
(48) спасибо, интересовал только п.1 ответа, только более развернуто 🙂 наверно все таки КТО поменял механизм не скажет. Я просто вижу проделана огромная работа, но целей все равно не пойму.
Вот нашли Вы разницу между формами. Это вы используете для обновлений измененных форм или чего? я не пойму просто.
(49) ИНТЕГРА, основных задач две:
1. Обновление измененных типовых форм (перенос изменений).
2. Код ревью, в том числе просмотр своих изменений, не поламалось ли что-то случайно.
Как раз КТО поменял механизм и говорит. В Гит для любого файла можно просмотреть, кто именно добавил каждую конкретную строчку, когда поменял и как подписал изменение в хранилище. Работает и для текстовых модулей и для объектов (формы, структуры документов)
(50) то есть при каждом обновлении делать выгрузку форм (а лучше не только форм) из новой конфигурации, сравнивать со своей измененной конфой в git. По выявленным откланениям видно свои доработки и доработки поставщика. Тут вроде все понятно.
Дальше вопрос: приводим в соответствие новую объединенную конфу в git или уже в конфигураторе?
А формы правите уже по-любому вручную в конфигураторе, тк их из git не выгрузить. Так получается?
Вроде что-то вырисовывается у меня, если я правильно понял процесс обновления.
(51) ИНТЕГРА, Тут кому как удобнее. Каждый сам решает.
Лично у меня Гит только для сравнения.
Вся работа с конфигурацией только стандартно из конфигуратора с коммитом в типовое хранилище.
Гит живет сам по себе, каждый коммит в типовое хранилище автоматом синхронизируется с Гитом. Специально вручную ничего выгружать не нужно.
Можно работать вообще без хранилища и все изменения переносить через сравнение текста именно с историей в Гит.
Зависит от задач.
Добрый день.
Коллеги, я считаю что в данной статье заложена одна очень большая ошибка: непосредственное изменение формы.
Если уйти на программное внесение изменений в форму сразу делает данную статью неактуальной.
Спасибо.
(53) Сергей, программное изменение разумно, если типовую меняешь, а если своя конфа/объекты? Неужели будешь с нуля кодом формы создавать? А они же тоже могут меняться, тоже нужен механизм отслеживания.
(54) В случае своей «конфы» также очень удобно программная работа с формами, в том числе для отслеживания изменений, в случае когда используются не управляемые формы.
Все вышеперечисленные XML diff умеют только сравнивать два файла, что при использовании git не особо помогает при разрешении конфликтов.
Перепробовал многое и нашел единственное подходящее —
Кто ни будь знает как в Git Extensions подключить более одного merge tool?