あるいは: バージョン管理を楽しく 使う方法について。
Ben Campbell 著.
Sverre Husebyのすばらしい
WinCVS ユーザガイドを元にしています。
CVS は、他のバージョン管理システムとは違ったやりかたで動きます。 開発者は、同じファイルを同時にいじることができます。 最初にやることは、リポジトリからソースコードのあるバージョンを チェックアウトすることです。それから単に変更したいファイルを 編集したり新しいファイルを作ったり、削除したりします。終わったら ファイルをリポジトリに格納します。
もし誰かほかの人があなたがやったのと同じファイルを変更していると、格納は 失敗します。その場合、すべてのソースコードのファイルをリポジトリから更新 してください。これはほかの開発者の変更を自動的に自分の作業用コピーにマージします。
ときどき、これは自動的にはいかないことがあります。たとえば、二人がソースコードの 同じ場所を修正したような場合です。これは、衝突と呼ばれます。衝突は 思っているほど起こらないものです。CVS はそのファイルの中に、衝突を起こした両方の バージョンを埋め込みます。二つのバージョンは、特別な印で区切られています。 衝突を解消するためには、手でそのファイルを編集してください。
それがすんだらもう一度、格納してください。今度はうまくいきます。
このやり方はいろいろとメリットがあります。両方の開発者は、それぞれ自分の 作業用コピーで仕事をします。ほかの開発者がやった変更は、格納しようと するまでは、自分からは分離されています。ほかの人がチェックアウトしている最中 だから自分が修正できないというようなことはなくなります。どの開発者もサーバに 直接アクセスすることなしに作業ができ、更新または格納するときにだけサーバに 接続することが必要になります。
最初にCVSサーバからモジュールをもってくることを、チェックアウト といいます。リポジトリからチェックアウトすると、モジュールと呼ばれる ディレクトリ階層の作業用コピーを手に入れることができます。
すでにWinCVSやほかのCVSクライアントでモジュールをチェックアウト していた場合は、この章を飛ばして、すぐに作業にとりかかることができます。
チェックアウトするには、モジュールをもってきたいと思うディレクトリで 右クリックして、ポップアップメニューから "CVS チェックアウト..." を選んでください。 チェックアウトダイアログには、以下のような項目があります。
前もってこれらの情報を手にいれておく必要があります。たいていのプロジェクトは どうやって接続し、モジュールをチェックアウトするかについてのドキュメントがあります。 見つからなければ、知っている人を探すしかありません。:-)
モジュールあとにくるディレクトリはチェックアウトするディレクトリ中に作られる ので、チェックアウトしたいすべてのモジュールを、ひとつのディレクトリの中に まとめておくことができます。別のプロジェクトであってもそうです。
[ CVS Doc: "checkout -- Check out sources for editing" ]
ファイルやフォルダによっては、アイコンオーバーレイがあるのに気づくと 思います。
よく、自分の作業用コピーにほかの人の変更を取り込みたいことがあります。 このサーバから自分の作業用コピーに対する変更処理のことを更新と 言います。更新はひとつのファイルに対しても、複数にファイルに対しても、 また、再帰的にディレクトリ構造全体に対してもできます。 更新には、処理対象のファイルやディレクトリを選択し、その場所で右クリック してから、"CVS 更新"を選択します。実行中には、処理経過をしめすポップアップ ウィンドウが表示されます。
他の人による修正は作業用コピーにマージされ、あなたの変更も同じファイルに 保存されます。更新によってリポジトリの内容は影響を受けません。
更新中に衝突の報告を受けた場合には、"衝突の解消" の章を読んでください。
CVSマニュアルのupdate outputの 章は処理中の各行の先頭に表示される謎めいた文字についての説明です。
[ CVS Doc:
"Bringing a file up to date" ]
[ CVS Doc:
"update -- Bring work tree in sync with repository" ]
作業用コピーでの修正をリポジトリに反映させることを、修正の 格納(committing)と言います。
格納による変更処理は、自動的に新しいファイルをリポジトリに追加したりは しません。新しいファイルの追加については ファイルとディレクトリの追加 を見てください。
[ CVS Doc: "commit -- Check files into the repository" ]
時々リポジトリからファイルを更新しようとするときCVS サーバが衝突 を報告することがあります。衝突は、二人以上の開発者がファイルの同じ行を 変更したときにおこります。CVS はプロジェクトの意味については何も知らない ので、衝突の解消は開発者にゆだねます。衝突が報告されたときにはファイルを ひらいて、<<<<<<<で始まる行を探してください。 衝突している場所はこんな感じにマークされています:
<<<<<<< filename
あなたがやった変更
=======
リポジトリからマージされたコード
>>>>>>> revision
コードをどう修正すべきかを決定し、必要な修正を加え、CVS のマーカを削除し、 最終的な変更をリポジトリに格納してください。
[ CVS Doc: "Conflicts example" ]
新しいファイルやディレクトリを作るとアイコンに疑問符がつくのに気づくと 思います。そのようなファイル、ディレクトリを CVS 管理下には置くには:
ファイルの追加操作の後で、そのアイコンは"変更された"状態表示になります。 これは追加が作業用コピーの変更として扱われるためで、格納 するまでは、その変更はリポジトリに反映されません。
ディレクトリに対しては、特別なメニュー項目、 が使えます。 この操作は、ディレクトリ構造を降りていって、サブディレクトリを含むすべての ファイルを追加対象とするものです。不注意で不要なファイルまでリポジトリに 追加してしまうことがあるので注意して使ってください。(たとえば、.o や .obj のようなコンパイルの中間ファイルまで追加してしまうかも知れません。)
追加するファイルがテキストかバイナリかは心配する必要が ありません。TortoiseCVS が自動検出します。 FAQ entryにもっと詳しい 情報があります。
[ CVS Doc: "Adding, removing, and renaming files and directories" ]
ファイルにした変更点を見たい場合は、 メニューを選んでください。
オプションは、ブラウザを使って ファイルの履歴を表示するためにViewCVSか、 CVSWeb を起動します。このようなプログラムは、CVSリポジトリを閲覧したり、古いバージョンを ダウンロードしたり、バージョン間の違いを表示したりします。 サーバ管理者に ViewCVSをインストールするように説得することを強くお勧めします。 このソフトは、コードの各行について、だれが最後の修正をしたかについての 注釈表示機能があります。
[ CVS Doc:
"diff -- Show differences between revisions" ]
[ CVS Doc:
"log -- Print out log information for files" ]
ファイルを削除するばあい、まず削除予告をし、その変更を格納(commit. ここでは確定、 という程度の意味です - 訳者)します:
これでファイルはリポジトリからも、あなたの作業用コピーからも削除されます。
ディレクトリは、その中にあるすべてのファイル、サブディレクトリが削除 されると自動的に削除されます。これは、次の CVS 更新時におこります。
[ CVS Doc: "Adding, removing, and renaming files and directories" ]
ファイルやディレクトリの移動や名称変更の操作は CVS にはありません。 CVS の欠点のひとつです。移動や名称変更にあたることをするには、 削除と、追加の操作を組み合わせなくてはなりません。 ファイルとディレクトリの追加 と ファイルとディレクトリの削除 を見てください。
[ CVS Doc: "Moving and renaming files" ]
変更を取り消してリポジトリのバージョンに戻るときは CVS サブメニューで、を選んでください。 ダイアログでを選びます。 これは個別のファイルに対しても、フォルダ全体に対しても使えます。
作業用コピーがぐちゃぐちゃになったり、混乱してしまったりしたときには もうひとつ有効な方法があります。ハードディスクからファイルやフォルダを いったん消してから親ディレクトリで更新を選択すると、最後のバージョンに 戻ることができます。
開発の特定の状況で、ひとつ以上のファイルのそれぞれのリビジョンに共通のラベル を貼ることを、ファイルのタグづけといいます。 典型的には、モジュール全体に対して実行して、あとで現在のモジュールの 状態を復元できるようにします。 この手のタグづけは、プロジェクトのリリース時や、大きな変更の前にはいつでも やるべきです。
ひとつ以上のファイルやディレクトリにタグづけするには:
タグ情報は、直接リポジトリに送られます。格納の操作は不要です。
タグの名前に使える文字には強い制限があります: タグは文字で始まり 文字と数字、"-" (ダッシュ) と "_" (アンダースコア) のみが許されます。ドットや、空白は許されないということです。 タグにバージョン番号を含めたい場合はドットをダッシュで置き換えて ください。二つのタグ名称はCVSでは特別な名前として予約されています: "HEAD" はリポジトリで１番最近のリポジトリを示し、 "BASE" はローカルディレクトリを最後にチェックアウトした リビジョンを示します。
[ CVS Doc: "Tags -- Symbolic revisions" ]
新しい CVS モジュールを作るには:
CVSにはプロジェクトファイルの階層構造を再構築するための良い機能 はないので、あらかじめモジュールレイアウトについてよく考えておくと いろいろなトラブルを防ぐことができます。
CVSは空のディレクトリを存在していないものとみなすことに注意して ください。ファイルもサブディレクトリも持たないようなディレクトリを 追加したい場合は、ダミーのファイルをその中に作る必要があります。 README.txtという名前のファイルを作るのが良いと思います。 そしてそこにそのディレクトリの意味について説明を書きます。
TortoiseCVS は、モジュールを、そのモジュールがあるまさにその場所 に作ります。これは他のCVSクライアントのインポート方法とは違って います。裏でTortoiseCVSがやっていることは、チェックアウトしたあと にインポートしています。
[ CVS Doc: "Starting a project with CVS" ]
バージョン管理システムの一つの機能は、開発の別ラインに変更部分を分離する 能力にあります。この別ラインのことを、ブランチ(分岐)といいます。 (See What branches are good for in the CVS documentation.)
ブランチを作るには、次のようにします:
こうして新しい名前をもったブランチがリポジトリに作られました。 注意: ブランチは、リポジトリの中にだけ作られます。 新しく作成されたブランチ上で作業するには、作業ブランチの 選択にかかれていることをやらなくてはなりません。
[ CVS Doc: "Branching and merging" ]
デフォルトの主系の開発のかわりに作業ブランチで作業を始める場合は、 作業用コピーをそのブランチに結び付けなくてはなりません。これは、 開発の主系ではなく、ブランチにたいして更新、格納などの処理をする ことを保証するのに必要になります。
別のブランチに作業用コピーを移す場合は、以下のようにしてください:
これで TortoiseCVS は指定した作業ブランチに対して作業用コピーの更新を したり転送したりします。更新には、ファイルの追加や削除も含まれます。
CVS は、ブランチによって影響されるファイルに張り付きタグと呼ばれる ものをつけます。このタグを削除して主系にもどるには、 開発の主系に戻ることに書かれた操作をしてください。
[ CVS Doc: "Accessing branches" ]
ブランチにやった修正に満足したら、開発の主系に変更を反映させたいと 思うかも知れません。あるブランチと別のブランチの修正を一緒にすることを マージといいます。あるブランチをマージするには、次のようにします:
これでブランチに加えた変更は作業用コピーにはマージされます。 多分、マージされたファイルをリポジトリに戻したいと思うかも知れません。 これには、変更点をCVSに送るを見てください。
重要: この方法でのマージは、ブランチの最初からの変更をマージ しようとします。二度目のマージをやろうとする場合、(最後のマージの後で そのブランチにした修正点をさらにマージしようとする場合)、ブランチの 最初からのマージは、やりたいことではないので、おそらくトラブルの原因 になります。これを解決するには、マージの後ごとで新しいタグをブランチに つけて、二度目以降のマージには、ブランチにつけた新しいタグを使うことです。
[ CVS Doc: "Merging an entire branch" ]
ブランチでの作業を止めて作業用コピーを開発の主系に戻したいときは、TortoiseCVS を使って、すべての張り付いたタグを取り除く必要があります。張り付いたタグを取り除き、 作業用コピーを主系に更新するには、以下のようにします:
TortoiseCVS は、作業用コピーを更新するので、現在の開発の主系に一致することに なります。それまでいたブランチはまだリポジトリ中にあるので、いつでも 作業ブランチの選択 に書かれた方法で戻ることもできます。
Karl Fogel の The CVS Book は、 CVS をコマンドラインから利用するためのすばらしいガイドです。きっと TortoiseCVS を 極限まで使い倒す人の助けにもなるでしょう。
このガイド中のリンクは、Per Cederqvist氏たちの CVS でのバージョン管理です。 これは CVS マニュアルの決定版です。
CVS のドキュメントで使われる用語は、TortoiseCVS でも使われますが、 他のソース管理システムとは違っているかも知れません。混乱をさけるため、 よく利用される用語をならべておきます。
"リビジョン","リリース","バージョン","タグ"についての 詳細は、chapter 4 of the CVS documentation. を見てください。
CVS と WinCvs はいろいろな意味で Visual Source Safe(VSS) とは違っています。 いちばんはっきりした違いは CVS のユーザは作業しているファイルをロックする 必要がないことです。VSS の場合デフォルトはロックです。実際、 CVS のドキュメントは、ユーザにできるだけロックしないことを推奨して います。数人が同じファイルを同時に変更するというめったにない状況でも、 ふつうCVS はそれぞれの変更をマージすることができます。もし、二人かそれ以上 の開発者が同じ場所にある何行かを変更したときには、CVS は、衝突を 報告し、ファイル中にマークをつけ、どうするかを開発者にゆだねます。そういう 衝突がおこるのは非常にまれで、ふつうは開発者間の意思の疎通がない場合に おこるだけです。(たとえば二人の人間が同じ問題を解決しようとした、など)。
もうひとつの重要な違いは、VSS は、サーバ側からの見方を提供する のにたいして、TortoiseCVS は、クライアント側からの見方を提供 するところです。実際の場面で言うと、VSS とはちがい、更新や、選択したファイル の状態を明示的にたずねるまで、TortoiseCVS はリポジトリの変更について言って くることはありません。TortoiseCVS によって報告された変更は、最後の チェックアウト、更新、格納などの後ではじめて、反映されることに なります。