Уж коли пользуетесь гитом, позволю себе задать вопрос.
Реально ли изменить одну и ту же, например, форму двумя разными разработчиками (без использования хранилища) и, используя только выгрузку в файлы, после обычного текстового мерджа загрузить из файла готовую форму с изменениями?
Поясню - данные об объектах/формах/etc выгружаются в XML. Соответственно, когда два разработчика что-то меняют в форме, их измененные формы тоже выгружаются в XML. После push'а мы либо получим валидную XML, которую можем обратно свернуть в форму, либо полную кашу в случае, если 1с выгружает формы "каждый раз по-разному".
Хочу глобально изучить вопрос перевода контроля версий и групповой разработки на git, но как-то постоянно не нахожу на это времени :)
(1) nixel, Gitter никак не расчитан на использование без хранилища 1С. При использовании Gitter описанной проблемы быть не может.
Отвечая на ваш вопрос могу сказать, что отказ от хранилища в пользу других систем версионирования, таких как git, это достаточно серьезный и сложный шаг. У меня нет такого опыта использования Git. В вашем примере, второй разработчик, который выполняет push, вначале будет обязан выполнить pull, при этом он может получить коллизию при объединении файлов форм, которую сам и должен будет разрешить. При условии что Git ничего не знает о форматах, таких например как xml, то я бы не стал исключать вероятности получения невалидного файла формы после объединения, хотя если посмотреть форматирование xml файла формы, который формирует платформа 1С, то кажется, что эта вероятность сведена к минимуму.
(1) nixel, для модулей все без проблем, для всяких внутренних объектов, разработчику в случаи конфликта, необходимо собрать из исходников cf (тот cf который пришел из мастер ветки), объединить его со свое кофнигурацией, при этом объединять подглядывая в diff между ветками, где оставлять свой вариант, где чужой. Конфликты самому решать, для модулей подойдет штатное трехстороннее сравннеи, для форм, ролей как повезет.
После этого разбирает получившийся cf в папку с merge и коммитит.
1. Скорость получения версии cf из хранилища, только с toolCD удалось ускориться в несколько раз по сравнению со штатной выгрузкой 1С из хранилища по номеру.
2. на маленьких конфигурациях этого не видно, но на больших, такие как упп, УТ11 вся конфигурация в одной папке, очень не удобно. При выгрузке не поддерживается того дерева, которое есть в том же конфигураторе. Очень долго искать простейшее "Документ.Реализация.... "
3. Толстые формы выгружаются в запаковоном формате, что-бы вести историю и для модулей толстых форм, приходиться еще их дополнительно распаковывать.
p.s.: у меня как-то так организован процесс разработки redmine+git+1C , тоже использую синхронизацию хранилища с git.
1. Скорость действительно не очень высокая. На средней конфигурации выгрузка одного изменения происходит порядка 3 минут. Это является проблемой только в начале, когда нужно всю накопившуюся историю выгрузить в репозиторий.
2. Полностью с вами согласен. Я не понимаю почему 1С реализовала выгрузку именно так, и я надеюсь что они это переделают. В принципе, после выгрузки файлов конфигурации в каталог репозитория их можно "перекидать" по каталогам. Мысль о такой доработке для Gitter у меня имеется.
3. Да, такая особенность имеется. С ней я не собирался бороться. Хочется использовать только штатные средства.
Спасибо автору за разработку!
Начали с использования 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, Infostart, GitHub), и этих наработок: PBazelyuk, InfostartBitBucket, за что Вам, Евгений, и Петру также отдельное спасибо.
Для распаковки большого количества форм написали обработку-обертку для обработки-декомпилятора, чтобы 1С запускалась 1 раз, а не столько, сколько форм/обработок нужно распаковать. Работает на порядок быстрее.
Интересная разработка.
Спасибо.
Работает вполне корректно.
Пришлось подправить формат номера при получении версии из хранилища. Номер более 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 для форм https://github.com/xDrivenDevelopment/v83unpack/blob/develop/src/oscript/unpack.os#L1759 2. Если хотите посмотреть различия форм, в виде иерархии, тогда вам необходимо для просмотра различий использовать другие инструменты, например v8reader.epf .
(19) pumbaE, cпасибо.
Покопалась в Вашем ГитХабе. Остановилась на v8Reader.epr + diff-1c-cf.js.
Правда, не разобралась, как подключить произвольную программу сравнения к GitExtensions.
Пришлось параллельно поставить TortoiseGit.
Обработки, формы, конфигурации сравнивает вполне корректно.
(20) Мы сейчас активно юзаем SourceTree (бесплатно, только нужно зарегистрироваться на сайте). Очень удобно.
ЗЫ а у меня и SourceTree установлен, и TortoiseGit :) Но SourceTree намного чаще
(23) artbear, kdiff3 мощнее, но я не нашла, как в нем настроить вызов 1С для просмотра форм из GifExtensions.
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 https://github.com/xDrivenDevelopment/precommit1C
Поясни, что подразумевается под "настроить вызов 1С для просмотра форм из GifExtensions." ?
век живи, век учись
в упор не видел эту выгрузку в файлики пока не наткнулся на статью )))
конечно такая выгрузка имеет кучу нюансов, но путь 1с-овцами выбран правильный, посмотрим к чему он приведет.
(7) mikhailovaew, нет, в 8.2 имелась возможность выгрузить только программные модули, справочную информацию и макеты, а в 8.3 в файлы выгружается вся конфигурация
В соседней теме я как раз про такую штуку говорил http://infostart.ru/public/310640/ А тут как говорится "Все уже украдено до нас")
Кажется я смогу сэкономить себе времени. Спасибо.
Спасибо за инструмент. А почему Вы его не выложите на тот же самый гитхаб или битбакет? Тогда все те, кто модифицируют его самостоятельно смогут присылать Вам пул реквесты и Вам будет удобнее отслеживать изменения да и в целом, планировать разработку.
(26) Redokov, пожалуйста. Ссылку на репозиторий bitbucket я ненавязчиво указывал в пункте про открытость. По поводу pull request - Gitter так не работает, он выгружает только в одном направлении, из хранилища 1С в git репозиторий
(28) Elisy, Читал вчера вашу статью, у меня тоже возникало естественное желание раскидать все по папкам, я думаю что разработчики 1С придут к пониманию необходимости этого. В качестве примера можно посмотреть исходники Gitter - https://bitbucket.org/rtnm/gitter/src
Добрый день.
У меня возникла ошибка
{ОбщийМодуль.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)
Команда проверки состояния сообщит, что коммитить нечего. Это означает, что в репозитории хранится текущее состояние рабочего каталога, и нет никаких изменений, ожидающих записи.
У меня первый коммит прошел, а второй нет.
Т.о. получается, что первая версия хранилища равна второй, но это не так.
(34) cmd_vasec, сложно понять где пошел сбой, нужно проанализировать, что именно прошло первым коммитом, посмотреть что именно сейчас находится в рабочем каталоге и какой версии хранилища соответствует, посмотреть на состояние записей справочника ВыгруженаВЛокальныйРепозиторий и в частности на флажок ВыгруженаВЛокальныйРепозиторий, возможно нужно этот флажок сбросить, чтобы еще раз попытаться выгрузить в рабочий каталог проблемную версию хранилища.
Не исключаю, что каким-то образом первым коммитом ушла последняя версия хранилища. Какая версия платформы?
Если это выполнить с английскими региональным установками, то СтрЗаменить не сработает, т.к. у них разделитель разрядов - запятая.
Надо Формат(НомерВерсии, "ЧГ=")
(43) На мой взгляд с конфой работать гораздо нагляднее и удобнее, если она заточена тупо на выгрузку в гит.
Если используешь гитфлоу, то командная строка в виде gitsync рулит.
1С гит конвертер попробовал, тоже работает, но создает мусор в виде транзитных конфигураций в списке баз, ну и я уже как-то привык к gitter-у, допилил под себя, запустил на сервере.