Система контроля версий для 1С обработок. #796742

Интересует вопрос хранения версий. Зачем это нужно? Чтобы не засорять папку с обработками более ранних версий. Знаю что будь Java и тп то достаточно Git и Bitbucket. Но у меня 1С. Вот интересно кто-то решал для себя такой вопрос?

Сделай папку с версиями для разработки и отдельно с последними релизами

А вообще зачем хранить старые версии непонятно. Они же старые:-)

Как-то это не очень удобно. :)

Используй Git и Bitbucket. Для обработок самое оно.

куда еще удобнее то? Утащил релиз в папку разработки, поиздевался над ним и вернул на место:-)

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

Имеешь какое-то понятие о контроле версий и связанных с этим удобствами? Или 150 тыщ папок для тебя высшее счастье?

Чем Git  не устраивает?

у меня почти всегда максимум 2 предыдущих версии для разработки и одна рабочая последняя. Большое удобство, связанное с отсутствием ненужного мусора "на всякий случай", который годами валяется никому не нужный.

А для интерфейса Git что и как использовать?

SourceTree например

И что за вопрос, ты с гитом работал?

цифры с версиями в наименовании обработки не подошли, обязательно велосипед нужен?

Я работал из под IDEA через плагин для Bitbucket

А сравнить чем обработки отличаются?

Тогда см

Мне больше удобнее было бы dropbox или TimeMachine под винду, но чтобы версию можно было получить на любой момент времени

так они в конфигураторе нормально сравниваются

Велосепедист, ну используй дропбокс. Тебе походу контроль версий не нужен.

ой ли? Так всё легко и просто? Еще один любитель квадратных колес.

В дропбокс ограничение на 30 дней. Я хочу без ограничений :)

Я так понимаю для полноценного сравнения версий обработок конфигуратор не подойдет. Нужен распаковыватель кода 1С в текстовые файлы. Плюс плагин к текстовому редактору.

да вот как лошара жму файл->сравнить файлы и смотрю чем они отличаются

Не нужен распаковыватель.

Не очень наглядно в случае сравнения модулей.

Серьёзно? не очень наглядно???

куда уж, блин, нагляднее

Ладно, хорошо, наглядно.

да он про эту кнопку только что узнал

Это не снимает вопроса хранения нескольких версий.

Опишите как вы представляете себе СКВ под обработки 1С с использованием Git?

Используем svn. Сравниваем в конфигураторе.

А в чем загвоздка то?

Так же как и с любым другим исходным кодом.

я в этом случае захожу на джроббокс и выбираю старую версию. Но такое обычно нужно раз в год

Мне хватает папок по структуре Клиент-Базы-Разработки-Версии. Внутри обработок пиши в макете История в тексте.

На прошлой работе успешно пользовал trotise git и gitlab. До этого - svn локальный поднимал на других работах. В обоих случаях хранил просто как файлы erf и epf - без вот этого всего мажорства с распаковыванием на модули. На текущем месте планирую опять trotise git и gitlab - понравилось сильно. Ну, или bitbucket - не важно.

а, когда надо не почитать историю, а прямо вот вернуть код, который был написан 7 лет назад и три месяца назад затёрт, что делать? Страдать?

сравнивание и там кодревью - это, конечно, клёво и зашибись, когда оно достпуно. Но надо не забывать, что смысл SCM не в нем, а в самих по себе версиях и ветках.

если нужен дропбокс, но без ограничения по дате хранения, то можно попробовать Syncthing (под винду лучше ставить Synctrayzor).

А зачем как-то особенно распаковывать? Просто выбираешь Сохранить как... и всё.

Наконец то сменил место работы? Давно пора было дальше расти ))

Лично тупо нумерую версии обработок и конфигураций добавляя к имени _ТекущаяДата_НомерВерсииЗаСегодня ПримерОбработки_2017.05.04_01.epf

что значит "наконец-то"?

+ Храню это дело в облаке от mail.ru + копия в своем на ownCloud

В магните как понял довольно долго отработал же?

Это жесть...

Как теперь это развидеть? было дело. Но я уже после ухода от тута успел раз работу сменить

> когда надо не почитать историю, а прямо вот вернуть код, который был написан 7 лет назад и три месяца назад затёрт, что делать? например, поднять бекап. я конечно понимаю, что гипотетически может быть такой случай, когда код работал 7 лет, а потом в неё залез какой -нибудь дол...б (пардон, некомпетентный человек) и обнаружилось это через 1-3 месяца. но шансов на это очень не много.

бэкап обработки это сильно ))))

шансы на это стремятся к единице. бэкап - громоздкий метод. Бэкап может весить пару терабайт и разворачиваться сутки.

бэкап базы, я так понял, в которой в справочнике внешних обработок это лежит нужная версия. ХОтя, возможно, я что-то не так понял

> бэкап обработки это сильно )))) тебе, дорогой коллега, надо еще учиться и учиться 1су.

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

Да, разумеется. Бэкапте обработки дальше. ))

не, ну, при существовании таких SCM, как гит и свн бэкапить обработки - это за гранью бобра

Напиши на 1С

+ с превью кода модуля и модулей форм и вообще внешнего вида формы в режиме предприятия

вот это будет бомба

+1  за precommit1c

превью кода, модулей и формы в предприятии - мертворожденная затея.

Обоснования будут?

в git и смотри превью. зачем в 1С? Или ты боишся всего, что не 1с?

можно и так, я не против, но причем тут ?

в них нет нужды, будучи программистом, ты по идее должен это понимать. 1. программист работает в конфигураторе, а не в предприятии, соответственно, чтобы с этим работать, ему нужно будет запускать непонятно с какой целью отдельное приложение. 2. для того, чтобы сохранилась инфа о типах реквизитов, обработку надо открывать не в какой-то любой базе, а в именно тойц, где есть нужные типы. соответственно, если ты для ЕПР, например, кодишь, то тебе надо будет очень долго ждать, чтобы это превью получить. 3. За ким хером вообще писать мегатонны кода, чтобы смотреть это в предприятии, если в конфигураторе это уже и так само и даже больше возможностей?

потому что зачем делать инструмент, когда задачаи так уже решаема

Ну не пиши, я же не настаиваю.

ты спросил почему и я тебе ответил

отвечает на ТВОЙ вопрос, почему идея мертворожденная

"в них нет нужды, будучи программистом, ты по идее должен это понимать" У тебя видимо какие-то особый сакральный смысл в бытии программиста "для того, чтобы сохранилась инфа о типах реквизитов, обработку надо открывать не в какой-то любой базе, а в именно тойц, где есть нужные типы. соответственно, если ты для ЕПР, например, кодишь, то тебе надо будет очень долго ждать, чтобы это превью получить." Не надо её открывать. Храни только версию с текстовым кодом и делов " За ким хером вообще писать мегатонны кода, чтобы смотреть это в предприятии, если в конфигураторе это уже и так само и даже больше возможностей?" Да где там мегатонны кода? Простейшая конфа пишется за пару часов. Справочник и РС для хранения версий.

сделай. Лучшего способа доказать или опровергнуть мертворожденность нет

Мертворожденность у тебя в голове, скорее. Кому надо и будет желание и время - тот напишет.

Странно, что никто еще не написал.. в это что-то есть. Не находишь?

Угу, железный аргумент.

Кто в здравом уме будет писать свой гит?

Кстати можнов документобороте хранить. там есть версионирование )))

Пишите Шура, пишите..

не зря 1сников за программистов не считают

+100500 ))

Закидали таки яйцами))

>Как теперь это развидеть? Знаю что гениально :D