Mercurial > hg > Document > Growi
diff software/CVS.md @ 0:e12992dca4a0
init from Growi
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 16 Dec 2020 14:05:01 +0900 |
parents | |
children | b6c284fd5ae4 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/software/CVS.md Wed Dec 16 14:05:01 2020 +0900 @@ -0,0 +1,222 @@ +# CVSの使い方 + +CVS は共同プロジェクトによるドキュメントやプログラム・コード等の管理を +行う便利なツールです。ゲーム班にまつわる全ては CVS によって管理されま +すので、CVSで始まりCVSで終わるといっても過言ではないでしょう。 + +ここでは CVSの使い方を例を挙げて説明します。 +ただ、CVSをコマンドから直接打ち込むと面倒なので、cvs-cr というスクリプ +トを作って、それを使います。練習用のプロジェクトに +Game_project/Test/ 以下を用意しましたのでそちらを御利用下さい。 +実際のゲーム作りではGame_project/ 以下にプロジェクトを作ります。特に +PS2 Linux向けのプロジェクトならば Game_project/ps2 を、GBA向けの +プロジェクトならば Game_project/gba をお使い下さい。 + +ここでは Game_project/Test/ 以下に test_program という仮想のプロジェク +トを作り、cvs-cr の使い方の例を挙げて説明することにしていきましょう。 + +## つーかCVSって何だば? + +簡単に言えばプロジェクト運営用のツールで、データベースのような機能を提 +供します。 + + +例えば、プロジェクトとして複数人で一つのプログラムのコーディング作業を行ったら +どうなると思いますか? もちろん誰が何を変更したか分かりませんので、 +コーディングにバグが含まれていたら目も当てられませんね。 +バグを忍ばせた人が誰なのかは全くわかりません。 +よってチームの人間関係にヒビが入ります。 + + +編集する前には cpコマンドとかで バックアップをとるのが妥当ですが、 +cpでバックアップを毎回とるのですか? そいつはちと面倒です。 +それ以前にバックアップ自体にバグが含まれていたら +チームの人間関係に莫大なダメージを与えます。 + + +それと、よくある失敗で、 + + % rm -rf * (メガンテ!!) + +という自爆技があり、これによりチーム全員が自爆します。 +ホームディレクトリでやるとその効果は絶大です。 + + +ということを防ぐためにCVSを使いましょう。習得は楽なので恐れないで下さい。 + +## cvs-crの作りかた + +奴はシェルスクリプトで、中身はこんな感じです。 +locateかfindで探せば見付かるはずですが、まぁ取り敢えずここではcvs-crの作り方を説 +明します。 + + cvs -d game@firefly.cr.ie.u-ryukyu.ac.jp:/home/one/CVS_DB $* + +こんだけです。これを毎回打ち込むのはさすがに面倒なのでシェルスクリプトにするので +す。ここでは説明しませんが多分 alias でもいけますよ。 + +とりあえずcvs-crの作り方を説明します。取り敢えずエディタでcvs-crを書きましょう。 + + % vi cvs-cr + もしくは + % emacs cvs-cr + +これで上記の一行を書いて終了なのです。それから忘れずに実行権を与えましょう + + % chmod +x cvs-cr (ユーザの実行許可) + +でもって /bin ディレクトリ作って cvs-cr を放りこんで下さい。 + + % mkdir /bin + % mv cvs-cr /bin + +次に /bin に実行のパスを通してあげます。パスは tcsh なら /.tcshrc、 +bash なら /.bashrc に書かれてますので、こやつに /bin の実行パスを追 +加します。ここではtcshについて説明しますので適当にいじって下さい。 + + % emacs /.tcshrc (tcshの場合) + +でもって、こんな感じの行を探してみましょう。 + + set path = (/bin /usr/sbin /sbin ...省略(他のbinへのパス)...) + +こやつに追加します + + set path = (/bin /usr/sbin /sbin ...省略(他のbinへのパス)... /bin) + +編集が終わったら忘れがちなのがコレ! + + % source /.tcshrc + % rehash + +はい終了。簡単でした。でも実はこれだけじゃまだ設定不足で、環境変数の +設定が必要です。以下のcvsで用いる環境変数を読み下さい。 + + +## cvsで用いる環境変数 + +PS2Linux では cvs で用いる環境変数を /etc/bashrc , /etc/csh.cshrc で設 +定しています。 + +もし, 出来んやっし! とか PS2 Linux以外の PC から CVS 使う場合は, + /.bashrc か /.tcshrc あたりを以下のように設定しましょう。 + +こっちは bash の場合 + + export CVS_RSH=ssh + export CVSEDITOR=/usr/bin/emacs + +んで、こっちが tcshの設定です。 + + # CVS で用いるログインシェル. 本学科はsshを使うことになってます + setenv CVS_RSH ssh + + # CVS で用いる エディタ. vi でなく emacs とか書くと ログの書き + # 込み時に勝手に emacs が起動します。日本語化け対策はeucで保存す + # ればOK ! + setenv CVSEDITOR vi + + + +## 新規プロジェクトを開始する + +まず、cvsリポジトリの Game_project/Test/ 以下に test_program と +いう新しいプロジェクトを作ります。新規プロジェクトを開始する場合 +は import を使います。そのあとにオプションとして プロジェクト名、 +ユーザ名、リリースタグを指定します。インポートするとエディタが起 +動し、コメントを付けることができます。 +以下を実行すると、カレントディレクトリ以下の(. .. 以外の) ファイ +ル・ディレクトリが Game_project/Test/test_program にリポジトリと +してに追加されます。 + + $ cvs-cr import Game_project/Test/test_program game start + +## プロジェクトをチェックアウトする + +cvsリポジトリよりプロジェクトを入手(チェックアウト)します。 +checkout を使います。 +以下を実行すると、カレントディレクトリに +Game_project/Test/test_program ができます。また、ここで +Game_project/Test/ を指定すると、test_program だけではなく、 +Game_project/Test/ 以下の全てのプロジェクトをチェックアウトでき +ます。 + + $ cvs-cr checkout Game_project/Test/test_program +または + $ cvs-cr co Game_project/Test/test_program + + +おまけとして、checkoutした時に上記の場合、Game_project/Test/test_program +というdirectoryが作成されますが、実際作業するのにわざわざtest_programまで +移動しなければならないので、これがめんどいって人は、-dオプションを使用しましょう。 + + $ cvs-cr co -d directory-name Game_project/Test/test_program +directory-nameの部分に任意の名前をつける。すると、test_program以下が +directory-nameの中にできます。まぁ必要ない人は使わなくてもいいけど、 +リポジトリ階層がかなり深くなるとちょっと移動がめんどくなるので、 +便利かと思います。 + +## プロジェクトをコミットする + +チェックアウトしたファイルなどに変更を加え、その変更をリポジトリ +にも反映させたい場合は commit を使います。ただし、新しくファイル +やディレクトリを追加した場合は add を用いてからコミットしてくだ +さい。コミットしたときに指定したエディタが起動して、コメントを付 +けることができるので、変更箇所などの情報を書くといいでしょう。 +作業用ディレクトリ(チェックアウトした test_program) で以下を実行 +すると、変更を加えたファイルだけをリポジトリに反映します。特定の +ファイルだけをコミットしたい場合はオプションとしてファイル名 +(file_name)を指定してください。 + + $ cvs commit [file_name] + +## リポジトリの変更を自分の作業用ディレクトリに反映させる + +自分がチェックアウトした後に他の人がリポジトリに変更をコミットし +た場合、その変更を自分の作業用ディレクトリに反映させることができ +ます。その場合は update を使います。 + + $ cvs update + +##プロジェクトに新たにファイル・ディレクトリを追加する + +プロジェクトに新たにファイルやディレクトリを追加する場合は作業用 +ディレクトリで add を用いてからコミットします。add だけではリポ +ジトリにファイルができないので、コミットすることを忘れないで下さ +い。 +以下のコマンドは、test_program 以下に新たに add_dir というディレ +クトリと add_file_1.c というファイル、add_dir の下の +add_file_2.c というファイルを追加します。 + + $ cvs-cr add add_dir add_file_1.c + $ cvs-cr add add_dir/add_file_2.c + $ cvs-cr commit + +##プロジェクトにタグ(マーク)をつける +プロジェクトをcheckoutする場合、開発における一定のポイントを取り出したいということが多々あります。そのとき、日付による取得とタグによる取得があります。ここでは、タグによる取得を紹介します。 + +「あ、あのときのリリースバージョンとりたい!」ということが起きたとしましょう。そのとき、日付やタグによる取得をしらないと「えーっと、file_1.cはversion1.1で、file_2.cはversion1.2でfile_3,cはーえっと..???」なんてことになってしまいます。 + + +なぜそんなことがおきるのか?そう、CVSのバージョン管理はファイル別で行われているので(リポジトリ別ではない)、ファイルによって最新バージョンがバラバラになっていることがあります(例えば、file_1.cはversion1.1、file_2.cはversion1.2の様に)。 + +その問題を解決してくれるのが、タグ機能です。ある特定のポイントでタグをつけることにより、後でタグに指されたそれぞれバージョンのファイルをcheckoutすることができます。 + + +さあ、使ってみましょう。現在、Game_project/Test/test_programをcheckoutして、そのディレクトリにいるとします。 +- 以下はタグを付けるコマンドです。tagの後ろにタグ名を付けて下さい。 + cvs tag [tag_name] +- 以下はタグの付いたポイントをcheckoutするコマンドです。 + cvs-cr checkout -r [tag_name] Game_project/Test/test_program + +##プロジェクトを最新の状態にする +タグなどによって古いバージョンに戻したあと、再びプロジェクトを最新の状態にしたいとき。 + cvs up -A +オプション"A"を忘れずに付けましょう。 +##で、CVSって何よ? + +そんなあたなにプレゼント + +[[CVSの使い方:http://nile.ulis.ac.jp/ yuka/memo/cvs.html]] + +CVSについてさらに知りたければ、研究室にCVS関連の本がありますのでどうぞ。もしくは Let's google!!