CVSの使い方。

KEK 加速器研究部
山本昇

1. CVSとはなにか。

CVS(Concurrent Version System)はRCS(Revision Control System)をベースにしたVersion Managementのためのツールである。RCSとは異なり,複数の開発者によるソフトウェアの並行開発を念頭において開発された。RCSではまた, Versionの操作はファイル単位で行われていたがCVS・ナはdirectoryを単位として,コマンドを発行することが出来る。

 

 

1.1 用語

CVSでは環境変数CVSROOTに指定されるdirectoryの下にversion管理のためのファイル及びdirectoryを置く。これを repositoryとCVSでは呼んでいる。
 

2. CVSの使用法

2.1.1. CVSの環境変数。(全てのユーザ)

csh/tcshのユーザは,~/.cshrc に

setenv CVSROOT /SAD/cvsroot
#setenv CVSREAD
if( "`uname`" == "HP-UX" ) then
setenv RCSBIN /proj/local/bin
else
setenv RCSBIN /usr/local/bin
endif
#

setenv EDITOR "/usr/local/bin/emacs" # mergeの際に使われるEDITOR

 

を書き込んでおく。 (2004.10.21 追加:複数のCVS repositoryを使い分けるためには、CVSROOT環境変数を設定するより、
checkoutの際に-dオプションでCVSROOTディレクトリを指定するほうが望ましい。)


EPICS の場合には,一行目を

setenv CVSROOT /cont/ EpicsMaster

とする。

sh/kshのユーザは,~/.profileに
 

CVSROOT=<cvs root directory>;export CVSROOT
RCSBIN=<rcs command directory>; export RCSBIN

 

 

の様に書きこんでおく。

2.1.2. CVS repository の設定。(一般ユーザは不要)
上の環境変数を設定した後,
cvs distribution 中の

./cvsinit
   

を実行する。詳細はCVS distribution 中のINSTALLファイルを参照の事。
(2004.10.21追加:新しいcvsの版ではcvs -d <repository directory> init を使う。)

2.2. cvs コマンドのシンタックス

cvsコマンドの一般的な形式は,

cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]

 
 

である。cvs_commandの内重要なものは,

cvs checkout modules... (またはcvs co modules...)
cvs update
cvs commit file...
(またはcvs ci file...)
cvs add file...
cvs remove file...

 

 

の5種類である。普通の使い方ではcvs_optionsを使うこともない。

2.3 チェックアウト/チェックイン/アップデート

2.3.1 Working Directoryの作成。

CVSからソースコードをワーキングディレクトリに取り出すためには,ワーキングディレクトリをつくるディレクトリに移動して,cvs coコマンドで必要なディレクトリを取り出す。
たとえばホームディレクトリの下にoldsadの全ての環境を取り出すには,
 

cd ~/
cvs co oldsad

 

 

を実行する。これによって,ホームディレクトリの下にoldsad/ディレクトリとその下にある全てにファイル及びディレクトリが作られる。

2.3.2 チェックアウト

ワーキングディレクトリ下のファイルをCVS repositoryから取り出すには,そのファイルが属するディレクトリに移動して,cvs co filenameでファイルを取り出す。たとえば,oldsad/src/main.fをチェックアウトするには,  

cd ~/oldsad/src
cvs co main.f

の様にする。

 2.3.1.1ワーキングディレクトリの消去

ワーキングディレクトリが不要になったときには,ワーキングディレクトリの上のディレクトリで,cvs release コマンドを使う。

cd ~/
cvs release -d oldsad
   

cvs release コマンドは変更のあったファイルがcommitされているかどうかをチェックして全ての変更がrepositoryに加えられていることを確認してから ワーキングディレクトリを消去する。

2.3.2 チェックイン/アップデート
ワーキングディレクトリの中でファイルに変更を加え,その変更をCVS repositoryに反映させる為には,変更したファイルをチェックイン(あるいはcommit)する必要がある。

次のコマンド
 

cvs ci -m "your message here"

 

 

は現在のワーキングディレクトリ中の全てのファイルを調べ,変更のあったファイルをcommitする。特定のファイルだけをチェックインするために は,
 

cvs ci -m "your message here" file1 file2

 

 

等のようにファイル名(file1.f, file2,...)を指定することが出来る。
 

チェックインしようとするファイルがチェックインされてからこれまでに他の人によって変更が加えられその変更がcommitされている場合には, cvs commitコマンドはcommitを行わず,その旨を通知する。このファイルをチェックインするためには,cvs updateで他の開発者によってC VS repositoryに加えられた変更と自分の変更が矛盾しないようにmergeしてからチェックインをおこなう。

 

 

たとえば,main.fファイルに変更が加えられていれば,
 

cvs update main.f

 

 

コマンドを実行すると, 幾つかのメッセージのあと,EDITORで指定されたeditorがupdateされたmain.fの内容で開かれる。作業版のmain.fと Repositoryのmain.fに差があれば,その部分はエディタ中で
 

<<<<<<< main.f
Write(*,*) "good morning"
=======
Write(*,*) " good night"
>>>>>> 1.2

の様に表示される。Editorでこの部分を適当に修正し正しいプログラムとする。

例えば,

write(*,*) "good afternoon"

のように。
この後再びcvs ci コマンドでCVS repositoryにチェックイン(commit)する。
 
cvs ci -m "Your messages here" main.f

 

 

2.3.3 タグ

CVSで管理されているファイルにはRCSのリビジョン番号(1.1, 1.2,1.3, ...)が付けられている。
リビジョン番号は各ファイルの更新毎に増えていく。複数のファイルに別れたプログラムではあるまとまったセットのファイルはかならずしも同じリビジョン番 号を持っている訳ではない。このようなときリビジョン番号とは別に,この状態のファイル全てに共通の名前(tag)を付ける ことが出来る。
 

cvs tag FirstTag

 

 

はワーキングディレクトリにあるファイルの現在のリビジョンにタグ"FirstTag"をつける。
 

cvs tag anothertag filename

 

 

は特定のファイルにタグを付けるのに使われる。
タグの状態は
 

cvs status -v

または
cvs status -v filename

 

 

で調べることができる。

これらのタグは後で,この状態のファイルを取り出すときに利用することが出来る。
 

cvs co -r FirstTabg oldsad

 

 
 
 

2.3.4 ブランチ

CVSでは(RCSのブランチ機能をもちいて)リビジョンの枝別れを作り出すことができる。

主枝

1.1 -->
1.2 --> 1.3 ->....
|
|

bug_fix ブランチ
 +->1.2.1.1 --> 1.2.1.2 -> ....

 

 

ブランチを作るにはcvs rtagコマンドを使う。上の例であれば,
 

cvs rtag -b -r 1.2 bug_fix oldsad

 

 

の様につかう。ベースとなるリビジョンはリビジョン番号またはTagで指定する。

ブランチをチェックアウトした後,
 

cvs co -r bug_fix oldsad
cd oldsad

 

 

変更を加え,チェックインする。
 

cvs ci

 

 

この時ワーキングディレクトリがブランチからチェックアウトされたものであれば,これは
このブランチのリビジョン番号(1.2.1.x)を付ける。これをStiky tagと呼ぶ。

2.3.5ブランチのマージ(またはジョイン)

メインの開発とバグフィックス版の開発がそれぞれに進んだある時点で二つの枝を合流させることができる。

主枝

1.1 -->
1.2 --> 1.3 -->1.4 -> 1.5
|
|

bug_fix ブランチ
 +->1.2.2.1 --> 1.2.2.2 ->1.2.2.3

 

 
 
 

cvs co oldsad
# 主枝の最新版をチェックアウトする。
cvs update -j bug_fix
# ブランチで加えられた変更を全て取り入れる。
#1.2から1.2.2.3までに加えられた変更を
#ワーキングディレクトリ中のファイルに反映させる。
cvs ci -m "merged version" # create merged version in the main trunk 1.6

 

 
 
 

 マージの際にはコンフリクトが生じる可能性がある。この場合には,通常のコンフリクトと同じくファイルを編集する必要がある。 cvs coコマンドの-jオプションを使うと上の三行のコマンドは,次の二行のコマンドと等価である。
 

cvs co -j bug_fix oldsad
cvs ci -m "merged version"

 

 

2.4 ファイルの追加/削除

2.4.1ファイルの追加。

新しいファイルをCVSの制御の下に置くには,cvs addコマンドを用いる。

例えば,oldsad/srcの下に新しいファイル newfile.f を作りCVSの制御下に置くには
 
cd oldsad/src
cvs add newfile.f

 

 

とする。

2.4.2ファイルの削除。

不要になったファイルをCVSの制御からはずすには,cvs removeコマンドを用いる。

例えば,oldsad/srcの下の不要になったファイル obsolete.f をCVSの制御から取り除くには,
 
cd oldsad/src
rm obsolete.f
cvs remove obsolete.f
cvs ci -m "obsolete.f is removed"

 

 

とする。この操作によって最新版のファイルセットからはobsolete.fが取り除かれるものの,古いタグを用いてチェックアウトした際には obsolete.fが引き出される。
一度CVSの制御から取り除かれたファイルと同じ名前のファイルを再びCVSの制御下に作り出すことは,不可能と考えたほうがよい。

2.5 Third-partyソース
2.5.1サードパーティソースの輸入(import)

外部で開発されたソースコードの変更を加えることもできる。
外部で変更の加えられたソースをCVS repository に加えるには,cvs importコマンドをもちいる。
 

cd dir
cvs import -m "Your Messages" direrctory VendorTag ReleaseTag

 

 

2.5.1.1 import に関する注意

importコマンドではDeveloperに対応したブランチがつくられる。ブランチのバージョン間の違いをメインのトランクにマージすること ができる。注意すべきは, 同じDeveloperブランチにimportできるのは一日に一回である。どういうわけかは不明であるが,CVSはimportは一日に一・ネ上はお きないと仮定している。

 

 

3. 関係資料

"Version Management with CVS"
"CVS II: Parallelizing Software Development"

 

 

4. リモートCVS
 現在のCVSはリモートCVSをサポートしている。リモートCVSはワーキングディレクトリとリポジトリがネットワーク上の夫々別の
マシンにおかれている場合に使われる。リモートCVSはCVSサーバとなる計算機上でrshやsshなどのリモートシェル機能を使って、cvsの
操作を実行することで、実現されており、CVSサーバとなる計算機上でCVS サーバプロセスを起動する必要はない。
CVSROOT指定の一般型は、
 

    :method:[[user][:password]@]hostname[:port]]/path/to/repository


であり、ワーキングディレクトリのあるクライアント計算機上でcvsコマンドをhostnameを含むCVSROOTに対して実行することで、
hostnameの計算機上のrepositoryとの間でのCVSによるファイルの世代管理が行える。

 MacintoshにもMacCvs やMacCVSClientなどのCVS clientが存在するので、これらのクライアントをつかうことで、Macintoshなどの
PCでもCVSによるファイル管理が可能となる。

安全なCVSサーバ構築については、例えば、http://cvs.m17n.org/cvs/links.ja.htmlが 参考になるだろう。

5. 付録 FAQ
ahsad0:/proj/GNU/cvs-1.5/FAQからの引用。

----------------
-- Section 1D --

What do you mean by . . .? (Definitions)

----------------

**** Questions:

1D.1  "The Repository", "$CVSROOT" および "CVSROOT"とは何ですか。
1D.2 RCS fileてなに?
1D.3

working fileって何?

1D.4
working directory (or working area)って何?

1D.5
 "check out"って何?

1D.6
 a revisionって何?

1D.7
 a "Tag"って何?

1D.8
 "HEAD" と "BASE"って何?

1D.9
a Branchって何?

1D.10
 "the trunk"って何?

1D.11
 moduleって何?

1D.12
 "merge" ってなんて言うこと?

 

 

**** Answers:
 

1D.1

 "The Repository", "$CVSROOT" および "CVSROOT"とは何ですか。

 
The Repository is a directory tree containing the CVS
administrative files and all the RCS files that constitute
"imported" or "committed" work.
 The Repository is kept in a
shared area, separate from the working areas of all developers.

Repository とはCVSの管理ファイルと,すべての"import" あるいは"commited"されたRCSファイルを含んでいる,directory構造です。Repositoryはすべての開発者によって共有された 領域にあり,開発者の作業用領域とは分離されています。
 
Users of CVS must set their "CVSROOT" environment variable to the
absolute pathname of the head of the Repository. Most command
line interpreters replace an instance of "$CVSROOT" with the value
of the "CVSROOT" environment variable.
By analogy, in this
document "$CVSROOT" is used as shorthand for "the absolute
pathname of the directory at the head of the Repository".

CVSの利用者は環境変数 CVSROOT をRepositoryの先頭をさすように絶対パス名で指定しなければなりません。同様に,この文書では$CVSROOTを"Repositoryの先頭 をさすように絶対パス名"の意味で使用します。

EPICSのR3.12B13CEBAF以降ののRepositoryは/cont/EpicsMasterです。
 

One of the things found in $CVSROOT is a directory named CVSROOT.
It contains all the "state", the administrative files, that CVS
needs during execution.
 The "modules", "history", "commitinfo",
"loginfo" and other files can be found there. See 4B.2 for more
information about CVSROOT files.

$CVSROOTの中にはCVSROOTと名付けられたdirectoryが存在します。このCVSROOTのなかにはCVSが状態等の管理のために使用 するファイルが収められています。これらの管理ファイルの詳細はFAQの4B.2を見てください。
 

1D.2

RCS fileとは何ですか?

 
An RCS file is a text file containing the source text and the
revision history for all committed revisions of a source file.
It
is stored separately from the working files, in a directory
hierarchy, called the Repository.

RCSファイルは" commit"されたすべてのrevisionのソースコードテキストを含むテキストファイルです。RCSファイルはworking filesとは別にRepositoryと呼ばれるdirectory構造の下に収められています。
 
RCS is the "Revision Control System" that CVS uses to manage
individual files. RCS file names normally end in ",v", but
that can be altered (via the RCS -x option) to conform to file
naming standards on platforms with unusual filename limitations.

RCSはRevision Contorol System の略で,CVSはRCSをここのファイルを管理するために利用しています。RCSファイルの名前は通常 ",v"でおわっています。これを変更すること も,RCS -x オプションを利用して,可能です。これはファイル名に制限のあるシステムでCVSを利用すると・ォに有効です。

1D.3

working fileって何?

 
A working file is a disk file containing a checked-out copy of a
source file that earlier had been placed under CVS. If the
working file has been edited, the changes since the last committed
revision are invisible to other users of CVS.

Working file とは,CVSの管理下にあるソースファイルからcheck-outして作られたファイルです。Working fileに最後の"commit"から後に加えられた変更は他のユーザに影響しません。

1D.4

working directory (or working area)って何?
A working directory is the place where you work and the place
from which you "commit" files.

Working directoryとは開発作業(つまりソースコードの変更)を行い,"commit"を行う場所です。
 
The "checkout" command creates a tree of working directories,
filling them with working files. Each working directory contains
a sub-directory named ./CVS containing three administrative files,
which are created by "checkout" and are always present:

"checkout"コマンドはworking directoriesのツリー構造を作り,working filesをその中に収めます。それぞれのWorking directoryは./CVSと言う名のサブディレクトリを含んでいます。そのなかには次の三つのCVSの管理用ファイルがあります。これらのファイル はCVSで管理するwork ing directoryには常に存在します。
 
./CVS/Entries
contains information about working files.
Working file についての情報を収めています。
./CVS/Repository
contains the location of the directory within the
Repository that was used to create the working directory.
Wordking directoryを作るときに使われたRepository内のディレクトリの場所を
保存しています。
./CVS/Root
contains the value of $CVSROOT at the time you created
the working directory.
Working directoryが作られたときの$CVSROOTの値が保存されています。

 
Other files may also appear in ./CVS depending on the state of
your working directory:

次のファイルが場合によっては./CVSに含まれます。
./CVS/Tag
contains the "sticky tag" associated with the whole
directory. See 3A.2 for its main purpose.
[Created by "checkout" or "update" when using "-r <tag>".]
[Deleted by "checkout" or "update" when using '-A'.]
directory に関連する"sticky tag" を含んでいます。おもな目的をしるには
FAQ3A2を見てください。

 
./CVS/Entries.Static
contains a fixed list of working files.
 If this file
exists, an "update" doesn't automatically bring newly
added files out of the Repository.
[Created and maintained by hand.]
fixed list of working filesがこのファイルに保存されます。このファイルがある
と,"update"コマンドは,自動的には,Repositoryに新しく加えられたファイル
を引き出す事はしません。

 
./CVS/Checkin.prog
contains a program to run whenever anything in the
working directory is committed.
[Created by checkout if "-i <prog>" appears in the
modules file for the checked-out module.]
working directoryが"commit"されたときに常に実行されるプログラムが収められ
ています。

 
./CVS/Update.prog
contains a program to run whenever anything in the
working directory is updated.
[Created by checkout if "-u <prog>" appears in the
modules file for the checked-out module.]
working directoryが"update"されたときに常に実行されるプログラムが収められ
ています。

 

 
 
 

./CVS/<file>,p
./CVS/<file>,t
contain (possibly zero-length) state information about an
"add" that has not been committed.
[Created by "add".]
[Deleted by "commit" or "remove".]
まだ"commit"されていない,"add"についての情報が収められています。

 

 
 
 

1D.5

"check out"って何?

 
"Checking out" is the act of using the "checkout" command to
copy a particular revision from a set of RCS files into your
working area. You normally execute "checkout" only once per
working directory (or tree of working directories), maintaining
them thereafter with the "update" command.

"check out " コマンドによって,特定のrevisionのソースファイルをRepositoryからあなたの作業領域にコピーすることが出来ます。通常"check out"は一つの作業領域について一度だけ適用されます。その後は"update"コマンドが使用されます。
 
See section 3C on the "checkout" command.
"check out"コマンドについてはFAQの3Cをご覧下さい。

 

 

1D.6

revisionって何?
A "revision" is a version of a file that was "committed"
("checked in", in RCS terms) some time in the past. CVS (and
RCS) can retrieve any file that was committed by specifying its
revision number or its "tag" ("symbolic name", in RCS terms).

"revision"とは以前に"commit"されたファイルのversionを言います。CVSは(RCSも)以前に"commit"されたどのファ イルでもrevision numberまたは,"tag"(RCSではSymblic nameと呼びます)を指定することで,Repositoryから引き出すことが出来ます。
 
 
In CVS, a "tag" is more useful than a revision number.
It usually
marks a milestone in development represented by different revision
numbers in different files, all available as one "tagged"
collection.

CVSでは"tab"がrevision numberより役に立ちます。"tag"は通常,異なるファイルで異なるrevision numberをもつ開発の一里塚を記す記号として使われます。
 
Sometimes the word "revision" is used as shorthand for "the file
you get if you retrieve (via "checkout" or "update") the given
revision from the Repository."
ときには"revision"は"Repository から指定されたRevisionで("check out" 又は"update")によって引き出されたファイル"の意味で使われます。

 

 

1D.7

a "Tag"って何?

 
A "Tag" is a symbolic name, a synonym or alias for a
particular revision number in a file. The CVS "tag" command
places the same "Tag" on all files in a working directory,
allowing you to retrieve those files by name in the future.

"tag" とは,あるファイルのrevision numberをいみする,記号,同意語あるいは別名です。"cvs tag"コマンドはworking direcotory のすべてのファイルの"tag"を同じものに変更します。これによって,これらのファイルを将来この名前で引き出すことが出来ます。
 
The CVS "Tag" is implemented by applying RCS "symbols" to each
individual file. The Tags on a file (or collection of files) may
be displayed using the "log" command.

CVSの"Tag"はRCSの"symbols"をもちいて実現されています。ファイルそれぞれのTagは"log"コマンドで表示させることが出来ま す。

1D.8

"HEAD" と "BASE"って何?

 
HEAD and BASE are built-in tags that don't show up in the "log"
or "status" listings. They are interpreted directly by CVS.

"HEAD"及び"BASE"は"log"コマンドでは表示されない,組み込みの"tag"です。"HEAD"及び"BASE"はCVSによって直接解釈 されます。
 
"HEAD" refers to the latest revision on the current branch in the
Repository. The current branch is either the main line of
development, or a branch in development created by placing a
branch tag on a set of files and checking out that branch.

"HEAD"はRepository中の現在のブランチでの最新のrevisionをさしています。現在のブランチは開発の主流であってもよいし,あるい はbranch tagを設定することで作られた開発の副流であってもよい。
 
"BASE" refers to the revision on the current branch you last
checked out, updated, or committed. If you have not modified
your working file, "BASE" is the committed revision matching it.

 
Most of the time BASE and HEAD refer to the same revision. They
can become different in two ways:

 
1. Someone else changed HEAD by committing a new revision of your
file to the Repository. You can pull BASE up to equal HEAD by
executing "update".

 
2. You moved BASE backward by executing "checkout" or "update"
with the option "-r <rev/tag>" or "-D <date>". CVS records a
sticky tag and moves your files to the specified earlier
revision. You can clear the sticky tag and pull BASE up to
equal HEAD again by executing "update -A".

 

 
 
 

1D.9

What is a Branch?

 
In general, a branch is any mechanism that allows one or more
developers to modify a file without affecting anyone other than
those working on the same branch.

 
There are four kinds of "branch" CVS can manage:

 
1. The Vendor Branch.

 
A single vendor branch is supported.
 The "import" command
takes a sequence of releases from a source code vendor (called
a "vendor" even if no money is involved), placing them on a
special "Vendor" branch. The Vendor branch is considered part
of the "Main line" of development, though it must be merged
into locally modified files on the RCS Main branch before the
"import" is complete.

 
See Section 3H ("import").

 
2. Your Working directory.

 
A checked-out working directory, can be treated like a private
branch. No one but you can touch your files. You have
complete control over when you include work committed by
others. However, you can't commit or tag intermediate versions
of your work.

 
3. A Development branch.

 
A group of developers can share changes among the group,
without affecting the Main line of development, by creating a
branch. Only those who have checked-out the branch see the
changes committed to that branch. This kind of branch is
usually temporary, collapsing (i.e. merge and forget) into the
Main line when the project requiring the branch is completed.

 
You can also create a private branch of this type, allowing an
individual to commit (and tag) intermediate revisions without
changing the Main line. It should be managed exactly like a
Development Branch -- collapsed into the Main line (or its
parent branch, if that is not the Main Branch) and forgotten
when the work is done.

 
4. A Release branch.

 
At release time, a branch should be created marking what was
released. Later, small changes (sometimes called "patches")
can be made to the release without including everything else on
the Main line of development. You avoid forcing the customer
to accept new, possibly untested, features added since the
release. This is also the way to correct bugs found during
testing in an environment where other developers have continued
to commit to the Main line while you are testing and packaging
the release.

 
Although the internal format of this type of branch (branch tag
and RCS branches) is the same as in a development branch, its
purpose and the way it is managed are different. The major
difference is that a Release branch is normally Permanent.
Once you let a release out the door to customers, or to the
next stage of whatever process you are using, you should retain
forever the branch marking that release.

 
Since the branch is permanent, you cannot incorporate the
branch fixes into the Main line by "collapsing" (merging and
forgetting) the release branch. For large changes to many
files on the release branch, you will have to perform a branch
merge using "update -j <rev> -j <rev>". (See 4C.7)

 
The most common way to merge small changes back into Main line
development is to make the change in both places
simultaneously. This is faster than trying to perform a
selective merge.

 
See 1D.12 (merges) and Section 4C, on Branching for more info.

 

 
 
 

1D.10

What is "the trunk"?

 
Another name for the RCS Main Branch. The RCS Main Branch is
related, but not equivalent, to both the CVS Main branch and what
developers consider to be the Main line of development.
See 3H.3 and Section 4C on Branching.

 

 
 
 

1D.11

What is a module?

 
In essence, a module is a name you hand to the "checkout" command
to retrieve one or more files to work on. It was originally
intended to be a simple, unique name in the "modules" file
attached to a directory or a subset of files within a directory.

 
The module idea is now a somewhat slippery concept that can be
defined in two different ways:

 
A. A module is an argument to "checkout". There are three types:

 
1. An entry in the modules file. A "module" name as described
in 'B.' below.

 
2. A relative path to a directory or file in the Repository.

 
3. A mixed-mode string of "modulename/relative-path".
Everything up to the first slash ('/') is looked up as a
module. The relative path is appended to the directory
associated with the module name and the resulting path is
checked out as in #2 above.

 

 
 
 

B. A module is a unique (within the file) character string in the
first column of the modules file. There are five types:

 
1. A name for a directory within the Repository that
allows you to ignore the parent directories above it.

 
Example:

 
emacs
 gnu/emacs

 

 
 
 

2. A name for a subset of the files within such a directory.

 
Example:

 
ls
unix/bin Makefile ls.c

 
The 2nd through Nth strings in the above can be files,
directories or module substitutions. No relative paths.

 
A module substitution occurs when you use a '&module-name'
reference. The module-name referred to is logically
substituted for the '&module-name' string.

 

 
 
 

3. A relative pathname to a directory within the Repository
which, when checked out, creates an image of part of the
Repository structure in your current directory.

 
Example:

 
gnu/emacs -o /bin/emacs.helper gnu/emacs

 
The files checked out are exactly the same as the files
"checkout" would retrieve if the path weren't even in the
modules file. The only reason to put this kind of relative
pathname into the modules file is to hook one of the helper
functions onto it.

 

 
 
 

4. A relative pathname to a single file within the Repository
which, when checked out, creates something you probably
don't want: It creates a directory by the name of the file
and puts the file in it.

 
Example:

 
gnu/emacs/Makefile -o /bin/emacs.helper gnu/emacs Makefile

 
The file checked out is the same as what you would get if
you handed the relative pathname to the "checkout" command.
But it puts it in a strange place. The only reason to do
this is to hook a helper function onto a specific file name.

 

 
 
 

5. An alias consisting of a list of any of the above, including
other aliases, plus exceptions.

 
Example:

 
my_work -a emacs !emacs/tests gnu/bison unix/bin/ls.c

 

 
 
 

The exception "!emacs/test" above is functionally equivalent
to specifying "!emacs/tests" on the "checkout" command line.

 

 
 
 

Another way to look at it is that the modules file is simply
another way to "name" files. The hierarchical directory
structure provides another. You should use whatever turns out to
be simplest for your development group.

 
See 4G.2 for some specific ideas about how to use the modules file.

 

 

1D.12

What does "merge" mean?

 
A merge is a way of combining changes made in two independent
copies of a common starting file. Checking out an RCS revision
produces a file, so for the purposes of a merge "file" and
"revision" are equivalent. So, we can say there are always three
"files" involved in a merge:

 
1. The original, starting, "base" or "branch point" file.
2. A copy of the base file modified in one way.
3. Another copy of the base file modified in a different way.

 
Humans aren't very good at handling three things at once, so the
terminology dealing with merges can become strained. One way to
think about it is that all merges are performed by inserting the
difference between a base revision and a later revision (committed
by someone else) into your working file. Both the "later"
revision and your working file are presumed to have started life
as a copy of the "base" revision.

 
In CVS, there are three main types of "merge":

 
1. The "update" command automatically merges revisions committed
by others into your working file. In this case, the three
files involved in the merge are:

 
Base:
 The revision you originally checked out.
Later:
 A revision committed onto the current branch
after you checked out the Base revision.
Working: Your working file. The one lying in the working
directory containing changes you have made.

 
2. The "update -j <branch_tag> {optional files}" command merges
changes made on the given branch into your working files, which
is presumed to be on the Main line of development.

 
See 4C.6

 
3. The "update -j <rev> -j <rev> {optional files}" command merges
the difference between two specified revisions into files in
your working directory. The two revisions <rev> are usually on
the same branch and, when updating multiple files, they are
most useful when they are Tag names rather than numeric
revisions.

 
See 4C.7