Супер идея. Давно в голове зрело нечто подобное. Правда для студенческих нужд. Коллективные работы делать. Может есть какие-нибудь комбинации софта более подходящие?
Я пытался решать подобную проблему, и как раз теми инструментами, которые описаны выше (просто удивительное совпадение), и тоже столкнулся с тем, что не существует нормального способа работать с odt в subversion. На самом деле возможность просматривать diff-ы в odt - это не самая большая проблема, и существуют утилиты, которые её решают. Значительно более серьезная проблема - это трехстороннее слияние документа (merging), когда делаешь svn up, и он тебе из трех документов (предыдущая версия, обновленная версия из репозитория, твоя версия) должен сделать что-то среднее.
Пытаясь по-всякому выкручиваться, я сначала попробовал использовать wiki или что-нибудь вики-подобное (типа markdown). Такой вариант довольно неплохо подходит для внутренней документации или для документов, которые не предъявляют серьезных требований к оформлению.
Мой случай как раз оказался не таким (оформление должно было быть ГОСТовским), поэтому я пока остановился на суровом варианте - использовать LaTeX. У него нет никаких проблем с diff-ами и системами управления версиями, но есть, конечно, другая серьезная проблема - с наскоку его не освоишь. Я в общем согласен, что заставлять верстать в LaTeX-е секретарш - это чересчур жестоко и малоперспективно, но вот когда речь идет о "студенческих нуждах", пожалуй, лучшего средства не найти.
Думаю, что не проблема научить секретаршу пользоваться LaTeX. Грамотный админ должен установить софт + тренинг на один рабочий день.
Другое, что для мощь LaTeX не нужна для тех документов, которые делает секретарша. Word обычно подходит (odt/sxw, один чёрт, подойдут), тем более что с ним проще.
Реальная проблема с LaTeX следующая (с ней сталкивался):
- я пишу документ для человека, но не могу его заставить поставить TeX (большой начальник :) )
- посылаю ему PDF
- он хочет в документе внести правки, а не судьба
- с Word'ом этого нет. Здесь просмотрщик == редактор
я с этой проблемой столкнулся когда диссер руководителю за границу посылал... потом пришлось 2 дня конвертить его в РТФ, а правки обратно в ТеХ агреггировать еще 3 дня :(
Вики — это здорово, но что вы будете делать, если уже есть договорённости с партнёрами об обмене документами в ODF и PDF? Писать вики, предоставляющую весь необходимый функционал ODF, чтобы потом в него экспортировать? Т.е. это получается дополнительная внутренняя сущность. В моей модели лишних форматов не было (если не считать гипотетический XML diff). Лишний формат — лишние проблемы при перекодировании!
а зачем это все изобретать, когда есть Google Docs и куча других компаний, предоставляющая аналогичный функционал? там же есть и импорт/експорт в офисные форматы и множество фич, о которых у вас даже не упомянуто, но они нужны или облегчают работу.
В принципе, в нашем отделе документирования так всё и происходит, разве что нет связи автоматической связи между СУЗ и СУВ (пользуясь вашей терминологией). Честно говоря, плохо представляю, как это можно удобно автоматизировать, в СУЗ придется выбирать как-то вписывать изначально файл, чтобы она следила за изменениями.. Обычно же, достаточно просто комментом в СУЗ написать ссылку на СУВ, на конкретный файл и все нормально.
Конечно, нормально. Для исходного кода программ мы именно так сейчас и делаем.
У Subversion есть post-commit-hook, через него можно как-то и автоматизировать... А вообще, есть же неоткрытые объединённые системы, управляющие сразу и исходниками, и заданиями. Тот же Google Code, например.
- нет сервера под Linux;
- нет клиента под Linux;
- он же сцуко платный!
- на сайте Microsoft я что-то не нашёл толкового описания возможностей Sharepoint, но судя по опыту моего общения с MS Office, там никогда не было ничего похожего на diff, и соответственно, всей мощи управления версиями.
В Word'е есть возможность сливать два файла в один утверждая (или отвергая) различия между ними. Плюс есть возможность сохранять разные версии одного документа в одном файле. Так что если еще и тезисно описывать изменения в новой версии документа, то для небольших групп с малым документооборотом вполне можно использовать.
Открытые технологии в электронном документообороте