SCMコミットログはファイルのメタ情報

バージョン管理ツールがCVS、Subversion、MercurialやGitへ進化するに連れて、構成管理の意味合いが変化しているのに気付いた。
考えたことをメモ。

【元ネタ】
Twitter / @akipii: 良い記事。僕もPrivateファイルはMercurialで管理している。コメントや履歴のようなファイルのメタ情報はコミットログで保持すべき。重要ファイルはSubversionで管理する - Basic　

重要ファイルはSubversionで管理する - Basic

SVNのコミットログの書き方: プログラマの思索

TortoiseSVNの差分機能は素晴らしい: プログラマの思索

TortoiseSVNからBTSと連携する: プログラマの思索

TortoiseHgはSVNクライアントとしても優秀: プログラマの思索

TortoiseHgからBTSチケットへリンクできるようになった: プログラマの思索

僕は、仕事ではなく、自分だけのプライベートPCでも、ファイルのバックアップ代わりにMercurialで履歴管理している。
他に、自分で書いたソース、ApacheやRedmineの設定ファイルなども履歴管理している。
特にコミュニティの講演資料や記事などの原稿は、書きながら試行錯誤して完成していくため、その過程の履歴を後で思い出したいから。

重要ファイルはSubversionで管理する - Basicにも書いてあるように、履歴管理が必要になってくる理由は、バックアップだけでなく、修正時のコメントや理由なども記録したいからだ。
つまり、修正理由や変更理由のような情報は、ファイルのメタ情報であることを示唆している。
ファイルのメタ情報は、SubversionやMercurialのコミットログとして記録しておけばいい。

これは、ファイルのメタ情報をどこに配置すべきなのか、という問題につながる。
従来は、ソース自身に「@history」のようなJavaDocで履歴を書いたりしていたが、履歴や変更理由のような情報はSCMコミットログなりITSチケットに記録して分離した方がいい。
その方がソースは綺麗になるし、外出ししたコミットログやチケットに情報を追記したり更新することも可能になる。

最近は、TortoiseHgやTortoiseSVNのようなクライアントツールがとても優れているので、どんどん使った方がいいと思う。
実際、ExcelやWord、Powerpointの差分表示、BTSへのリンクなどの機能もあるので、とても作業しやすくなった。

チケット駆動開発では、成果物のメタ情報は、SCMコミットログに書かれたチケットNoを経由して、ITSで一括して保持する。
その利点は、ITSの統合DBにメタ情報が一括管理されているために、全文検索や変更理由の追跡も楽になる点にある。

ITSというプロジェクト管理ツール、そして、TortoiseHgやTortoiseSVNという優れたSCMクライアントツールのおかげで、作業の生産性は確実に上がってきている。
ツールが作業の内容を本質的に変えているという重要性にいちはやく気づくべき。
それは、ITリテラシーの一部とも言える。

優れたソフトウェアを使いこなすことで、未だに手作業で頑張っている人達よりも格段にアウトプットを作れる時代になってきている。
バージョン管理ツールを使いこなすことも、現代の一般人のITリテラシーになってきているのだ。