RCSINTRO(1) RCSINTRO(1) 名称 rcsintro - RCS 入門 解説 RCS (Revision Control System) は、ファイルのリビジョンを複数管理します 。 RCS は格納、取り出し、ログ、識別、リビジョンの併合を自動 化 し ま す 。RCS は頻繁に更新されるテキスト、たとえば、プログラム、ドキュメント、 グラフィックス、論文、定型手紙等を扱うのに便利です。 基本的なユーザインタフェースはとても単純です。初心者は 2 つのコマンド、 ci(1) と co(1) を覚えるだけで使用できます。 ci はチェックイン “check in” を省略した名前です。これは、ファイルの内容を「RCS ファイル」と呼 ば れる記録用のファイルに格納します。 RCS ファイルは、特定ファイルの全リビ ジョンを含んでいます。 co はチェックアウト“check out” を省略した名前 で す。これは、RCS ファイルからリビジョンを取り出します。 RCS の機能 · テキストの複数のリビジョンの保存と取り出しを行います。RCS はすべ ての古いリビジョンを効率的な方法で保存します。ファイルを変更して も元のリビジョンが失なわれることはなく、いずれも取り出すことが可 能です。リビジョンは、リビジョン番号、シンボル名、日付、作者、状 態を指定して取り出せます。 · 完全な変更の履歴を管理します。RCS は、すべての変更点を自動的に記 録します。各リビジョンの内容とともに、作者、チェックインした日時 、変更点を要約したログメッセージが記録されます。ログによって、ど のような変更が行われたのかがひと目でわかります。ソースリストを見 比べたり、一緒に作業しているプログラマにたずねたりする必要はあり ません。 · アクセス矛盾を解決します。複数のプログラマがあるファイルの同じリ ビ ジョンに対して変更を加えようとした場合、 RCS は警告を発し、他 者が行った変更を台無しにしてしまうのを防ぎます。 · リビジョンの木を管理します。RCS はモジュールごとに独立した開発ラ イ ンを管理できます。 RCS は、リビジョンの系図を表現した木を保存 します。 · リビジョンを併合し、矛盾を解決します。あるモジュールの 2 つの リ ビ ジョンを併合することができます。併合しようとする 2 つのリビジ ョンが、あるコードの同じ部分に対する変更を含んでいた場合、RCS は 変更が重複していると警告します。 · リリースと構成を管理します。リビジョンにはシンボル名をつけること ができます。また、「リリース版(released)」、「安定版(stable)」、 「実験版(experimental)」といった状態をつけることもできます。これ により、単純かつ直接的にモジュールの構成を表すことができます · リビジョン番号、作成日時、作者等を自動的に識別することができます 。識別情報は、消印のようにテキストの適当な場所に埋め込むことがで きます。これにより、あるソフトウェアの構成にどのモジュールのどの リビジョンが使用されているかを判断することが容易になります。 · 必要なディスク容量を最小にします。RCS は、リビジョンのために最小 のスペース(差分のみ)しか消費しません。もし途中のリビジョンが削除 されたなら、記録されていた差分もそれに従って小さくなります。 RCS 事始め RCS の管理下に置きたい f.c というファイルがあるとします。もし、まだ作成 していなければ、 RCS ディレクトリを以下のコマンドにより作成します。 mkdir RCS 次に ci (チェックイン) コマンドを実行します。 ci f.c これにより、 f.c の内容をリビジョン 1.1 として記録した RCS ファイ ル が RCS ディレクトリ内に作成され、 f.c は削除されます。また、 ci は f.c に 関する説明文の入力を促します。説明文にはファイルの内容を要約して書き ま す 。以降 ci を実行するたびに、ファイルに加えた変更の要約を入力するよう に促します。 RCS ディレクトリにあるファイルは RCS ファイルと呼ばれ、それ以外のファイ ルはワークファイルと呼ばれます。先の例で挙げたワークファイル f.c を取り 戻すには co (チェックアウト) コマンドを実行します。 co f.c このコマンドは RCS ファイル中の最新のリビジョンを取り出してファイル f.c に書き出します。もし、 f.c に変更を加えたければ、次のコマンドを使ってチ ェックアウトしロックしなければいけません。 co -l f.c これで f.c を編集することができます。 ある程度編集したところで、どのような変更を加えたか知りたくなるときが あ ります。この場合は、以下のコマンドを実行します。 rcsdiff f.c こ のコマンドは、最後にチェックインしたリビジョンとワークファイルの違い を表示します。編集が終わったら、以下のコマンドにより、もう一度チェッ ク インすることができます。 ci f.c これにより、リビジョン番号が自動的に付け直されます。 もし ci が ci error: no lock set by your name と いうエラーメッセージを出力したなら、それは、ロックせずにチェックアウ トしたファイルをチェックインしようとしたからです。もちろん、ここでロ ッ ク しチェックアウトし直すのでは遅すぎます。ここでチェックアウトすると、 あなたが行った編集は上書きされて失われてしまうからです。かわりに、以 下 のコマンドを実行します。 rcs -l f.c こ れは、ほかに誰もロックしていなければ、最新のリビジョンをロックします 。もし、すでに誰かがロックしてしまっていたなら、その人と相談しなけれ ば なりません。 ロックすることにより、あなただけがファイルを更新(チェックイン) できるよ うになり、同時に複数の人が同じファイルを編集する際の厄介な問題を回避 す る ことができます。たとえリビジョンがロックされていても、そのファイルを チェックアウトして内容を見たり、コンパイルすることは可能です。ロック 機 構は、ロックした人以外が チェックインできないようにするだけです。 もし扱う RCS ファイルが個人的なもの、すなわちそのファイルに対して新しい リビジョンをチェックインするのがあなただけである場合、厳格なロック機 構 は 必要ないでしょう。厳格なロック機構はオフにすることもできます。もし厳 格なロックモードがオフになっているなら、 RCS ファイルの所有者はロックし ていないファイルをチェックインすることができます(それ以外の人はロックが 必要です)。厳格なロックモードのオンとオフは、それぞれ以下のコマンドによ り行います。 rcs -L f.c 及び rcs -U f.c もしワークディレクトリに RCS ファイルをまき散らしたくないなら、RCS とい う名前のディレクトリを作成し、RCS ファイルをすべてその下に移動 し ま す 。RCS コマンドは RCS ファイルを探すとき、まず、 RCS ディレクトリを検索 します。この場合も、これまでに述べてきたコマンドは引数をいっさい変更 せ ずに実行できます(実際は RCS に RCS ファイルとワークファイルの対を指示す る方法は 3 通りあります: (a) 両方を指定する、(b) ワークファイルのみを指 定する、 (c) RCS ファイルのみを指定する。RCS ファイルとワークファイルは 自由なパスに置くことができますが、RCS コマンドはファイルの対をインテ リ ジェントに探します)。 チ ェックインしたときにワークファイルが削除されないようにする (編集を続 けたり、コンパイルしたりする場合)には以下のコマンドを使います。 ci -l f.c あるいは ci -u f.c これらのコマンドは通常どおり f.c をチェックインします。しかし、自動的に チ ェックアウトも行います。最初の例ではロックを行い、2 番目の例ではロッ クを行いません。このようにすればチェックアウト操作を 1 回省けます。最初 の 例は編集を続ける場合に、2 番目の例は単にファイルを読みたかったりコン パイルしたりする場合に便利です。どちらの場合も、ワークファイル中の識 別 用マーカ(後述)が更新されます。 ci にチェックインするリビジョンの番号を指定することができます。それまで のリビジョンが 1.1、1.2、1.3... だったときに、以下のコマンドによりリ リ ース2 を開始することができます。 ci -r2 f.c あるいは ci -r2.1 f.c これにより、新しいリビジョンには番号 2.1 がつけられます。以降、 ci はこ のファイルの新しいリビジョンに 2.2、2.3...と番号をつけていきます。対 応 した以下の co コマンド co -r2 f.c 及び co -r2.1 f.c は 、リビジョン番号が 2.x である最新のリビジョン、リビジョン 2.1 をそれ ぞれチェックアウトします。 co にリビジョン番号を指 定 し な い 場 合 、 幹(trunk)の上の最新のリビジョン (すなわち、x.x の形式で最大のリビジョン 番号を持つリビジョン)がチェックアウトされます。リビジョンの枝(branch)を 用いるためには 3 つ以上の番号が必要になります。たとえば、1.3 から枝を作 成するには、以下のコマンドを実行します。 ci -r1.3.1 f.c これにより、リビジョン 1.3 上に番号 1 の枝を作成し、枝上の最新リビジ ョ ンとして 1.3.1.1 を割り当てます。枝の詳細については rcsfile(5) を参照し てください。 自動識別 RCS は、リビジョンの識別のために特別な文字列をソースやオブジェクトコ ー ド に埋め込むことができます。リビジョンの識別を行うためには、以下の文字 列(マーク) $Id$ をコメントなどのテキスト部分に書きます。 RCS は、このマークを次の形式の 文字列に置換します。 $Id: ファイル名 リビジョン 日付 時刻 作者 状態 $ このようなマークをモジュールのソースコードの 1 ページ目に置くことにより 、編集しているファイルのリビジョンをすぐに判断することができま す 。RCS は マークの更新を自動的に行います。マークをオブジェクトコードに組み込む には、それをリテラルな文字列中に含めます。C 言語では、以下のようにし ま す。 static char rcsid[] = "$Id$"; ident コマンドは、オブジェクトファイルやダンプ出力からもマークを探し表 示することができます。従って ident コマンドを用いることにより、あるプロ グ ラムがどのモジュールのどのリビジョンによって作成されたかを知ることが できます。 マーク $Log$ をテキストやコメント内に含めることも有用かもしれません。こ の マークはチェックインのときに要求されたログを蓄えていきます。これによ り、変更の履歴を直接、ファイルに記録することができます。 RCS にはほかに もいくつかのマークがあります。詳しくは co(1) を参照してください。 作者 Author: Walter F. Tichy. Manual Page Revision: 1.5; Release Date: 1999/08/27. Copyright © 1982, 1988, 1989 Walter F. Tichy. Copyright © 1990, 1991, 1992, 1993 Paul Eggert. 関連項目 ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1) Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654. GNU 1999/08/27 RCSINTRO(1)
RCSINTRO(1) RCSINTRO(1) NAME rcsintro - introduction to RCS commands DESCRIPTION The Revision Control System (RCS) manages multiple revisions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised fre- quently, for example programs, documentation, graphics, papers, and form letters. The basic user interface is extremely simple. The novice only needs to learn two commands: ci(1) and co(1). ci, short for “check in”, deposits the contents of a file into an archival file called an RCS file. An RCS file contains all revisions of a particular file. co, short for “check out”, retrieves revisions from an RCS file. Functions of RCS · Store and retrieve multiple revisions of text. RCS saves all old revisions in a space efficient way. Changes no longer destroy the original, because the previous revisions remain accessible. Revisions can be retrieved according to ranges of revision numbers, symbolic names, dates, authors, and states. · Maintain a complete history of changes. RCS logs all changes automatically. Besides the text of each revision, RCS stores the author, the date and time of check-in, and a log message summarizing the change. The logging makes it easy to find out what happened to a module, without having to compare source listings or having to track down colleagues. · Resolve access conflicts. When two or more programmers wish to modify the same revision, RCS alerts the programmers and pre- vents one modification from corrupting the other. · Maintain a tree of revisions. RCS can maintain separate lines of development for each module. It stores a tree structure that represents the ancestral relationships among revisions. · Merge revisions and resolve conflicts. Two separate lines of development of a module can be coalesced by merging. If the revisions to be merged affect the same sections of code, RCS alerts the user about the overlapping changes. · Control releases and configurations. Revisions can be assigned symbolic names and marked as released, stable, experimental, etc. With these facilities, configurations of modules can be described simply and directly. · Automatically identify each revision with name, revision number, creation time, author, etc. The identification is like a stamp that can be embedded at an appropriate place in the text of a revision. The identification makes it simple to determine which revisions of which modules make up a given configuration. · Minimize secondary storage. RCS needs little extra space for the revisions (only the differences). If intermediate revisions are deleted, the corresponding deltas are compressed accord- ingly. Getting Started with RCS Suppose you have a file f.c that you wish to put under control of RCS. If you have not already done so, make an RCS directory with the command mkdir RCS Then invoke the check-in command ci f.c This command creates an RCS file in the RCS directory, stores f.c into it as revision 1.1, and deletes f.c. It also asks you for a descrip- tion. The description should be a synopsis of the contents of the file. All later check-in commands will ask you for a log entry, which should summarize the changes that you made. Files in the RCS directory are called RCS files; the others are called working files. To get back the working file f.c in the previous exam- ple, use the check-out command co f.c This command extracts the latest revision from the RCS file and writes it into f.c. If you want to edit f.c, you must lock it as you check it out with the command co -l f.c You can now edit f.c. Suppose after some editing you want to know what changes that you have made. The command rcsdiff f.c tells you the difference between the most recently checked-in version and the working file. You can check the file back in by invoking ci f.c This increments the revision number properly. If ci complains with the message ci error: no lock set by your name then you have tried to check in a file even though you did not lock it when you checked it out. Of course, it is too late now to do the check-out with locking, because another check-out would overwrite your modifications. Instead, invoke rcs -l f.c This command will lock the latest revision for you, unless somebody else got ahead of you already. In this case, you’ll have to negotiate with that person. Locking assures that you, and only you, can check in the next update, and avoids nasty problems if several people work on the same file. Even if a revision is locked, it can still be checked out for reading, compiling, etc. All that locking prevents is a check-in by anybody but the locker. If your RCS file is private, i.e., if you are the only person who is going to deposit revisions into it, strict locking is not needed and you can turn it off. If strict locking is turned off, the owner of the RCS file need not have a lock for check-in; all others still do. Turn- ing strict locking off and on is done with the commands rcs -U f.c and rcs -L f.c If you don’t want to clutter your working directory with RCS files, create a subdirectory called RCS in your working directory, and move all your RCS files there. RCS commands will look first into that directory to find needed files. All the commands discussed above will still work, without any modification. (Actually, pairs of RCS and working files can be specified in three ways: (a) both are given, (b) only the working file is given, (c) only the RCS file is given. Both RCS and working files may have arbitrary path prefixes; RCS commands pair them up intelligently.) To avoid the deletion of the working file during check-in (in case you want to continue editing or compiling), invoke ci -l f.c or ci -u f.c These commands check in f.c as usual, but perform an implicit check- out. The first form also locks the checked in revision, the second one doesn’t. Thus, these options save you one check-out operation. The first form is useful if you want to continue editing, the second one if you just want to read the file. Both update the identification markers in your working file (see below). You can give ci the number you want assigned to a checked in revision. Assume all your revisions were numbered 1.1, 1.2, 1.3, etc., and you would like to start release 2. The command ci -r2 f.c or ci -r2.1 f.c assigns the number 2.1 to the new revision. From then on, ci will num- ber the subsequent revisions with 2.2, 2.3, etc. The corresponding co commands co -r2 f.c and co -r2.1 f.c retrieve the latest revision numbered 2.x and the revision 2.1, respec- tively. co without a revision number selects the latest revision on the trunk, i.e. the highest revision with a number consisting of two fields. Numbers with more than two fields are needed for branches. For example, to start a branch at revision 1.3, invoke ci -r1.3.1 f.c This command starts a branch numbered 1 at revision 1.3, and assigns the number 1.3.1.1 to the new revision. For more information about branches, see rcsfile(5). Automatic Identification RCS can put special strings for identification into your source and object code. To obtain such identification, place the marker $Id$ into your text, for instance inside a comment. RCS will replace this marker with a string of the form $Id: filename revision date time author state $ With such a marker on the first page of each module, you can always see with which revision you are working. RCS keeps the markers up to date automatically. To propagate the markers into your object code, simply put them into literal character strings. In C, this is done as fol- lows: static char rcsid[] = "$Id$"; The command ident extracts such markers from any file, even object code and dumps. Thus, ident lets you find out which revisions of which mod- ules were used in a given program. You may also find it useful to put the marker $Log$ into your text, inside a comment. This marker accumulates the log messages that are requested during check-in. Thus, you can maintain the complete history of your file directly inside it. There are several additional identi- fication markers; see co(1) for details. IDENTIFICATION Author: Walter F. Tichy. Manual Page Revision: 5.3; Release Date: 1993/11/03. Copyright © 1982, 1988, 1989 Walter F. Tichy. Copyright © 1990, 1991, 1992, 1993 Paul Eggert. SEE ALSO ci(1), co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1), rcsmerge(1), rlog(1) Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654. GNU 1993/11/03 RCSINTRO(1)
Copyright(C) linux-cmd.com All Rights Reserved. Author Takayuki Yukawa