[CVS超入門]

Prev: 枝の併合

▼ベンダ枝の怪

ベンダ枝というのは、 cvs import でできる枝 (1.1.1.X) のことです。 こいつの挙動は他の枝とはちょっと(いやだいぶ)違う。

$Id: cvsvendor.html,v 2.3 2009/02/06 18:25:58 kabe Exp $

▽ハマリ：無修整のものは、ベンダ側の修正が伝播する

わかりにくいですね。

普通に、まずベンダ枝へ import してからせっせこと改造していると、 リポジトリや作業領域には当然、 俺様がいじったファイルと、いじっていないファイルの両方が混じっています。

この状態から、ベンダから新しいリリースが出たので、 ベンダ枝に追加しようと cvs import ProjectY VENDOR VENDOR_1_2 なんかを行うと、

俺は修正してない、がベンダでは修正したファイルは、 勝手にベンダ版に更新されます。

さすがに現在の作業領域のファイルが何もせずに更新される、 てことはありませんが、作業領域で cvs update すると更新されます。

「便利じゃん」という場合と「うげ〜〜〜、まじかよ〜〜〜」 両方あると思います(普通は後者)。 ベンダの変更が俺変更と干渉していたりすると、 次回のcvs update で動かなくなることがあります。

▽なぜ？

というのもですねぇ、「ベンダ版から一度も変更してないファイル」は、 RCSでいうデフォルト枝が 幹ではなく 1.1.1枝 に なっているからなんですねぇ…

ので、ベンダ枝 (1.1.1.x) を cvs import で伸ばすと、 各作業領域にある無修整ファイルは次回の update で 「1.1.1.xの最新版」に 更新されるので、ベンダの修正が伝播するわけです…

自分が修正したファイルでこれが起らないのは、 初回の commit で CVS がデフォルト枝を幹にリセットしてくれるからです。 (結果、作業領域は旧版由来のファイルと新版のファイルが混ざった状態になる…)

この処理は CVS 的な枝ではなく、RCS的な枝で処理されているので、 cvs status ではよくわかりません。cvs log の "branch:" で見ます。 

	【例】 jhlp.c はベンダ版から手を入れているが、
	       jutil.c は修整していない。

	% cvs status jhlp.c jutil.c

	===================================================================
	File: jhlp.c            Status: Up-to-date

	   Working revision:    1.4     Mon Jul 14 20:10:30 2003
	   Repository revision: 1.4     /usr/local/src/wnn/cvsroot/FreeWnn/Wnn/uum/jhlp.c,v
	   Sticky Tag:          (none)
	   Sticky Date:         (none)
	   Sticky Options:      -kb

	===================================================================
	File: jutil.c           Status: Up-to-date

	   Working revision:    1.1.1.1 Sat Mar 30 01:45:41 2002
	   【1.1ではない、に注意！「ベンダ枝」の版番がついている】
	   Repository revision: 1.1.1.1 /usr/local/src/wnn/cvsroot/FreeWnn/Wnn/uum/jutil.c,v
	   Sticky Tag:          (none)
	   Sticky Date:         (none)
	   Sticky Options:      -kb

	

	% cvs log -r0 jhlp.c jutil.c

	RCS file: /usr/local/src/wnn/cvsroot/FreeWnn/Wnn/uum/jhlp.c,v
	Working file: jhlp.c
	head: 1.4
	branch:
	【デフォルト枝なし、つまり「幹」。普通の修正済ファイルはこれ】
	locks: strict
	.....

	=============================================================================

	RCS file: /usr/local/src/wnn/cvsroot/FreeWnn/Wnn/uum/jutil.c,v
	Working file: jutil.c
	head: 1.1
	branch: 1.1.1
	【無修整ファイルはデフォルト枝が「枝1.1.1 (ベンダ枝)」になっている】
	locks: strict
	access list:
	....

「普通は幹」などと書いてますが、 他人のソースを cvs import していじくる場合は 手をつけていないファイルが大多数なので、 数の上ではベンダ枝のままになっているファイルの方が多いのが普通です。

▽勝手に伝播するのはいやじゃ

そらそーです。

ので、一番らくちんなのは、 初めての cvs import 直後に デフォルト枝を全部 幹 (X.X) にリセットしてしまう (cvs admin -b) ことでしょう。

一応、このことについては CVS の info版のマニュアルの cvs admin の項に書いてはあるのだが、わかりにくい。 
	% cvs import ProjectY VENDOR VENDOR_1_0
	...
	% cvs checkout ProjectY	# cvs admin は作業領域内でしか
	% cd ProjectY		# 使えないので、いったんcheckout
	% cvs admin -b

デフォルト枝を全リセットすると、「いじっていない」ファイルの版番は 通常の 1.1.1.1 から 1.1 になります。

cvs import 後に作業領域で update をかけてハマり状態になっても、 cvs admin -b 後に updateしなおせばなんとか復帰できます。 (以前 1.1.1.1 だったものが 1.1 に置き換わる)

ただし cvs admin は「直接リポジトリをRCS的にいじくる」 低レベルツールなので、むやみに使うのは危険です。 マニュアルやFAQでも繰り返し「使うな」とされています。 動作に確信が持てないうちは お試し用のリポジトリ・作業領域で練習しましょう。

「俺は勝手に伝播するのはいやじゃ」では上記手順でいいんですが、 デフォルト枝の書き換えはリポジトリに直接作用するので 「俺だけいやじゃ」というわがままには直接対応できません。 問題になることはないと思いますが

▽なんでこんな変な仕様なのか？

たぶん、ベンダ更新時にちゃんと苦労しなさい、 ということなのではないかと… 変更が自動伝播すれば、いやでも最新版に対応すべく 自分の担当領域の修正に取りかからざるを得ないでしょう。

ベンダ枝が特殊な扱われかたをしているのは、 歴史的な事由が一番大きいと思われます。 初期の CVS ではユーザーが作れる枝はなく、ベンダ枝だけでした。 RCSに用意されている枝機構を活用したのはある意味当然。

逆になんで通常枝が magic branch を使っているのかが よーわからんのですよね… いろいろ調べたり考えたりしてみましたが、 「枝はあるけど伸びていない」(1.1 から枝を生やしたが、まだ1.1.2.1はない) 状態で枝タグ名だけ記録する (rcs -Nbranchtag:1.1.2) のは RCS では不可能だから、程度の理由しか考え付きませんでした。 昔のCVSはRCSのかぶせものだったので、この制限に影響されたと思われます。

かべ＠sra-tohoku．co．jp