Снегопат

А как вы организовываете работу с внешними обработками/отчетами?
Один репозиторий на все, или новый на каждую обработку?

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

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

Вот... правильно я понимаю, что fossil merge делается для всего репозитория? Если начинаю работу над новой обработкой, то ее получается надо добавить сначала в ветку разработки?
Из этого исхожу, что прозрачнее под каждую обработку свой репозиторий?

Попробуй другой порт, может он у тебя чем-то занят? Или антивирус блокирует?
Удалось повторить, подправлю на днях.
Для универсальных обработок, ирМобильные и т.д. отдельный репозитарий.
Для клиента один репо. Внешние обработки отчеты разбиваю по папкам, вначале общий список обработок, если выделяются отчеты/обработки в отдельную группу или "Подсистему", тогда перемещаю в отдельную папку (fossil mv oldfilename newfilename для сохранения истории). Чаще всего структура папок у меня повторяет структуру справочника "Внешние обработки".
Для всей ветки/истории коммитов, но ты всегда можешь отказаться от merge некоторых файлов или сделать merge с веткой и указать определенный файл. Второй вариант надо проверить, я обычно пользуюсь fossil merge , он выводит мне 4 файла, делаю fossil undo Файл1, Файл2, Файл3 и у меня остается мердж только с одним файлом Файл4.

У меня обычно 2-3 ветки, trunk - рабочий вариант, dev(на основе trunk) где веду разработку, ну и feature (на основе dev).
Да, обычно так.

Запутаешься, если много обработок и в различные идут коммиты, тогда создавай ветку "dev_УправлениеЗакупками", "dev_Логистика" , "dev_Инкассация" и т.д. Тогда сможешь всегда смержить только необходимый набор файлов и в теории конфликтов не часто будет.

Общий подход - "один проект - один репозитарий". И тут просто надо решить, насколько отдельная обработка является "самостоятельным проектом".

Чаще это не так, в нашей деятельности обычно "Один проект - одна конфигурация [конкретного клиента]", плюс все обработки вокруг нее.

Поэтому обработки для одного клиента я бы держал в одном репо.

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

Спасибо!
А после команды fossil undo из красивого графа тоже ветвь перехода стирается или рисуется следующая? =)
Попробую покапать в сторону merge отдельного файла.

Разделение веток по назначению(подсистеме) немного смущает тем, что если не доведу до рабочего состояния и отложу на когда нить потом, то простым поиском, когда ветка переключена на основную, я эту заготовку просто не найду.
Когда под каждую обработку будет выделяется свой репозиторий, то начальная версия будет в ветке trunk, соответственно физически на диске будет хоть какая версия вне зависимости от активной ветки.
Правда можно наверно при создании новой обработки в DEV сразу перенести ее и в trunk ветвь и добиться того же результата.

1. Добавляешь новый файл в trunk, переключаешься в dev и делаешь merge с trunk, в теории у тебя конфликтов не будет и в dev попадет только новый файл.
2. Добавляешь новый файл в dev , переключаешься в trunk и merge с dev только этот файл.

Думаю для линейности истории, лучше использовать первый вариант.

Что закоммитишь, то и будет в графе отображаться. После undo и merge одного файла, будет отображаться merge только этого файла и все. Можешь в ui смотреть timeline с кнопочкой "Показывать файлы" и будет видно какие файлы зашли, а какие нет.