原稿管理は考えてなかったな。
構造を持ったテキストって、管理しにくいんじゃないかと思ったり。
trac / subversion での原稿管理には何通りかの手法がありそうです。
真っ先に思いつくのは、ひんぱんにバージョンアップを繰り返す原稿全体をバージョン管理するというもの。うちでは分家で公開しているCatalystのマニュアル類やphpMyAdminのドキュメントがそれに該当しますが、これはもうプログラムのコードと同じように作業中のもの、リリースしたものとわけて管理するだけ。前の版に戻る必要はめったにありませんが、tracにしろTortoiseSVNのようなツールにしろ、簡単に差分が見られますので、元原稿の差分とつきあわせれば、直したところの見直しが簡単にできるのがまずありがたい。
また、たとえば翻訳の場合なら、元原稿同士の差分と、翻訳したもの同士の差分を見比べることで、直し漏れを見つけたり、余計な修正を加えてしまったところを発見したり、というのも簡単にできる。
一歩進んだ使い方と言えるかどうか、たとえば途中で大幅に用語を変えたくなったとき、変更を加える前に一度コミットして、機械的に全置換などしたあとに差分をとれば、不適切な修正をしてしまった場所がないか、簡単にわかる。もちろんここでコミットログを残しておけば、そういう修正を加えたという事実を残せるという点でもありがたい。その変更がいまいちあやしい（最終確定するか不安な）ものなら、もちろんここで枝分けして、あとからマージするという手もありでしょう。
もっと細かい単位（章とか節単位）で管理する場合も基本は同じ。subversionはCVSと違って管理しているファイル全体の状態をひとつのリビジョンとして持っていますから、subversionから見ればたまたま複数ファイルにわかれているだけで、扱いとしてはひとつのファイルを扱うのと大差ありません。
で、tracのTicket機能を使うと、結城浩さんのトドちゃん管理のようなことが簡単にできるようになる。TODOができるたびにチケット発行して、済んだら回収。チケットはチケットで記録に残りますから、たとえば論文を書くとき、参考資料になりそうなものを探すべしというチケットを発行して、見つけたらその内容と出典を書いた状態でチケット回収すれば、論文の本文中にメモ書きをべたべた挿入しなくても統一的な管理ができる。
もちろん日々コミットを繰り返していけば、串刺しで差分をとるだけでその日の作業量が一目瞭然。今日はたくさん書いたつもりだったけど、書き直しばっかりで総量的には全然進んでないじゃんとかいうのが一発でわかる。
バックアップという意味でも、まあ、ありがたいかな。リポジトリのバックアップを忘れなければの話ですが。
どこででも仕事ができるというのもいいですね。ノートパソコンにチェックアウトしておいて、外出先で仕事して、帰ってきたらコミット。バージョン管理しておけば、いちいちノートとデスクトップのファイルの日付を見比べて、なんて作業がなくなります。
まだまだ自分で気がついていないメリットはたくさんありそうですが、こんな便利なもの、プログラマだけに使わせておくのはもったいないですよ。
デメリットはまだちょっと導入や運用の敷居が高いことですが、まあ、その辺の心配はどなたかがしてくださることでしょう。
最近はWikiで原稿を書くとか、自分でWikiもどきをつくってそこで原稿を書くとか、いろいろ試していたのですが、しばらくはtracにハマりそうです。
追記：構造って、XMLとかのことが前提だったのかしら。アウトライン付きの原稿でもXML/HTMLでも基本的には同じだと思いますが。文字コードの問題はありうるかもしれませんが、基本的にベタテキストで表示できるものならなんでも同様の手法で管理できると思います。
