Gitter (Хранилище 1С => Git)
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Уж коли пользуетесь гитом, позволю себе задать вопрос.
Реально ли изменить одну и ту же, например, форму двумя разными разработчиками (без использования хранилища) и, используя только выгрузку в файлы, после обычного текстового мерджа загрузить из файла готовую форму с изменениями?
Поясню - данные об объектах/формах/etc выгружаются в XML. Соответственно, когда два разработчика что-то меняют в форме, их измененные формы тоже выгружаются в XML. После push'а мы либо получим валидную XML, которую можем обратно свернуть в форму, либо полную кашу в случае, если 1с выгружает формы "каждый раз по-разному".
Хочу глобально изучить вопрос перевода контроля версий и групповой разработки на git, но как-то постоянно не нахожу на это времени :)
Реально ли изменить одну и ту же, например, форму двумя разными разработчиками (без использования хранилища) и, используя только выгрузку в файлы, после обычного текстового мерджа загрузить из файла готовую форму с изменениями?
Поясню - данные об объектах/формах/etc выгружаются в XML. Соответственно, когда два разработчика что-то меняют в форме, их измененные формы тоже выгружаются в XML. После push'а мы либо получим валидную XML, которую можем обратно свернуть в форму, либо полную кашу в случае, если 1с выгружает формы "каждый раз по-разному".
Хочу глобально изучить вопрос перевода контроля версий и групповой разработки на git, но как-то постоянно не нахожу на это времени :)
(1) nixel, Gitter никак не расчитан на использование без хранилища 1С. При использовании Gitter описанной проблемы быть не может.
Отвечая на ваш вопрос могу сказать, что отказ от хранилища в пользу других систем версионирования, таких как git, это достаточно серьезный и сложный шаг. У меня нет такого опыта использования Git. В вашем примере, второй разработчик, который выполняет push, вначале будет обязан выполнить pull, при этом он может получить коллизию при объединении файлов форм, которую сам и должен будет разрешить. При условии что Git ничего не знает о форматах, таких например как xml, то я бы не стал исключать вероятности получения невалидного файла формы после объединения, хотя если посмотреть форматирование xml файла формы, который формирует платформа 1С, то кажется, что эта вероятность сведена к минимуму.
Отвечая на ваш вопрос могу сказать, что отказ от хранилища в пользу других систем версионирования, таких как git, это достаточно серьезный и сложный шаг. У меня нет такого опыта использования Git. В вашем примере, второй разработчик, который выполняет push, вначале будет обязан выполнить pull, при этом он может получить коллизию при объединении файлов форм, которую сам и должен будет разрешить. При условии что Git ничего не знает о форматах, таких например как xml, то я бы не стал исключать вероятности получения невалидного файла формы после объединения, хотя если посмотреть форматирование xml файла формы, который формирует платформа 1С, то кажется, что эта вероятность сведена к минимуму.
(1) nixel, для модулей все без проблем, для всяких внутренних объектов, разработчику в случаи конфликта, необходимо собрать из исходников cf (тот cf который пришел из мастер ветки), объединить его со свое кофнигурацией, при этом объединять подглядывая в diff между ветками, где оставлять свой вариант, где чужой. Конфликты самому решать, для модулей подойдет штатное трехстороннее сравннеи, для форм, ролей как повезет.
После этого разбирает получившийся cf в папку с merge и коммитит.
После этого разбирает получившийся cf в папку с merge и коммитит.
1. Скорость получения версии cf из хранилища, только с toolCD удалось ускориться в несколько раз по сравнению со штатной выгрузкой 1С из хранилища по номеру.
2. на маленьких конфигурациях этого не видно, но на больших, такие как упп, УТ11 вся конфигурация в одной папке, очень не удобно. При выгрузке не поддерживается того дерева, которое есть в том же конфигураторе. Очень долго искать простейшее "Документ.Реализация.... "
3. Толстые формы выгружаются в запаковоном формате, что-бы вести историю и для модулей толстых форм, приходиться еще их дополнительно распаковывать.
p.s.: у меня как-то так организован процесс разработки , тоже использую синхронизацию хранилища с git.
2. на маленьких конфигурациях этого не видно, но на больших, такие как упп, УТ11 вся конфигурация в одной папке, очень не удобно. При выгрузке не поддерживается того дерева, которое есть в том же конфигураторе. Очень долго искать простейшее "Документ.Реализация.... "
3. Толстые формы выгружаются в запаковоном формате, что-бы вести историю и для модулей толстых форм, приходиться еще их дополнительно распаковывать.
p.s.: у меня как-то так организован процесс разработки , тоже использую синхронизацию хранилища с git.
(3) pumbaE,
1. Скорость действительно не очень высокая. На средней конфигурации выгрузка одного изменения происходит порядка 3 минут. Это является проблемой только в начале, когда нужно всю накопившуюся историю выгрузить в репозиторий.
2. Полностью с вами согласен. Я не понимаю почему 1С реализовала выгрузку именно так, и я надеюсь что они это переделают. В принципе, после выгрузки файлов конфигурации в каталог репозитория их можно "перекидать" по каталогам. Мысль о такой доработке для Gitter у меня имеется.
3. Да, такая особенность имеется. С ней я не собирался бороться. Хочется использовать только штатные средства.
1. Скорость действительно не очень высокая. На средней конфигурации выгрузка одного изменения происходит порядка 3 минут. Это является проблемой только в начале, когда нужно всю накопившуюся историю выгрузить в репозиторий.
2. Полностью с вами согласен. Я не понимаю почему 1С реализовала выгрузку именно так, и я надеюсь что они это переделают. В принципе, после выгрузки файлов конфигурации в каталог репозитория их можно "перекидать" по каталогам. Мысль о такой доработке для Gitter у меня имеется.
3. Да, такая особенность имеется. С ней я не собирался бороться. Хочется использовать только штатные средства.
Спасибо автору за разработку!
Начали с использования git для внешних обработок + Redmine. Понравилось.
Решили перетащить историю хранилища также в git, ибо скорость сравнения версий в хранилище не сопоставима с таковой в git. Также после выгрузки файлов конфигурации в git сравнение ролей и списков предопределенных доступно "из коробки" (xml). Плюс blame. Плюс авто-подкрепление коммитов к задаче в Redmine.
Ваше решение подошло практически полностью. Что изменили:
(3) pumbaE, п.2: решили выделением всего до первой точки в папку (Document, Catalog). Получилась структура, более-менее привычная. И Explorer/GitExtensions перестали тормозить от 10000+ файлов в одном каталоге. Если нужно, python-скрипт могу выслать.
(3) pumbaE, п.3: распаковываем, извлекаем только модуль. Раньше еще "декомпилировали" обычные формы, но поняли, что то, что получается, смотреть тоже не ахти как удобно, да и не все аспекты декомпилируются. Кроме того, на некоторых формах платформа вываливалась в дамп (если интересно, тест для воспроизведения ошибки есть).
Для распаковки большого количества форм написали обработку-обертку для обработки-декомпилятора, чтобы 1С запускалась 1 раз, а не столько, сколько форм/обработок нужно распаковать. Работает на порядок быстрее.
В качестве обработки-декомпилятора и precommit-скриптов используем помеси Ваших (pumbaE, , ), и этих наработок: PBazelyuk, , за что Вам, Евгений, и Петру также отдельное спасибо.
Начали с использования git для внешних обработок + Redmine. Понравилось.
Решили перетащить историю хранилища также в git, ибо скорость сравнения версий в хранилище не сопоставима с таковой в git. Также после выгрузки файлов конфигурации в git сравнение ролей и списков предопределенных доступно "из коробки" (xml). Плюс blame. Плюс авто-подкрепление коммитов к задаче в Redmine.
Ваше решение подошло практически полностью. Что изменили:
- Убрали папку "Конфигурация", в которую сгружались все файлы. В итоге папки/файлы располагаются сразу в корневой папке репозитория.
- По мелочи: увеличили размер реквизита "Комментарий"; в коммит вставляется номер версии из хранилища; сделали подмену имени пользователя из хранилища в имя пользователя git.
(3) pumbaE, п.2: решили выделением всего до первой точки в папку (Document, Catalog). Получилась структура, более-менее привычная. И Explorer/GitExtensions перестали тормозить от 10000+ файлов в одном каталоге. Если нужно, python-скрипт могу выслать.
(3) pumbaE, п.3: распаковываем, извлекаем только модуль. Раньше еще "декомпилировали" обычные формы, но поняли, что то, что получается, смотреть тоже не ахти как удобно, да и не все аспекты декомпилируются. Кроме того, на некоторых формах платформа вываливалась в дамп (если интересно, тест для воспроизведения ошибки есть).
Для распаковки большого количества форм написали обработку-обертку для обработки-декомпилятора, чтобы 1С запускалась 1 раз, а не столько, сколько форм/обработок нужно распаковать. Работает на порядок быстрее.
В качестве обработки-декомпилятора и precommit-скриптов используем помеси Ваших (pumbaE, , ), и этих наработок: PBazelyuk, , за что Вам, Евгений, и Петру также отдельное спасибо.
(9) mikhailv, я в основном использую вот этот инструментарий .
Для распаковки большого количества форм написали обработку-обертку для обработки-декомпилятора, чтобы 1С запускалась 1 раз, а не столько, сколько форм/обработок нужно распаковать. Работает на порядок быстрее.
если есть возможность, прошу pull-request.
Интересная разработка.
Спасибо.
Работает вполне корректно.
Пришлось подправить формат номера при получении версии из хранилища. Номер более 1000 передавался как 1 000. Думаю, не хватает еще регламентного задания. Чтобы настроить и больше не трогать.
(9) mikhailv, Тоже увеличила ширину поля комментария и добавила номер версии.
Структуру не трогали. В ней очень удобно ищутся данные поиском по Ctrl+F в Gif Extensions. С папками, возможно, будет хуже.
При стандартной выгрузке не выгружаются в текст обычные формы. В результате при сравнении
Подскажите какое-то простое решение. Либо как распаковать перед соммитом, либо может есть какой-то вариант сравнения чем-то другим (использую kdiff3).
Спасибо.
Работает вполне корректно.
Пришлось подправить формат номера при получении версии из хранилища. Номер более 1000 передавался как 1 000. Думаю, не хватает еще регламентного задания. Чтобы настроить и больше не трогать.
(9) mikhailv, Тоже увеличила ширину поля комментария и добавила номер версии.
Структуру не трогали. В ней очень удобно ищутся данные поиском по Ctrl+F в Gif Extensions. С папками, возможно, будет хуже.
При стандартной выгрузке не выгружаются в текст обычные формы. В результате при сравнении
diff --git a/Конфигурация/Catalog.Номенклатура.Form.ФормаЭлемента.Form b/Конфигурация/Catalog.Номенклатура.Form.ФормаЭлемента.Form
index 83c2a4c..962f1a1 100644
Binary files a/Конфигурация/Catalog.Номенклатура.Form.ФормаЭлемента.Form and b/Конфигурация/Catalog.Номенклатура.Form.ФормаЭлемента.Form differПодскажите какое-то простое решение. Либо как распаковать перед соммитом, либо может есть какой-то вариант сравнения чем-то другим (использую kdiff3).
(18) ekaruk, вопрос в том, какие различия вы хотите получить.
1. Если только модуль, тогда дополнительно используете v8unpack.exe для форм
2. Если хотите посмотреть различия форм, в виде иерархии, тогда вам необходимо для просмотра различий использовать другие инструменты, например v8reader.epf .
1. Если только модуль, тогда дополнительно используете v8unpack.exe для форм
2. Если хотите посмотреть различия форм, в виде иерархии, тогда вам необходимо для просмотра различий использовать другие инструменты, например v8reader.epf .
(19) pumbaE, cпасибо.
Покопалась в Вашем ГитХабе. Остановилась на v8Reader.epr + diff-1c-cf.js.
Правда, не разобралась, как подключить произвольную программу сравнения к GitExtensions.
Пришлось параллельно поставить TortoiseGit.
Обработки, формы, конфигурации сравнивает вполне корректно.
upd. Разобралась с GitExtensions.
По аналогии с подключила DiffMerge
Покопалась в Вашем ГитХабе. Остановилась на v8Reader.epr + diff-1c-cf.js.
Правда, не разобралась, как подключить произвольную программу сравнения к GitExtensions.
Пришлось параллельно поставить TortoiseGit.
Обработки, формы, конфигурации сравнивает вполне корректно.
upd. Разобралась с GitExtensions.
По аналогии с подключила DiffMerge
(23) artbear, kdiff3 мощнее, но я не нашла, как в нем настроить вызов 1С для просмотра форм из GifExtensions.
TortoiseGit как-то меньше понравился.
(21) artbear, Да, видела v8diff на ГитХабе. Собственно, из него и взяла diff-1c-cf.js
Насколько я понимаю, v8diff это и есть v8reader + diff-1c-cf.js + ИР.
Или он чем-то еще отличается? В чем смысл отдельного проекта, зачем ИР для сравнения?
TortoiseGit как-то меньше понравился.
(21) artbear, Да, видела v8diff на ГитХабе. Собственно, из него и взяла diff-1c-cf.js
Насколько я понимаю, v8diff это и есть v8reader + diff-1c-cf.js + ИР.
Или он чем-то еще отличается? В чем смысл отдельного проекта, зачем ИР для сравнения?
(24) весь смысл v8diff и есть в связке v8reader + diff.js + ИБ_1С
ИМХО ИР в ИБ не нужен, реально нужен простейший код конфигурации
Я не понимаю, зачем ты юзаешь GifExtensions ? в чем прелесть/преимущество?
ИМХО SourceTree и черепаха и Kdiff3 перекрывают практически все сценарии.
У меня анализ/сравнение используется как для бинарника/epf через v8reader, так и напрямую для текстовых представлений модулей и форм, разобранных через проект precommit1C
Поясни, что подразумевается под "настроить вызов 1С для просмотра форм из GifExtensions." ?
ЗЫ написал в личку, можно ускорить общение :)
ИМХО ИР в ИБ не нужен, реально нужен простейший код конфигурации
Я не понимаю, зачем ты юзаешь GifExtensions ? в чем прелесть/преимущество?
ИМХО SourceTree и черепаха и Kdiff3 перекрывают практически все сценарии.
У меня анализ/сравнение используется как для бинарника/epf через v8reader, так и напрямую для текстовых представлений модулей и форм, разобранных через проект precommit1C
Поясни, что подразумевается под "настроить вызов 1С для просмотра форм из GifExtensions." ?
ЗЫ написал в личку, можно ускорить общение :)
век живи, век учись
в упор не видел эту выгрузку в файлики пока не наткнулся на статью )))
конечно такая выгрузка имеет кучу нюансов, но путь 1с-овцами выбран правильный, посмотрим к чему он приведет.
в общем спасибо за наводку )
в упор не видел эту выгрузку в файлики пока не наткнулся на статью )))
конечно такая выгрузка имеет кучу нюансов, но путь 1с-овцами выбран правильный, посмотрим к чему он приведет.
в общем спасибо за наводку )
Спасибо за инструмент. А почему Вы его не выложите на тот же самый гитхаб или битбакет? Тогда все те, кто модифицируют его самостоятельно смогут присылать Вам пул реквесты и Вам будет удобнее отслеживать изменения да и в целом, планировать разработку.
Добрый день.
У меня возникла ошибка
{ОбщийМодуль.Git.Модуль(81)}: Неизвестная ошибка при совершении комита(git commit -m "Добавить функционал, как в предварительном контакте" --date 2014-09-24T10:11:03)
ВызватьИсключение ИсключениеОшибкаПриВыполненииКоманды(ОписаниеОшибки, ТекстКоманды);
что не так?
У меня возникла ошибка
{ОбщийМодуль.Git.Модуль(81)}: Неизвестная ошибка при совершении комита(git commit -m "Добавить функционал, как в предварительном контакте" --date 2014-09-24T10:11:03)
ВызватьИсключение ИсключениеОшибкаПриВыполненииКоманды(ОписаниеОшибки, ТекстКоманды);
что не так?
(32) cmd_vasec, проблема в том что ВыполнитьКоманду("Путь/до/репозитория", "git commit -m ""Добавить функционал, как в предварительном контакте"" --date 2014-09-24T10:11:03") возвращает ненулевое значение, а значит есть ошибка. Можно запустить туже самую команду в командной строке (cmd.exe) и всего скорее будет видно более внятное описание проблемы. Так же можно доработать само решение (gitter) - перенаправить вывод программы git из стандартного потока ввода-вывода в файл, тогда можно будет получать более внятное описание проблемы. Еще можно в описании ошибки указывать используемый ПутьДоРепозитория при запуске ВыполнитьКоманду - хуже не будет.
(33)
Получил:
On branch master
nothing to commit (working directory clean)
Команда проверки состояния сообщит, что коммитить нечего. Это означает, что в репозитории хранится текущее состояние рабочего каталога, и нет никаких изменений, ожидающих записи.
У меня первый коммит прошел, а второй нет.
Т.о. получается, что первая версия хранилища равна второй, но это не так.
Что делаю не так?
Получил:
On branch master
nothing to commit (working directory clean)
Команда проверки состояния сообщит, что коммитить нечего. Это означает, что в репозитории хранится текущее состояние рабочего каталога, и нет никаких изменений, ожидающих записи.
У меня первый коммит прошел, а второй нет.
Т.о. получается, что первая версия хранилища равна второй, но это не так.
Что делаю не так?
(34) cmd_vasec, сложно понять где пошел сбой, нужно проанализировать, что именно прошло первым коммитом, посмотреть что именно сейчас находится в рабочем каталоге и какой версии хранилища соответствует, посмотреть на состояние записей справочника ВыгруженаВЛокальныйРепозиторий и в частности на флажок ВыгруженаВЛокальныйРепозиторий, возможно нужно этот флажок сбросить, чтобы еще раз попытаться выгрузить в рабочий каталог проблемную версию хранилища.
Не исключаю, что каким-то образом первым коммитом ушла последняя версия хранилища. Какая версия платформы?
Не исключаю, что каким-то образом первым коммитом ушла последняя версия хранилища. Какая версия платформы?
(35)
Почему то выгрузилось последняя версия хранилища. Версия платформы 8.3.5.1482.
Думаю, что не происходит обновление основной конфигурации конфигурацией из хранилища.
Как я правильно понял, в начале мы обновляем основную конфу конфой из хранилища по номеру, а потом выгружает файлы основной конфигурации.
Почему то выгрузилось последняя версия хранилища. Версия платформы 8.3.5.1482.
Думаю, что не происходит обновление основной конфигурации конфигурацией из хранилища.
Как я правильно понял, в начале мы обновляем основную конфу конфой из хранилища по номеру, а потом выгружает файлы основной конфигурации.
Сегодня столкнулся с ошибкой выгрузки хранилища с номером 1000. Автор так и не исправил это.
В Общем модуле ПакетныйРежим в Процедуре ЗагрузитьКонфигурациюИзХанилища() строку
ДобавитьВКомандуКлючЗначение(ТекстКоманды, "-v", НомерВерсии);
заменил на
ДобавитьВКомандуКлючЗначение(ТекстКоманды, "-v", СтрЗаменить(СокрЛП(НомерВерсии),Символы.НПП,""));
В Общем модуле ПакетныйРежим в Процедуре ЗагрузитьКонфигурациюИзХанилища() строку
ДобавитьВКомандуКлючЗначение(ТекстКоманды, "-v", НомерВерсии);
заменил на
ДобавитьВКомандуКлючЗначение(ТекстКоманды, "-v", СтрЗаменить(СокрЛП(НомерВерсии),Символы.НПП,""));
(41)
Если это выполнить с английскими региональным установками, то СтрЗаменить не сработает, т.к. у них разделитель разрядов - запятая.
Надо Формат(НомерВерсии, "ЧГ=")
ДобавитьВКомандуКлючЗначение(ТекстКоманды, "-v", СтрЗаменить(СокрЛП(НомерВерсии),Символы.НПП,""));
Если это выполнить с английскими региональным установками, то СтрЗаменить не сработает, т.к. у них разделитель разрядов - запятая.
Надо Формат(НомерВерсии, "ЧГ=")
(41) (42) Можно использовать мою версию гиттера
А можно взять Гиттер от 1С - ГитКонвертер
И там и там нет проблемы с выгрузкой 999+ версий, и там и там есть инкрементальная выгрузка, что появилась в 8.3.10
Но самым популярным проектом для выгрузки хранилище в гит сейчас является гитсинх
А можно взять Гиттер от 1С - ГитКонвертер
И там и там нет проблемы с выгрузкой 999+ версий, и там и там есть инкрементальная выгрузка, что появилась в 8.3.10
Но самым популярным проектом для выгрузки хранилище в гит сейчас является гитсинх
(43) На мой взгляд с конфой работать гораздо нагляднее и удобнее, если она заточена тупо на выгрузку в гит.
Если используешь гитфлоу, то командная строка в виде gitsync рулит.
1С гит конвертер попробовал, тоже работает, но создает мусор в виде транзитных конфигураций в списке баз, ну и я уже как-то привык к gitter-у, допилил под себя, запустил на сервере.
Если используешь гитфлоу, то командная строка в виде gitsync рулит.
1С гит конвертер попробовал, тоже работает, но создает мусор в виде транзитных конфигураций в списке баз, ну и я уже как-то привык к gitter-у, допилил под себя, запустил на сервере.