IE 2016

Системы контроля версии и 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
136
.zip 278,98Kb 136 Скачать

См. также

Лучшие комментарии

36. kabanoff (файл скачал) 13.03.2012 10:33
Отличная вещь, спасибо!

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

Правильно будет сделать так:
СоответствиеВидовФайлов = Новый Соответствие;
СоответствиеВидовФайлов.Вставить("cf", 0);
СоответствиеВидовФайлов.Вставить("cfu", 2);
СоответствиеВидовФайлов.Вставить("epf", 1);
СоответствиеВидовФайлов.Вставить("erf", 3);
СоответствиеВидовФайлов.Вставить("mxl", 100);
...Показать Скрыть
Ответили: (37)
+ 1 [ bambr1975; ]
# Ответить
40. pumbaE 15.03.2012 23:30
(39) iceflash, советую использовать TortoiseGit. При использовании Tortoise(SVN, GIT, HG) настройка для сравнения делается аналогично как и для TortoiseSVN.

Вот пример: Видео настройка git
Ответили: (41) (42)
+ 1 [ iceflash; ]
# Ответить

Комментарии

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

Я раньше использовал в bzr хук при commit автоматом запускало v8unpack и для модулей всегда можно было посмотреть различия, но обезличено.
# Ответить
3. pumbaE 22.02.2012 11:25
Автор v8Reader подсказал, что есть досадная ошибка при построении дерева измененных...
Открываю общедоступный репозиторий, где буду выкладывать изменения: https://bitbucket.org/Shenja/diff1c
# Ответить
4. Steelvan 22.02.2012 11:31
Да, если просто хранить внешние обработки в конфигурации, то у реквизитов формы слетают типы. Поэтому приходиться придумывать типа сабжа.
# Ответить
5. andy_minsk 22.02.2012 12:26
А для себя, если не секрет, что используешь? Мы на Bazaar пробуем, просто он не совсем "модный", интересен опыт других.
Ответили: (7)
# Ответить
6. orefkov 22.02.2012 12:52
Я вот пользую mercurial и для небольших проектов - fossil.
Ответили: (8)
# Ответить
7. pumbaE 22.02.2012 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.2012 13:18
(6) orefkov, я бы тоже использовал с удовольствием mercurial, но так как на работе XP, дома linux, на сервере redmine (тоже linux), а английский я хорошо не знаю, да и 1С предлагает все таки русские наименования обработок... пришлось искать альтернативы.
# Ответить
9. orefkov 22.02.2012 13:22
Ну у меня mercurial в С++ проектах используется, и что он кириллицу в именах файлов не поддерживает, я даже как-то впервые услышал.
# Ответить
10. pumbaE 22.02.2012 13:29
Он поддерживает, только к себе в хранилище сохраняет имена в системной кодировке (в xp cp1251), когда на другие системы разворачиваешь, естественно перекодирует (utf-8) и получается, Файл МояОбработка удален, файл МояОбработка добавлен. Аналогично и git.
# Ответить
11. andy_minsk 22.02.2012 13:44
Причины использования bzr, fossil, svn а не git и hg: нормальная работа с кирилицей в именах файлов. Если есть XP, 7 и linux - тогда только bzr, fossil или svn. Если только win7 (vista) и linux тогда можно и hg или git.

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

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

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

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


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

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

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

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


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

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

(пример не показательный но картинка может заинтересует).
Ответили: (26) (29)

Прикрепленные файлы:

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

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

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

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

* с быстрыми коммитами в больших конфигурациях с большим числом объектов;
* быстрая на операциях сравнения объектов разных версий "здесь и сейчас" (сценарии "Покажи мне, что я изменил после предыдущего коммита" и "Покажи, что изменилось в этой версии относительно вот этой версии");
* с возможностью создавать ветки;
* с возможностью немонопольного захвата объектов
Ответили: (30)
# Ответить
30. pumbaE 27.02.2012 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) (47)
# Ответить
31. kuntashov 27.02.2012 13:38
(30) Если что, оговорюсь, что я посыл стати прекрасно понял и сообщение написал в порядке дискуссии.
Названные технические проблемы моих "пожеланий" тоже прекрасно понимаю.
Пока же остается ждать 8.2.16 и эксперементировать с существующими возможностями.
# Ответить
32. pumbaE 27.02.2012 14:01
Между делом: Какое же хранилище тяжелое... в плане помещения объектов и извлечения. Bzr делает commit .cf макс за 20 секунд, fossil при той же модели до минуты. Выгрузка практически сразу. По размерам хранилища fossil сжимает, bzr хранит полностью файл, соответственно в размере хранилища bzr проигрывает хранилищу конфигурации процентов на 30% (больше у bzr). Fossil выигрывает размер хранилища самый маленький.

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

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

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

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

Вот пример: Видео настройка git
Ответили: (41) (42)
+ 1 [ iceflash; ]
# Ответить
41. iceflash 16.03.2012 11:37
(40) pumbaE, Благодарю=) попробую, просто со стандартным Git + Git extension настраивать замучался, вот с черепахой попробую, даже не знал что есть она для гита=)
# Ответить
42. iceflash 16.03.2012 12:14
(40) pumbaE, "Вообще Огонь!" Огромное спасибо!
Ответили: (43)
# Ответить
43. pumbaE 16.03.2012 12:21
(42) iceflash, заслуга больше V8Reader (с расширенным анализом форм) , только благодаря этой разработке можно было, что либо сделать.
Ответили: (44)
# Ответить
44. iceflash 16.03.2012 12:34
(43) pumbaE, Это да, согласен, но в любом случае спасибо за наводку и помощь=)
# Ответить
45. iceflash 05.06.2012 10:00
Кстати по вопросу с кириллицой, это проблема TortoiseGIT или самого GIT? до сих пор не могу понять, как так существуют такие проблемы, используйте UTF и все должно быть хорошо.
Так вот по самому вопросу, планируется ли исправление, pumbaE, не в курсе?
Ответили: (46)
# Ответить
46. pumbaE 05.06.2012 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.2012 14:30
(30) pumbaE, Вообщем альтернативное хранилище конфигураций нужно :(.... Похоже ты единственный кто более-менее приблизился к решению проблемы... собственно нужно по сути научиться извлекать файлы конфигурации и отправлять их в систему контроля версий... Герман уже вроде этой затеей развлекался, но до коллективной разработки в iE у него ещё далеко, и особо пока в другом направлении работает... может спросить и поделится подходом, тогда можно будет попробовать скрипт для снегопата написать...
# Ответить
48. Voyager 14.08.2013 12:06
Огромный плюсище!
Просьба для автора: дополнить скрипт diff-1c-cf.js чисткой файлов после себя, а также обратить внимание на то что файлы в папке Temp могут быть с атрибутом "только для чтения" и тогда при вызове метода CopyFile возникает ошибка
# Ответить
49. Chrizt 13.11.2013 11:24
Окей, отчёт по изменениям у нас есть и вполне удобоваримый. А как быть, если необходимо вернуться к какой-то версии?
Ответили: (50)
# Ответить
50. pumbaE 13.11.2013 11:49
(49) Chrizt, ни что не мешает сделать "сохранить версию файла"
Ответили: (51)

Прикрепленные файлы:

Snap32.png
# Ответить
51. Chrizt 13.11.2013 14:16
(50) pumbaE, так. А как же патчер?
Ответили: (52)
# Ответить
52. pumbaE 13.11.2013 14:21
(51) Chrizt, не понял. Расшифруйте плиз.
Ответили: (53)
# Ответить
53. Chrizt 13.11.2013 14:30
(52) pumbaE, патч накатить нельзя, ибо это не код. Всегда оперируем только цельным файлом обработки :(
Ответили: (54)
# Ответить
54. pumbaE 13.11.2013 14:52
(53) Chrizt, да, патчи не наложишь. Но и патчи можно в реальности наложить только на текст, не на формы, не на макеты. Для конфигураций уже можно пробовать, а для внешних обработок пока к сожалению нет. Появиться в 8.3 возможность выгружать внешние обработки и обратно загружать, тогда будет возможность патчи накладывать.
Ответили: (55)
# Ответить
55. Chrizt 13.11.2013 14:58
(54) pumbaE,
Появиться в 8.3 возможность выгружать внешние обработки и обратно загружать

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


Вылетает вот такая ошибка при попытки сравнения в bazaar. кто-нибудь знает как это можно полечить?
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл