KOIE Hidetaka (鯉江英隆)
hide****@koie*****
2003年 1月 15日 (水) 20:16:26 JST
ML:cvs-m****@vox***** は2002年12月で閉じたので TO:cvs-j****@lists***** にしています。 Message-Id: <20030****@mail*****> Date: Mon, 13 Jan 2003 17:52:51 +0900 From: unno-****@necat***** Subject: [cvs-ml 1938] サードパーティの追っかけ ( ベンダブランチ.. | 海野@NECATです。 | お世話になります。 | | いわゆる「サードパーティーのおっかけ」をしているのですが、ベンダーブランチに | インポートしたファイルの扱いについてわからないことがあるので教えてください。 | | 1度もワーキングディレクトリで修正のないベンダーブランチ上のファイルは、マージ | の制御ができないのは、仕様の問題なのでしょうか？ マージは自動でおこなわれるけど検証は人間がやってね という前提なので | | ちょっと説明しずらいので下記の[詳細]を説明します。 | | | サードベンダーにより途中から追加され、1度も自分で修正したことのないような | ファイル z.c は、下記(5)の操作のような結果、-j なしの update コマンドで | 暗黙のうちにワークディレクトリに入りこみ、下記(8)のような操作の結果、 | 暗黙のうちにマージされてしまいます。 | | これでは、z.c の差分が x.c, y.c のカレントに影響がある場合には非常にまずい | ことになってしまいます。 | | また、マージされたことは update コマンドを投入したときのメッセージに一回のこる | だけで、それをチェックするのを逃してしまうと、マージされたことが分かりません。 | | いったん、下記10の操作のように、自分で修正してコミットするとレビジョンがベンダ | ーブランチ側(1.1.1x)から外れて、メイントランク側(1.x)になるので、4thリリースが | あったような場合は -j で明示的にマージするようになります。 | | (5)の時点で、z.c (1.1.1.1) が入ったのをチェックして、そのときに 1.1 にレビジョ | ンを付けなおす、ようなことをしていかなければいけなかったのでしょうか？ | | # 普通のブランチ上の新規ファイルはかってにワーキングディレクトリに入りこむ | ことはないです。ベンダーブランチ上の レビジョン 1.1.1.1 をもつファイルは | どこか違う。 importするとデフォルトブランチが1.1.1に設定されて commitするとデフォルトブランチがリセットされる という裏仕様です。 デフォルトブランチの設定を変更するにはcvs admin -b REV FILEを 参照するにはcvs log -h FILEをつかいます。 リセットするにはcvs admin -b FILEです。 | | | [詳細] | o サードベンダからのリリース内容 | | リリース日 MYVENDORからリリースされる projectX の中身 | ========================================================================= | 2003/01/01 : x.c,y.c | 2003/01/05 : x.c(差分なし),y.c(差分あり,z.c内の関数呼出),z.c | 2003/01/10 : x.c(差分なし),y.c(差分あり) ,z.c(差分あり) | | | o 私のワーキングディレクトリのレビジョンの遷移 | | 2003/01/01 2003/01/05 2003/01/10 | | | | | | V V | | \--------------------------------------------------- MYVENDOR branch | | \ [TAGB] [TAGC] | | \ | V\ | [TAGA] | (2)------(3)--(5)------(6)------(8)------(9)-------(10)-- MAIN trunk | | x.c 1.1.1.1 1.2 1.2 1.2 1.2 1.2 1.2 | y.c 1.1.1.1 1.2 1.2 1.3 1.3 1.4 1.4 | z.c ------- ---- 1.1.1.1 1.1.1.1 1.1.1.2 1.1.1.2 1.2 | | | o 操作の履歴 | | import以外は全てメイントランクからチェックアウトしたワーキングディレクトリ上で | 操作しました。 | | ポイント| 操作とその時の各ファイルのレビジョン | --------+------------------------------------- | (1) 初インポート | cvs import projectX MYVENDOR TAGA | | (2) cvs co projectX | | x.c 1.1.1.1 | y.c 1.1.1.1 | | (3) x.c をmodifyしてcommit | y.c をmodifyしてcommit | | x.c 1.2 | y.c 1.2 | | (4) セカンドリリースをインポート | cvs import projectX MYVENDOR TAGB | | (5) cvs up projectX | (z.cが自動的にcoされる) | | x.c 1.2 | y.c 1.2 | z.c 1.1.1.1 | | (6) cvs up -j TAGA -j TAGB projetX | y.c がmergeされたのでcommit | | x.c 1.2 | y.c 1.3 | z.c 1.1.1.1 | | (7) サードリリースをインポート | cvs import projectX MYVENDOR TAGC | | (8) cvs up projectX | (z.cが自動的に更新される) | | x.c 1.2 | y.c 1.3 | z.c 1.1.1.2 ここでマージしたつもりもないのに 勝手にz.cが更新されてしまうのはいやならば (5)のところで cvs admin -b z.c してデフォルトブランチをリセットしてみてはどうでしょうか。 | | (9) cvs up -j TAGC -j TAGB projetX まちがい? (9) cvs up -j TAGB -j TAGC projetX | y.c がmergeされたのでcommit | | x.c 1.2 | y.c 1.4 | z.c 1.1.1.2 だとしても cvs update -jで z.c の 1.1.1.1 から 1.1.1.2 への変更が作業ファイルに とりこまれてしまうので結局は人間が判断するしかないんですよね。 | | (10) z.cを修正してcommit | | x.c 1.2 | y.c 1.4 | z.c 1.2 | | | (以上のことは手元でまったく検証していません) -- 鯉江英隆 <hide****@koie*****>
