Снегопат

в Редмайне есть фича простого связывания commit комментария с заданием - ты можешь сколько угодно редакций (commit'ов) связать с задачей.

делается это простым добавлением комментарием - пример " Сделал счастье всем по задаче #3456"
а закрыть задачу можно будет с помощью скрипта/плагина к Снегопату

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

Что касается остальных предложений:

1. Правильно я понимаю, что предлагается сделать отдельный интерфейс для редмайна, а с ним общаться через предоставляемый им api? Не проще ли использовать его веб-интерфейс, открывая его в полеHTMLДокумента на форме скрипта? Если нужна обработка действий на этой странице (делать что-то в скрипте по клику на ссылке или при сабмите формы и т.п.) - это все легко биндится из скрипта для Снегопата после загрузки страницы.

2. По адаптеру мне кажется, лучше не напрямую с хранилищем работать, а перехватывать команды хранилища еще в конфигураторе (если речь идет о перенаправлении коммитов в какую-либо стороннюю VCS/DVCS).

И основной вопрос: ты уже рукава засучил или пока только размышления?

p.s.

Что касается раскраски кода 1С на веб-страницах, то hightlight.js Ивана Сагалаева умеет это делать давно, года с 2004 кажется. Вы когда копали ее откапывали или не докопали? Единственное, этот скрипт заточен под 7.7 и не поддерживает определения языка запросов 1С, но это легко исправляется.

С его использованием пару недель назад я сделал одноименный скрипт для Снегопата (в транк я его сразу положил, но публично об этом не сообщал).

_________________
С уважением,
Александр Кунташов
Канал про 1С в Телеграме: @kuntashov_devnotes

Алексей, вроде ж еще на инфостарте Steban рассказывал как это сделать. Ты тоже вроде принимал активное участие в той ветке, так что пропустить точно не мог



Нет, я просто хотел сказать, что хочется иметь возможность "общения" с багтрекером и его конкретными задачами, в том числе и закрывать задачу по ключевой фразе "Закрыть задачу #НомерЗадачи". Но одним только закрытием, ес-но, ограничиваться не надо.

1. v8.rb от Степана НЕ захотел у меня взлетать по unix'ом, а мой Редмайн уже 4 года крутиться под Debian .
2. HIGHLIGHT.JS я "не докопал" - надо подумать как его прикрутить к Редмайну в качестве подсветки синтаксиса.
3. на первом этапе будет достаточно и отображения htmlФормы Редмайна - однако: для меня отдельный интерфейс позволит решить самую главную для меня автоматизацию действий в Редмайне - отчет по затрачиваемому времени на задачу.

и последнее я уже засучил рукава - только у меня маловато опыта JS, поэтому идет тяжеловато. С Ruby у меня проблем то нет.

А адаптер к хранилищу был бы универсальней - исключал бы 2 ситуации:
1. когда с хранилищем работает кто-то кто не купил Снегопат
2. когда кто-то, может даже и я - закомитил в хранилище изменение забыв включить Снегопат/Плагин для перехвата commit'ов в хранилище.

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

Для начала просили перехват окна фиксации в хранилище, чтобы:

1. указать номер задачи с которой связан commit
2. указать ключевое слово для задачи - #закрыть,#time_track,
3. интеграция с Redmine - оказывается у большинства он. С остальными надо будет думать, так что необходим какой-то AbstractRequestTrackerAdapter.

В первом приближении хочется совсем немного:
1. В конфигурации помещаем объект в хранилище со своими комментариями, где в том числе указаны и всякие тэги для внешних систем
2. Снегопат вытаскивает этот текст и объекты, которые помещаются. Затем объекты раскладывает в какое-либо представление: для модулей - текст, таблички в mxl, СКД в xml, формы в ? и т.д.
3. Делаем коммит из результата пункта 2 в CVS, SVN, fossil и т.п.

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

И еще попутно вопрос к Саше Орефкову: реально ли сделать свой пункт в контекстном меню конфигуратора?
Дальше будет хотеться что-то вроде такого: правой кнопкой жмакаем на объект в дереве конфигурации, там выбираем наш "внедренный" пункт "Показать во внешнем хранилище" и далее переходим непосредственно в нашу систему версионирования/багтрекинга.

Я тогда опишу уж свой варинат:
1. полностью согласен, я вижу это как вызываем макрос, показывает табличку со списоком задач, необходимые выделяем, в комментарий переносится список номеров и краткое описание по из задачи (тут уже можем редактировать).
2. Как вариант интеграции я расматривал:
2.1 Отдельная база подключенная к хранилищу, забирает cf файл из хранилища по номеру версии.
2.2 С помощью tool_cd выгружаем табличку с коммитами (к сожалению отчет по хранилищу в пакетном режиме не дает информации об авторе), парсим xml и получаем автора и commit /
2.3 В сторнюю систему делаю коммит в бинарного cf файла с комментарием и автором.
2.4 Тут вступает уже как удобней или 8.3 или 8.2 , создается пустая база по cf файлу и делается выгрузка модулей и т.д. полная.
2.5 Разбивается на структуру папок и создается служебный файл переименований, т.к. при простом разбиении по папкам через точку не удобно просматривать историю по объекту, т.е. Catalog.Банки.xml в теории будет Как Конфигурация\Catalog\Банки.xml , а хотелось бы Конфигурация\Catalog\Банки\Банки.xml и вот такое преобразование должно записаться в служебный файл.
2.6 Делаем коммит в ветку или отдельный репозиторий уже исходных текстов.
3. По желанию сразу отправляем на общий сервер данные.
4. Подключаем к extfiles папку с git/fossil распакованной конфигурации.
5. Добавиляем прозрачное получение истории для открытого модуля. Т.е. стоим в модуле документа , вызываем макрос "Показать историю", преобразовываем в правильное имя и вызываем показ истории из extfiles.

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

что из перечисленного уже работает?

Есть заготовки кода, частично пробовалось сделать руками и т.д. Вообще тема очень обширная и вопросы: что показывать в изменения модуля - с учетом последних изменений в git/fossil , а если разработчик не обновил конфигурацию из хранилища и т.д. Как учитывать историю конфигурации на поставке, git/bzr предполагают вести историю как субмодули в отдельной папке, но для общего дерева конфигурации такой вариант не подходит. Возможно ли выделить историю отдельной подсистемы или файлов, в другой репо, отдать на доработку и потом обратно смержить...

Вопросов очень много. Постараюсь систематизировать на выходных, причесать скрипты и расписать что я накопал и мое видение алтернативных хранилищъ.