バージョン管理 short tours: uyota 匠の一手

一人で各種の履歴管理システム/プログラムを使い初める為の簡単な例。以下の作業を各々のプログラムにて実行する。

1. work ディレクトリに a.txt と 1.txt を作成。

   
   % cd /tmp
   % mkdir work
   % cd work
   % echo "A B C" > a.txt
   % echo "1 2 3" > 1.txt
   
   

2. import/checkout の作業を行なう。
3. 1.txt を編集し、status と diff を見る。

   
   % echo "10 11 12" >> 1.txt
   
   

4. 1.txt の変更をコミット。
5. a.txt を A.txt に変更し、コミット。
6. ログを見る。

プログラムのデザインと思想によって、始め方は千差万別だ。各々、特徴的な初期化のやり方をする。しかし、そう何回も繰り返す作業ではない。

一度、使い始めると大切な作業は三つ。

1. 変更を確認する。
2. 変更を記録する。
3. 履歴を見る。

これらの作業が中心となる。コマンド的には、checkout(co)、diff、commit(ci)、update、log、status 等が並ぶ。これらのコマンドがある程度使えると、不自由はしない。

そして集団で使うとなると、更に二つの作業が必要になる。

4. 他人の変更を引っ張ってくる。
5. 衝突を解消する。

個人的に使っていても、二つ以上の作業場を用意して、疑似体験することは出来る。大きいプロジェクトや既に安定運用している成果物だと変更箇所も分散される事が多い。また、正しく管理されている仕事であれば衝突を避けるように計画するべきなので、衝突の解消を行なう事自体は少ない。こちらについては、今回は扱っていない。

集中管理型や分散型による違い。各思想の違いもコマンドに現れていて面白い。RCS は単体ファイルのみ。CVS 以降はディレクトリ構成も含めて、ファイルを集合として扱える。新しいい物も RCS/CVS に準拠したコマンド名も多い。使い手としては、コマンドと動作がある程度似ていた方が、試しやすく抵抗感も少ない。欠点としては、RCS/CVS の動作に寄せる形になるので、設計に RCS/CVS の影響が多かれ少なかれ出てくる事だ。

旅程。 cvs。 Mercurial/hg。 git。 Subversion/svn。 rcs。 svk。