PDF　千夜一夜

【意見2】
・開発者の文書をDITAに継続的に変換するのは望ましくない。DITAのためにはDITAで書くほうが良い。
・ビルドは簡単。
・プログラマと同じようにDITAの執筆者も定期的に執筆、ビルド、テストをするのが良い。
・毎日というのは不合理とは思わない。執筆者が毎日文書を配布することは薦めないが。
・製品と文書のビルドを統合するのは良い。
Troy Klukewich

【意見3】
・我々はソースをCVS（ソースコードを管理するバージョン管理システム）で管理しており、DITAのソースは別のSVNを使っている。
・SVNの幹を使う方針だ。製品をリリースする毎にタグを付けて、先へ進める。
・製品単位で文書化しているが、機能単位にするように要求を受けている。DITAのソースとプログラムのソースが一緒だと、機能単位の内容をどこに置くか困るのではないだろうか？
Andy Hall

【意見4】
・内容をSVNで管理するのは問題ない。
・プログラムとは別の領域を確保するように。そうしないと、文書のリリースのためにソースのリリースを止める必要が生じると説明したらどうか。
・文書を、一括ではなく、ひとつひとつ変換していくように。
・夜間にバッチを動かしてビルドする。
・承認印なしで、出荷させないように。
Steve

こうしてみますと、DITAのコンテンツ管理にSVNを使っているケースは結構多いように思います。

考えて見ますと、この質問はDITA特有ということではないように思います。製品ドキュメントをXMLで記述し、XML文書をSVNやCVSで管理しておいて、製品のビルドに合わせて、PDF、HTML、ヘルプを作りだすのは簡単にできます。

例えば、弊社の「書けまっせ!!PDF」の場合、製品ドキュメントはXMLで作成しています。XMLからPDFファイルをFormatterで作成し、同時にCHTMLヘルプを生成しています。ドキュメントはCVSで管理していますので、上述とほとんど同じことをやっていることになります。