committer の生活

ChangeLog

ChangeLog というファイルは行なわれた変更内容を記録しておくためのものです。これは変更内容を一覧できる便利なファイルであり、そして、 cvs 管理されていない場合はおそらく唯一の詳細な変更記録です。ここで、このファイル自身を更新していく方法にはいくつかの流儀があります。

また、ChangeLog とは別に、commit するときには log を記述します。しかし、どちらも変更内容を記録するものなので、通常、どちらかの記述をもう一方にコピーして使います。

commit した後に emacs で vc-update-change-log

commit する前に vi で書いて一度に commit

cvs2cl で一括生成

ChangeLog の形式

とくに vi などで記述する場合、どうやって正しい形式で記述するかが問題になります。 rcs2log で生成したものを修正すれば比較的簡単に正しい形式で記述できます。

ChangeLog と非 ASCII 文字

もし、ChangeLog が ISO-8859-1 などのコードで記述されている場合 - たとえば人名に使われているとか - 「日本語化」されたエディタで編集するのは危険です。 (日本語化されていない)8bit clean なエディタか多言語化されたエディタをつかって編集します。また、commit 前に diff をとり、余計な変更がされていないことを確認します。

キーワード展開

必要ないと思うなら -ko を指定する。

rcs2log と emacsen

cvs 附属の rcs2log は消す。

cvsadmin グループ

cvs admin が許されるかどうか。(-k はグループに関係なく許される。)

default branch について

タグや日時を指定せずに co した場合、出てくる版は次のように決定されます。

• default branch が設定されている場合、その branch の先端。 default branch は import によって 1.1.1 に設定されることが多いため、大抵 1.1.1.x が出てきます。
• 設定されてない場合、main trunk の先端。 main trunk は x.y という形の . が一つしか含まれていない revision の並びです。通常、x は 1 なので、1.y が出てきます。

通常、default branch の設定は import によってファイルが追加された時に行なわれ、そのファイルに commit したときに除去されます。また、cvs admin -b によって default branch を設定・除去できます。

import について

cvs import は(-b で import 先の branch を指定しなかった場合)

• RCS ファイルがすでに存在した場合 (ファイルが以前に存在した過去があり、現在削除されている場合も含む)、 1.1.1 枝に revision を追加します。 1.1.1 枝がまだ存在していなければその時点で作ります。ただし、1.1.1 枝の先端が import しようとしているファイルと一致した場合には新しい revision は作りません。
• RCS ファイルが存在しなかった場合、1.1 と 1.1.1.1 を import したファイルとし、default branch を 1.1.1 とします。

新しい module を作るには

• cvs import を使う。vendor branch/release tag が邪魔な場合、空の directory で行なう。
• toplevel directory (.) の working directory で cvs add <subdirectory>。なお、toplevel directory の working directory は空のディレクトリを作り、その中で cvs -d ... co -l . として作成できる。また、CVSROOT/config で TopLevelAdmin=yes としてあれば、 module を checkout するついでに current directory が toplevel directory の working directory になる。

import 時の conflict

import 時に conflict が存在すると表示されることがありますが、これは update 時の conflict とは意味が異なります。 import 時の conflict は単に(タグや日時の指定無しで)co したときに import したファイルが出てこないということを示しているだけです。これは次のような場合に起こります。

• RCS ファイルが存在し、default branch が指定されていない。この場合、import したファイルではなく main trunk の先端が出てきます。
• default branch が指定されていても、import 先とは異なる branch が指定されている。この場合、import したファイルではなく default branch の先端が出てきます。

パーミッションについて

ファイルのパーミッションは RCS と同様に、読み込み・実行許可が RCS ファイルのパーミッションとして記録されます。書き込み許可は記録されません。

なお、パーミッションの履歴は管理されません。 cvs-1.10.8 の時点では PreservePermissions というものがあったのですが、 cvs-1.11 で無効になりました。

.cvsignore について

オブジェクトファイルなど自動的に生成されるファイルを書いておくと cvs update 時に余計なメッセージが出なくなる。

環境変数 CVSROOT

cvs はカレントディレクトリの CVS ディレクトリ内に記録された情報を使用するので、 CVS ディレクトリがある場合(ワーキングディレクトリ内での作業中)には環境変数 CVSROOT を設定しておく必要ははありません。 CVSROOT が意味を持つのは主に checkout や import のときです。したがって、checkout や import する対象となるリポジトリが固定されているならば CVSROOT を設定するのもいいかも知れません。また、cvs の 解説の類では、最初に一回説明すればいいためか、シェルの初期設定で CVSROOT を設定する例がよく見られますが、複数のリポジトリを扱う場合にはあまりおすすめできません。

:ext: と 環境変数 CVS_RSH, CVS_SERVER

環境変数では柔軟性が足りないなら、cvs-rsh を使う。

ssh の警告

ssh を使用してサーバに接続した場合、

Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side.
Warning: Remote host denied authentication agent forwarding.

という警告が出る場合があります。これは、クライアントが X protocol や agent の中継を要求したのに、サーバがそれを禁止している場合におこります。 cvs ではそれらの中継は必要ないのでサーバがこれを禁止するのは適切ですし、そうでなくても ssh server のデフォルト設定がそうなっていることもあります。この警告を抑制するには中継を要求しないようにすればよく、これは次のような記述を ~/.ssh/config にすることで実現できます。

Host cvs.server.host
ForwardX11 no
ForwardAgent no

また、cvs サーバに(cvs アカウントとは別に)通常のアカウントを持っており、そちらでは中継を有効にしておきたい、という場合には、cvs サーバの(ssh 設定における)別名を作ります。

Host no-forwarding-cvs.server.host
HostName cvs.server.host
ForwardX11 no
ForwardAgent no

このような設定をしておけば、 :ext:user@no-forwarding-cvs.server.host:/path/to/repository という CVSROOT を利用することによって、中継の要求を抑制することができます。

防火壁を越えて

cvs サーバは一般にネットワークの先にあるわけですが、防火壁があってサーバに直接コネクションを繋げない場合があります。そのような場合でも、何らかの方法でサーバとの双方向通信路を確立することができれば動作させることができます。

(cvs でつかえる)防火壁を越えて通信路を確立する方法にはさまざまなものがありますが、結局は直接繋ぐかわりに途中に中継点を作り、そこのアプリケーション層で中継するということを行ないます。中継点を作る方法にはいくつかの種類があります。

SOCKS

SOCKS はまさにこのような中継をするためのソフトウェアであり、 cvs にも使えます。ただし、cvs 自体の接続の仕方にいろいろな種類があるため、 SOCKS の使い方もいろいろなやりかたがあります。

HTTP の CONNECT メソッド

RFC2817 に記述されている CONNECT メソッドは HTTP proxy を中継に使えるようにするもので、 cvs で防火壁を越えるのにも利用できます。これはもともと SSL を中継するために作られたものであり、さまざまな proxy server でサポートされていますが、アクセス制限により SSL の標準 port (443) 以外への接続が禁止されている場合もあります。

ssh

中継点となるマシン上にアカウントがあり、 ssh を使ってそのマシンに login できる場合、さまざまな方法で中継を行なうことができます。また、cvs サーバに接続するコマンドを(非対話的に)起動して ssh client があたかも cvs サーバとして振舞うようにしてもいいですし、 port forwarding で通信路を確立することもできます。

なお、cvs サーバ自体に ssh プロトコルで接続しなければならない場合もありますが、その場合 ssh プロトコルをクライアント - サーバ間の通信路に載せることになります。つまり、その場合かならず ssh を使う必要がありますが、中継には(ssh 自体を含む)さまざまな方法が使えます。必ずしも ssh だけを使わなければならないということではありません。 ssh 自身は透過的な通信路を提供するものであり幾重にも重ねることができるので、どの段階の ssh を考えているのか混乱しないようにしましょう。

httptunnel

httptunnel は HTTP の GET/PUT メソッドで通信路を確立するツールです。中継点のマシンに httpdunnel のサーバを動かす権限はあるが、クライアントと中継点の間の通信が HTTP しか使えない、 proxy サーバも CONNECT を使わせてくれない、という状況の場合に役にたつでしょう。たぶん。

単純な中継

中継点となるマシンの管理権限がある場合、対象の cvs サーバに繋ぐ専用の中継機構を動かしておくという方法が使えます。この場合の中継は単純なものなので、 delegate の tcprelay, ucspi-tcp, inetd, socket(1)(pkgsrc), など、さまざまなツールが使えます。

ただし、複数の cvs サーバを扱う場合には、それらを区別する工夫が必要になります。このためには、複数の IP アドレスをつかったり、 pserver の場合には port を変えるなどの方法が使えます。ただし、pserver クライアントで port を変えるには cvs-1.11.1 以降が必要です。

これらの中継点を具体的にどのように設定し、動作させるかにはさまざまな方法があります。

ext

cvs の ext メソッドは (デフォルトでは) rsh を起動し、サーバマシン上で cvs server というコマンドを実行することによってサーバとの通信路を確立するものです。ここで、CVS_RSH という環境変数の設定により、rsh 以外のコマンドも使うことができます。なお、この通信路を流れるデータは(認証無しの)cvs client/server protocol と呼ばれます。

結局のところ、cvs server として実行したコマンドとの双方向の通信路が確立できればいいので、通信路を確立する方法にはさまざまな方法をとることができます。

SOCKS

ssh-tunnel.pl (CONNECT)

ProxyCommand (ssh)

pserver

cvs の pserver メソッドは指定したホストの cvspserver(2401) port に接続しつ通信路を確立するものです。 pserver メソッドでは最初に認証をした後 cvs client/server protocol により、通信を行ないます。

SOCKS

tunnel.patch (CONNECT)

ssh port forwarding (ssh)

delegate,

ucspi-tcp, socket, ...

ext と pserver の変換

ext メソッドでの通信内容は先頭に認証を付け加えることによって、 pserver メソッドでの通信内容に変換することができます。したがって、そのような変換を行なえば、 pserver メソッドで提供されているサーバにクライアントからは ext メソッドで接続することができます。つまり、この変換を行なうことにより、 ext メソッドで使えるさまざまな中継方式を pserver メソッドにも使えるようになります。

cvs のはなし