2009/10/8
そもそもなぜ１つのワークで２つのリポジトリにアクセスしたくなったかといえば、
パブリックに公開されているオープンソースなどに対して、独自の変更を加えたくなったからである。
そうなると、独自の変更を管理しながら、オープンソースなどのオリジナルの変更を取り込まなければならない。
そこで思いついたのが、独自の変更の管理がCVSで、オープンソースなどの管理がSubversionというわけである。
初めてバージョン管理（CVS)でソースを管理し始めたのが2000年頃だから、約10年もたってしまったが、その間にいろいろなバージョン管理が普及してきた。
そのおかげで、このような同時に２つのバージョン管理のもとでソースを変更するということができるようになった。
さて、再度やりたいことをまとめると・・・
１）Subversionのリポジトリには変更を加えない。つまりコミットはしない。
２）Subversionのワークでは変更をするが、この変更を管理したい。
３）Subversionのリポジトリ上で何か変更があったら、それを取り込みたい。
ということで、変更の管理をローカルのCVSで管理しようというわけだ。
仮に手元で変更しても、Subversionのマージ機能でできるだけ、最新についていこうというわけだ。
また、もし、マージ不可能になれば、実装方法を変えるか、最新についていかない（いけない）ということだ。
また、この仕組みは別の用途でも使える。
手元のリポジトリ（CVS)で細かい変更を管理し、ある程度まとまった管理を(Subversion)で管理する。という手法だ。
開発をしていると自分が何をしているのかのメモのためでも、１日の終わりにコミットしておきたいなと思うときがある。
それは、プログラムがコンパイルを通らないような状況のときもあるが、ソース管理のやり直し、取り消しなどの機能があると非常に便利で、コミットしておきたくなる。しかし、これが全体に悪影響を及ぼすのでできなかったのが、可能になる。
また、Subversionでは変更管理をするための周辺ツールなども揃っており、これらと連携するためにもある程度、機能単位でまとまってコミットできるとそれらのツールも使いやすいし、後で管理もしやすい。バグ番号などで管理しているならば、それらの単位でコミットできれば、まとまりとして管理できるので後でパッチなどもバグ毎に作りやすい。
この場合には
１）機能として説明できないほど小さいレベルや、１つのファイルでは修正が完了しないような変更はCVSにコミット
２）バグ番号、機能番号としてまとまったレベルまで変更がたまってきたら、それらを一括してSubversionにコミット
ということで、いろいろと応用ができる使い方ができる。
（ただし、csvとsvnで微妙にコマンドが違うので、自分が多少混乱する。）
では、そのための手順は、
１）Subversion のワークを作成
svn co svn://foo/..........
２）このワークをそのまま、cvsにインポートする。
ただし、Subversionの管理ディレクトリはいらないので、cvsignoreなどを使い .svnは無視するようにする。
cvs import .......
３）２で作ったリポジトリのワークを作るためにチェックアウトする。
cvs co [リポジトリ名]
４）３で取り出したソースを、１に上書きする。
SubversionもCVSも単純にディレクトリ直下の既定のディレクトリで管理しているので、これらがあればそれぞれのワークとして機能する。
(tar などを使ってご自由に上書きしてください。）
以上で、完了です。
（かなり、SubversionもCVSも使い方は省略しています。）
あとは、Subversionの変更を取り込むには、svn updateで、CSVの変更を取り込むには同じディレクトリ上で、cvs updateと打てばいいので結構楽です。これ。
また、個人的にはCVSのタグ付の機能がSubversionにはないので、これをCVSのほうで補完できます。
関連記事
Posted in 開発
