val it: α → α = fun

http://d.hatena.ne.jp/yoriyuki/20070401/p1 と
http://www.milkstand.net/fsgarage/archives/000984.html を読んだけれど、指摘としては重要だと思う。バージョン管理システムを使いはじめるには何らかのコストを支払う必要がある。ではメリットは何か。

履歴管理に対するファイルシステムによる対応といえば、 Plan9 のWORMなファイルシステムもあるし、次期 OSX に搭載されるというTimeMachineもそうですね。それならこれでいいという話がある。

で、現在のシステムで Plan9 風のバックアップをしよう、というコンセプトで開発されたのが pdumpfs だ。実行すると、年月日の名前のディレクトリに、ツリーを丸ごとコピーする。それくらいなら cp -a でも簡単にできるのだが、 pdumpfs は、以前の実行によってできたバックアップと中身が同じファイルの場合、ファイルをコピーせずにハードリンクで済ませる。だから、あまり変化のないものもいっしょにまとめて簡単にバックアップできるのがメリットだ(ただし、内容の比較をするから遅くなるという手がある)。 UNIX 風のシステムなら cron で一日一回やっておけば、かなり安全である。わたしはホーム領域ぜんたいをバックアップしている。その成果が生きたことは、いまンとこないけれど。

履歴管理のメリットである差分表示については diff -r を使えば済むし、あとはコミットログが残せないということくらいか。しかし個人用途じゃ大したログを書かない人も多いだろうし、簡便な用途では充分だろうと思う。

さて、バージョン管理というとき、現代的な意味では遠隔地との同期っていうメリットもある。 pdumpfs はローカルなディスクにしか書き込めないし、仮に遠隔地に書き込めたとしてもそれと作業ディレクトリの同期とは違う。

そこでオススメするのが unison。 unison はディレクトリを同期するためのツール。遠隔地との効率的なコピーというと rsync がすぐ思い浮かぶと思うけれども、 rsync は一方向の同期しかしない。つまり遠隔地からぜんぶ取ってくるか、遠隔地にぜんぶ持っていくか、しかできない。 unison は双方向に、どちらが新しいかを見て、同じ状態に持っていく。どのファイルをどっち方向にコピーするか、というのも GUI で対話的にできるし、CUIで対話的にもできるし、全自動にもできる。かなり便利である。

この pdumpfs + unison は、今の UNIX 風システムではけっこう現実的な解決策だと思う。

……と書いていて、ようやくバージョン管理システムがこれに勝る部分を思いついた気がする。第一にファイルの移動に対する対処。 pdumpfs はファイルの移動を検知できないから、ファイル名を変更したりするとその変化を追えない。 cvs(RCS) を除くバージョン管理システムでは、ファイル名の変更に対応していて、きちんと処理できるようになっているはずだ。

第二が、同一ファイル内の変更。同期したいファイルが中央で共有されているものと手元とでどちらにも変更が加えられているとき。もちろん同じ箇所を変更していたらコンフリクトの発生だけど、違う場所であればふつうはうまくマージできる。こういうのは、ファイル単位で同期するしかない unison や rsync では対処できない。

もちろん「個人用途」という状況を念頭に置くと、ファイル名の変更は運用でカバーする方法は幾らでもあるし、大雑把に覚えていられるだろうという話がある。第二の問題はほとんど起こりえない状況で、そういう場合には簡単に対処できるはずといえばその通り。

しかし、そういう「運用でカバー」する方法を考えるのがメンドくさいわけであり、そのためにバージョン管理ツールというのはあるのかもしれない。と、いうことなのかもしれない。

ところであれだ、 _new とか _org とか、そういうファイル名は気軽につけがちだけど、ほっとくとどれが何だかさっぱりわからなくなったりして混乱するので、やるならやはり、命名規則をきっちりしておくにしくはない。命名規則がかっちり決まったら、それに対応したスクリプトを書いて自動化すると楽で……とやっていくと、そのうちバージョン管理システムになるんじゃないだろうか。その手前にとどまっているのも楽だと思うけれど。

それにしても darcs でレポジトリから旧バージョンの特定のファイルだけを取り出す仕組みがないのは残念ですね。これはまったくもってそのとおり。