RCS 超入門

-- but not for dummies. Be a human first.

[RCS超入門] [RCS初級講座] [RCS中級講座] [RCSエラー対処] [RCS-SCCS対応表] [リンク集]

ファイルの更新サイクル
まず使ってみる
基本コマンド ci,co
RCSでの管理をやめる

$Id$に気をつけろ
RCS適用の向き・不向き

当文書の著作権は東芝グループ、富士通グループ構成各社のいずれにも帰属しません。

$Id: rcs.html,v 3.9 2016-07-02 11:12:44+09 kabe Exp $

▼RCS管理下ファイルの更新サイクル

(このサイクルから外れると小技裏技で修正する必要が出てくる)

		↓
	　　　登録する
		↓
	　→→→＋ <<< 普段はここ。ファイルは書込不可
	↑　　　↓
	↑　ロックをかける (編集可能になる)
	↑　　　↓
	↑　お好みのエディタで編集する
	↑　　　↓
	↑　登録してロックを解除する (編集不可になる)
	↑　　　↓
	　←←←

▼まず使ってみる▼

まず "RCS" というディレクトリを作ります。
% mkdir RCS
次にファイルのどこかに $Id$ という部分を作ります。
```
	# $Id$
	/* $Id$ */
	// $Id$
	static char *rcsid = "$Id$";
	
```
そして ci -u filenameとすれば RCS 管理下に入ります。
初めてのファイルでは、そのファイル自体に関する簡単な説明を要求されますので入れておきましょう。エラーじゃないです。思いつかなければ空でも良い。最後は".<CR>"。
$Id$の部分はRCSによって置換されて
/* $Id: foo,v 1.1 1996/11/28 13:14:43 kabe Exp$ */
といった形になり、さらに書き込み権限が落ちます。
編集したくなったら
% co -l filename
で書き込み権限がつくので、お好みのエディタで編集します。
どこを変更したのか知りたくなったら
% rcsdiff filename
ひと区切りついたら
% ci -u filename
で変更を登録します。「コメントを入れろ」と要求されるので、手短に変更点を説明して".<CR>"と打ちましょう。

ということが rcsintro(1) に書かれています。附属のマニュアルは割に詳しいのでちゃんと読もう。

▽自動で生成されるファイル

これだけだと、裏で何が行なわれるのかが前もってわからないので不安になりますが、新しく生成されるファイルは RCS/filename,v だけです。他には何もつくられません。単純。

▼RCSでの管理をやめる

./RCS/filename,v ファイルを消します。
./RCS/ を掘っていなかった場合は、ファイルと同じディレクトリの filename,v というファイルを消します。
./RCS/ が空であれば、ディレクトリごと消してかまいません。
filename の mode を手動で戻します。 chmod +w filename など。

普通は ./RCS/ ディレクトリを掘りますし、やめたくなった時はそこのファイル全部やめる、でしょうから、 rm -fr ./RCS だけで十分でしょう。

▼基本コマンド▼

普段使用するぶんにはco -l , ci -u だけを知っていれば使えます。

% co -l filename

(co: Check Out, -l: Lock)
ファイルを自分が編集できるようにします。つまり自分だけのwrite permissionがついた状態になります。

% ci -u filename

(ci: Check In, -u: Unlock)
ファイルをRCSに登録し、ロックを外します。ロックが外れると他の人が co -l ができるようになります。 ci -u としたファイルはすべてのWrite permissionが落ちるので、 あせって chmod しないように 。編集したいときは co -l します。

ファイルがすでに編集されていれば、Revision番号がつけかわり、変更点のコメントを要求されます。後々のためにもどこをなぜ変更したか、をこれで記録しておくと良いでしょう。

% co filename

% ci filename

「ファイルがなくなったです～(;_;)」

単に ci filename とするとファイルがカレントディレクトリから消えてしまいます。そうなったら あわてずに co だけを実行 しましょう。オプションなしの co は「閲覧用に取り出す」という意味で、端的には書き込み権限がつきません。(-r--r--r--)

ci -u filename は ci filename; co filenameと同じになります。

くわしくは man rcs で…

▽一人でしか使わないんだけど

目先の利益：誤って rm * とかしても RCS管理下にしておけば co で復活できるので、一人だけで使っていてもRCSを使う価値はあります。 (さすがに rm -fr * では全滅する。バックアップはちゃんととりましょう;_;)

長期的利益：新版の登録毎にコメントを要求されるので、必然的に修正に関する説明をひねりだす必要性が出てきます。漠然と修正するのではなく、履歴で説明できるような目的意識をもって修正を行なうようになるという教育的効果もあるかもしれません。 (毎回 .<CR> で済ませている人は、３ヶ月後には後悔すると思いますよ～)

実際上は更新履歴を見て悦に入ったり感心したりのほうが多いと思いますが

▼$Id$があるぞ、気をつけろぉ

$Id$ という文字列があれば、 ダブルクオートの中だろうと置換してしまう ので、"$Id$"といった文字定数を使うのであれば何とかしてバラしましょう。例えばこの文章なんかもそこいらに $Id$ があるのでそのまま RCS管理下に入れると変になります。

ですからこの一連のRCS入門だけはSCCSで管理しようと思ったんですが JISコードに含まれる"%"に反応してしまうんでダメでした(;_;)
もっともRCSでも「ど笋」「つ癆紊」「と縺粤鮑」には反応するんで (それぞれ "$Id$" "$Date$" "$Header:") 油断できません。

さいわい、HTMLでは "$" のかわりに "$" と書いて回避することができます。これに気づいてから (遅いぞ) このRCS入門もめでたく RCS管理下に入れることができました。

それでも上の「ど笋」までは気づかず、超はまりました。さてどうやって回避してるんでしょう

▼RCS管理に向いているもの

素の RCS は、基本的に単一のファイルを管理するように作られているので、

各種設定ファイル (.htaccess, smb.conf, moderators…)
単独スクリプト
一本の文書
とにかくファイル一つでだいたい独立しているもの
/etc/にある大量のファイルのうち、１つだけ

を管理するのに向いています。

逆にきわめて不向きなのが、複数のファイルが組になっているような

ちょっとしたプログラム (*.cが数本、マニュアル、README…)
章毎に分けたような文書
とにかく.tar.gzで配るようなもの
そのディレクトリ以下のファイルを全部

もちろん変更履歴が残せるといった利点もあるので何も使わないよりはずっといいのですが、まとめて管理するという目的にはなじみません。しゃーないので結局 hoge19991231.tar.gz とかいったファイルで残しがちです。番号ではなく名前つきタグで管理すればある程度複数ファイルも扱えますが、使い勝手はあんましよくありません。

RCSが想定している「一人が編集、みんなで閲覧」も、素の RCS ではめんどくさいため現実的ではありません。素直に CVS などのもっと高級なツールをかぶせましょう。 Emacsなら VC てのもあるらしいですぞ。

RCSは複数ファイルの扱いが苦手なので、RCSばっかり使っていると、複数ファイルに分けたほうが楽なようなプログラムも、無意識のうちに管理がめんどくさそうだと一本にまとめたがるようになります(それ俺)。なので、自分でこのことに気づいたらさっさとCVSなりにステップアップしましょう。（＜おまえがさきにやれ)

かべ＠sra-tohoku．co．jp