Comments 46
Суть статьи.
Система контроля версий хорошо.
SVN тупит при большом количестве маленьких фалов.
Освоить нормировку XML это для слабаков.
Для github использовать github client.
Система контроля версий хорошо.
SVN тупит при большом количестве маленьких фалов.
Освоить нормировку XML это для слабаков.
Для github использовать github client.
Немного по-другому:
Система контроля версия лучше, чем Хранилище конфигураций 1С
Из систем контроля версий пока лучше GitHub
До 1С 8.3 нельзя было красиво сделать публикацию в GitHub
В 1С 8.3 без обработок сторонними средствами все равно нельзя сделать красивую выгрузку в GitHub
Для GitHub проще использовать GitHub Client, а не, например, Tortoise GitHub client.
Система контроля версия лучше, чем Хранилище конфигураций 1С
Из систем контроля версий пока лучше GitHub
До 1С 8.3 нельзя было красиво сделать публикацию в GitHub
В 1С 8.3 без обработок сторонними средствами все равно нельзя сделать красивую выгрузку в GitHub
Для GitHub проще использовать GitHub Client, а не, например, Tortoise GitHub client.
Для GitHub проще использовать GitHub Client, а не, например, Tortoise GitHub client.Это же хабр. Мы не хотим как проще, мы хотим как лучше )
Откуда вообще мысли использовать клиент GitHub для GitHub.
Это все го лишь удобная веб оболочка для git репозитория, то почему бы не пользоваться любым удобным git клиентом, от консольного, заканчивая SourceTree или GitExtentions
Это все го лишь удобная веб оболочка для git репозитория, то почему бы не пользоваться любым удобным git клиентом, от консольного, заканчивая SourceTree или GitExtentions
Что-то мешает использовать другого клиента? Клиент GitHub для GitHub — это самое простое и надежное решение. После его освоения можно эстетствовать с другими клиентами.
Простое потому что мало кнопок? Этим клиентом более-менее ещё можно пользоваться, если вы с проектом работаете один (да и то бывают проблемы). А уже когда начинается совместное использование, то мерджи и прочее в сущий ад превращается.
Проще всё же использовать консольный git. Один раз почитать документацию и научиться работать с любым git-хостингом. К тому же автоматизировать проще.
«Лучше день потерять, потом за пять минут долететь» © м/ф.
«Лучше день потерять, потом за пять минут долететь» © м/ф.
Elisy, вот ты опять велосипедишь, вместо того, чтобы контрибьютить в сообщество. Ведь уже давно есть открытые проекты синхронизации 1С и git. Мы у себя ими активно пользуемся в production системах. Ты сделал ровно то, что сообщество сделало уже год назад. Нет, вместо участия и вклада, взял и сделал свой велосипед… Странные люди…
Не понятны обиды. Данная статья, где делюсь опытом, разве не «контрибьюция в сообщество»? Было у меня время на новогодних каникулах, сделал эксперимент, оформил в виде серии понятных логически завершенных статей. Опубликовал. Сообществу полезно будет. Комментарии еще полезнее.
До этого я не встречал технологии публикации 1С в системах версионирования, которая бы меня устроила. Ваш пример xDrivenDevelopment/v83unpack
меня тоже не устраивает, так как основан на внутреннем формате 1С, который не обладает наглядностью.
До этого я не встречал технологии публикации 1С в системах версионирования, которая бы меня устроила. Ваш пример xDrivenDevelopment/v83unpack
меня тоже не устраивает, так как основан на внутреннем формате 1С, который не обладает наглядностью.
Как раз там используется штатная выгрузка в XML средствами 8.3, а потом точно такой же алгоритм раскладывания по папкам. Поэтому я и назвал «велосипедом», ибо делает ровно то же самое.
Обид лично на вас нету. Некоторая досада есть на само положение дел, что вроде в сообществе 1С-ников много компетентных авторов, но всем обязательно нужен свой велосипед вместо консолидации усилий. Одних только проектов синхронизаций с git я знаю не менее трех. Тот, что я привел, наиболее развит в плане наступленных граблей. Т.е. в этом проекте накоплен опыт обхода и решения многих встречающихся проблем. Всем новым проектам еще предстоит по ним пройти. xDrivenDevelopment/v83unpack занимается именно синхронизацией. Мониторит хранилище, определяет уже синхронизированные коммиты и добавляет в git новые.
Ну и кроме того, задача запуска 1С с ключом выгрузки исходников и раскладывание их по папкам на основании их имени — это задача для несложного скрипта. Имхо, писать для этого целый солюшен на .net — как-то тяжеловато. Скриптом проще поделиться с коллегами.
Итого, это не критика лично вас, а вздох и инкремент счетчика «еще один проект 1С+git».
Обид лично на вас нету. Некоторая досада есть на само положение дел, что вроде в сообществе 1С-ников много компетентных авторов, но всем обязательно нужен свой велосипед вместо консолидации усилий. Одних только проектов синхронизаций с git я знаю не менее трех. Тот, что я привел, наиболее развит в плане наступленных граблей. Т.е. в этом проекте накоплен опыт обхода и решения многих встречающихся проблем. Всем новым проектам еще предстоит по ним пройти. xDrivenDevelopment/v83unpack занимается именно синхронизацией. Мониторит хранилище, определяет уже синхронизированные коммиты и добавляет в git новые.
Ну и кроме того, задача запуска 1С с ключом выгрузки исходников и раскладывание их по папкам на основании их имени — это задача для несложного скрипта. Имхо, писать для этого целый солюшен на .net — как-то тяжеловато. Скриптом проще поделиться с коллегами.
Итого, это не критика лично вас, а вздох и инкремент счетчика «еще один проект 1С+git».
1. Дайте пожалуйста адрес репозитария, где можно посмотреть пример выгрузки конфигурации, полученного вашим инструментом? Чтобы можно было объективно сравнить с примером github.com/elisy/ssl
2. Проект хорош тогда, когда о нем знают. Дайте пожалуйста адреса статей, где можно почитать о вашем подходе выгрузки в репозитарии. Сейчас обсуждаю на мисте эту статью — человека 3 признались, что давно работают с репозитарием. У каждого в этом случае есть проект и каждый может вздыхать, что появился еще один велосипед.
3. .net выбран еще и потому, что обработку файлов легко на нем распараллелить. Это значит, что обработка займет в несколько раз меньше времени, чем на скрипте.
4. Про консолидацию усилий — консолидироваться можно, когда все участники разговаривают на одном языке — на Java, PHP, 1С или на C#. Если вы, например, разговариваете на 1С или Python, я не подойду вам из-за разговора на C#. Если я начну разговаривать на Python с непривычки, то результат моей работы будет некачественным. А на 1С я не буду писать из-за того, что 1С не приспособлен к решению таких задач, и потому что он очень медленный.
2. Проект хорош тогда, когда о нем знают. Дайте пожалуйста адреса статей, где можно почитать о вашем подходе выгрузки в репозитарии. Сейчас обсуждаю на мисте эту статью — человека 3 признались, что давно работают с репозитарием. У каждого в этом случае есть проект и каждый может вздыхать, что появился еще один велосипед.
3. .net выбран еще и потому, что обработку файлов легко на нем распараллелить. Это значит, что обработка займет в несколько раз меньше времени, чем на скрипте.
4. Про консолидацию усилий — консолидироваться можно, когда все участники разговаривают на одном языке — на Java, PHP, 1С или на C#. Если вы, например, разговариваете на 1С или Python, я не подойду вам из-за разговора на C#. Если я начну разговаривать на Python с непривычки, то результат моей работы будет некачественным. А на 1С я не буду писать из-за того, что 1С не приспособлен к решению таких задач, и потому что он очень медленный.
Согласен. По пунктам 2 и 4 — особенно. Репо дать не могу, ибо они наши внутренние и закрытые. О проектах на github мне, к сожалению, неизвестно. Попробую сделать демо-пример, но чуть позже, ок?
Что касается опять же пункта 4, то в этом направлении есть надежда — сейчас мы все наработки постепенно переводим на OneScript. Это как раз lingua franca, на котором разговаривают все одинэсники. Собственно, исходный v83unpack, который представлял собой epf-обработку 1С, мы перевели на скриптинг и пользуемся именно «скриптовым» вариантом.
Ну а насчет статьей — они обязательно нужны, напишу.
Что касается опять же пункта 4, то в этом направлении есть надежда — сейчас мы все наработки постепенно переводим на OneScript. Это как раз lingua franca, на котором разговаривают все одинэсники. Собственно, исходный v83unpack, который представлял собой epf-обработку 1С, мы перевели на скриптинг и пользуемся именно «скриптовым» вариантом.
Ну а насчет статьей — они обязательно нужны, напишу.
Вот пример выгрузки конфигурации, сделанный v83unpack
Начинаем сравнивать выгруженные сравнимые вещи: например, справочник Валюты
bitbucket.org/Shenja/elementaltrade/src/a018bb29fe2e7edb59188cc25bb7771516ba99ad/src/Catalog/%D0%92%D0%B0%D0%BB%D1%8E%D1%82%D1%8B/?at=master
и
github.com/elisy/ssl/tree/master/Catalog/%D0%92%D0%B0%D0%BB%D1%8E%D1%82%D1%8B
Все хорошо, пока дело не касается деталей. Но вот я вижу, что в вашем случае Help.xml вынесен из папки Help, а в моем — внесен в папку. Что это значит? Это значит, что если help.xml поменяется, то его изменения не отследишь по папке Help (что было бы логичным), потому что он принадлежит родительской папке. Такое поведение у вас и у форм — ФормаЭлемента.xml вынесена из папки Forms/ФормаЭлемента.
Судя по всему не на все грабли вы еще наступили. Поэтому рассматривать ваш проект, как нечто идеальное, лишенное недостатков, нельзя. Так как это идеальное не продумано в деталях, не описано. В данном конкретном случае (проекты нетрудоемкие) конкуренция, как двигатель прогресса, пойдет на пользу двум проектам.
bitbucket.org/Shenja/elementaltrade/src/a018bb29fe2e7edb59188cc25bb7771516ba99ad/src/Catalog/%D0%92%D0%B0%D0%BB%D1%8E%D1%82%D1%8B/?at=master
и
github.com/elisy/ssl/tree/master/Catalog/%D0%92%D0%B0%D0%BB%D1%8E%D1%82%D1%8B
Все хорошо, пока дело не касается деталей. Но вот я вижу, что в вашем случае Help.xml вынесен из папки Help, а в моем — внесен в папку. Что это значит? Это значит, что если help.xml поменяется, то его изменения не отследишь по папке Help (что было бы логичным), потому что он принадлежит родительской папке. Такое поведение у вас и у форм — ФормаЭлемента.xml вынесена из папки Forms/ФормаЭлемента.
Судя по всему не на все грабли вы еще наступили. Поэтому рассматривать ваш проект, как нечто идеальное, лишенное недостатков, нельзя. Так как это идеальное не продумано в деталях, не описано. В данном конкретном случае (проекты нетрудоемкие) конкуренция, как двигатель прогресса, пойдет на пользу двум проектам.
Я и не говорил про отсутствие недостатков, и уж тем более, про идеал. Я говорил про то, что например, поведение с папкой help (и другие улучшения) желательно применять в одном проекте, двигая его вперед. Конкуренция тоже дело хорошее. Я еще не смотрел Gitter, который привели в каментах ниже. Тем не менее, я сторонник консолидации усилий в проектах, которые открыты и бесплатны. Конкуренция хороша в погоне за прибылью. А в проектах энтузиастов это часто приводит к распылению усилий, решению одних и тех же проблем и угасанию энтузиазма. Я ведь не срача ради вам тут пишу)
Честно говоря, после ваших фраз: «ты опять велосипедишь», «всем новым проектам еще предстоит наступать на грабли», «ХХХ уже давно реализовано в нашем проекте», мне действительно показалось, что ваш проект – идеал, который был мною упущен из виду, к которому следует всем остальным стремиться.
Ну этот проект (кстати, он не мой, я подключился, как контрибьютор не так давно) действительно, на мой взгляд, самый развитый из тех, что я пробовал. Он уже применяется в реальных бизнес-задачах в ряде немаленьких компаний. В частности, весь код-ревью по нашим проектам мы ведем по исходникам, лежащим в гит.
Ну а фразы про «велосипедишь» и «грабли» они не противоречат отсутствию идеала. Можно не иметь идеала и продолжать «велосипедить», создавая еще больше «неидеалов», вместо стремления к идеалу.
Короче, это софистика, я умываю руки.
Ну а фразы про «велосипедишь» и «грабли» они не противоречат отсутствию идеала. Можно не иметь идеала и продолжать «велосипедить», создавая еще больше «неидеалов», вместо стремления к идеалу.
Короче, это софистика, я умываю руки.
Если через 6-7 месяцев у конфигуратора изменится поведение, то вся структура раскладки «в четком соответствии по точкам» рухнет. Будет новая структура каталогов. Причем для систем версионирования это будет равнозначно как удаление файлов и создание файлов в новом каталоге, т.е. версионирование на данном этапе прекращается.
В моем же случае, когда сначала планируется результат, а нет привязки к точкам, даже при изменении характера выгрузки 1С выгрузка будет идти однотипно. Я остаюсь при своем мнении, что Help.xml должен быть внутри папки Help, также как и описатели форм в папках для конкретной формы, чтобы по конкретной папке можно было отследить историю работы с этими объектами.
В моем случае ведется файл откуда-куда скопирован файл github.com/elisy/ssl/blob/master/Configuration.xmlproj
В моем же случае, когда сначала планируется результат, а нет привязки к точкам, даже при изменении характера выгрузки 1С выгрузка будет идти однотипно. Я остаюсь при своем мнении, что Help.xml должен быть внутри папки Help, также как и описатели форм в папках для конкретной формы, чтобы по конкретной папке можно было отследить историю работы с этими объектами.
В моем случае ведется файл откуда-куда скопирован файл github.com/elisy/ssl/blob/master/Configuration.xmlproj
Вообще-то git корректно понимает перемещение файла, и в логе это отображает соответствующим образом.
Я намеренно про Git в комментарии ничего не написал, потому что не знаю всех его особенностей. SVN не понимает — для него будет такая операция равносильна удалению файла и добавлению файла в другом каталоге. Если нужно показать SVN копирование, нужно на клиенте SVN явно указывать, что файл был скопирован.
В любом случае система получается не универсальная.
В любом случае система получается не универсальная.
Ну я-то как раз с тобой согласен, что текущее поведение правильное. А мой камент был о том, что дискуссии о поведении и предложения по поведению намного продуктивнее вести в рамках какого-то конкретного проекта. Просто пример со справкой неудачно выбрал.
А из всех этих папок с xml файлами как потом загрузить конфигурацию в 1С обратно?
Ps Ждём на GitHub выбор языка 1С
Ps Ждём на GitHub выбор языка 1С
Учитывая, что сейчас преобразование заключается только в переименовании файлов без потери значимой информации, можно придумать обратный алгоритм копирования по полному пути в единую папку. Из единой папки загружать в 1С.
И это тоже уже давно реализовано v83unpack. Я осознал, что нужна полноценная статья. В сообществе очень большой перечень наработок для «правильной» разработки под 1С.
Кстати, опыт обратной сборки пока не очень удачный. В официальном баг-трекере платформы мы зарегистрировали подтвержденный баг обратной сборки из XML.
Кстати, опыт обратной сборки пока не очень удачный. В официальном баг-трекере платформы мы зарегистрировали подтвержденный баг обратной сборки из XML.
Поделитесь опытом загрузки из файлов обратно в конфигурацию. Столкнулся с тем, что если в Конфигурации (например, в типовой БП) в общем макете используются «Общие стили» — загрузить конфигурацию из командной строки не получается — вываливается без объяснения причин (экспериментально нашел причину). При этом в интерактивном режиме загрузка проходит без проблем.
Пробовал на самых свежих версиях платформы — ошибка везде воспроизводится.
В понедельник попробую зафиксировать ошибку в 1С
Пробовал на самых свежих версиях платформы — ошибка везде воспроизводится.
В понедельник попробую зафиксировать ошибку в 1С
А вот это кто-нибудь пробовал?
Gitter (Хранилище 1С => Git)
Gitter (Хранилище 1С => Git)
Как раз на этой неделе запустил. Доработал под себя (фоновые задания, раскладываение по папкам перед размещенеим в репозиторий, формирование версии не путем обновления, а путем создания новой конфигурации из выгруженного cf-файла).
Вроде работает, но долго: выгрузка одной версии БП 3.0 занимает порядка получаса.
Вроде работает, но долго: выгрузка одной версии БП 3.0 занимает порядка получаса.
Я все смотрю на ваш проект, но не хвататет времени разобраться с ним детально.
Задам несколько вопросов:
Задам несколько вопросов:
- Я дописал в Gitter что-то типа прекоммита: раскладываю файлы по папкам (разбиваю пути по точкам в имени исходного файла). Ваш проект использует ту же систему раскладки?
- Мы при разработке изспользуем Хранилище от 1С — и это решение непоколебимо. Совместим ли ваш проект с работой с Хранилищем? А то мне попадалась статья, где как раз уходят от Хранилища в сторону Репозиториев
- Есть ли какое-нить описание, как можно быстро развернуть ваш проект на замену тому же Gitter, например?
Тормозит на этапе выгрузки из 1С или в момент раскладывания по папкам?
Продолжу про велосипеды: я себе давно навелосипедил простую программку, которая раскладывает выгруженные файлы по папкам, и потом назад складывает в кучу.
Работает она только с выгрузкой 8.1/8.2 (на тот момент 8.3 ещё не было), и использую я её только для модулей (т.е. для кода). Это мне дает легко обновлять измененные типовые — т.к. формы я меняю только программно.
Так вот. Самое неприятное тут — это то, что выгрузка/загрузка работает очень медленно… особенно для монстра УПП.
Тут ИМХО лучше смотреть в сторону дополнения конфигуратора родными средствами работы с VCS. Вот в 8.3 хранилище уже заметно ускорили. Осталось выкинуть и заменить git-ом :)
Работает она только с выгрузкой 8.1/8.2 (на тот момент 8.3 ещё не было), и использую я её только для модулей (т.е. для кода). Это мне дает легко обновлять измененные типовые — т.к. формы я меняю только программно.
Так вот. Самое неприятное тут — это то, что выгрузка/загрузка работает очень медленно… особенно для монстра УПП.
Тут ИМХО лучше смотреть в сторону дополнения конфигуратора родными средствами работы с VCS. Вот в 8.3 хранилище уже заметно ускорили. Осталось выкинуть и заменить git-ом :)
Решилась проблема с SVN. Клиент зависал из-за неверной сетевой настройки сервера SVN и проброски портов. После устранения проблемы скорость просмотра логов стала приемлемой.
В новых версиях 1с есть выгрузка в файлы по папкам. Так что программа С++ не нужна.
Правда, не знаю, работает ли в режиме командной строки выгрузка по папкам.
Правда, не знаю, работает ли в режиме командной строки выгрузка по папкам.
Sign up to leave a comment.
Публикация конфигурации 1С на GitHub