Утилита Elisy XmlProject подготавливает xml-выгрузку 1С к публикации в системах версионирования, отличных от хранилища конфигурации 1С. Для ускорения работы применена многопоточность. Требует для работы установленный .Net Framework и Elisy .Net Bridge.
Пример публикации конфигурации на основе старых обновлений БСП четырехлетней давности (с 1.0.7.5 по 1.1.3.1) можно посмотреть по адресуhttps://github.com/elisy/ssl. Таким же образом можно делать публикацию в других системах версионирования: SVN, Mercurial.
Для запуска необходимо выбрать файл выгрузки Configuration.xml и указать файл проекта в новом каталоге, куда будут скопированы файлы, например Configuration.xmlproj.
Технология более подробно описана здесь:
http://www.richmedia.us/post/2015/02/23/1c-83-xml-github.aspx
svn — очень долгий индекс.
hg — не поддержки для кириллических названий файлов и папок в windows системах.
(1) pumbaE,
тут хотелось бы уточнения. Держал хранилище для конфы под Mercurial 2.5.2 — бед не знал. НО: работа под одним пользователем, на одном компе, с одной веткой и в одну сторону (только выгрузка для хранения).
(2) baton_pk, в таком варианте поддерживает. Как только коллективная работа, отправка на внешнее хранилище (а там linux) — все начинает ломаться. За состоянием поддержки слежу наэтой страничке
(0) pumbaE,
Можете на конкретном примереhttps://github.com/elisy/ssl показать, где что сломалось? Пример на внешнем хранилище, скорее всего под управлением Linux.
Скриншоты в статье сделаны с SVN — пока не заметил долгого индекса. Была проблема, которую я описал на Хабре, но она оказалась не связанной с самим SVN, а была связана с сетевыми настройками файрвола. После настройки скорость значительно возросла.
(4)
github стал поддерживать Mercurial-хранилища? Проверил, вроде нет. Разговор про Mercurial (Hg), а не про git.
(4) нет. Там все названия метаданных на англицком языке.
Тест очень прост на самом деле, в hg создать папку на кириллице, в ней файл в наимовании использовать кириллицу и отправить на битбакет, склонировать с битбакета к в новую папку, изменить файл, закомитить, отправить на битбакет и потом в первоначальной папке получить изменения.
Есть возможность разобрать файлы форм обычного приложения? Отделить отдельно текст модуля формы от всего остального. Все это выгружается в файл с расширением «form», почитать его как текстовый пока не получилось.
(7) gubanoff, есть, вам нужна одна простая командаhttps://github.com/xDrivenDevelopment/v83unpack/blob/develop/src/oscript/un pack.os#L526
(8) pumbaE, а где брать 4-ю версию Elisy .Net Bridge? Поискал, но не нашел где вы ее выкладываете.
(9) gubanoff, а причем тут я? Это к Elisy обращайтесь.
https://github.com/xDrivenDevelopment .
Я конкурент, обработка была написана на чистом 1с, дописана на чистом oscript (тоже 1с) и отдана в общественное достояние, дорабатывается в проекте
Позволяет просто разобрать/собрать cf в/из исходников, на базе этого позволяет синхронизировать хранилище 1с с git.
p.s.: А elisy еще выдумывать и выдумывать свои велосипеды, не удивлюсь, если еще за тесты возьметесь и все на базе Elisy .Net Bridge …
А в чём преимущества данного проекта над аналогом изhttps://github.com/xDrivenDevelopment ?
(9) gubanoff,
На Инфостарт можно найти на странице
http://infostart.ru/public/20035/
(10) pumbaE,
За тесты пока не возьмусь — есть более интересное направление: SDK и API для динамического построения конфигураций 1С.
Обычно, за что берусь, написано под .Net. Как следствие все написанное под .Net сразу становится доступным в 1С через Elisy .Net Bridge без танцев с бубном.
(12) спасибо, скачал, запустил, получил конфигурацию, разложенную по папкам. Правда, возникла ошибка, но для меня это не важно. С другой стороны это же можно было и на 1С написать — сортировку по папкам я имею ввиду.
(10) pumbaE, спасибо, я сразу не понял ху ис ху.
(8) pumbaE, подскажите — как это использовать? Создать обработку в нее скопировать текст или как?
(14) сначало писал на node.js в асинхронном режим, но что даст эта «многопоточность», «асинхронность», когда узким местом оказались диски…, загрузка конфигурации в пустую базу — нагрузка на диски, выгрузка в xml — нагрузка на диски и уже конечное переименование этого всего небольшой процент от всего времени которое необходимо на полный цикл выгрузки.
(14) на github есть wikihttps://github.com/xDrivenDevelopment/v83unpack/wiki
https://github.com/xDrivenDevelopment/v83unpack/wiki
(16)
(15) gubanoff,
http://infostart.ru/public/331927/
Да, конечно можно на 1С написать. Я алгоритм описывал здесь:
Обработка для тех, кто не хочет возиться. И если будет популярная, есть потенциал для доработки.
(17) pumbaE,
Это если ограничиться переименовыванием. Тему выгрузки можно продолжить еще дальше — на лету обрабатывать XML. Например, не выгружать значения по умолчанию — конечный объем сократится по грубым оценкам в 1.5 раза, а если выгружать в альтернативный формат, то в 2 раза.
(18) pumbaE,
Уже ближе к теме. xDrivenDevelopment сбивает очень с толку, а v83unpack — более раскрученное название.
CfProject и v83unpack — конкуренты. Они оба нацелены на cf-файлы.
XmlProject нисколько не конкурент v83unpack, скорее
(20) видно вы только начинаете еще с этим работать, к сожалению еще сама 1с не определилась с форматом xml файла и переодически подкидывает то реквизиты считаем по умолчанию, то заполнять их надо null , т.е. с выходом новой версии может все поменяться и вряд-ли. Единственный момент где необходима серьезная оптимизация формата — это роли. Ну и не пихать в макеты бинарные данные или правила обмена на 5 метров, но это уже к разработчикам.
(22) pumbaE,
Сейчас именно тот момент, когда отсутствие опыта работы с XML — это преимущество. Зная стиль 1С по выводу на рынок полуфабрикатов, я старался как можно дальше отодвинуть момент знакомства с XML. Судя по вашим словам, оказался прав. На грабли, связанные с изменением формата попались вы )))) — более опытные товарищи.
Тем не менее, нестабильный формат XML — явление временное и когда-то он установится. И если смотреть в будущее, то XML более перспективный формат из-за открытости и наглядности.