CVSルートはdennou-k:/GFD_Dennou_Club/ftp/arch/davis/cvsroot、 プロジェクト名は gfdnavi である
参考資料
幹である開発版メインと、リリース用に動作確認を旨とするリリースブランチ、 任意の個別開発用ブランチの3種類とする。なお、個別開発版ブランチはなる べく使わず、開発版メインを利用することを推奨する。個別開発用ブランチは 次のような場合の利用を想定している。
枝の分け方と名づけは次のようにする。
開発版メイン(幹)とリリース版の関係(ver 0.1 の場合)
(開発版幹)---タグ BASE_0_1 -----------------------> \ (リリース版) ブランチタグ タグ 必要なら タグ RELEASE_0_1 --> VERSION_0_1 (--> VERSION_0_1_1)
ここで、BASE_0_1 は RELEASE_0_1 の枝分かれ直前の状態に対してつける。 RELEASE_0_2 等、その後のリリース版も幹から直接枝分かれさせる:
(開発版幹) ---------------------------------------------- \ \ (リリース版) -- RELEASE_0_1 -- RELEASE_0_2
開発版幹と個別開発用ブランチの関係
(開発版幹)---タグ BASE_SEIYA_VTK ---- タグ BASE_YUKIKO_DCCHART ------> \ \ (個別ブランチ) ブランチタグ ブランチタグ BRANCH_SEIYA_VTK --> BRANCH_YUKIKO_DCCHART -->
checkout する場合、「幹」なのでタグの指定は要らない:
% cvs -d dennou-k:/GFD_Dennou_Club/ftp/arch/davis/cvsroot co gfdnavi
ブランチの作業用コピーを、幹のそれに切り替えたい場合は、
% cvs update -dA
cvs作業用コピーを最新にアップデートしておいて、トップディレクトリ にて、
% cvs tag BASE_0_1 % cvs tag -b RELEASE_0_1
既に作業用コピーがある場合、以下を打ち込んでリリース版ブランチ のための作業用コピーとする。
% cvs update -dr RELEASE_0_1
ここで、オプション d は、何か新しいディレクトリができてても 対応できるようにするため。ないことがわかっていれば不要。
新たに作業用コピーを作りたい場合、以下を使ってチェックアウトする。
% cvs -d dennou-k..... co -r RELEASE_0_1 gfdnavi
ここで dennou-k..... は、このドキュメントの始めに書いたCVSルート である。
トップディレクトリで
make cl
して、ChangeLog ファイルを更新する。(必要なコマンドが なくて実行できない場合、dennou-k でなら動く。)
ブランチ(RELEASE_0_1)に対し、リリース版のタグ付け:
% cvs tag VERSION_0_1
リリース用のとりまとめ。例えば、新たに
% cvs -d dennou-k..... co -r VERSION_0_1 gfdnavi
し、作業用レポジトリ内の CVS というディレクトリーを 削除(rm -r `find gfdnavi -name CVS -type d` などで)。 さらにトップディレクトリーで % make cl により、ChangeLog をアップデートする。最後に cd .. し、ディレクトリ名を gfdnavi-0.1 に変えて
% tar cvzf gfdnavi-0.1.tar.gz gfdnavi-0.1
リリース版と同じだが、ブランチタグは次のようにする(BRANCH_ から始まり、内容が分かるようになってれば良い)。
BRANCH_ユーザ名_機能名 (例:BRANCH_SEIYA_VTK) BRANCH_ユーザ名_機能名_数字 (同じ名前だけど最初の枝を捨てて やりなおす場合。) BRANCH_機能名 (複数で取り組むブランチ. 例:BRANCH_P2P) BRANCH_機能名_数字 (同上)
ブランチ作成元には、"BRANCH" を "BASE" で置き換えたタグをつける。 例:
% cvs tag BASE_SEIYA_VTK % cvs tag -b BRANCH_SEIYA_VTK
基本は
である。
残念ながら, 一発ではできないようである。現在作業しているのが幹のコピー であるなら, まず幹でコミットし, 次いでそれをブランチの作業ディレクトリ に取出してから, コミットする (逆もまた然り). 詳細は下記を参照のこと.
リリース版(RELEASE_0_1とする)の作業ディレクトリ内に, 反映したい版を取出す. 変更したいファイルが lib/tasks/setup.rake で, その最新版のリビジョン番号が 1.15 である場合、
% cvs update -j 1.15 lib/tasks/setup.rake
とする。これを次のようにコミットする。
% cvs commit -m "* merged from trunk (revision 1.15)" lib/tasks/setup.rake
なお、幹の最新版のリビジョン番号がわからない場合は、 別途幹をチェックアウトして (ブランチを指定せず普通にチェックアウトする), CVS/Entries ファイルを見ればよい (上の例なら lib/tasks/CVS/Entries を見る).
幹とブランチが一致するかどうかは、下記の方法で調べられる.
幹の作業ディレクトリで、次を実行する(ブランチ RELEASE_0_1 の場合)。
% cvs diff -u -r RELEASE_0_1
この場合、カレントディレクトリ以下の変更がすべて表示される. ファイル名を引数に与えて, 特定ファイルについて調べることもできる.
出力が長すぎれば次のようにすればいい(tcshの場合)。
% cvs diff -u -r RELEASE_0_1 |& egrep 'RCS|\+\+\+|\-\-\-'
(以下、ブランチ RELEASE_0_1 を反映させるとして説明する。) 幹の作業ディレクトリを最新に update し、まずは
% cvs diff -u -r RELEASE_0_1 | less
などで変更部分を眺めてみる。そして、次を実行する.
% cvs diff -u -r RELEASE_0_1 |& egrep '\-\-\-' | \ ruby -ne 'a=$_.split; print "cvs update -j #{a[-1]} #{a[1]}\n"'
ただし、このリダイレクション (|&) は (t)csh の場合用である。 こうすると、次のように RELEASE_0_1 と差がある部分を取出すコマンドを表示する。
cvs update -j 1.2.2.1 ChangeLog cvs update -j 1.78.2.2 app/controllers/analysis_controller.rb cvs update -j 1.5.2.1 app/controllers/function_controller.rb cvs update -j 1.34.2.1 app/models/analysis.rb cvs update -j 1.1.2.1 app/models/function_argument.rb cvs update -j 1.18.2.3 app/models/query.rb cvs update -j 1.32.2.1 app/models/variable.rb cvs update -j 1.8.2.1 app/views/description/variable.rhtml cvs update -j 1.3.2.1 app/views/function/create.rhtml cvs update -j 1.19.2.1 config/environment.rb cvs update -j 1.31.2.1 db/register_directory_tree.rb cvs update -j 1.2.2.1 public/javascripts/function.js
これらを打ち込めば、現在使っている幹の作業ディレクトリに ブランチの最新版が取出される。ただし、枝分け後に 幹のほうで編集が進んでいる場合はエラーになるので、手で修正が必要である。
取出し後、
% cvs diff -u -r RELEASE_0_1
で、ブランチと現在の作業用コピーとの違いをチェックし、 問題なければ、変更をコミットする:
% cvs commit -m '* Merged from branch RELEASE_0_1'