Доброго времени суток! Как сделать так, чтобы вместо стандартного редактора кода использовался внешний (например, VS Code)? Версия 1C: 1C:Enterprise 8.3, training version (8.3.8.1933).

(0) EDT поставь если железо позволяет
И да есть плагин под ЯП 1С для VS Code

(1)+ https://edt.1c.ru/
надеюсь с учебной версией платформы EDT пашет

(0) Только платформу учебную возьми поновее ибо 8.3.8 дикое старье

Хорошо, спасибо. :)

(0) Конфигуратор не поддерживает подключение внешних редакторов.
Но можно выгрузить конфигурацию в файлы (в конфигураторе есть такой пунт).
Тогда можно будет модули редактировать любым редактором. После чего собрать конфигурацию обратно из файлов.

(5) Проще взять EDT там сразу поддержка Git

(6)+ Еще бы оно не тормозило так на реальных больших конфах

(6) Ну, "поддержка git" - это сильно сказано. С гитом легко работать и без всякой "поддержки".

(8) Переключаться между ветками однако

(9) А что, в VS Code нету "поддержки Git для переключения между ветками"? :)

Хранилище конфигураций 1С это одна мастер версия (с блокировкой захваченных объектов) и локальные ветки разрабов которые могут отличаться от мастера и веток других разрабов

Гит же это дохера веток фич кроме основных (мастер, релиз и т.д.) ветки

(10) Отладка как?
В EDT просто накатываешь ветку на базу 1С и запускаешь а в VS Code как это делать?

(12) Никак. Вопрос был про редактирование кода. Просто слыхал, что некоторые предпочитают VS Code если что-то по-быстрому подправить надо.
Сам-то я по старинке в конфигураторе ваяю на обычном хранилище. Команда небольшая и каждый свой кусок пилит. Не жмет, короче.

(13) Там плюсы гит vs хранилище не столько размер команды сколько работа над одними объектами одновременно

(14) Я ж сказал. Не жмет у нас в этом месте.

Иногда git blame хочется. Но лень настраивать синхронизацию хранилища с гитом. Вернее не так. Один раз попытался выгрузить хранилище в гит со всей историей. Пыхтело несколько суток и на очередном коммите встало колом. "Не в силах" говорит. Не помню уже подробностей. Ну и плюнул до поры до времени.

(15) Как часто в чате кто захватил XXX отпустите!!! И молчание ибо разраб afk

(17) Никогда. Все в одном кабинете, дольше необходимого не держим, кто захватил - видно и так. Специфика работы такая, что пересекаемся редко.

(17) зачем захватывать заранее?
каждый пусть пилит, потом захватывается и заливается когда закончил

То есть у вас "ручная" децентрализованная разработка, а в хранилище вы только результат мержите? Но это же жутко неудобно и чревато боком.

(20) Без трехстороннего сравнения (который очень неплох в EDT) не представлю как они так

(21) в 1с тоже есть трехстороннее сравнение + внешние сравнилки трехсторонние можно подключать

(20) как раз таки это удобно

(22) Где? Как? Я про трехстороннее сравнение только при обновлении конфигурации поставщика знаю.

(24) ну и делай свои поставки

(25) Все равно не догоняю, как вы работаете. Причем тут свои поставки? Можешь расписать ваш процесс разработки пошагово?
ЗЫ. И все равно же вся фишка централизованных VCS - в отсутствии необходимость мержить как таковой.

(26) через поставки платформа позволяет делать трехстороннее объединение, например:
Сторона 1: исходная база на поддержке, которую можно создать из своей поставки
Сторона 2: разработческая база 2, от которой делается поставка для заливки
Сторона 3: разработческая база 3, от которой делается поставка для заливки

обновляешь сначала сторону 1 поставкой 2
потом обновляешь сторону 1 поставкой 3 - тут будет трехсторонне объединение: сторона 1, сторона 2, сторона 3

(27) Ок. Распиши процесс вашей работы, если несложно.
Вот у вас есть продакшн. Его вы обновляете через выпуск поставок или из хранилища?
Вот я новый разработчик в команде. Вчера пришел. Еще ничего нет. Голый комп. Мне сказали - запилить фичу.
Пошагово - какие и как базы я себе поднимаю, как настраиваю, как заливаю обновления других разрабов, как пилю фичу, как она доставляется в продакшн и другим разрабам.

(27) наверное в п.2,3 можно без поставок, надо проверить

(29) Так ты это сейчас на ходу фантазируешь, как можно было бы работать? Или ты в реальной команде, которая так работает?

(30) фантазирую на ходу, что чтото применяю на практике

я к тому, что трехстороннее объединение это не только про обновление доработанной типовой конфиги

(31) Предупреждать надо :) А то у меня уже почти мозг сломался.

(0) Хм. А в чем прикол стороннего редактора кода?

(33) но то что я написал работает, можешь легко проверить на пустой конфиге, и допилить под свой процесс

(35) Могу. Просто суть в том, что схема из (19) - мертворожденная.

(36) ты проверял?

(37) Для меня это очевидно. Ну или ответь внятно на (28). Распиши рабочую схему полностью и мы ее вместе сравним с обычной работой через хранилище и с работой через гит.

(0) Какова цель этих телодвижений?

(36) фирма 1с дает инструкцию как организовать аналог ветвления, используя несколько хранилищ для одного проекта, есть где то на итс
т.е. с последующим слиянием, а тут всего лишь одно

(40) https://its.1c.ru/db/v8std/content/709/hdoc

Технический проект – задание на доработку конфигурации. Каждый технический проект имеет четко сформулированную цель и конечный список изменений, которые нужно выполнить, чтобы достигнуть этой цели.

4.1. Разработка каждого технического проекта ведется в отдельном хранилище.

(38) > это очевидно.

Если ты включишь свой сломанный мозг, то увидишь, что эта схема - один в один работа с ветками. Выделяется корневая "master", разработчики пилят в девелоперских бранчах, импортируют изменения их корня и сливают изменения в корень. Только полностью вручную. Вместо "веток" - хранилища.

Постановка же "веток" на поддержку от "корня", это просто техническая фишка, предназначенная для обеспечения работы трехстороннего сравнения. И требование подъема версии конфигурации оттуда же.

Так что работа с ветками гит, она по твоему мнению тоже мертворожденная. Вот так вот уровень практики и выясняется =)

(43) Речь шла про удобство, а не про техническую невозможность. Читай (20) и (23).
В этой схеме нет никакого практического смысла. Вернее, он когда-то был. Когда вариантов работать через гит еще не было, а пилить бранч кровь из носу надо было. И то совет ИТС ограничивается только самыми базовыми "длинными" бранчами. Потому что если натягивать эту схему на фиче-бренчи, то это вообще будет ад.
(41) Спасибо. Интересно. Но в текущих условиях никакого смысла в этом нет. Это жутко неудобная схема, которую очень странно предлагать в качестве удобной альтернативы централизованной VCS (если работа в ней устраивает) и гиту, если нужна децентрализованная.

(44) Ну "попили мне бранч" в конфигурации на обычных формах, ага.

(45) Мозг я сломал, когда пытался осознать, что есть реальная команда, работающая по такой схеме, в потугах представить, что ее может на это сподвигнуть. То есть ваша команда по такой схеме работает?

(44) я говорил про удобство по сравнению с пессимистической блокировкой от разраба, когда он захватывает в хранилище в начале разработки
и привел пример когда ты написал "Я про трехстороннее сравнение только при обновлении конфигурации поставщика знаю"

(46) О, начинается плавный переход от претензий к технологии к претензиям к командам. Ну и как, удалось представить?

(47) За этот момент спасибо. С поставками опыта у меня мало. Все равно не до конца понимаю этот момент для трехстороннего мерджа. При обновлении через поставку с трехсторонним сравнением будет же и конфигурация поставщика обновлена? И нужно как-то заморачиваться с соблюдением очередности ее версий? Или нет?
(48) Для случая, описанного на ИТС - смысл этих мучений я прекрасно представляю. А в случае обычного "фичепиления в продакшн" - абсолютно не представляю.

На ИТС хранилище технического проекта обновляется через поставку из хранилища основного проекта. Ок. Тут все ясно. Обычное обновление через поставку. То есть конфа хранилища ТП стоит на поддержке конфы ОП.
А вот как заливать обратно с трехсторонним сравнением?

Другими словами, если пытаться перенести эту технику на стандартную разработку, то будет так: конфа каждого разраба стоит на поддежке конфы основного хранилища и они ведут централизованную разработку, обновляясь из основного хранилища через трехстороннее сравнение. А где трехстороннее сравнение при заливке фичи в основное хранилище?

"и они ведут ДЕцентрализованную разработку"

В принципе, трехсторонний и не нужен... Если сразу перед этим обновиться из основной.
Но все равно получается, что чтобы залить фичу в основное хранилище, необходимо делать выпуск его новой версии... Ну, такое себе.

Народ, а может таки вернемся к обсуждению заявленной темы?

(54) Осталось, что обсуждать?

(53) + Плюс получается, что для доработки типовых такая схема вообще может не подойти. В том смысле, что придется переводить основной проект с типовой поддержки на собственную.

Маловато опыта с поставками... Если можно сделать так, чтобы основное хранилище было на типовой поддержке, а базы разработчиков - на поддержке базы из основного хранилища и при этом можно создавать новые поставки не меняя версии, тогда ограничений нет.

Все модули в 1с выгружаются в файлы bsl,которые можно редактировать как текст.
Выгрузка идёт по команде,то есть можно выгрузить файл,поправить его и загрузить обратно.
Вопрос только в том,что особого удобства это не добавляет.

(57) я думаю многие вопросы решаемы, если автоматизировать
плохо только что конфигуратор закрыт и не все можно скриптами сделать
хотя сейчас с едт тема эта отходит, конечно

(11) научить бы ещё гит сравнивать не пофайлово, а попроцедурно. Ну или 1сников научить писать компактные процедуры, а не портянки на тыщу строк

(60) Дык это ж функционал не гита а диффалки.
Какой-нибудь плагин к winmerge запросто реализует такое сравнение с учетом семантики встроенного языка.
Наверняка кто-нибудь уже пытался.

Изначально cvs строился на diff, где сравнение построчно,поэтому,по идее,и попроцедурно должно работать.