Vasiliy_M, это не сложности, сложности будут когда вы багу будете ловить по всему проекту. Коммиты в dev определяют целостные и не очень большие модификации. Скачок между 2мя релизами (мастерами) может быть довольно большой и если придётся что-то через полгода отлаживать, подобная организация позволит очень быстро найти коммит, который внёс ошибку.
Ну, в моем случае стоит задача генерации документа из некоторой исходной информации, которая не отслеживается, а результат, т.е. сгенерированный документ - должен отслеживаться и при этом открываться в редакторе с сохранением всего форматирования. Планируется создать шаблон с минимальным набором стилей и не менять его, после чего дифф 2х генераций документа будет показывать изменения "по существу", не принимая во внимание форматирование, поскольку шаблон не меняется.
Какие это несет неудобства: если руками чуть-чуть поправить сгенерированный документ - шаблон "поедет" - из-за того что редактор навставляет автостилей и ссылок на них в содержании. Поэтому последовательность следующая: изменился исходник информации - сгенерился по шаблону документ - положился под контроль - открылся текстовым процессором - перегнался в pdf. Если требуется правка содержания, правится исходник, после чего повторить процедуру.
Других способов я не знаю. Какой формат документов не возьми - либо zip архив, либо бинарник своего формата, либо текстовый, но с количеством тегов, намного превышающим flat xml. Возможно вам больше подойдет как раз генератор docx с автораспаковщиком/запаковщиком, потому что стили там отдельно, содержание отдельно, но готовых решений/библиотек я не знаю. Знаю библиотеку python-docx, тоже решение, если держать контент в текстовом формате и генерить документ скриптом использующим python-docx, но этот велосипед ещё надо написать.
так вот в том то и дело, что мешает. В ситуации когда 10 программистов ведут 15 веток и постоянно сливаются друг с другом, чтобы иметь последние изменения до релиза получается спагетти-репозиторий. Ориентироваться в нем между двумя последними релизами ещё можно, память свежа, но потом это уже бесполезно. Ценность старых веток снижается. Для старой истории достаточно иметь devel где каждый коммит - одна большая модификация, подробнее просто не нужно.
плохо знаю питон, но сделаю ещё 2 предположения
1) msg_body - ты уверен что буква o - или ещё какая другая - это именно та буква как и в msg_body = '' ?
выглядеть она может так же, но код буквы другой и вся переменная воспринимается как другая
скопируй сюда название переменной из строки msg_body = ''
2) обрати внимание - ругается на str(msg_body).decode('utf-8'), хотя двумя строками выше есть обращение к этой же переменной и там всё ок. Какие особенности работы с try в питоне?