そうなってきた途端に新しいソフトウェアのアイディアが湧いてくるのはどうしたことか。そして俺はまだ俺専用バージョン管理ツールを書き終えていない。というか、書いてるうちにバージョン管理ツールの使いかたとかいろいろなものが変化して、すごい勢いで迷走中。仕方がないので最近思い付いたアイディアをちょっと公開。
今までは darcs よろしく一回のコミットでの変更点を一つのパッチファイルに突っ込むというスタイルで進めていたのだけど、それだとまんま darcs でつまんねーなと思っていたわけよ。それでふと思ったのだけど、普通にパッチファイルを一つ一つのファイルにしたらどうなるのかなってこと。例えばリポジトリに foo.txt と bar.txt があったとして、それに対する変更点を foo0.patch, bar0.patch, foo1.patch ... って風に保存してくの。これだとファイルシステムが ext2 とかだったりすると、何かリビジョンが 1000 の位に行く前に死ねそうだしあんま美しくないかなあと思ったのだけど、だったら一つのファイルに付きディレクトリ一個作ればいいじゃん。
例えば以下のようなファイルとディレクトリのレイアウトを考える。
foo.txt
bar.txt
baz/
abc.txt
def.txtこれをリポジトリにつっこむと、リポジトリ内に以下のようなディレクトリ構造が出来上がる。
foo/
bar/
bazabc/
bazdef実際にはダイジェスト値を使ったルックアップテーブルを用意することになると思うけど (ファイル名の変更とかの追跡)、それはまた別の話。あとは各ファイルへの変更点を対応するディレクトリに突っ込んでいくと。これならいざってときに、 Unix の標準ツールである patch をごりごり適用してとりあえずデータを復旧できる。というか別にこれだけなら、やろうと思えばシェルスクリプトでも事足りるのだよな。流石にそれだと限界がありそうだけど、原理的にそうだってのが重要だ。
これ自体は楽に実装できるんだけど、コミットメッセージとかその他諸々の情報をどう持たせようかで悩んでいたりする。アノテーションとか、一人で開発する分には全然いらねえよなあ。そのためだけに余計な事をするのもどうかと思うし。やっぱ俺が使う上での最低限の機能だけに留めておくかなあ。
ジャケ買いして失敗したことあるだろ?
ファイル名の変更の追跡で別ファイルを用意しないといけないのがちょっといけてない感じなので、ファイル名その他の情報を持たせたヘッダを入れ込んじまうか。そこに変更者名の情報もいれとけば、万が一アノテーションを付けるときにも困らないな。スケールするかどうかは微妙だけど。
だってテレビ持ってないし、持っていても見る時間ないし、絶対に俺のイメージと違ってる自信があるし。