gifts2017

Системы контроля версии и 1С

Опубликовал Евгений Сосна (pumbaE) в раздел Программирование - Инструментарий

Системы контроля версий на службе у 1С-ника.

Пока во всем мире идут споры, какая система контроля версий лучше (svn, git, hg, bzr и т.д.), в плане 1С эти споры бесмысленны. 

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

Если честно мне надоели  в папках файлы "МояСуперОбработка_20120115.epf" и "МояСуперОбработка_20120201.epf" и захотелось воспользоваться одной из систем контроля версии. В принципе даже для простой истории изменений и записи в конце дня, что сделал очень полезно. Но как всегда есть маленькая ложка дегтя - все системы контроля версий в основном предназначенны для исходных текстов, а формат epf, erf для них звучит как binary и не хотят они показывать изменения. 


Но благодоря V8Reader (с расширенным анализом форм)  можно исправить ситуацию в плане показа изменений.  Хотелось бы на этом акцентировать внимание.

Итак, берем данную обработку, встариваем ее в пустую конфигурацию. При начале работы системы парсим параметры командной строки и выводим сравнение для обработок или отчетов. Дальше больше, возмем вашу любимую систему контроля версий и настроим ее: задача для определенных файлов вызывать не стандратный просмотр различий, а необходимую нам командную строку. 

Для svn, в частности TortioseSVN, идем в настройки "External programm" -> "Advanced ..." и добавляем для необходимых нам расширений файлов вызов diff-1c-cf.bat по аналогии с другими вариантами. 

Для bzr и в частности графическая оболочка Qbzr в настройках пользователя добаляем свою программу для просмотра изменений. (Для bzr есть нюанс, отдельно для определенного расширения файла невозможно настроить свою комманду, только в целом для всех изменений. Но при этом можно выбирать смотреть с помощью определенной программы или встроенным).

И для окончательной настройки нам достаточно в diff-1c-cf.js прописать правильные переменные pathTo1C и pathToBase (путь к базе).

Как это выглядит:

 

Приятным бонусом стало: возможность сравнить mxl файлы для семерки средствами 8.


Upd: 22.02.2012


Добавил на общедоступный репозитарий https://bitbucket.org/Shenja/diff1c/overview .

Так же добавляю описание, что нужно закачать и поставить для работы:

  1. BZR : http://www.python.org/getit/ (версия 2.7), http://www.riverbankcomputing.co.uk/software/pyqt/download (PyQT 4.9 для python2.7) http://wiki.bazaar.canonical.com/WindowsDownloads (я бы советовал 2.5b), Qbzr  https://launchpad.net/qbzr/ и наконец https://launchpad.net/bzr-explorer/+download красивая графическая оболчка. (Пока все перечислил, аж вспотел. Как же в linux с этим проще - это просто констатация факта). Устанавливаем все в порядке указания ссылок. После этого я бы советовал создавать новые репозитарии с типом "colocated " (в случаии версии bzr 2.5) хотя если ни разу не работали, тогда вариант по умолчанию. Как настраивать, думаю на скриншотах видно.
  2. fossil: http://www.fossil-scm.org/download.html(желательно скопировать в каталог, который есть в переменной PATH) и http://sourcegear.com/diffmerge/index.html (инструмент для просмотра различий, отличительная возможность которого, для определенных расширений файлов вызывать сторонние приложения). В принципе настройка производиться diffmerge, в меню Tools - Options - External toll добавляем для расширений cf, epf, erf, mxl свою настройку  и для каталога под версионным контролем fossil делаем настройку: "fossil set gdiff-command d:\WORK\1C\DiffMerge\sgdm.exe" ну или путь, где у вас будет ваш viewer. После этого командой "fossil gdiff" будет вызываться необходимая нам программа.

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
diff1c.zip
.zip 278,98Kb
22.02.12
138
.zip 278,98Kb 138 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Евгений Сосна (pumbaE) 22.02.12 09:07
Системы контроля версий на службе у 1С-ника.

Перейти к публикации

1. Александр Орефков (orefkov) 22.02.12 09:07
Правильно ли я понял, что сами файлы уходят в систему контроля версий как бинарники, просто добавлена возможность просмотреть разницу "по-человечьи"?
2. Евгений Сосна (pumbaE) 22.02.12 11:05
(1) orefkov, совершенно верно. Даже при таком простом подходе вероятность порчи внешних обработок (случайно кэш почистили) уменьшается в разы.
Видна простейшая история изменений. Та даже просто когда есть несколько веток разработки уже красиво становиться.

Я раньше использовал в bzr хук при commit автоматом запускало v8unpack и для модулей всегда можно было посмотреть различия, но обезличено.
3. Евгений Сосна (pumbaE) 22.02.12 11:25
Автор v8Reader подсказал, что есть досадная ошибка при построении дерева измененных...
Открываю общедоступный репозиторий, где буду выкладывать изменения: https://bitbucket.org/Shenja/diff1c
4. Игорь Steelvan (Steelvan) 22.02.12 11:31
Да, если просто хранить внешние обработки в конфигурации, то у реквизитов формы слетают типы. Поэтому приходиться придумывать типа сабжа.
5. andy_minsk (andy_minsk) 22.02.12 12:26
А для себя, если не секрет, что используешь? Мы на Bazaar пробуем, просто он не совсем "модный", интересен опыт других.
6. Александр Орефков (orefkov) 22.02.12 12:52
Я вот пользую mercurial и для небольших проектов - fossil.
7. Евгений Сосна (pumbaE) 22.02.12 12:58
(5) andy_minsk, Раньше использовал svn, но это остатки прежних заказов. На машине стоит в принципе зоопарк: svn, git, hg, bzr, вот еще благодаря снегопату fossil осилил:
Кратко сейчас использую две системы fossil и bzr: bzr последний который 2.5 beta, там добавили работу с ветками как в git. Fossil использую на выездах (удобно со снегопатом сочетается, в принципе я дорабатываю плагин для снегопата - работа с версионным контролем), пришел к клиенту сделал fossil open, если дорабатывал какие либо отчеты внешние, закоммител и уже дома сделал синхронизацию (для каждого клиента своя ветка) - так же есть скрипт самопальный, который делает экспорт из fossil ревизий в bzr.

Причины использования bzr, fossil, svn а не git и hg: нормальная работа с кирилицей в именах файлов. Если есть XP, 7 и linux - тогда только bzr, fossil или svn. Если только win7 (vista) и linux тогда можно и hg или git.

Мы на Bazaar пробуем, просто он не совсем "модный"
но только он из модных с красивым GUI поддерживает в хранилище у себя unicode названия файлов.
8. Евгений Сосна (pumbaE) 22.02.12 13:18
(6) orefkov, я бы тоже использовал с удовольствием mercurial, но так как на работе XP, дома linux, на сервере redmine (тоже linux), а английский я хорошо не знаю, да и 1С предлагает все таки русские наименования обработок... пришлось искать альтернативы.
9. Александр Орефков (orefkov) 22.02.12 13:22
Ну у меня mercurial в С++ проектах используется, и что он кириллицу в именах файлов не поддерживает, я даже как-то впервые услышал.
10. Евгений Сосна (pumbaE) 22.02.12 13:29
Он поддерживает, только к себе в хранилище сохраняет имена в системной кодировке (в xp cp1251), когда на другие системы разворачиваешь, естественно перекодирует (utf-8) и получается, Файл МояОбработка удален, файл МояОбработка добавлен. Аналогично и git.
11. andy_minsk (andy_minsk) 22.02.12 13:44
Причины использования bzr, fossil, svn а не git и hg: нормальная работа с кирилицей в именах файлов. Если есть XP, 7 и linux - тогда только bzr, fossil или svn. Если только win7 (vista) и linux тогда можно и hg или git.

Да, поскольку линукс, 7 и ХР, победили кодировки только в bzr, и сами пришли к этой мысли :).
А насколько интенсивно пользуете, примерное количество веток, ревизий?
12. Евгений Сосна (pumbaE) 22.02.12 13:58
(11) trunk, dev, production

Из production - в базу, в trunk основная разработка, dev быстрые, срочные правки.
trunk по желанию разбивается на bug123, новаяФича и т.д.. Мелкие ветки в основном задаю, когда с консолью играюсь и СКД-шные макеты надо сохранить, а то сейчас вот как добавлю еще один подзапрос и посмотрю...

Для cf около 80 commit, в целом если брать production около 200 (254 посмотрел) сейчас. Ну а ветки кто ж их считает..., коли их просто удалять. Сказать, что суппер быстро работает, не скажу - но зато у меня есть возможность в отличии от хранилища 1С накидать 10 commit и потом сделать merge c основной веткой и главное красиво все будет видно в истории.
13. Модератор раздела Артур Аюханов (artbear) 22.02.12 16:35
Полезная публикация
Цитата: "Но благодоря http://infostart.ru/public/106310/ можно исправить ситуацию в плане показа изменений"
исправь,пожалуйста, ссылку на человечную (вроде [V8Reader (с расширенным анализом форм)] )
14. Модератор раздела Артур Аюханов (artbear) 22.02.12 16:38
еще бы инфу о развертывании репозитариев (bzr/fossil/т.д.) для конфигураций и отдельных файлов 1С 8 почитать.
Имхо была бы еще одна очень полезная публикация :)
15. Евгений Сосна (pumbaE) 22.02.12 16:50
(13) поправлю обязательно.
(14) я если честно, с трудом пишу публикации, советом, примерами могу помочь. Постараюсь написать, но не гарантирую, я эту статью 4 раза переписывал (в такие дебри уходил).
16. Александр Кунташов (kuntashov) 22.02.12 22:51
(12) Тоже очень интересуюсь организации альтернативы хранилищу. Вопросы:

1. Как организовано хранение cf-файлов? Также, как и обработок? Выгружаете cf и коммитите целиком как бинарник?
2. Если да, то насколько быстро выполняется коммит? Если нет, как организовано версионирование изменений в cf?
17. Евгений Сосна (pumbaE) 22.02.12 23:21
(16) kuntashov, cf также как и обработок, commit длиться около 30 секунд(субъективно, завтра замеряю более точно, но хочу сразу уточнить использую bzr, а про него вроде как говорят не сильно скоростной, но по очучениям :) быстрее хранилища).
Были попытки командной строкой выгружать модули объектов и потом скриптом Документ.АвансовыйОтчет.МодульОбъекта.txt разбивался в папку Документ\АвансовыйОтчет\МодульОбъекта.txt, но к сожалению этой информации не хватало для дальнейшего анализа, нет не реквизитов, ни форм.
Есть большое желание сделать выгрузку как у gcomp - хотя бы для выгружать структуру форм и модулей по папкам, опять на основании v8Reader, он то дерево строит. (В хранилище ложить cf и дерево файлов, без cf страшно)


OFF:
Так же планирую в посмотреть в сторону bugzila - нравиться мне как у fedora сделана зависимость между пакетами и их версиями. Это просто как идея витает: есть внешняя обработка допустим заполнить табличную часть док Авансового учета - для версии документа "Авансовый Отчет", в случаи изменения ревизии для объекта(пакет) Авансовый отчет, автоматом информировать проверить такую ревизию такого файла... Ну или пытаться вникнуть в юнит-тестирование...
18. Александр Кунташов (kuntashov) 22.02.12 23:32
(17) Спасибо. Не уточнишь, о конфигурации какого размера идет речь?

Скорость для меня очень важна, иначе теряются многие преимущества, которые я ожидаю получить.

Если ограничиваться текстовым представлением, то можно вместе с выгружаемыми модулями коммитить отчет по конфигурации. Теоретически, должно быть быстрее на последующих операциях сравнения. Но тут опять узким местом может стать выгрузка модулей и формирование этого отчета...
19. Евгений Сосна (pumbaE) 22.02.12 23:46
(18) kuntashov, УПП-ыще. Формирование отчета и выгрузка модулей действительно узкое место, в принципе для анализа модулей может попробовать v8unpack запускать (хотя бы тексты модулей). Отчет по конфигурации имеет такое свойство: строиться табличный документ, только он всеми системами определяется как binary, кажется выгружает utf-8 только без BOM, сейчас точно уже не вспомню, последний раз так делал летом. Кстати по ощущениям (опять таки на глаз), fossil дольше commit делает, хотя может и вправду статусная строка движущаяся на ощущения влияет, у bzr есть, у fossil нет.
20. Александр Кунташов (kuntashov) 22.02.12 23:55
(19) Я имел в виду отчет по конфигурации в текстовом (TXT) виде (Меню "Конфигурация" - пункт "Отчет по конфигурации", в диалоге переключатель в позиции "Текстовый документ").
21. Евгений Сосна (pumbaE) 22.02.12 23:59
(20) kuntashov, да, да. После формирования, надо выбирать Сокранить как, выбрать любую кодировку, потом обратно utf-8 тогда будет правильный utf-8 файл сохранять.
22. Сергей Старых (tormozit) 23.02.12 11:31
8.2.16 вроде как обещает предоставить больше возможностей по детальной выгрузке метаданных. Но насколько она будет детальной пока непонятно.
23. Евгений Сосна (pumbaE) 23.02.12 11:43
(22) tormozit, только на это и надежда (только вот как быстро это будет ...). В принципе в плане сравнения и объединения в 1С не хватает 3-х уровнего merge. Уже подумывал скрипт может написать взять cf base создать поставку - создать базу - объединить с this - создать обновление для other и потом показать окно конфигурации с обновлением. (Сейчас в комментариях приходиться прописывать объекты измененные
*ОбщиеМодули.ОбщегоНазначения
*Документ.АванасовыйОтчет
что бы видеть что же поменялось по сравнению с базовой).
24. Алексей Прилепский (IamAlexy) 23.02.12 17:02
беда всех этих "контроллеров версий" в том что слишком много накладных расходов по установке, настройке и поддержке данных систем..

всмысле, для тупого 1Сника это все черезчур сложно и геморно..
проще поставить себе БСП, и заюзать ее подсистему хранения файлов... где есть версии, описания версий и тд..


вот и получается у вас база с наработками и версионированиеам.. а так же с поиском, общей архивацией и тд и тп..
25. Евгений Сосна (pumbaE) 23.02.12 17:47
(24) IamAlexy, беда в лени, а не в установке. Даже возьми ту же БСП - это же надо хотя бы раз в день сохранить версию и че то написать поморщивши лоб.
Тупому 1Снику это не предназначено...

Мне допустим нравиться пользоваться ветками (в понимании версионных систем), причем особенно нравиться для макетов СКД, когда не знаешь куда кривая тебя приведет.

(пример не показательный но картинка может заинтересует).
Прикрепленные файлы:
26. bsi bsi (bsi) 23.02.12 23:44
(25) да для 77 красиво смотрится - душа радуется. а для 82 покажи пример
27. Денис Яковлев (iceflash) 24.02.12 08:56
Да, версионирование кода 1С, это просто такой... недостаток, стандартное хранилище тоже не устраивает, решил в очередной раз попробовать ваш вариант, попробую на git=)
29. Александр Кунташов (kuntashov) 27.02.12 08:40
(24), (25) Согласен с мнением IamAlexy. Для меня тоже основная проблема - сложность совместного использования такой системы в команде со "среднестатистическим 1Сником". Конечно же, эффект от использования в одиночку тоже есть, но это совсем не то, что ожидаешь от систем коллективной разработки.

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

Все усугубляется еще и тем, что 1С:Предприятие 8 не очень располагает к использованию таких инструментов из-за отсутствия представить конфигурацию полностью в текстовом виде. А с бинарниками работать зачастую специфично.

Но альтернативная система контроля версий нужна однозначно. Или не альтернативная, а улучшенная существующая:

* с быстрыми коммитами в больших конфигурациях с большим числом объектов;
* быстрая на операциях сравнения объектов разных версий "здесь и сейчас" (сценарии "Покажи мне, что я изменил после предыдущего коммита" и "Покажи, что изменилось в этой версии относительно вот этой версии");
* с возможностью создавать ветки;
* с возможностью немонопольного захвата объектов
30. Евгений Сосна (pumbaE) 27.02.12 12:12
(29) kuntashov, основной посыл данной публикации, использовать для внешних отчетов и обработок альтернативные системы контроля версий. Сегодня в типовых много приходиться добавлять внешних отчетов, обработок заполнения ТЧ, печатных форм... Хранилище для этого использовать - как из пушки по воробьям.
Работа с системами контроля версий для простейших случаев, согласитесь не сложнее работы с хранилищем "commit" и в африке "commit". Установка DVCS сегодня уже проще простого, в примере описания bzr (неудачный пример, скоро дополню инструкцией для hg и git, там же все значительно проще).

Помечтаем:
Компоновщик 1С: натравил на папку с исходниками, собрал cf. Натравил на cf - создал дерево исходников. (узкое место оказывается сборка, компиляция рабочей конфигурации. Но, если мечты понесут еще дальше: берем пакетные менеджеры - 1 документ, справочник = 1 пакет. Есть зависимости: док 1 зависит от Справочника 2, есть мета-пакет Подсистема 22)
Режим разработчика в конфигураторе: у этого объекта изменить uuid - прозрачно прошла реструктуризация базы данных.
Закончили мечтать.

* с быстрыми коммитами в больших конфигурациях с большим числом объектов;
Или должна 1С сделать или возможно только, если дерево конфигурации будет представлено в файлов варианте и редактировать будем отдельные файлы (системы контроля версий для быстрого определения изменения смотрят на время изменения файла, если каждый раз перезаписывать все дерево, тогда sha1 для каждого файла - не будет быстрого коммита.
* быстрая на операциях сравнения объектов разных версий "здесь и сейчас" (сценарии "Покажи мне, что я изменил после предыдущего коммита" и "Покажи, что изменилось в этой версии относительно вот этой версии");
Если предыдущий пункт выполниться, тогда это возможно и это было бы прекрасно.
* с возможностью создавать ветки;
* с возможностью немонопольного захвата объектов
Ветки и непомопольный захват объектов: путь к 3-х уровневому сравнению... (и это печально, потому как вероятность, что 1С это сделает крайне низка, хотя может какой либо американский (канадский) блогер-прогер, блогер-аналитик заплюет 1С за это и они сделают...).

Хотелось бы посоветовать, тем кто в принципе ничем не пользуется: Используйте хоть, что-то.
31. Александр Кунташов (kuntashov) 27.02.12 13:38
(30) Если что, оговорюсь, что я посыл стати прекрасно понял и сообщение написал в порядке дискуссии.
Названные технические проблемы моих "пожеланий" тоже прекрасно понимаю.
Пока же остается ждать 8.2.16 и эксперементировать с существующими возможностями.
32. Евгений Сосна (pumbaE) 27.02.12 14:01
Между делом: Какое же хранилище тяжелое... в плане помещения объектов и извлечения. Bzr делает commit .cf макс за 20 секунд, fossil при той же модели до минуты. Выгрузка практически сразу. По размерам хранилища fossil сжимает, bzr хранит полностью файл, соответственно в размере хранилища bzr проигрывает хранилищу конфигурации процентов на 30% (больше у bzr). Fossil выигрывает размер хранилища самый маленький.

Как вариант может делать на основании v8Reader отчет и дерево файлов (cf так и так будет ложиться), но при этом можно будет видеть сразу изменения и для
* быстрая на операциях сравнения объектов разных версий "здесь и сейчас" (сценарии "Покажи мне, что я изменил после предыдущего коммита" и "Покажи, что изменилось в этой версии относительно вот этой версии");
, единственная большая проблема это 3-х уровневое сравнение (при слиянии веток).
34. Айрат Ахметсафин (рибак) 01.03.12 08:52
Я тоже пользую mercurial, но публикация нормаль
35. Андрей Якшин (YakshinAnd) 01.03.12 10:08
Очень сложно. Те кто незнакомы со сторонними программами, те может и будут использовать. Те кто работал в svn и mercurial тот этим способом не будет пользоваться.
36. Евгений Кабанов (kabanoff) 13.03.12 10:33
Отличная вещь, спасибо!

При сравнении отчетов выдает ошибку, т.к. неправильно настроено соответствие видов файлов.

Правильно будет сделать так:
СоответствиеВидовФайлов = Новый Соответствие;
СоответствиеВидовФайлов.Вставить("cf", 0);
СоответствиеВидовФайлов.Вставить("cfu", 2);
СоответствиеВидовФайлов.Вставить("epf", 1);
СоответствиеВидовФайлов.Вставить("erf", 3);
СоответствиеВидовФайлов.Вставить("mxl", 100);
...Показать Скрыть
37. Евгений Сосна (pumbaE) 13.03.12 14:59
(36) kabanoff, спасибо. По иронии судьбы ради версионного контроля внешних отчетов я начал разбираться с системами DVCS и как их к 1С прикрутить...
Ошибку исправил: Ссылка на последние изменения
38. Игор Мудрицкий (Zas1402) 13.03.12 15:58
Правильно ли я понял, что сами файлы уходят в систему контроля версий как бинарники, просто добавлена возможность просмотреть разницу "по-человечьи"?

Правильно
39. Денис Яковлев (iceflash) 15.03.12 20:44
Может кто подсказать с настройкой под git, что то совсем не выходит=(
40. Евгений Сосна (pumbaE) 15.03.12 23:30
(39) iceflash, советую использовать TortoiseGit. При использовании Tortoise(SVN, GIT, HG) настройка для сравнения делается аналогично как и для TortoiseSVN.

Вот пример: Видео настройка git
41. Денис Яковлев (iceflash) 16.03.12 11:37
(40) pumbaE, Благодарю=) попробую, просто со стандартным Git + Git extension настраивать замучался, вот с черепахой попробую, даже не знал что есть она для гита=)
42. Денис Яковлев (iceflash) 16.03.12 12:14
(40) pumbaE, "Вообще Огонь!" Огромное спасибо!
43. Евгений Сосна (pumbaE) 16.03.12 12:21
(42) iceflash, заслуга больше V8Reader (с расширенным анализом форм) , только благодаря этой разработке можно было, что либо сделать.
44. Денис Яковлев (iceflash) 16.03.12 12:34
(43) pumbaE, Это да, согласен, но в любом случае спасибо за наводку и помощь=)
45. Денис Яковлев (iceflash) 05.06.12 10:00
Кстати по вопросу с кириллицой, это проблема TortoiseGIT или самого GIT? до сих пор не могу понять, как так существуют такие проблемы, используйте UTF и все должно быть хорошо.
Так вот по самому вопросу, планируется ли исправление, pumbaE, не в курсе?
46. Евгений Сосна (pumbaE) 05.06.12 13:13
(45) iceflash, это проблема именно git и mercurial, имена файлов или латиницей или же в UTF, но именно в XP кодировка консоли cp1251 (а файловая система в unicode) - в результате, получаются проблемы с кодировками: для git есть сборки UTF-8 http://code.google.com/p/utf8-git-on-windows/ (у японцев тоже проблемы с наименованиями файлов). Как вариант ставить git c поддержкой c cygwin, но тогда лишаемся красивой оболочки в виде tortoise. В дополнение можно поставить http://code.google.com/p/gitextensions/ (но у меня все равно не получилось завести).

И да проблема будет с кодировками только если будут использоваться и XP и (Win 7 или linux (тот же github или сервер на linux)).

Я пока остановился на svn, bzr и fossil.
Так вот по самому вопросу, планируется ли исправление, pumbaE, не в курсе?
Не будет, как считают разработчики: это не ошибка, а фича :).
Если нет файлов с русскими наименованиями или же нет необходимости синхронизации с другими компьютерами то можно смело использовать git.
47. Олег Филиппов (comol) 21.11.12 14:30
(30) pumbaE, Вообщем альтернативное хранилище конфигураций нужно :(.... Похоже ты единственный кто более-менее приблизился к решению проблемы... собственно нужно по сути научиться извлекать файлы конфигурации и отправлять их в систему контроля версий... Герман уже вроде этой затеей развлекался, но до коллективной разработки в iE у него ещё далеко, и особо пока в другом направлении работает... может спросить и поделится подходом, тогда можно будет попробовать скрипт для снегопата написать...
48. Voyager (Voyager) 14.08.13 12:06
Огромный плюсище!
Просьба для автора: дополнить скрипт diff-1c-cf.js чисткой файлов после себя, а также обратить внимание на то что файлы в папке Temp могут быть с атрибутом "только для чтения" и тогда при вызове метода CopyFile возникает ошибка
49. Алексей Крайст (Chrizt) 13.11.13 11:24
Окей, отчёт по изменениям у нас есть и вполне удобоваримый. А как быть, если необходимо вернуться к какой-то версии?
50. Евгений Сосна (pumbaE) 13.11.13 11:49
(49) Chrizt, ни что не мешает сделать "сохранить версию файла"
Прикрепленные файлы:
51. Алексей Крайст (Chrizt) 13.11.13 14:16
(50) pumbaE, так. А как же патчер?
52. Евгений Сосна (pumbaE) 13.11.13 14:21
(51) Chrizt, не понял. Расшифруйте плиз.
53. Алексей Крайст (Chrizt) 13.11.13 14:30
(52) pumbaE, патч накатить нельзя, ибо это не код. Всегда оперируем только цельным файлом обработки :(
54. Евгений Сосна (pumbaE) 13.11.13 14:52
(53) Chrizt, да, патчи не наложишь. Но и патчи можно в реальности наложить только на текст, не на формы, не на макеты. Для конфигураций уже можно пробовать, а для внешних обработок пока к сожалению нет. Появиться в 8.3 возможность выгружать внешние обработки и обратно загружать, тогда будет возможность патчи накладывать.
55. Алексей Крайст (Chrizt) 13.11.13 14:58
(54) pumbaE,
Появиться в 8.3 возможность выгружать внешние обработки и обратно загружать

А можете подробнее, что имеется в виду под этой фразой?
Вроде и так же выгружаются и загружаются обработки.
56. Евгений Сосна (pumbaE) 13.11.13 15:20
(55) Chrizt, 8.3 позволяет выгружать полностью конфигурацию, но отдельно внешний файл (обработка, отчет) невозможно. Получается полноценно использовать git для конфигураций можно, а для внешних обработок пока только в бинарном виде и хранить.
57. Алексей Крайст (Chrizt) 18.11.13 10:56
(56) pumbaE, а, в этом плане... Да уж, 1С в этом плане — довольно убогая прикладная фигня.
Давно бы уже всё стало проще, если бы исходники модулей и схемы UI были бы текстовыми файлами, хотя бы даже упакованными в зипчик какой-нибудь подписанный или типа того.
Все нормальные ЯП - это сорцы в чистом виде, а с 1С нужно быть магом, чтобы считать его хоть сколько-нибудь ЯП.
Хотя, Википедия говорит, что есть альтернативы :)
58. Иван Сафронов (djolejek) 20.03.14 21:43


Вылетает вот такая ошибка при попытки сравнения в bazaar. кто-нибудь знает как это можно полечить?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа