Meta-CVS が分かってきた
停滞していた Meta-CVS ドキュメントの翻訳を今日一気に進めたら概要は分かった。
- Meta-CVS は Lisp で書かれた CVS のフロントエンド
- リポジトリは CVS のものをそのまま使う
- ただしディレクトリ構造の変更に対応するためディレクトリ構造はすべてフラットな特殊なファイル名に展開される
その対応は
foo/MCVS/F-123D61C8FE942733281D2B08C15CD438
foo/MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h
foo/MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0
foo/MCVS/F-1C43C940D8745CAA78752C1206316B55.c
foo/MCVS/MAP
foo/MCVS/MAP-LOCAL
こういう感じで記述される。
(("MCVS/F-123D61C8FE942733281D2B08C15CD438"
"README")
("MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h"
"inc/foo.h")
("MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0"
"src/Makefile")
("MCVS/F-1C43C940D8745CAA78752C1206316B55.c"
"src/foo.c"))
from Meta-CVS-PAPER in Meta-CVS アーカイブ
要するにディレクトリ構造ごと versioning できないという CVS の問題点を、「ディレクトリ構造を扱わないようにする」というアプローチで回避しているってこと。同じく filename と repository 内の entry の関連づけを修正することで rename 問題に対応してる。なるほどね。
CVS で直接リポジトリを参照すると訳が分からないが Meta-CVS 経由でなら human readable なファイル名になる。でもこれ、ViewCVS とか CVSWEB とか対応してないとつらいよな。GUI な CVS ツールでの対応も大事だし。要するにみんながあらゆる局面で Meta-CVS 経由でアクセスしないといけないわけだ。
クライアントの状況が揃わないうちは localcvs であれこれ構造を考えるときに利用して、本チャン repository には投入しないって運用になるような気がするけど、それって localcvs を別に用意している段階で Meta-CVS の問題のあらかた解決(操作が簡単になるメリットはなくならないけど)してるんだよな。
つまり、ファイル名、ディレクトリ構造を変更したときの履歴を追えないという CVS の最も致命的な問題と、Meta-CVS へのクライアントの対応状況および学習/教育コストのトレードオフ。クライアントの対応状況は Meta-CVS よりすでに Subversion の方が充実してそうだし、少なくとも公開のプロジェクトで今から Meta-CVS の導入ってちょっとつらいだろうなぁ。
Meta-CVS を Lisp でない、GUI も作りやすい1もので作り直したらもう少しアプリの対応は進むかもしれないが、なんだか遠い道のりだなぁ。Meta-CVS は、BerkeleyDB に依存しないし、サーバ立てなくてもいきなり使い始められるというメリットがあるから個人的には嬉しいブツなんだけど。
ViewCVS には Meta-CVS 対応パッチがあるな。取り込まれているといちばん嬉しいけど、それは都合よすぎか。
Lisp の GUI の状況はさっぱり分かりません ↩