\input texinfo  @c -*-texinfo-*-
@comment Documentation for CVS.
@comment Copyright (C) 1992, 1993, 1999 Signum Support AB
@comment Copyright (C) 1993 Free Software Foundation, Inc.
@comment Copyright (C) 1995-1999 Makoto Hiroyasu
@comment Copyright (C) 1999 Yoshiki Hayashi

@comment This file is not part of the CVS distribution.

@comment CVS is free software; you can redistribute it and/or modify
@comment it under the terms of the GNU General Public License as published by
@comment the Free Software Foundation; either version 2, or (at your option)
@comment any later version.

@comment CVS is distributed in the hope that it will be useful,
@comment but WITHOUT ANY WARRANTY; without even the implied warranty of
@comment MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
@comment GNU General Public License for more details.

@c See ../README for A4 vs. US letter size.
@c When we provided A4 postscript, and people tried to
@c print it on US letter, the usual complaint was that the
@c page numbers would get cut off.
@c If one prints US letter on A4, reportedly there is
@c some extra space at the top and/or bottom, and the side
@c margins are a bit narrow, but no text is lost.
@c
@c See
@c http://www.ft.uni-erlangen.de/~mskuhn/iso-paper.html
@c for more on paper sizes.  Insuring that margins are
@c big enough to print on either A4 or US letter does
@c indeed seem to be the usual approach (RFC2346).

@c This document seems to get overfull hboxes with some
@c frequency (probably because the tendency is to
@c sanity-check it with "make info" and run TeX less
@c often).  The big ugly boxes just seem to add insult
@c to injury, and I'm not aware of them helping to fix
@c the overfull hboxes at all.
@finalout

@setfilename cvs-ja.info
@include CVSvn.texi
@settitle CVS---Concurrent Versions System (in Japanese)
@setchapternewpage odd
@iftex
@c @documentlanguage ja
@documentencoding EUC-JP
@end iftex
@c FIXJA

@c -- TODO list:
@c -- Fix all lines that match "^@c -- "
@c -- Also places marked with FIXME should be manual
@c problems (as opposed to FIXCVS for CVS problems).

@ifinfo
@format
START-INFO-DIR-ENTRY
* CVS-JA: (cvs-ja).        Concurrent Versions System (Japanese)
END-INFO-DIR-ENTRY
@end format
@end ifinfo

@ifinfo
Copyright @copyright{} 1992, 1993 Signum Support AB
Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
Copyright @copyright{} 1995-1999 Makoto Hiroyasu
Copyright @copyright{} 1999 Yoshiki Hayashi

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the Free Software Foundation.
@end ifinfo

@comment The titlepage section does not appear in the Info file.
@titlepage
@sp 4
@comment The title is printed in a large font.
@center @titlefont{CVSによるバージョン管理}
@sp 2
@center Version Management with CVS
@center for @sc{cvs} @value{CVSVN}
@center Per Cederqvist et al
@sp 25
@center 日本語訳 : 廣保 誠, 林 芳樹

@comment  The following two commands start the copyright page
@comment  for the printed manual.  This will not appear in the Info file.
@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1992, 1993 Signum Support AB
Copyright @copyright{} 1995-1999 Makoto Hiroyasu
Copyright @copyright{} 1999 Yoshiki Hayashi

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the Free Software Foundation.
@end titlepage

@comment ================================================================
@comment                   The real text starts here
@comment ================================================================

@ifinfo
@c ---------------------------------------------------------------------
@node    Top
@top CVS 1.10.7 Japanese Manual
@c Note: there is a space after that @top command.
@c The texinfo-format-buffer Emacs function and
@c the makeinfo shell command disagree on what arguments
@c @top takes; @top followed by a single space is
@c something they can both cope with.

この info manual は、
@sc{cvs} version @value{CVSVN}
の使用方法と管理方法について記述します。
@end ifinfo

@c This menu is pretty long.  Not sure how easily that
@c can be fixed (no brilliant ideas right away)...
@menu
* Overview::                    CVS への導入
* Repository::                  全てのソースが保存される場所
* Starting a new project::      CVS でプロジェクトを始める
* Revisions::                   リビジョンの数値とシンボルの名前
* Branching and merging::       開発の枝の多様化/再一本化
* Recursive behavior::          CVS はディレクトリを降りていく
* Adding and removing::         ファイル/ディレクトリを加える/取り除
                                く/名前を変える
* History browsing::            ファイルの履歴をいろいろな方法で閲覧する

CVS と現実の世界
-----------------------
* Binary files::                CVS はバイナリ・ファイルを扱うことができる
* Multiple developers::         CVS の開発者グループの援助の仕方
* Revision management::         リビジョン管理のポリシーへの質問
* Keyword substitution::        CVS はファイルの中にリビジョンを含むこ
                                とができる
* Tracking sources::            サード・パーティーソースの追っかけ
* Builds::                      CVS とコンパイルに関する問題
* Special Files::		デバイス、リンクと他の普通でないファイ
                                ル

リファレンス
-----------
* CVS commands::                CVS の命令は同じものを使う
* Invoking CVS::                CVS の命令の quick reference
* Administrative files::        管理ファイルへのリファレンスマニュアル
* Environment variables::       CVS に影響する全ての環境変数
* Compatibility::               CVS のバージョンを上げる
* Troubleshooting::             動作しないときのいくらかのこつ
* Credits::                     このマニュアルへの貢献者達
* BUGS::                        CVS かこのマニュアルのバグの対処
* 翻訳者より:Translation.       日本語訳について
* Index::                       索引
@end menu

@c ---------------------------------------------------------------------
@node Overview
@chapter 概観
@cindex Overview

この章は @sc{cvs} を一度も使ったことが無く、おそらく以前にバージョン管
理ソフトを使ったことの無い人のためのものです。

既に @sc{cvs} に親しんでいて、特定の機能を学んだり、特定の命令を覚えよ
うとしているときは、ここは全て飛ばしてください。

@menu
* What is CVS?::                @sc{cvs} で何が出きるか
* What is CVS not?::            @sc{cvs} が解決しようとしない問題
* A sample session::            基本的な @sc{cvs} の利用のツアー
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node What is CVS?
@section CVS とは?
@cindex What is CVS?
@cindex Introduction to CVS
@cindex CVS, introduction to

@sc{cvs} はバージョン管理システムであり、
あなたのソース・ファイルの変遷を記録するのに使用します。

@c -- ///
@c -- ///Those who cannot remember the past are condemned to repeat it.
@c -- ///               -- George Santayana
@c -- //////

@c -- Insert history  quote here!
例えば、ソフトウェアの修正に伴なってバグが入り込み、
発見されるまでに長い時間がかかったとします。
@sc{cvs} を使っていれば、古いバージョンを簡単に復元し、
バグの原因となった変更点を正確に調べることができます。
この特徴に救われる時が必ずあります。

全てのバージョンの全てのファイルを保存しておくこともできますが、
ディスク容量の無駄使いでしかありません。
@sc{cvs} は、バージョン間の差分のみを保存する方法により、
各ファイルの全バージョンを一つのファイルに記録します。

@sc{cvs} は、複数の開発者が同じソフトウェアに
取り組む場合に、真価を発揮します。
このような場合にはよほど気を付けていないと、
他の人が変更したファイルを上書きしてしまいます。
@sc{gnu} Emacs のようなエディタを使えば、
複数の人が同時に同じファイルを編集することはありません。
しかし不幸なことに、全員が同じエディタを使うとは限りません。
@sc{cvs} は開発者を互いに隔離することにより、この問題を解決しました。
全ての開発者は自分のディレクトリで作業し、
その仕事を @sc{cvs} が組み合わせます。

@cindex History of CVS
@cindex CVS, history of
@cindex Credits (CVS program)
@cindex Contributors (CVS program)
@sc{cvs} は Dick Grune が作成し、
1986年 12 月に @code{comp.sources.unix} の volume 6 に投稿した、
シェル・スクリプトから始まりました。
現在の @sc{cvs} は、
これらのシェル・スクリプトのコードを全く含みませんが、
衝突解決のアルゴリズムの大部分を受け継いでいます。

1989年 4 月に Brian Berliner が @sc{cvs} を設計し、コーディングしました。
その後、Jeff Polk が @sc{cvs} の ベンダー枝とモジュールの設計を助けました。

@cindex Source, getting CVS source
@sc{cvs} をインターネットからの自由なダウンロードなど、いろいろな方法
で取得することができます。 @sc{cvs} のダウンロードや、他の @sc{cvs} の
話題の情報は、以下のところを参照してください。

@example
http://www.cyclic.com/
http://www.loria.fr/~molli/cvs-index.html
@end example

@cindex Mailing list
@cindex List, mailing list
@cindex Newsgroups
@w{@code{info-cvs}} という @sc{cvs} 専門のメーリング・リストがあります。
@c このメーリング・リストに
参加、又は脱退したい場合には、
@w{@code{info-cvs-request@@gnu.org}} にメールを出して下さい。
Usenet グループの方を好むのであれば、正しいグループは
@code{comp.software.config-mgmt} で、@sc{cvs} の議論を
するために適した場所です (他の構成管理システムと一緒で
すが)。 将来は @code{comp.software.config-mgmt.cvs} を
作ることも可能かもしれませんが、おそらく
@code{comp.software.config-mgmt} に十分な流量があるよう
になったときだけでしょう。
@c Other random data is that past attempts to create a
@c gnu.* group have failed (the relevant authorities
@c say they'll do it, but don't), and that tale was very
@c skeptical of comp.software.config-mgmt.cvs when the
@c subject came up around 1995 or so (for one
@c thing, because creating it would be a "reorg" which
@c would need to take a more comprehensive look at the
@c whole comp.software.config-mgmt.* hierarchy).

@ref{BUGS} でより詳細に説明されている bug-cvs メーリン
グリストを講読するともできます。講読するためには、
bug-cvs-request@@gnu.org にメールを送ってください。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node What is CVS not?
@section CVS は何ではない?
@cindex What is CVS not?

@sc{cvs} は多くのことができますが、全ての人に全てのことを
するようにはなっていません。

@table @asis
@item @sc{cvs} は構築システムではありません。

リポジトリと modules ファイルの構造と構築システム (例. 
@file{Makefile}) とは相互作用するかもしれませんが、本質的
に独立したものです。

@sc{cvs} は、何かの作り方を指示したりはしません。
@sc{cvs} はあなたの意思に従って、
ツリー構造から望むファイルを取り出すだけです。

@sc{cvs} は、@code{checkout} 先の作業ディレクトリのディスク容量の使用
法について指示したりはしません。あなたが @file{Makefile} やスクリプトを
全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
るとすると、リポジトリ全てを取り出す必要が生じます。

あなたが仕事をモジュール化し、(@file{Makefile} に link,
mount, @code{VPATH}等を使用して、)ファイルを共有するよ
うな構築システムを構成すれば、好きな様にディスクの利用
法を決めることが出来ます。

しかしこれら@emph{全ての}システムは、
構築と維持に多大な労力が必要なことに、
気を付けなければいけません。
@sc{cvs} は、このような問題に関して考慮しません。

もちろん、これらの構築システムを支援するための道具
(スクリプト, @file{Makefile} 等) は、
@sc{cvs} の管理下に置くと良いでしょう。

何らかの変更があった際に、再構築が必要なファイルを調べるのは、
やはり @sc{cvs} の守備外です。
伝統的な手法の一例をあげると、
構築には @code{make} を用い、
@code{make} に必要な依存関係は自動化されたツールを用いて生成します。

@sc{cvs} と結合して構築を行うための情報は @ref{Builds}
を参照してください。

@item @sc{cvs} は管理者代理ではありません。

あなたの管理者や上司は、期日に従っているかどうかや、 
マージ点、枝の名前、リリースの日時等について、
あなたと度々話しあうことを求められています。
彼等がそうしないなら、@sc{cvs} は役に立ちません。

@sc{cvs} は、あなたの調律に従ってソースを踊らせる楽器の
ようなものです。あなたは楽器奏者もしくは作曲者のような
ものです。どんな楽器も勝手に演奏をしたりしないし、音楽
が勝手に書かれたりもしません。

@item @sc{cvs} は開発者同士の意志疎通の代用にはなりません。

あるファイルに衝突が起きた場合に、
ほとんどの開発者はそれほど苦労せずに解決します。
しかし、@dfn{衝突} (@dfn{conflict})のより一般的な定義には、
開発者同士の意志疎通なしには解決できない
困難な問題も含まれます。

同じファイル (もしくはファイルの集合) に、
同時に加えられた変更に論理的な衝突があっても、
@sc{cvs} には分りません。
@dfn{衝突}という概念は単に文字列の比較によるもので、
同じファイルを基に加えられた二つの変更が、
@code{merge} コマンド (つまり @code{diff3}) を驚かせるのに
十分なほど近接している場合にのみ生じます。

@sc{cvs} は、
プログラムの論理に、文字列でない衝突や、散らばった衝突
があったとしても、警告を表示しません。

例: 
あなたは @file{A} で定義された関数 @code{X} の引数を変更したとします。
同じ時に、誰かが @file{B} を編集して、
古い引数を使って @code{X} を呼び出したとします。
これは @sc{cvs} の能力の範囲外です。

仕様書を読み、同僚と話し合う習慣を付けましょう。


@item @sc{cvs} は変更管理をしません。

変更管理という言葉は様々な意味を持ちます。
まず@dfn{バグ追跡}と解釈すれば、バグ報告と各バグの状態
(修正されたか? どのリリースか? 報告者は修正を確認したか? )
についてのデータベース管理を意味します。
@sc{cvs} とバグ追跡システムとの連携については、
@file{rcsinfo} と @file{editinfo} ファイルを見て下さい 
(@pxref{Administrative files})。

論理的には一つと考えられる変更のため、
複数のファイルが同時に変更されたことを覚えておくことも、
変更管理と呼ばれます。
複数のファイルの変更を一つの @code{cvs commit} により格納した場合、
@sc{cvs} はそれらのファイルが同時に格納されたことを忘れてしまいます。
そして、それらのファイルを結ぶ事柄は、
同じログ・メッセージを持つことだけになるのです。
@sc{gnu} 形式の @file{ChangeLog} を用いれば何らかの助けになるでしょう。
@c FIXME: should have an xref to a section which talks
@c more about keeping ChangeLog's with CVS, but that
@c section hasn't been written yet.

各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
開発者によって加えられた変更もあれば、
他の開発者によって追試中の変更もあるとか、そういったことです。
一般的に @sc{cvs} でこのようなことをするには、
(@code{cvs diff} や @code{diff} を用いて) 差分を生成し、
@code{patch} を当てる人物にメールとして送ります。
これは非常に融通のきく方法ですが、
@sc{cvs} 以外の機構に依存しているので、
問題が無いことを保証できません。

@item @sc{cvs} は自動検査プログラムではありません。

@code{commitinfo} ファイルを使えば、
強制的に必須の項目を検査することは可能だと思います。
しかし、
そんなことをしようとしたプロジェクトのことは聞いたことがありません。

@item @sc{cvs} は手順規範を備えていません。

変更やリリースに必要とされる色々な手順や多くの承認を、
確実に行なう方法を備えたシステムもあります。
@sc{cvs} を用いてこれを達成することも可能ですが、
ちょっと面倒だと思います。
場合によっては、
@file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{verifymsg} 
等のファイルを用いて、変更点を格納する前に、
必要な手順を確実に踏むように設定できるでしょう。
また枝やタグといった機構を用いて、
開発用の枝で仕事を実行し、
安定性が証明された確実な変更だけを
安定化指向の枝に統合することも考えられます。
@end table

@c ---------------------------------------------------------------------
@node A sample session
@section 作業例
@cindex Example of a work-session
@cindex Getting started
@cindex Work-session, example of
@cindex tc, Trivial Compiler (example)
@cindex Trivial Compiler (example)

@c I think an example is a pretty good way to start.  But
@c somewhere in here, maybe after the sample session,
@c we need something which is kind of
@c a "roadmap" which is more directed at sketching out
@c the functionality of CVS and pointing people to
@c various other parts of the manual.  As it stands now
@c people who read in order get dumped right into all
@c manner of hair regarding remote repositories,
@c creating a repository, etc.
@c
@c The following was in the old Basic concepts node.  I don't
@c know how good a job it does at introducing modules,
@c or whether they need to be introduced so soon, but
@c something of this sort might go into some
@c introductory material somewhere.
@ignore
@cindex Modules (intro)
リポジトリはディレクトリやファイルを含み、
任意の場所に設定できます。
複数のディレクトリやファイルから成る単位を、
@dfn{モジュール} (@dfn{modules}) として一括して管理できます 
(@pxref{modules})。
各モジュールは、
プロジェクト毎に定義するのが普通です。
@end ignore

@sc{cvs} を紹介する方法として、@sc{cvs} を使って典型的な仕事をしてみま
す。最初に理解すべきことは @sc{cvs} は全てのファイルを中央に集められた 
@dfn{リポジトリ} (@dfn{repository}) (@pxref{Repository}) に保存すると
いうことです。この節ではリポジトリは準備されていると仮定します。
@c I'm not sure that the sentence concerning the
@c repository quite tells the user what they need to
@c know at this point.  Might need to expand on "centralized"
@c slightly (maybe not here, maybe further down in the example?)

あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語
で書かれたファイルでできていて、@file{Makefile} を含んでいるとします。
このコンパイラを @samp{tc} (Trivial Compiler) と呼ぶことにします。そし
て @samp{tc} というモジュール名でリポジトリに登録されています。

@menu
* Getting the source::          作業場所の作成
* Committing your changes::     あなたの仕事を他の人が利用可能にする
* Cleaning up::                 お掃除
* Viewing differences::         差分を見る
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Getting the source
@subsection ソースの取得
@cindex Getting the source
@cindex Checking out source
@cindex Fetching source
@cindex Source, getting from CVS
@cindex Checkout, example

まず、@samp{tc} のソースの作業コピーを取ってくることから始めましょう。
これには @code{checkout} コマンドを使用します:

@example
$ cvs checkout tc
@end example

@noindent
とすると @file{tc} という新しい作業ディレクトリが作られ、
その中にソース・ファイルがコピーされます。

@example
$ cd tc
$ ls
CVS         Makefile    backend.c   driver.c    frontend.c  parser.c
@end example

@file{CVS} というディレクトリは @sc{cvs} が内部的に使用
します。普通はその中にあるどんなファイルでも修正したり
削除してはいけません。

で、あなたの好きなエディタを用いて @file{backend.c} をハックして、
数時間後にコンパイラの最適化経路を加えたとします。
@sc{rcs} と @sc{sccs} の利用者への注意: 編集したいファ
イルをロックする必要はありません。その説明は、 @xref{Multiple
developers}.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Committing your changes
@subsection 変更の格納
@cindex Committing changes
@cindex Log message entry
@cindex CVSEDITOR, environment variable
@cindex EDITOR, environment variable

あなたはコンパイラが相変わらずコンパイル可能であることを確認し、
@file{backend.c} の新しいバージョンとすることに決めました。これは新し
い @file{backend.c} をリポジトリに格納し、同じリポジトリを使っている他
の人が使用できるようにします。

@example
$ cvs commit backend.c
@end example

@noindent
@sc{cvs} はログ・メッセージを記すためにエディタを開きます。
そこで ``Added an optimization pass.'' などと入力し、
一時ファイルに保存し、エディタを終了します。

どのエディタが開かれるかは環境変数 @code{$CVSEDITOR} により決定されま
す。@code{$CVSEDITOR} が設定されておらず、環境変数 @code{$EDITOR} が設
定されていれば、これを使用します。@code{$CVSEDITOR} と @code{$EDITOR} 
の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
フォルトが使われます。例えば、unix では @code{vi}で、Windows NT/95 で
は @code{notepad} です。

@cindex VISUAL, environment variable
加えて、@sc{cvs} は @code{$VISUAL} 環境変数も調べます。この動作が望ま
しいか、また @sc{cvs} の将来のリリースが @code{$VISUAL} を調べるべきか
どうか、という意見は人によって異なります。@code{$VISUAL} が設定されて
いないか、@code{$EDITOR} に設定されていることを確実にすることで、どち
らになっても対処することができます。
@c This probably should go into some new node
@c containing detailed info on the editor, rather than
@c the intro.  In fact, perhaps some of the stuff with
@c CVSEDITOR and -m and so on should too.
@sc{cvs} がエディタを開始したときは、修正されたファイルのリストを含ん
でいます。@sc{cvs} のクライアントでは、このリストはファイルの修正時刻
を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
いないというときも、修正されたものとして表示されます。これに対する最も
簡単な対処法は単純に気にしないことです---それを commitすると、@sc{cvs} 
は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
す。次の @code{update}はファイルが無修正であるという事実に基づき、将来
のセッションでファイルが表示されないように、タイムスタンプを保存されて
いるものに設定し直します。
@c FIXCVS: Might be nice if "commit" and other commands
@c would reset that timestamp too, but currently commit
@c doesn't.
@c FIXME: Need to talk more about the process of
@c prompting for the log message.  Like show an example
@c of what it pops up in the editor, for example.  Also
@c a discussion of how to get the "a)bort, c)ontinue,
@c e)dit" prompt and what to do with it.  Might also
@c work in the suggestion that if you want a diff, you
@c should make it before running commit (someone
@c suggested that the diff pop up in the editor.  I'm
@c not sure that is better than telling people to run
@c "cvs diff" first if that is what they want, but if
@c we want to tell people that, the manual possibly
@c should say it).

わざわざエディタを開くのが嫌ならば、代わりにコマンド行の @samp{-m} フ
ラグを使うことでログメッセージを以下のように指定することができます:

@example
$ cvs commit -m "Added an optimization pass" backend.c
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Cleaning up
@subsection お掃除
@cindex Cleaning up
@cindex Working copy, removing
@cindex Removing your working copy
@cindex Releasing your working copy

他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も
ちろん、次のようにしても可能です

@example
$ cd ..
$ rm -r tc
@end example

@noindent
しかし、@code{release} コマンドを使用するほうが良いでしょう 
(@pxref{release}):

@example
$ cd ..
$ cvs release -d tc
M driver.c
? tc
You have [1] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': n
** `release' aborted by user choice.
@end example

@code{release} コマンドは、あなたの修正が格納されているかどうか確認し
ます。ログを記録する設定ならば、ファイル @file{history} にメモします。 
@xref{history file}.

@code{release} コマンドに @samp{-d} フラグを使用すると、
確認と同時に作業コピーを削除します。

上の例では、@code{release} コマンドが何行か出力しています。
@samp{? tc} は @sc{cvs} が @file{tc} というファイルを知らないという意味です。
モジュール @samp{tc} のことではなく、
生成したコンパイラ @file{tc} を指しており、
これはリポジトリに格納しなくて良いので無視して構いません。
この警告を消すための情報は @ref{cvsignore} 参照。
@code{release} の出力の詳細な説明は @ref{release output} 参照。

@samp{M driver.c} の方は重要です。
これは、@file{driver.c} というファイルに加えた修正が、
格納されていないことを指摘しています。

@code{release} コマンドは、常に作業コピーの
修正が加えられたファイルの数を報告した後、
ファイルを削除したり履歴ファイルにメモする前に、
その確認を求めてきます。

ここでは大事を取って、最後に @code{release} が確認を求めたときに 
@kbd{n @key{RET}} を入力しました。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Viewing differences
@subsection 差分を見る
@cindex Viewing differences
@cindex Diff

あなたは @file{driver.c} に加えた修正を覚えていなかったので、
何をしたのか調べる必要があります。

@example
$ cd tc
$ cvs diff driver.c
@end example

このコマンドは @code{diff} を実行して、取り出した時と、あなたの作業コ
ピーの @file{driver.c} のバージョンを比較します。その出力を見て、最適
化経路を有効にするオプションを、コマンド行で指定できるようにしたことを
思い出しました。その変更を格納して、このモジュールに対する作業を終了し
ます。
@c FIXME: we haven't yet defined the term "check in".

@example
$ cvs commit -m "Added an optimization pass" driver.c
Checking in driver.c;
/usr/local/cvsroot/tc/driver.c,v  <--  driver.c
new revision: 1.2; previous revision: 1.1
done
$ cd ..
$ cvs release -d tc
? tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': y
@end example

@c ---------------------------------------------------------------------
@node Repository
@chapter リポジトリ
@cindex Repository (intro)
@cindex Repository, example
@cindex Layout of repository
@cindex Typical repository
@cindex /usr/local/cvsroot, as example repository
@cindex cvsroot

@sc{cvs} の@dfn{リポジトリ} (@dfn{repository}) は、
バージョン管理の対象となる全てのファイルとディレクトリの、
完全なコピーを保管します。

通常、リポジトリ中のファイルを直接利用することはありません。
その代わりに @sc{cvs} コマンドを使用して、
作業者自身のファイルのコピーを @dfn{作業ディレクトリ}
に取り出し、そのコピーを用いて作業します。

そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も
しくは @dfn{格納} します (@dfn{commit}))。リポジトリは、変更を加えたも
のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され
ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ
とに注意してください。別の位置にあるべきです。
@c Need some example, e.g. repository
@c /usr/local/cvsroot; working directory
@c /home/joe/sources.  But this node is too long
@c as it is; need a little reorganization...

@cindex :local:
@sc{cvs} は様々な方法でリポジトリを利用することができます。
リポジトリは、使用中のコンピュータ内であってもいいし、
別の部屋のコンピュータや、別の国のコンピュータであっても構いません。
リポジトリに接続する方法を区別するために、
リポジトリの名前の最初に@dfn{接続経路} (@dfn{access
method}) を加えることがあります。例えば @code{:local:} は、リポジトリ
であるディレクトリを利用することを意味します。つまり 
@code{:local:/usr/local/cvsroot} で表されるリポジトリは、@sc{cvs} を実
行したコンピュータの @file{/usr/local/cvsroot} というリポジトリを意味
します。他の接続経路については @ref{Remote repositories} 参照。

@c Can se say this more concisely?  Like by passing
@c more of the buck to the Remote repositories node?
接続経路の指定が省略され、リポジトリに @samp{:} が含まれない場合には、
@code{:local:} が仮定されます。
@samp{:} が含まれていた場合には、
@code{:ext:} か @code{:server:} が仮定されます。
例えばリポジトリ @file{/usr/local/cvsroot} が同じコンピュータ内にある場合、
@code{:local:/usr/local/cvsroot} を省略して
@code{/usr/local/cvsroot} と記述しても構いません。
しかし(Windows NT などで)、
リポジトリが @file{c:\src\cvsroot} にある場合、 
@code{:local:c:\src\cvsroot} として、
接続経路を明示する必要があります。

@c This might appear to go in Repository storage, but
@c actually it is describing something which is quite
@c user-visible, when you do a "cvs co CVSROOT".  This
@c isn't necessary the perfect place for that, though.
リポジトリは二つの要素から構成されます。
@file{$CVSROOT/CVSROOT} には @sc{cvs} の管理用ファイルが置かれます。
その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。

@menu
* Specifying a repository::     どのリポジトリを使うか CVS に教える
* Repository storage::          リポジトリの構造
* Working directory storage::   作業ディレクトリの構造
* Intro administrative files::  モジュールの定義
* Multiple repositories::       複数のリポジトリ
* Creating a repository::       リポジトリの作成
* Backing up::                  リポジトリのバックアップ
* Moving a repository::         リポジトリの移動
* Remote repositories::         別のマシンのリポジトリを利用する
* Read-only access::            リポジトリの読み込みのみの利用を許可する
* Server temporary directory::  サーバは一時ディレクトリを作成する
@end menu

@node Specifying a repository
@section CVS にリポジトリの場所を教える

@sc{cvs} にリポジトリの場所を教えるには、
いくつか方法があります。
一つ目はコマンド行で、
@code{-d} ("directory" を示します) オプションを用いて
指定する方法です:

@example
cvs -d /usr/local/cvsroot checkout yoyodyne/tc
@end example

@cindex .profile, setting CVSROOT in
@cindex .cshrc, setting CVSROOT in
@cindex .tcshrc, setting CVSROOT in
@cindex .bashrc, setting CVSROOT in
@cindex CVSROOT, environment variable
二つ目は、環境変数 @code{$CVSROOT} に、
絶対パスでリポジトリを指定する方法です。
例では @file{/usr/local/cvsroot}です。
@code{csh} や @code{tcsh} のユーザは各々
@file{.cshrc} や @file{.tcshrc} に次の行を加えて下さい:

@example
setenv CVSROOT /usr/local/cvsroot
@end example

@noindent
@code{sh} や @code{bash} のユーザは各々 
@file{.profile} や @file{.bashrc} に次の行を加えて下さい:

@example
CVSROOT=/usr/local/cvsroot
export CVSROOT
@end example

@cindex Root file, in CVS directory
@cindex CVS/Root file
@code{-d} によるリポジトリの指定は、
環境変数 @code{$CVSROOT} よりも優先されます。
一旦リポジトリから作業コピーを取得すれば、
リポジトリの場所が記憶されます
(この情報は、作業ディレクトリ内の 
@file{CVS/Root} に記録されます)。

オプション @code{-d} とファイル @file{CVS/Root} は、
どちらも環境変数 @code{$CVSROOT} よりも優先されます。
また、@file{-d} と @file{CVS/Root} が一致しない場合は、
前者が使用されます。
もちろん、
二つともが同じリポジトリを参照するのが、まともなやり方です。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Repository storage
@section リポジトリでのデータの保存方法
@cindex Repository, how data is stored

@sc{cvs} がリポジトリに情報を保存する@emph{方法}を知っていても、
たいてい何の役にも立ちません。
実際、過去に書式が変更されましたし、
将来変更されることもあるでしょう。
ほとんど全ての場合、
@sc{cvs} コマンドを通してリポジトリを利用しますから、
書式を変更しても混乱は起きません。

しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え
ば @sc{cvs} のロック解除が必要な場合 (@pxref{Concurrency}) や、リポジ
トリのファイルの許可属性を適切に設定する必要がある場合などです。

@menu
* Repository files::            リポジトリに保管されるファイル
* File permissions::            ファイル使用許可
* Windows permissions::         Windows 特有の問題
* Attic::                       Attic に保存されるファイルもある
* CVS in repository::           CVS ディレクトリの追加情報
* Locks::                       CVS ロックは並列接続を制御する
* CVSROOT storage::             CVSROOT の少しの違い
@end menu

@node Repository files
@subsection リポジトリのどこにファイルを保存するか

@c @cindex filenames, legal
@c @cindex legal filenames
@c Somewhere we need to say something about legitimate
@c characters in filenames in working directory and
@c repository.  Not "/" (not even on non-unix).  And
@c here is a specific set of issues:
@c 	Files starting with a - are handled inconsistently. They can not
@c   be added to a repository with an add command, because it they are
@c   interpreted as a switch. They can appear in a repository if they are
@c   part of a tree that is imported. They can not be removed from the tree
@c   once they are there.
@c Note that "--" *is* supported (as a
@c consequence of using GNU getopt).  Should document
@c this somewhere ("Common options"?).  The other usual technique,
@c "./-foo", isn't as effective, at least for "cvs add"
@c which doesn't support pathnames containing "/".

リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい
ます。例えば、リポジトリが

@example
/usr/local/cvsroot
@end example

@noindent
にあれば、次のようなディレクトリの木構造になります (ディレクトリだけを
表示しています):

@example
@t{/usr}
 |
 +--@t{local}
 |   |
 |   +--@t{cvsroot}
 |   |    | 
 |   |    +--@t{CVSROOT}
          |      (管理用ファイル)
          | 
          +--@t{gnu}
          |   | 
          |   +--@t{diff}
          |   |   (@sc{gnu} diff のソース)
          |   | 
          |   +--@t{rcs}
          |   |   (@sc{rcs} のソース)
          |   | 
          |   +--@t{cvs}
          |       (@sc{cvs} のソース)
          | 
          +--@t{yoyodyne}
              | 
              +--@t{tc}
              |    |
              |    +--@t{man}
              |    |
              |    +--@t{testing}
              | 
              +--(その他の Yoyodyne のソフトウェア)
@end example                              

ディレクトリの中身は、管理下にあるファイルの@dfn{履歴ファイル} 
(@dfn{history files}) です。
履歴ファイルの名前は、各ファイル名の最後に @samp{,v} を付加したものです。
次に、ディレクトリ @file{yoyodyne/tc} のリポジトリ構造を示します:
@c FIXME: Should also mention CVS (CVSREP)
@c FIXME? Should we introduce Attic with an xref to
@c Attic?  Not sure whether that is a good idea or not.
@example
  @code{$CVSROOT}
    |
    +--@t{yoyodyne}
    |   |
    |   +--@t{tc}
    |   |   |
            +--@t{Makefile,v}
            +--@t{backend.c,v}
            +--@t{driver.c,v}
            +--@t{frontend.c,v}
            +--@t{parser.c,v}
            +--@t{man}
            |    |
            |    +--@t{tc.1,v}
            |
            +--@t{testing}
                 |
                 +--@t{testpgm.t,v}
                 +--@t{test2.t,v}
@end example

@cindex History files
@cindex RCS history files
@c The first sentence, about what history files
@c contain, is kind of redundant with our intro to what the
@c repository does in node Repository....
履歴ファイルは、
どのリビジョンのファイルでも再構築できる情報を持ち、
また変更内容が格納された時のログ・メッセージと、
その時のユーザの名前も記録しています。
ファイルをこのような書式で保管した最初のプログラムが、
@sc{rcs} というバージョン管理システムであったために、
履歴ファイルは @dfn{RCS ファイル} と呼ばれます。
ファイル書式の完全な記述は、@sc{rcs} の配布セットにある
@cite{rcsfile(5)} の @code{man} ページか、@sc{cvs} のソー
ス配布のファイル @file{doc/RCSFILES} を参照してください。
このファイル書式は非常に一般的なので、
@sc{cvs} や @sc{rcs} 以外のシステムでも、
少くとも理解をすることができます。
@c FIXME: Think about including documentation for this
@c rather than citing it?  In the long run, getting
@c this to be a standard (not sure if we can cope with
@c a standards process as formal as IEEE/ANSI/ISO/etc,
@c though...) is the way to go, so maybe citing is
@c better.

@sc{cvs} で使用されている @sc{rcs} ファイルは標準の書式と少し違います。
最大の違いは魔法の枝です。詳細は @ref{Magic branch numbers} を参照して
ください。@sc{cvs} では、有効なタグ名は @sc{rcs} で使用できるもののサ
ブセットになっています。@sc{cvs} の規則は @ref{Tags} を参照してくださ
い。

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node File permissions
@subsection ファイル使用許可
@c -- Move this to @node Creating a repository or similar
@cindex Security
@cindex File permissions, general
@cindex permissions, general
@c FIXME: we need to somehow reflect "permissions in
@c repository" versus "permissions in working
@c directory" in the index entries.
@cindex Group
@cindex read-only files, in repository
全ての @samp{,v} ファイルは読み込み専用であり、
この使用許可を変えるべきではありません。
これに対し、リポジトリ中のディレクトリは、
ファイルの修正を行なう人物に対して、
書き込みを許可しなくてはいけません。
これはつまり、
ファイルの修正を行なう人物からなるグループを作って 
(@cite{group(5)}参照)、
そのディレクトリの所有グループとすることを意味しています。
@c See also comment in commitinfo node regarding cases
@c which are really awkward with unix groups.

従って、
ディレクトリ単位でしかファイルのアクセス権を
管理することができません。

@sc{cvs} はロック・ファイルを作成する必要があるため 
(@pxref{Concurrency})、ファイルを取り出す使用者にも、書き込み許可が必
要であることに注意して下さい。

@c CVS seems to use CVSUMASK in picking permissions for
@c val-tags, but maybe we should say more about this.
@c Like val-tags gets created by someone who doesn't
@c have CVSUMASK set right?
利用者は @file{CVSROOT/val-tags} ファイルに書き込み許可が必要なことも
注意してください。@sc{cvs} はそれをどのタグが有効かを記録するために使
います (作成時と、ときどきタグが使用されたときに更新されます)。

それぞれの @sc{rcs} ファイルは最後に書き込んだ利用者に所有されます。こ
れはあまり重要ではありません。重要なのは誰がディレクトリを所有している
かです。

@cindex CVSUMASK, environment variable
@cindex umask, for repository files
木の中に新しいディレクトリを加える場合、
@sc{cvs} はできるだけ適当な使用許可を与える努力をします。
しかし新しいディレクトリの使用許可が、
親ディレクトリのものと異なる必要がある場合には、
手動で変更する必要があります。
環境変数 @code{CVSUMASK} を設定すれば、
リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。
@code{CVSUMASK} は、作業ディレクトリのファイル使用許可には影響しません。
作業コピーの使用許可は、
新たに作成したファイルに通常与えられるものと同じです。
但し、@sc{cvs} が読み込みだけを許可することがあります
(監視時 @ref{Setting a watch}, -r 使用時 @ref{Global options},
CVSREAD 設定時 @ref{Environment variables} を各々参照)。
@c FIXME: Need more discussion of which
@c group should own the file in the repository.
@c Include a somewhat detailed example of the usual
@c case where CVSUMASK is 007, the developers are all
@c in a group, and that group owns stuff in the
@c repository.  Need to talk about group ownership of
@c newly-created directories/files (on some unices,
@c such as SunOS4, setting the setgid bit on the
@c directories will make files inherit the directory's
@c group.  On other unices, your mileage may vary.  I
@c can't remember what POSIX says about this, if
@c anything).

クライアント/サーバ @sc{cvs} を使用すると (@pxref{Remote
repositories})、@code{CVSUMASK} を設定する良い方法はありません。クライ
アントマシンでの設定は効果がありません。@code{rsh} で接続しているなら、
オペーレーティングシステムの説明に書いてあるように、@file{.bashrc} や
@file{.cshrc} で @code{CVSUMASK} を設定することができます。この振る舞
いは将来のバージョンの @sc{cvs} では変更されるかもしれません。クライア
ントの @code{CVSUMASK} の設定には頼らず、それは無効になるでしょう。
@c FIXME: need to explain what a umask is or cite
@c someplace which does.
@c
@c There is also a larger (largely separate) issue
@c about the meaning of CVSUMASK in a non-unix context.
@c For example, whether there is
@c an equivalent which fits better into other
@c protection schemes like POSIX.6, VMS, &c.
@c
@c FIXME: Need one place which discusses this
@c read-only files thing.  Why would one use -r or
@c CVSREAD?  Why would one use watches?  How do they
@c interact?
@c
@c FIXME: We need to state
@c whether using CVSUMASK removes the need for manually
@c fixing permissions (in fact, if we are going to mention
@c manually fixing permission, we better document a lot
@c better just what we mean by "fix").

pserver を使う場合は、一般的に、 @sc{cvsroot} ディレクトリと木構造でそ
れより上のディレクトリには厳しい使用許可が必要です。@ref{Password
authentication security} を参照してください。

@cindex setuid
@cindex setgid
@cindex security, setuid
@cindex installed images (VMS)
オペレーティングシステムには特定のプログラムが、プログラムの呼び手には
できないような動作をする能力とともに実行される機能があるものがあります。
例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や
VMS の installed image 機能です。CVS はそのような機能を使用するように
書かれていませんので、そのような方法で CVS をインストールすると事故の
過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして
いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使
用許可を得るかもしれません。代わりに pserver を使用することを考えるか
もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ
キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供
する可能性がありますので、このオプションを考えているなら、pserver の説
明文書を注意深く読んでください。(@ref{Password authentication
security})。

@node Windows permissions
@subsection Windows に特有なファイルの使用許可問題
@cindex Windows, and permissions
@cindex File permissions, Windows-specific
@cindex permissions, Windows-specific

ファイルの使用許可には Windows オペレーティングシステムに特有の問題も
あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ
ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、
確かではありません)。

ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ
トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる
ことがあることが報告されています。Samba の設定で WRITE=YES にすると修
正される/何とかなると言われています。
責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調
査をしていません。加えて、問題を避けるために CVS が違ったようにするこ
とができるかどうかも調べていません。何か発見したなら、@ref{BUGS} に書
かれているように我々に報せてください。

@node Attic
@subsection The attic
@cindex attic

ときどき @sc{cvs} は @sc{rcs} ファイルを @code{Attic} に保存することが
あることに気付くでしょう。例えば、@sc{cvsroot} が 
@file{/usr/local/cvsroot} でディレクトリ @file{yoyodyne/tc} のファイル
@file{backend.c} について話をしているとき、普通はファイルは以下のとこ
ろにあります

@example
/usr/local/cvsroot/yoyodyne/tc/backend.c,v
@end example

しかし、attic に行けば、代わりに

@example
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
@end example

@cindex dead state
になります。利用者にとってはファイルが attic にあるかどうかは関係あり
ません。@sc{cvs} はこれを記録し、必要なときは attic を調べます。詳細を
知りたい人のために書くと、幹の先頭リビジョンが @code{dead} の状態であ
るまさにそのときだけ、ファイルは attic に保存されます。@code{dead} の
状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが
ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは
@code{dead} の状態になり枝のリビジョンは @code{dead} ではない状態にな
ります。
@c Probably should have some more concrete examples
@c here, or somewhere (not sure exactly how we should
@c arrange the discussion of the dead state, versus
@c discussion of the attic).

@node CVS in repository

@subsection リポジトリの CVS ディレクトリ
@cindex CVS directory, in repository

それぞれのリポジトリのディレクトリの @file{CVS} ディレクトリはファイル
属性などの情報が収められています (@file{CVS/fileattr} というファイルで
す。)。将来はこのディレクトリには他のファイルが加えられる可能性があり
ますから、実装は追加のファイルを静かに無視するのが良いでしょう。

この動作は @sc{cvs} 1.7 とその後のものだけで実装されています。詳細は
@ref{Watches Compatibility} を参照してください。

fileattr ファイルの書式は以下の形式の登録の連続したものです (@samp{@{}
と @samp{@}} は括弧の中のテキストを0回以上繰り返すことができるというこ
とです):

@var{ent-type} @var{filename} <tab> @var{attrname} = @var{attrval}
  @{; @var{attrname} = @var{attrval}@} <linefeed>

@var{ent-type} はファイルでは @samp{F} で、その場合は登録はそのファイ
ルの属性を指定します。

@var{ent-type} が @samp{D} で、@var{filename} が空であると、新しく追加
されたファイルへの既定属性を指定します。

他の @var{ent-type} は将来の拡張のために予約されています。CVS 1.9 とそ
れ以前のものはファイル属性を書き込むときにいつでもそれらを消すでしょう。
CVS 1.10 とそれ以降はそれらを保存します。

行の順番は関係無いことに注意してください。
fileattr ファイルを書き込むプログラムは便利な様に再編成するかもしれま
せん。

ファイル名でのタブとラインフィード、@var{attrname} での @samp{=},
@var{attrval} での @samp{;}、などを引用する方法は今はありません。

習慣では、@var{attrname} は CVS により特別な意味を持っている属性は 
@samp{_} で始まります。他の @var{attrname} は使用者定義の属性のために
あります (もしくは、実装が使用者定義の属性のサポートを始めたときにそう
なるでしょう)。

作りつけの属性です:

@table @code
@item _watched
存在すると、ファイルが監視下にあり、読み込み専用で取り出すべきであるこ
とを意味します。

@item _watchers
このファイルを監視している使用者です。値は
@var{watcher} > @var{type} @{ , @var{watcher} > @var{type} @}
で、@var{editor} は使用者名、@var{val} は 
@var{time}+@var{hostname}+@var{pathname} で、@var{time} は @code{cvs
edit} コマンド (もしくはそれと等価なもの) が発生したときで、
@var{hostname} と @var{pathname} は作業ディレクトリのためです。
@end table

例:

@c FIXME: sanity.sh should contain a similar test case
@c so we can compare this example from something from
@c Real Life(TM).  See cvsclient.texi (under Notify) for more
@c discussion of the date format of _editors.
@example
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs
D _watched=
@end example

は @file{file1} は読み込み専用で取り出されるべきだということです。加え
て、joe は edit を監視しており、mary は commit を監視しています。ファ
イル @file{file2} は読み込み専用で取り出されるべきです。sue は 1975年1
月8日にマシン @code{workstn1} のディレクトリ @file{/home/sue/cs}編集を
始めました。この例を表現するために、@samp{D}, @samp{Ffile1},
@samp{Ffile2} の後に空白を表示していますが、実際は単独のタブ文字がそこ
にあり、空白があってはいけません。

@node Locks
@subsection リポジトリの CVS ロック

@cindex #cvs.rfl, technical details
@cindex #cvs.wfl, technical details
@cindex #cvs.lock, technical details
@cindex locks, cvs, technical details
利用者から見える部分の CVS のロックに焦点をあてた紹介は 
@ref{Concurrency} を参照してください。次の部分は同じリポジトリをアクセ
スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう
なツールを書きたい人を対象にしています。@dfn{読み込みロック}
(@dfn{read lock}), @dfn{書き込みロック} (@dfn{write lock}), @dfn{デッ
ドロック} (@dfn{deadlock}) のような概念がよくわからなかったら、オペレー
ティングシステムやデータベースの文献を参照すると良いかもしれません。

@cindex #cvs.tfl
リポジトリ中の @file{#cvs.rfl.} で始まる全てのファイルは読み込みロック
です。リポジトリ中の @file{#cvs.wfl} で始まる全てのファイルは書き込み
ロックです。古いバージョンの CVS (CVS 1.5 以前) は @file{#cvs.tfl} で
始まる名前のファイルも作成していましたが、ここではそれらは議論しません。
ディレクトリ @file{#cvs.lock} はマスターロックとして働きます。すなわち、
他のロックを取得する前に、まずこのロックを取得しなければならない、とい
うことです。

書き込みロックを取得するためには、まず @file{#cvs.lock} ディレクトリを
作成します。この操作は原子的操作でなければなりません (これはたいていの
オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた
めに失敗すれば、しばらく待ってもう一度試します。@file{#cvs.lock} ロッ
クを取得した後、@file{#cvs.rfl.} の後に選択した情報 (例えば、ホスト名
とプロセス番号) が続いた名前のファイルを作成します。それからマスターロッ
クを解放するために @file{#cvs.lock} ディレクトリを消去します。それから
リポジトリを読んで続行します。終った後、読み込みロックを解放するために
@file{#cvs.rfl} ファイルを消去します。

書き込みロックを取得するためには、読み込みロックと同様にまず 
@file{#cvs.lock} ディレクトリを作成します。それから @file{#cvs.rfl.} 
で始まるファイルが無いかどうかを調べます。もしあれば、@file{#cvs.lock} 
を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、
@file{#cvs.wfl} の後に選択した情報を続けた名前のファイルを作成します 
(例えば、ホスト名とプロセス番号)。ロック @file{#cvs.lock} を続けます。
リポジトリへの書き込みを実行します。それが終わると、まず 
@file{#cvs.wfl} ファイルを消去し、それから @file{#cvs.lock} ディレクト
リを消去します。@file{#cvs.rfl} ファイルと違って、@file{#cvs.wfl} ファ
イルは情報提供のためだけにあることに注意してください。@file{#cvs.lock} 
そのもののロックを続ける以上のロック操作の効果はありません。

それぞれのロック (書き込みロック及び読み込みロック) は @file{Attic} と
@file{CVS} を含んだリポジトリの単独のディレクトリのみをロックしますが、
バージョン管理下の他のディレクトリは含まないことに注意してください。木
全体をロックするためには、それぞれのディレクトリをロックする必要があり
ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため
に再挑戦の前に木全体を解放しなければならないことに注意してください)。

@sc{cvs} は個々の @file{foo,v} ファイルへのアクセス制御のために書き込
みロックを期待するということにも注意してください。@sc{rcs} には 
@file{,foo,} ファイルがロックとして働く機構がありますが、@sc{cvs} はそ
れを実装しておらず、@sc{cvs} の書き込みロックを取り出すことが推奨され
ています。さらなる議論/合理性は @sc{cvs} のソースコードの 
rcs_internal_lockfile のところのコメントを読んでください。

@node CVSROOT storage
@subsection CVSROOT ディレクトリでファイルが保管される方法
@cindex CVSROOT, storage of files

@file{$CVSROOT/CVSROOT} ディレクトリにはいろいろな管理ファイルがありま
す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て
います。そこにはファイル名が @samp{,v} で終わる多くの @sc{rcs} ファイ
ルがあり、多くの @sc{cvs} コマンドは同じ方法でそれを操作します。しかし、
少しの違いはあります。

それぞれの管理ファイルには、@sc{rcs} ファイルに加えて、ファイルの取り
出された版のコピーがあります。例えば、@sc{rcs} ファイル 
@file{loginfo,v} とそれの最新リビジョンであるファイル @file{loginfo}
があります。管理ファイルを格納したときは、@sc{cvs} は

@example
cvs commit: Rebuilding administrative file database
@end example

@noindent
を印字し、@file{$CVSROOT/CVSROOT} の取り出された版のコピーを更新するよ
うになっています。もしそうならなければ、何かがおかしくなっています 
(@pxref{BUGS})。自分自身のファイルをこのように更新されるファイル群に追
加するために、それらを管理ファイル @file{checkoutlist} に追加できます 
(@pxref{checkoutlist})。

@cindex modules.db
@cindex modules.pag
@cindex modules.dir
初期設定では @file{modules} ファイルは上で説明されているように振舞いま
す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし
て保存しているとモジュールの探索が遅くなるかもしれません (@sc{cvs} が
最初にこの機能を追加したときほど関心があるかどうかは定かではありません。
ベンチマークは見ていませんので)。ですから、@sc{cvs} ソースコードに適切
な修正を加えるとおで、modules ファイルを Berkeley db や GDBM のような 
@code{ndbm} インターフェースを実装したデータベースで保存することができ
ます。このオプションが使用されると、modules データベースは
@file{module.db}, @file{modules} と/もしくは @file{modules.dir} に保存
されます。
@c I think fileattr also will use the database stuff.
@c Anything else?

いろいろな管理ファイルの意味に関する情報は @ref{Administrative files}
を参照してください。

@node Working directory storage
@section リポジトリでのデータの保存方法

@c FIXME: Somewhere we should discuss timestamps (test
@c case "stamps" in sanity.sh).  But not here.  Maybe
@c in some kind of "working directory" chapter which
@c would encompass the "Builds" one?  But I'm not sure
@c whether that is a good organization (is it based on
@c what the user wants to do?).

@cindex CVS directory, in working directory
しばしば表面に現れてくるかもしれない @sc{cvs} の内部についての話をして
いる間に、@sc{cvs} が作業ディレクトリの @file{CVS} ディレクトリに何を
入れるかも話した方が良いでしょう。リポジトリと同様に、@sc{cvs} がこの
情報を扱い、普通は @sc{cvs} のコマンドを通してだけそれを使用します。で
も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター
フェース の @code{jCVS} や emacs のための @code{VC} パッケージなどの他
のプログラムがそれを見る必要があるかもしれません。そのようなプログラム
は、上で書いたプログラムやコマンド行 @sc{cvs} クライアントの将来のバー
ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望
むなら、この節の推奨規格に従う必要があります。

@file{CVS} ディレクトリには複数のファイルがあります。このディレクトリ
を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在
するけれどここで説明されていないファイルは静かに無視するのが望ましいで
す。

ファイルは使用しているシステムのテキストファイルの習慣に従って保存され
ます。これはテキストファイルの補完の習慣が違うシステム間では作業ディレ
クトリは可搬性が無いということです。これは意図的になされていて、おそら
く CVS で管理されているファイル自体がそのようなシステム間では可搬性が
ないであろう、という理由に基づいています。

@table @file
@item Root
このファイルは @ref{Specifying a repository} で説明されているように、
現在の @sc{cvs} のルートを保持しています。

@cindex Repository file, in CVS directory
@cindex CVS/Repository file
@item Repository
このファイルは現在のディレクトリが対応するリポジトリでのディレクトリを
保持しています。指定は絶対パス名と相対パス名のどちらでも可能です。
@sc{cvs} は少なくともバージョン 1.3 くらいから両方の形式を読み込む能力
を備えています。相対パスはルートからの相対位置で、より賢い方法ですが、
絶対パス名は非常によく使われており、実装は両方を受け付けることが望まれ
ます。例えば、以下のコマンドの後で

@example
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
@end example

@file{Root} は以下のようになり

@example
:local:/usr/local/cvsroot
@end example

@file{Repository} は

@example
/usr/local/cvsroot/yoyodyne/tc
@end example

@noindent
か

@example
yoyodyne/tc
@end example

@noindent
のどちらかになります。

特定の作業ディレクトリがリポジトリのディレクトリに対応しなければ、
@file{Repository} は @file{CVSROOT/Emptydir} になっているはずです。

@cindex Entries file, in CVS directory
@cindex CVS/Entries file
@item Entries
このファイルは作業ディレクトリ中のファイルとディレクトリの一覧を挙げて
います。
各行の最初の文字はそれがどんな行かを示します。将来の拡張ができるように、
文字を認識できない場合は、ファイルを読み込んでいるファイルは暗黙にその
行を飛ばすことが望まれます。

最初の文字が @samp{/} であれば、様式は:

@example
/@var{name}/@var{revision}/@var{timestamp}[+@var{conflict}]/@var{options}/@var{tagdate}
@end example

で、@samp{[} と @samp{]} は登録の一部ではありませんが、その代わりに 
@samp{+} と衝突の印は省略任意であることを示しています。@var{name} はディ
レクトリ中のファイルの名前です。@var{revision} は作業中のファイルの元
のリビジョンで、@samp{0} の場合は追加されたファイル、@samp{-} の後にリ
ビジョンは削除されたファイルです。@var{timestamp} は @sc{cvs} がファイ
ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の
修正時刻と違えば、ファイルは修正されたということです。それは ISO C
astime() 関数で使われる様式で保存されます (例えば、@samp{Sun Apr 7
01:29:26 1996})。ファイルが常に修正されていると見なされるように、例え
ば、@samp{Result of merge} のようにその様式とは違う文字列を書くかもし
れません。これは特別な場合ではありません。ファイルが修正されたかどうか
を調べるために、プログラムはファイルのタイムスタンプを単純に 
@var{timestamp} と文字列比較をするべきです。衝突があれば、
@var{conflict} は、ファイルが衝突の印とともに書き込まれた後でファイル
の修正時刻に設定することができます (@pxref{Conflicts example})。 もし 
@var{conflict} がその後も実際の修正時刻と同じであるなら、ユーザは明か
に衝突を解消していません。@var{options} は貼り付けられたオプションを保
持しています (例えば、バイナリ・ファイルのための @samp{-kbd})。
@var{tagdate} は @samp{T} の後にタグ名が続いているか、日付 (date) の 
@samp{D} で、貼り付けられたタグか日付がつづいているかのどちらかを保持
しています。@var{timestamp} が単独のタイムスタンプではなく、スペースで
分離されたタイムスタンプの対であるなら、@sc{cvs} 1.5 より前のバージョ
ンの @sc{cvs} を扱っているということに注意してください (ここでは説明さ
れていません)。

CVS/Entries のタイムスタンプの標準時 (ローカルもしくは共通時) はオペレー
ティングシステムがファイル自身のタイムスタンプとして保存するものと同じ
である必要があります。例えば、Unix ではファイルのタイムスタンプは共通
時刻 (UT) ですので、CVS/Entries のタイムスタンプもそうなっているべきで
す。@sc{vms} ではファイルのタイムスタンプはローカル時刻なので、
@sc{vms} 上の @sc{cvs} はローカル時刻を使うべきです。この規則は、標準
時が変わったためだけでファイルが修正されたようにならないためです (例え
ば、サマータイムになったり、それが終わったときなどです)。
@c See comments and calls to gmtime() and friends in
@c src/vers_ts.c (function time_stamp).

@file{Entries} の行の最初の文字が @samp{D} であると、それはサブディレ
クトリを現しています。行が @samp{D} だけのときは、 @file{Entries} ファ
イルを書いたプログラムはサブディレクトリを記録したということを現します 
(ですから、そのような行があって、他に @samp{D} で始まる行がなければ、
サブディレクトリがないことがわかります)。そうでなければ、行は次のよう
になっています:

@example
D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
@end example

ここで @var{name} はサブディレクトリの名前であり、将来の拡張のために、
全ての @var{filler} 部分は暗黙の内に無視されるべきです。@code{Entries} 
を修正するプログラムはこれらの部分を保存するのが望まれています。

ファイル @file{Entries} 中の行はどんな順番でも構いません。

@cindex Entries.Log file, in CVS directory
@cindex CVS/Entries.Log file
@item Entries.Log
このファイルは @file{Entries} に無いさらなる情報を記録することはありま
せんが、@file{Entries} ファイル全体を再書き込みすることなく、情報を更
新するための方法をもたらし、その中には @file{Entries} と 
@file{Entries.Log} を書いているプログラムが不意に異常終了しても情報を
保護する機能もあります。@file{Entries} ファイルを読み込むプログラムは
@file{Entries.Log} も調べるべきです。後者が存在すれば、@file{Entries} 
を読み込んで、@file{Entries.Log} にある変更を適用すべきです。変更を適
用した後で、@file{Entries} を再度書き込んで、@file{Entries} を消去する
習慣が推奨されています。@file{Entries.Log} の行の様式は、単独文字コマ
ンドがあり、その後にスペースが続き、その後は @file{Entries} の行に指定
された様式になります。単独文字コマンドは登録が追加されたことを示す
@samp{A} と登録が消去されたことを示す @samp{R} か、@file{Entries} の登
録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2
番目の文字が @file{Entries.Log} の行の2番目の文字がスペースでないと、
それは @sc{cvs} の古いバージョンで書かれています (ここでは説明されてい
ません)。

読み込みではなく、書き込みをしているプログラムは、もし望むならば
@file{Entries.Log} ファイルを安全に無視することもできます。

@cindex Entries.Backup file, in CVS directory
@cindex CVS/Entries.Backup file
@item Entries.Backup
これは一時ファイルです。推奨された使用法は、新しい Entriy ファイルを 
@file{Entries.Backup} に書き、それから @file{Entries} に改名する (もし
可能なら原子的操作で) ことです。

@cindex Entries.Static file, in CVS directory
@cindex CVS/Entries.Static file
@item Entries.Static
このファイルが関連する唯一のことはそれが存在するか否か、ということです。
もし存在すると、ディレクトリの一部分だけが取得されていて、@sc{cvs} は
そのディレクトリに追加のファイルを作成しないということです。それを消去
するためには、@code{update} コマンドを @samp{-d} オプションとともに使っ
てください。そうすれば、追加のファイルを取得して、
@file{Entries.Static} を消去します。
@c FIXME: This needs to be better documented, in places
@c other than Working Directory Storage.
@c FIXCVS: The fact that this setting exists needs to
@c be more visible to the user.  For example "cvs
@c status foo", in the case where the file would be
@c gotten except for Entries.Static, might say
@c something to distinguish this from other cases.
@c One thing that periodically gets suggested is to
@c have "cvs update" print something when it skips
@c files due to Entries.Static, but IMHO that kind of
@c noise pretty much makes the Entries.Static feature
@c useless.

@cindex Tag file, in CVS directory
@cindex CVS/Tag file
@cindex Sticky tags/dates, per-directory
@cindex Per-directory sticky tags/dates
@item Tag
このファイルはディレクトリごとの貼り付いたタグを保持します。最初の文字
は枝のタグには @samp{T}、枝でないタグは @samp{N}、日付は @samp{D} にな
り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ
の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付
は新規に追加されたファイルに適用されること等に使用されることに注意して
ください。貼り付きタグと日付に関する一般的な情報は @ref{Sticky tags} 
を参照してください。
@c FIXME: This needs to be much better documented,
@c preferably not in the context of "working directory
@c storage".
@c FIXME: The Sticky tags node needs to discuss, or xref to
@c someplace which discusses, per-directory sticky
@c tags and the distinction with per-file sticky tags.

@cindex Checkin.prog file, in CVS directory
@cindex CVS/Checkin.prog file
@cindex Update.prog file, in CVS directory
@cindex CVS/Update.prog file
@item Checkin.prog
@itemx Update.prog
これらのファイルはそれぞれ modules ファイルの @samp{-i} と @samp{-u}
オプションで指定されたプログラムを保存します。

@cindex Notify file, in CVS directory
@cindex CVS/Notify file
@item Notify
このファイルはまだサーバに送信されていない通知 (例えば、@code{edit} や 
@code{unedit} のため) を保存します。書式はまだここでは説明されていませ
ん。

@cindex Notify.tmp file, in CVS directory
@cindex CVS/Notify.tmp file
@item Notify.tmp
このファイルと @file{Notify} の関係は @file{Entries.Backup} と 
@file{Entries} の関係と同じです。即ち、@file{Notify} を書くためにはま
ず新しい内容を @file{Notify.tmp} に書き、それから (可能であれば自動的
に) それを @file{Notify} に改名します。

@cindex Base directory, in CVS directory
@cindex CVS/Base directory
@item Base
監視を使用していると、@code{edit} コマンドはファイルの元のコピーを 
@file{Base} ディレクトリに保存します。これで、サーバと通信できないとき
でさえ @code{unedit} コマンドが実行できるようになります。

@cindex Baserev file, in CVS directory
@cindex CVS/Baserev file
@item Baserev
このファイルは @file{Base} ディレクトリのそれぞれのファイルのリビジョ
ンを一覧にします。書式は:

@example
B@var{name}/@var{rev}/@var{expansion}
@end example

で、@var{expansion} は将来の拡張のために、無視されるべきものです。

@cindex Baserev.tmp file, in CVS directory
@cindex CVS/Baserev.tmp file
@item Baserev.tmp
このファイルと @file{Baserev} の関係は @file{Entries.Backup} と
@file{Entries} との関係と同じです。即ち、@file{Baserev} に書くために、
まず新しい内容を @file{Baserev.tmp} に書き、それから (もし可能なら自動
的に) それを @file{Baserev} に改名します。

@cindex Template file, in CVS directory
@cindex CVS/Template file
@item Template
このファイルには @file{rcsinfo} ファイルで指定された雛型が入っています
(@pxref{rcsinfo})。それはクライアントだけに使われます。非クライアント/
サーバ型 @sc{cvs} は直接 @file{rcsinfo} ファイルを調べます。
@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Intro administrative files
@section 管理用ファイルの紹介
@cindex Administrative files (intro)
@cindex Modules file
@cindex CVSROOT, module name
@cindex Defining modules (intro)

@c FIXME: this node should be reorganized into "general
@c information about admin files" and put the "editing
@c admin files" stuff up front rather than jumping into
@c the details of modules right away.  Then the
@c Administrative files node can go away, the information
@c on each admin file distributed to a place appropriate
@c to its function, and this node can contain a table
@c listing each file and a @ref to its detailed description.

@file{$CVSROOT/CVSROOT} には、いくつか @dfn{管理用ファイル} 
(@dfn{administrative files}) があります。完全な説明は 
@xref{Administrative files}. これらのファイルが無く
ても @sc{cvs} を使用することができます。しかし、少なくとも 
@file{modules} というファイルが適切に設定してあれば @sc{cvs} のコマン
ドはうまく働きます。

管理用ファイルの中で、
最も重要なファイルは @file{modules} です。
これはリポジトリの中の全てのモジュールを定義しています。
@file{modules} ファイルの例を次に示します。

@c FIXME: The CVSROOT line is a goofy example now that
@c mkmodules doesn't exist.
@example
CVSROOT         CVSROOT
modules         CVSROOT modules
cvs             gnu/cvs
rcs             gnu/rcs
diff            gnu/diff
tc              yoyodyne/tc
@end example

@file{modules} ファイルは行ごとに意味を持つファイルです。
@file{modules} ファイルの各行はそれぞれ、
モジュール名, 空白, モジュールのあるディレクトリ名
という書式で記述されます。
モジュールのあるディレクトリ名は、
@code{$CVSROOT} からの相対パスです。
@file{modules} ファイルの各行はそれぞれ、
モジュール名, 空白, モジュールのあるディレクトリ名
という書式で記述されます。
モジュールのあるディレクトリ名は、
@code{$CVSROOT} からの相対パスです。
上の例の最後の4行はそのような行の例です。

@c FIXME: might want to introduce the concept of options in modules file
@c (the old example which was here, -i mkmodules, is obsolete).

モジュール @samp{modules} を定義する行については、
ここでは説明しません。
より詳しい説明は @ref{modules} 参照。

@c FIXME: subsection without node is bogus
@subsection 管理用ファイルの編集
@cindex Editing administrative files
@cindex Administrative files, editing them

管理用ファイルは、
他のモジュールと同じ方法で編集します。
@samp{cvs checkout CVSROOT} を用いて作業コピーを取り出して、
編集し、通常通り変更内容を格納します。

間違いのある管理用ファイルを格納することも可能です。
このような場合には、間違いを正して新たなリビジョンを登録します。
しかし管理用ファイルに深刻な間違いがあれば、
新たなリビジョンの登録さえも不可能になります。
@c @xref{Bad administrative files} for a hint
@c about how to solve such situations.
@c -- administrative file checking--

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Multiple repositories
@section 複数のリポジトリ
@cindex Multiple repositories
@cindex Repositories, multiple
@cindex Many repositories
@cindex Parallel repositories
@cindex Disjoint repositories
@cindex CVSROOT, multiple repositories

特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ
のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ
ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変
数 @code{$CVSROOT} で設定するか、@sc{cvs} のオプション @samp{-d} に指
定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に @sc{cvs} 
に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ
けです。

複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。
@sc{cvs} バージョン 1.10 では、単独のコマンドは違うリポジトリのディレ
クトリを再帰的に辿ることはできません。開発バージョンの @sc{cvs} では、
複数のサーバから作業ディレクトリに取り出すことがでます。@sc{cvs} は要
求されたコマンドを実行するために必要であれば、再帰的に動作し、対応する
数のサーバ・マシンに接続するという細い作業全部を扱います。
以下は作業ディレクトリを設定する例です:

@example
cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update
@end example

@code{cvs co} コマンドは作業ディレクトリを設定し、それから @code{cvs
update} コマンドは server2 に接続し、dir1/sdir サブディレクトリを更新
し、その他のものを更新するために server1 に接続します。
@c FIXME: Does the FAQ have more about this?  I have a
@c dim recollection, but I'm too lazy to check right now.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Creating a repository
@section リポジトリの作成

@cindex Repository, setting up
@cindex Creating a repository
@cindex Setting up a repository

@sc{cvs} リポジトリを設定するために、まずソースファイルのリビジョン履
歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも
のですので、たいていのマシンは十分なはずです。詳細は @ref{Server
requirements} を参照してください。
@c Possible that we should be providing a quick rule of
@c thumb, like the 32M memory for the server.  That
@c might increase the number of people who are happy
@c with the answer, without following the xref.

ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを
移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、
バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ
ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに
なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは
ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同
じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、
全体の木かそれの一部分のどちらかになります)。

リポジトリはサーバ経由からか直接 @sc{cvs} を使う全てのマシンからか、
(直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に
する必要があります。クライアントのマシンは @sc{cvs} プロトコル経由以外
でそれにアクセス可能である必要はありません。@sc{cvs} は、リポジトリに
ロック・ファイルを作成する必要があるため (@pxref{Concurrency})、利用者
が読み込み許可しか持たないリポジトリを、@sc{cvs} から使うことはできま
せん。

@cindex init (subcommand)
リポジトリを作成するときには、@code{cvs init} コマンドを実行して下さい。
通常の方法で指定された @sc{cvs} のルート (@pxref{Repository}) 以下の、
空のリポジトリを利用できるように整えます。例えば次のようにします。

@example
cvs -d /usr/local/cvsroot init
@end example

@code{cvs init} は注意深いので、リポジトリに存在するファイルを上書きし
ません。従って既に利用できる状態のリポジトリに対して @code{cvs init} 
を実行しても、何の不都合もありません。

@code{cvs init} は、操作履歴を記録するように設定します。
もしこれを望まないのであれば、@code{cvs init} を実行した後に、
@file{history} ファイルを削除して下さい。@xref{history file}.

@node Backing up
@section リポジトリのバックアップ
@cindex Repository, backing up
@cindex Backing up, repository

リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん
どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき
点も幾つかあります。

@cindex locks, cvs, and backups
@cindex #cvs.rfl, and backups
最初の点は偏執的で、バックアップ中には @sc{cvs} を使用しないか、バック
アップ中はバックアッププログラムに @sc{cvs} をロックさせる必要がありま
す。@sc{cvs} を使わないために、リポジトリを操作できるマシンへのログイ
ンを禁止したり、@sc{cvs} サーバを停止したり、同様な機構を利用するかも
しれません。詳細はあなたのオペレーティングシステムと、@sc{cvs} を設定
した方法に依存します。@sc{cvs} をロックするためには、@file{#cvs.rfl} 
ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう
に言ってきましたが、これらの事前注意をせずにただバックアップを行なって
も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元
すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること
が非常に難しいということは無いでしょう。

リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時
から変更されていると仮定すると、失敗に影響を受けあかったディレクトリは
今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし
れません。そのようなディレクトリで @sc{cvs} を実行しようとすると、普通
はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す
方法の一つに以下のようなものがあります:

@itemize @bullet
@item
新しい作業ディレクトリを取得します。

@item
失敗前に作業ディレクトリからファイルをコピーします (もちろん、
@file{CVS} ディレクトリの内容をコピーしないでください)。

@item
新しい作業ディレクトリで作業をし、@code{cvs update} や @code{cvs diff} 
のようなコマンドを使って何が変更されたかを見つけ、準備がでいたなら、変
更をリポジトリに格納します。
@end itemize

@node Moving a repository
@section リポジトリの移動
@cindex repository, moving
@cindex moving a repository
@cindex copying a repository

リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く
似ているように、リポジトリを別の場所に移動する必要があるときも、それは
他のファイルの集合を移動するのと非常に良く似ています。

主に考慮することは、作業ディレクトリがリポジトリを指しているか、という
ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し
い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ
クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような
何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作
業ディレクトリを再利用したいなら、@file{CVS/Repository} ファイルを手で
手術することで可能です。@file{CVS/Repository}  と @file{CVS/Root} ファ
イルの情報は @ref{Working  directory storage} で参照することができます
が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。
@c FIXME: Surgery on CVS/Repository should be avoided
@c by making RELATIVE_REPOS the default.
@c FIXME-maybe: might want some documented way to
@c change the CVS/Root files in some particular tree.
@c But then again, I don't know, maybe just having
@c people do this in perl/shell/&c isn't so bad...

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Remote repositories
@section 別のマシンのリポジトリ
@cindex Repositories, remote
@cindex Remote repositories
@cindex Client/Server Operation
@cindex server, CVS

ソースの作業コピーはリポジトリと別のマシンに存在することができます。
@sc{cvs} をこの方法で使うことは @dfn{クライアント/サーバ}
(@dfn{client/server}) 操作として知られています。@dfn{クライアント} と
して、@sc{cvs} を作業ディレクトリを mount できるマシンで @sc{cvs} を実
行し、@dfn{サーバ} となる、リポジトリを mount できるマシンと通信するよ
うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式
が以下のようになることを除き、ローカルのものを使うのと同じです:

@example
:@var{method}:@var{user}@@@var{hostname}:/path/to/repository
@end example

どれが本当に設定する必要があるかは、サーバに接続している方法に依って変
わります。

@var{method} が指定されず、リポジトリ名に @samp{:} が含まれる場合には、
使用するオペレーティングシステムに依って @code{ext} か @code{server} 
が既定値とされます。詳しくは @ref{Connecting via rsh} 参照。
@c Should we try to explain which platforms are which?
@c Platforms like unix and VMS, which only allow
@c privileged programs to bind to sockets <1024 lose on
@c :server:
@c Platforms like Mac and VMS, whose rsh program is
@c unusable or nonexistent, lose on :ext:
@c Platforms like OS/2 and NT probably could plausibly
@c default either way (modulo -b troubles).

@c FIXME: We need to have a better way of explaining
@c what method to use.  This presentation totally
@c obscures the fact that :ext: and CVS_RSH is the way to
@c use SSH, for example.  Plus it incorrectly implies
@c that you need an @code{rsh} binary on the client to use
@c :server:.
@c Also note that rsh not pserver is the right choice if you want
@c users to be able to create their own repositories
@c (because of the --allow-root related issues).
@menu
* Server requirements::         サーバのためのメモリと他の資源
* Connecting via rsh::          接続に @code{rsh} プログラムを利用する
* Password authenticated::      パスワードを利用して直接接続する
* GSSAPI authenticated::        GSSAPI を利用して直接接続する
* Kerberos authenticated::      ケルベロスを利用して直接接続する
* Connecting via fork::         接続に fork された @code{cvs server}を使う
@end menu

@node Server requirements
@subsection サーバの要求

サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は
こじんまりとしたものであるということです---32M のメモリやそれ以下のサー
バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。
@c Say something about CPU speed too?  I'm even less sure
@c what to say on that subject...

もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の
見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分
が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで
ないものがあれば、この説明文書を更新できるように、@ref{BUGS} に書かれ
ているように、我々に知らせてください)。

大量のメモリ消費をする最初の部分は、@sc{cvs} サーバを使っているときの
大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための
2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ
ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー
ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな
るか、2メガバイトほどかどちらか大きいものになることが予想されています。
@c "two megabytes" of course is SERVER_HI_WATER.  But
@c we don't mention that here because we are
@c documenting the default configuration of CVS.  If it
@c is a "standard" thing to change that value, it
@c should be some kind of run-time configuration.
@c
@c See cvsclient.texi for more on the design decision
@c to not have locks in place while waiting for the
@c client, which is what results in memory consumption
@c as high as this.

それぞれの @sc{cvs} サーバの大きさを予想上の一度に活動するサーバ数で掛
けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい
ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ
リでしょう。
@c Has anyone verified that notion about swap space?
@c I say it based pretty much on guessing that the
@c ->text of the struct buffer_data only gets accessed
@c in a first in, first out fashion, but I haven't
@c looked very closely.

@c What about disk usage in /tmp on the server?  I think that
@c it can be substantial, but I haven't looked at this
@c again and tried to figure it out ("cvs import" is
@c probably the worst case...).

大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの
@code{diff} です。これはバイナリ・ファイルでさえも必要です。大体の目安
は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が
適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を
するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ 
でなければ、@sc{cvs} を実行しているマシン) に100メガバイトのメモリがあ
るのが良いです。これは物理メモリでなく、スワップであるかもしれません。
メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ
れるときのためのメモリを準備する必要は特にありません。
@c The 5-10 times rule of thumb is from Paul Eggert for
@c GNU diff.  I don't think it is in the GNU diff
@c manual or anyplace like that.
@c
@c Probably we could be saying more about
@c non-client/server CVS.
@c I would guess for non-client/server CVS in an NFS
@c environment the biggest issues are the network and
@c the NFS server.

クライアントの資源消費はさらに少ないです---オペレーティングシステムを
動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。
@c Is that true?  I think the client still wants to
@c (bogusly) store entire files in memory at times.

ディスク容量に対する要求の情報は、@ref{Creating a repository} を参照し
てください。

@node Connecting via rsh
@subsection rsh で接続する

@cindex rsh
CVS はこれらの操作を実行するために @file{rsh} プロトコルを用いますので、
遠隔側の使用者のホストはローカルの使用者の接続を許可する
@file{.rhosts} を持つ必要があります。

例えば、あなたがローカルマシン @file{toe.example.com} の利用者
@file{mozart} であり、サーバマシンは @file{faun.example.org} であると
しましょう。faun では、以下の行を @file{bach} のホームディレクトリ
の @file{.rhosts} ファイルに書いてください:

@example
toe.example.com  mozart
@end example

そして、@code{rsh} の動作を次の行で確認します。

@example
rsh -l bach faun.example.org 'echo $PATH'
@end example

@cindex CVS_SERVER, environment variable
次に @code{rsh} が、
サーバを発見できるかどうか確認する必要があります。
上記の例で @code{rsh} が表示したパスの中に、
サーバである @code{cvs} のあるディレクトリが
含まれているかどうか確認して下さい。
@file{.login} や @file{.profile} でなく、
@file{.bashrc}, @file{.cshrc} 等に
パスを設定する必要があります。
代わりに、クライアント側で環境変数 @code{CVS_SERVER} に、
@file{/usr/local/bin/cvs-1.6} などと、
使用したいサーバ名を設定できます。
@c FIXME: there should be a way to specify the
@c program in CVSROOT, not CVS_SERVER, so that one can use
@c different ones for different roots.  e.g. ":server;cvs=cvs-1.6:"
@c instead of ":server:".

@file{inetd.conf} を編集したり、
@sc{cvs} のサーバ・デーモンを走らせる必要はありません。

@cindex :server:, setting up
@cindex :ext:, setting up
@cindex Kerberos, using kerberized rsh
@cindex SSH (rsh replacement)
@cindex rsh replacements (Kerberized, SSH, &c)
@code{rsh} 経由で @code{$CVSROOT} を利用するときに
指定できる接続経路は二つあります。
@code{:server:} を指定した場合、
@sc{cvs} が内部実装した @code{rsh} のクライアントが用いられますが、
移植版では利用できないものもあります。
@code{:ext:} を指定した場合、外部の @code{rsh} プログラムが用いられます。
@code{rsh} が既定となっていますが、
サーバを利用できる他のプログラムを呼び出す場合は、
環境変数 @code{CVS_RSH} に設定して下さい 
(例えば HP-UX 9 では、
@code{rsh} は何か別のものなので @code{remsh} を用いて下さい)。
指定するプログラムは、データを変更しないで送受信できなくてはいけません。
例えば Windows NT の @code{rsh} は、
既定では @t{CRLF} を @t{LF} に換えるので不適当です。
@sc{cvs} の OS/2 版はこれを回避するため、
@code{rsh} に @samp{-b} を渡して切り抜けていますが、
標準的な @code{rsh} でないプログラムを黙認する形になるので、
将来は別のやり方になるでしょう。
@code{CVS_RSH} に @code{SSH} 等の @code{rsh} の代替物を設定した場合、
この節の残りの @file{.rhosts} の使用説明などは、
おそらく不適当でしょうから、
各 @code{rsh} の代替物の文書資料を参照して下さい。
@c FIXME: there should be a way to specify the
@c program in CVSROOT, not CVS_RSH, so that one can use
@c different ones for different roots.  e.g. ":ext;rsh=remsh:"
@c instead of ":ext:".
@c See also the comment in src/client.c for rationale
@c concerning "rsh" being the default and never
@c "remsh".

例を続けます。仮に @file{faun.example.org} の
リポジトリ @file{/usr/local/cvsroot/} 中の
モジュール @file{foo} を利用したい場合には、
もう準備はできています:

@example
cvs -d :ext:bach@@faun.example.org:/usr/local/cvsroot checkout foo
@end example

(クライアント側とサーバ側で、使用者名が同じ場合には、
@file{bach@@} を省略することが出来ます。)

@c Should we mention "rsh host echo hi" and "rsh host
@c cat" (the latter followed by typing text and ^D)
@c as troubleshooting techniques?  Probably yes
@c (people tend to have trouble setting this up),
@c but this kind of thing can be hard to spell out.

@node Password authenticated
@subsection パスワード認証による直接接続

@sc{cvs} のクライアントは、
パスワード・プロトコルを用いて、
サーバと接続することもできます。
この方法は、
@code{rsh} の使用が可能でなく 
(例えばサーバが防火壁の向こうにある場合)、
またケルベロスも利用できない場合に特に有効です。

この方法を使用するために、
サーバとクライアント双方での調整が必要になります。

@menu
* Password authentication server::     サーバ側の設定
* Password authentication client::     クライアントの使用
* Password authentication security::   この方法が何をして何をしないか
@end menu

@node Password authentication server
@subsubsection パスワード認証のためのサーバの設定

まず最初に、@file{$CVSROOT} と @file{$CVSROOT/CVSROOT} ディレクトリの
使用許可をきつくすることを考えるでしょう。詳細は @ref{Password
authentication security} を参照してください。

@cindex Pserver (subcommand)
@cindex password server, setting up
@cindex authenticating server, setting up
@c FIXME: this isn't quite right regarding port
@c numbers; CVS looks up "cvspserver" in
@c /etc/services (on unix, but what about non-unix?).
サーバ側では @file{/etc/inetd.conf} を編集する必要があります。
正しいポートに接続を受けた時、
@code{inetd} がコマンド @code{cvs pserver} を実行する様に変更します。
ポート番号の既定値は 2401 ですが、
クライアントをコンパイルした時に、
@code{CVS_AUTH_PORT} に他の値を定義した場合には異なります。

あなたの使用する @code{inetd} が、
ポート番号を素のまま @file{/etc/inetd.conf} に書いて良いならば、
次の記述で十分でしょう 
(@file{inetd.conf} には一行で記述して下さい):

@example
2401  stream  tcp  nowait  root  /usr/local/bin/cvs
cvs --allow-root=/usr/cvsroot pserver
@end example

@samp{-T} オプションで一時ファイルを作成するディレクトリも指定できます。

@samp{--allow-root} オプションは使用可能な @sc{cvsroot} ディレクトリを
指定します。違う @sc{cvsroot} ディレクトリの使用を試みるクライアントは
接続できません。許可したい @sc{cvsroot} ディレクトリが2つ以上あるなら、
オプションを繰り返してください。(不幸なことに、@code{inetd} の多くのバー
ジョンはコマンドと引数の両方、もしくはどちらかの長さ全体に対して非常に
小さくなるように制限を課しています。この問題に対する普通の解決は、
@code{inetd} に @sc{cvs} を必要な引数と共に起動するシェルスクリプトを
実行させることです。)

あなたの使用する @code{inetd} が、
素のポート番号ではなく、サービス名を要求するならば、
@file{/etc/services} に次の行を追加して下さい:

@example
cvspserver      2401/tcp
@end example

そして @file{inetd.conf} には、
@code{2401} ではなく @code{cvspserver} と記述して下さい。

以上を注意して行なった後、
@code{inetd} を再起動するか、
初期設定ファイルを再読させるのに必要な処置を取って下さい。

これの設定に問題があるときは、@ref{Connection} を参照してください。

@cindex CVS passwd file
@cindex passwd (admin file)
クライアントはパスワードを平文のまま保存または伝送します 
(ほぼそのように---詳細は @ref{Password authentication security})。
従って、リポジトリを利用する時に、
正規のパスワードを危険に曝さないために、
@sc{cvs} では別のパスワードファイルを使用します。
このファイルは @file{$CVSROOT/CVSROOT/passwd} です。
その書式は、使用者名、パスワード、サーバが使用する任意に省略可能な使用
者名という二つか三つの欄しかない事を除けば、
@file{/etc/passwd} と同様です。
次に例示します:

@example
bach:ULtgRLXo7NRxs
cwang:1sOp854gDF3DY
@end example

パスワードは、標準 Unix の関数 @code{crypt()} によって暗号化されます。
従って、標準 Unix の @file{passwd} から直接コピーすることも可能です。

パスワード認証では、まずサーバが、
@sc{cvs} の @file{passwd} ファイル中の、使用者のエントリを確認します。
使用者のエントリがあれば、入力されたパスワードと比較されます。
使用者のエントリが無いか、
あるいは @sc{cvs} の @file{passwd} ファイルが存在しない場合には、
システムが使用者の調査機構に使用するパスワードと一致するか試されます
(cofig ファイルで @code{SystemAuth=no} を設定することで、システムの使
用者調査機構を使用不能にすることができます)。
サーバはエントリの三番目の欄にある使用者の権限で実行されます。
三番目の欄が無い場合には、最初の欄にある使用者の権限が使用されます 
(つまり @sc{cvs} の @file{passwd} ファイルに、
システムで有効な使用者を併せて記述すれば、
架空の使用者名を使用できます)。
どちらの場合でも、
(有効な) 使用者が持たない特権は付与されません。

@cindex user aliases
@file{$CVSROOT/CVSROOT/passwd} ファイルのパスワードの後にコロンとシス
テムの使用者名を追加することで、CVS 専用の使用者名をシステムの使用者名
に ``マップ'' することが可能です。(例えば、システムのログイン名に)。例
えば:

@example
cvs:ULtgRLXo7NRxs:kfogel
generic:1sOp854gDF3DY:spwang
anyone:1sOp854gDF3DY:spwang
@end example

こうやって、次のコマンド:

@example
cvs -d :pserver:cvs@@faun.example.org:/usr/local/cvsroot checkout foo
@end example

で @file{faun.example.org} のリポジトリに遠隔接続する人は、認証に成功
すると、システムの kfogel としてサーバを実行することになります。しかし、
遠隔使用者は、 @file{$CVSROOT/CVSROOT/passwd} ファイルに @sc{cvs} のみ
が使用する違ったパスワードがあるかもしれませんので、kfogel のシステム
パスワードが必ず必要なわけではありません。そして、上記の例で示されてい
るように、複数の cvs 利用者名を単一のシステムの利用者名にマップするこ
とができます。

この機能はリポジトリへの接続をシステムへの完全な接続を行うことなく (特
に、@ref{Read-only access} を参照してください) 可能にするために設計さ
れています。しかし、@ref{Password authentication security} も参照して
ください。どんな種類のリポジトリ接続でも、ある程度の総合的なシステム接
続も含んでいる可能性が高いのです。

現在、
@sc{cvs} の @file{passwd} ファイルにパスワードを加えるには、
他のどこかからコピーするしか方法がありません。
いつの日か @code{cvs passwd} コマンドができることでしょう。
@file{$CVSROOT/CVSROOT} の多くのファイルと違って、@file{passwd} ファイ
ルは @sc{cvs} 経由ではなく、直接編集します。
@c We might also suggest using the @code{htpasswd} command
@c from freely available web servers as well, but that
@c would open up a can of worms in that the users next
@c questions are likely to be "where do I get it?" and
@c "how do I use it?"
@c Also note that htpasswd, at least the version I had,
@c likes to clobber the third field.

@node Password authentication client
@subsubsection パスワード認証によるクライアントの使用
@cindex Login (subcommand)
@cindex password client, using
@cindex authenticated client, using
@cindex :pserver:, setting up
サーバに接続する前に、
使用者はコマンド @code{cvs login} を用いて
@dfn{ログイン}する必要があります。
サーバのパスワード確認と同時に、
後のサーバとの処理のためにパスワードを保存します。
コマンド @code{cvs login} は、
使用者名, サーバのホスト名, リポジトリへのフルパス等の情報が必要で、
リポジトリの引数もしくは環境変数 @code{CVSROOT} から取得します。

@code{cvs login} は対話的です---それはパスワード入力を促します:

@example
cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot login
CVS password:
@end example

サーバによりパスワードが照合され、
正しければ @code{login} が成功しますが、
誤りであれば失敗して、パスワードが正しく無いと文句を言います。

一度ログインに成功すると、@sc{cvs} に保存されたパスワードを
使って認証し、直接サーバに接続するようにさせられます:

@example
cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot checkout foo
@end example

@sc{cvs} がサーバに接続する際、
@code{:pserver:} が無ければ、
@code{rsh} が用いられます (@pxref{Connecting via rsh})。
従って、必ず @code{:pserver:} を付加して下さい。
(一旦作業コピーを取り出した後、
作業ディレクトリ中で @sc{cvs} を実行する場合には、
もう明示的にリポジトリの指定をする必要はありません。
@sc{cvs} は作業コピーのサブディレクトリ @file{CVS} に、
引数のリポジトリを記録しているためです。)

パスワードは、既定ではファイル @file{$HOME/.cvspass} に保存されます。
ファイルは人が読める書式で書かれていますが、
十分な知識無しに編集してはいけません。
パスワードは平文ではなく、
"悪気無く"見られる事 (つまり、システム管理者が偶然そのファイルを見付け、
不注意に見るといった事) を防ぐために、
簡単な符号化がなされています。

@c FIXME: seems to me this needs somewhat more
@c explanation.
@cindex Logout (subcommand)
現在選ばれている遠隔リポジトリのパスワードは @code{cvs logout} コマン
ドを使用すると CVS_PASSFILE から消去できます。

環境変数 @code{CVS_PASSFILE} は、この既定値に優先します。
この変数を使用するのであれば、
@code{cvs login} を実行する@emph{前に}設定しなければいけません。
@code{cvs login} を実行した後に設定した場合、
その後の @sc{cvs} コマンドは、
サーバに送るパスワードを見付けられません。

@node Password authentication security
@subsubsection パスワード認証における安全性の考察

@cindex security, of pserver
パスワードは、
平文を簡単に符号化してクライアント側に保存されており、
送信の際も同じ符号化が用いられます。
この符号化は、パスワードが偶然見られること (すなわちシステム管理者が
不注意に見てしまう事) を防ぐためのもので、
素人の攻撃からパスワードの取得を防ぐことさえ出来ません。

@c FIXME: The bit about "access to the repository
@c implies general access to the system is *not* specific
@c to pserver; it applies to kerberos and SSH and
@c everything else too.  Should reorganize the
@c documentation to make this clear.
@sc{cvs} 独自のパスワードファイルにより 
(@pxref{Password authentication server})、
リポジトリを利用する時には、
システムにログインする時とは別のパスワードが使用できます。
しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、
多様な方法により、サーバ上でプログラムが実行可能になります。
つまりリポジトリの利用は、
かなり広範囲にシステムが利用できる事を暗示しています。
これを防止するように @sc{cvs} を修正する事は可能でしょうが、
これを書いている時点までには誰もやっていません。
@c OpenBSD uses chroot() and copies the repository to
@c provide anonymous read-only access (for details see
@c http://www.openbsd.org/anoncvs.shar).  While this
@c closes the most obvious holes, I'm not sure it
@c closes enough holes to recommend it (plus it is
@c *very* easy to accidentally screw up a setup of this
@c type).

@file{$CVSROOT/CVSROOT} ディレクトリには @file{passwd} と他のセキュリ
ティを調べるために使われるファイルがあるので、このディレクトリの使用許
可をを @file{/etc} と同じくらいきつくしなければならないことに注意して
ください。同じことが @file{$CVSROOT} ディレクトリそのものと、木のそれ
より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ
クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが
できます。これらの使用許可は普通は pserver を使っていないときに使用す
るものよりもきついものであることに注意してください。
@c TODO: Would be really nice to document/implement a
@c scheme where the CVS server can run as some non-root
@c user, e.g. "cvs".  CVSROOT/passwd would contain a
@c bunch of entries of the form foo:xxx:cvs (or the "cvs"
@c would be implicit).  This would greatly reduce
@c security risks such as those hinted at in the
@c previous paragraph.  I think minor changes to CVS
@c might be required but mostly this would just need
@c someone who wants to play with it, document it, &c.

要約すると、
パスワードを得た人物は誰でもリポジトリを利用できます
(これはまたある程度通常のシステム利用も可能になるということを含むかも
しれません。)
ネットワークのパケットを漁ったり、
保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、
全ての人物がパスワードを入手可能です。
あなたが本物の安全を望むのならば、ケルベロスにしましょう。

@node GSSAPI authenticated
@subsection GSSAPI による直接接続

@cindex GSSAPI
@cindex security, GSSAPI
@cindex :gserver:, setting up
@cindex Kerberos, using :gserver:
GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般
的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、
@sc{cvs} を GSSAPI で認証して、直接 @sc{tcp} 接続を通して接続すること
ができます。

これをするためには、@sc{cvs} が GSSAPI サポート付きでコンパイルされて
いる必要があります。@sc{cvs} を configure しているときに、ケルベロス 
version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま
す。構築するために @file{--with-gssapi} も使用できます。

接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認
証@emph{されません}。ストリームの認証を要求するためには、広域オプショ
ン @code{-a} を使用する必要があります。

既定状態では、データ転送は暗号化@emph{されません}。
クライアントとサーバ双方を、
暗号化を有効にしてコンパイルしておく必要があります。
構築時に @file{--enable-encryption} オプションを付加して、
暗号化機能を有効にして下さい。
また暗号化を要求するために、
使用時に広域オプション @samp{-x} を付加する必要があります。

GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ
れます。@ref{Password authentication server} 参照。ケルベロスのような
強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ
る認証を使用不能にしたいと思うかもしれません。そのためには、空の 
@file{CVSROOT/passwd} パスワードファイルを作成して、config ファイルで 
@code{SystemAuth=no} を設定します (@pxref{config})。

GSSAPI サーバは cvs/@var{hostname} の主な名前を使い、@var{hostname} は
サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ
うにこれを設定しなければなりません。

GSSAPI を使用して接続するには、@samp{:gserver:} を使用します。例えば、
以下のようになります。

@example
cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
@end example

@node Kerberos authenticated
@subsection ケルベロスによる直接接続

@cindex Kerberos, using :kserver:
@cindex security, kerberos
@cindex :kserver:, setting up
ケルベロスを使う一番簡単な方法は @ref{Connecting via rsh} で説明されて
いるようにケルベロスの @code{rsh} を使用することです。
rsh を利用する際の主な欠点は、
全てのデータが他のプログラムを経由する必要があるため、
時間がかかるかもしれない事です。
もしケルベロスが導入されているならば、
ケルベロスの認証により、直接 @sc{tcp} 接続する事が可能です

この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関
するものです。ケルベロス バージョン5は前節で説明されているように、
GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ
うになっています。

このためには、
ケルベロスの支援を受けるように @sc{cvs} をコンパイルする必要があります。
@sc{cvs} は configre 時に
ケルベロスが利用できるかどうかを検出しようとしますが、
駄目ならフラグ @file{--with-krb4} を用いて強制させることも可能です。

既定状態では、データ転送は暗号化され@emph{ません}。
クライアントとサーバ双方を、
暗号化を有効にしてコンパイルしておく必要があります。
構築時に @file{--enable-encryption} オプションを付加して、
暗号化機能を有効にして下さい。
また暗号化を要求するために、
使用時に広域オプション @samp{-x} を付加する必要があります。

@cindex CVS_CLIENT_PORT
サーバの @file{inetd.conf} を編集する必要があります。
クライアントが使用する既定のポート番号は 1999 です。
他のポートを使用したい場合には、
クライアントの環境変数 @code{CVS_CLIENT_PORT} で指定して下さい。

@cindex kinit
@sc{cvs} を利用する前に、
通常の方法で切符を取得して下さい (一般的には @code{kinit} です)。
この切符でサーバへのログインが許可されるはずです。
これで準備ができました:

@example
cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
@end example

ここで接続に失敗した場合、
以前のバージョンの @sc{cvs} は rsh で再接続を試みましたが、
このバージョンでは再試行されません。

@node Connecting via fork
@subsection fork を通じての接続

@cindex fork, access method
@cindex :fork:, setting up
この接続方法で、ローカル・ディスクのリポジトリに遠隔プロトコルを使って
接続することができます。言い換えると、それは @code{:local:} とほとんど
同じことをしますが、変な振舞いや、バグやその他のものはローカルの
@sc{cvs} のものではなく、遠隔 @sc{cvs} のものです。

毎日の作業では、@code{:local:} か @code{:fork:} を好むかは個人の好みに
依ります。もちろん @code{:fork:} は @code{cvs} と遠隔プロトコルをデバッ
グしているときは特に役立ちます。特に、我々は他の遠隔アクセス方法のネッ
トワーク関連の設定、変更、時間切れ設定、認証全てを避けることができ、そ
の上で遠隔プロトコルを使う接続を作成することができるのです。

@code{fork} 方法を用いて接続するためには、@samp{:fork:} とローカルのリ
ポジトリへのパス名を使用します。例えば、:

@example
cvs -d :fork:/usr/local/cvsroot checkout foo
@end example

@cindex CVS_SERVER, and :fork:
@code{:ext:} と同様に、サーバは既定値の @samp{cvs} と呼ばれるか、
@code{CVS_SERVER} 環境変数の値になります。

@c ---------------------------------------------------------------------
@node Read-only access
@section 読み込み専用リポジトリ接続
@cindex read-only repository access
@cindex readers (admin file)
@cindex writers (admin file)

パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める
ことができます (@pxref{Password authenticated})。 (他の接続方法は全て
リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用
許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助
はありません。)

読み込み専用接続の使用者は、特定の ``管理'' ファイル (ロックファイルや
履歴ファイル) を除いて、リポジトリを変更しない @sc{cvs} の操作のみを実
行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ
う (@pxref{Password authentication server})。

以前のバージョンの @sc{cvs} と違って、読み込み専用使用者はリポジトリを
読むことができるだけで、サーバのプログラムを実行できないようになってい
るはずです。そうしないと、予期しないレベルの接続を得ることができてしま
います。もしくは、より正確に言うと、@emph{既知の}穴は塞がれました。こ
の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ
リティへの関心に従って、どのような程度の注意も払うべきというのは正当の
ようです。

使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除
です。

"包含" は、使用者を特別に @file{$CVSROOT/CVSROOT/readers} ファイルに一
覧表示するということで、それは単純な改行で分離された利用者の一覧です。
これは @file{readers} ファイルの例です:

@example
melissa
splotnik
jrandom
@end example

(最後の使用者の後の改行を忘れないでください。)

"排除" は @emph{書き込み} 接続のできる人を全て明示的に一覧表示するとい
うことです---もしファイル

@example
$CVSROOT/CVSROOT/writers
@end example

@noindent
が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その
他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相
変らず @sc{cvs} @file{passwd} ファイルに挙げられている必要があります。)
@file{writers} ファイル は @file{readers} ファイルと同じ書式です。

注意: @sc{cvs} @file{passwd} ファイルが cvs の使用者をシステムの使用者
にマップしているときは、@emph{cvs} の使用者名を使って書き込み専用接続
を拒否したり認めたりしていて、システムの使用者名を使っていないことを確
認してください。すなわち、@file{readers} と @file{writers} ファイルに
cvs の使用者名があるということで、それはシステムの使用者名と同じかもし
れませんし、違うかもしれません。

これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ
の振舞いの完全な説明です。

@file{readers} が存在して、この使用者がそこに挙げられていれば、読み込
み専用接続になります。もしくは、@file{writers} が存在していて、使用者
がそこに挙げられていなければ読み込み専用接続になります (@file{readers}
が存在するけれど、そこには挙げられていないというときにもそのようになり
ます)。その他の場合では、完全な読み込み書き込み接続になります。

もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。
これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより
多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな
ります。

@node Server temporary directory
@section サーバの一時ディレクトリ
@cindex temporary directories, and server
@cindex server, temporary directories

@sc{cvs} サーバは実行中に一時ディレクトリを作成します。それは

@example
cvs-serv@var{pid}
@end example

@noindent
のような名前で、@var{pid} はサーバのプロセス番号です。それらは環境変数
@samp{TMPDIR} (@pxref{Environment variables})、@samp{-T} 広域オプショ
ン (@pxref{Global options})、で指定されるディレクトリもしくは、それら
がないと @file{/tmp} に置かれます。

ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時
ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな
い場合がいくつかあります。例えば:

@itemize @bullet
@item
サーバがサーバの内部エラーで異常終了すると、デバッグを助けるためにディ
レクトリを保存するかもしれません。

@item
サーバが後始末をできない方法で kill されたとき (主にほとんど unix での 
@samp{kill -KILL})。

@item
システムが、サーバに後始末をするように告げる通常のシャットダウンをする
ことなくシャットダウンしたとき。
@end itemize

このような場合は、手で @file{cvs-serv@var{pid}} ディレクトリを消去する
必要があります。プロセス番号 @var{pid} で動いているサーバが無ければ、
その行為は安全です。

@c ---------------------------------------------------------------------
@node Starting a new project
@chapter CVS でプロジェクトを始める
@cindex Starting a project with CVS
@cindex Creating a project

@comment --moduledb--
ファイルの改名とディレクトリ間の移動はうまくできないので、
新しいプロジェクトを始めるときには、
最初にファイルの構成をよく考えておく必要があります。
ファイルの改名や移動は、
不可能ではありませんが非常にやっかいです。
特にディレクトリの改名に関して、
@sc{cvs} は癖のある動作をします 
(@pxref{Moving files})。

次に何をするかは、始める状況に依ります。

@menu
* Setting up the files::        ファイルをリポジトリに加える
* Defining the module::         ファイルからモジュールを作る
@end menu
@c -- File permissions!

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Setting up the files
@section ファイルの準備

始めの一歩は、リポジトリ中にファイルを生成することです。
これには幾つか異なる方法があります。

@c -- The contributed scripts
@menu
* From files::                  既存のプロジェクトに便利な方法
                                (既にファイルが存在する場合)
* From other version control systems::  古いプロジェクトの、他の
                                        システムでの履歴を保存する
* From scratch::                ゼロからディレクトリを作成する
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node From files
@subsection 存在するファイルからディレクトリを生成する
@cindex Importing files

@sc{cvs} を使い始める場合に、
おそらく @sc{cvs} を使用できるプロジェクトが
既に幾つかあるでしょう。
この場合 @code{import} コマンドを使用するのが最も簡単です。
例を挙げて説明します。
@sc{cvs} に組み込みたいファイルが @file{@var{wdir}} にあり、
それを @file{$CVSROOT/yoyodyne/@var{rdir}} に置きたい時、
次のようにします。

@example
$ cd @var{wdir}
$ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
@end example

@samp{-m} フラグでログ・メッセージを与えなかった場合、@sc{cvs} により
エディタが開かれ、メッセージの入力が促されます。文字列 @samp{yoyo} は 
@dfn{ベンダー・タグ}と呼ばれるものであり、
@samp{start} は@dfn{リリース・タグ}と呼ばれるもの
です。この文脈では意味をなさないかもしれませんが、@sc{cvs} はそれらの
存在を要求します。詳しくは @xref{Tracking sources}.

では実際に動作したことを確かめた後、元のソースディレクトリを削除します。
@c FIXME: Need to say more about "verify that it
@c worked".  What should the user look for in the output
@c from "diff -r"?

@example
$ cd ..
$ mv @var{dir} @var{dir}.orig
$ cvs checkout yoyodyne/@var{dir}       # @r{下で説明}
$ diff -r @var{dir}.orig yoyodyne/@var{dir}
$ rm -r @var{dir}.orig
@end example

@noindent
誤って @sc{cvs} を通さないで編集してしまわないように、下のソースを削除
すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るの
が賢明です。

@code{checkout} コマンドはモジュールの名前 (以前の全ての例のように)、
または @code{$CVSROOT} からの相対パス (上の例のように) を引数に取りま
す。

@sc{cvs} が @samp{$CVSROOT} 中のディレクトリに設定した
使用許可とグループ属性が、
適切かどうか調べると良いでしょう。@xref{File permissions}.

取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、
wrapper 機能を用いて、どのファイルがバイナリなのか
明示するとよいでしょう。@xref{Wrappers}.

@c The node name is too long, but I am having trouble
@c thinking of something more concise.
@node From other version control systems
@subsection 他のバージョン管理システムからファイルを作成する
@cindex Importing files, from other version control systems

@sc{rcs} 等の、
他のバージョン管理システムで保守されてきたプロジェクトがあり、
そのプロジェクトのファイルを @sc{cvs} に移管する場合、
各ファイルの修正履歴の維持を望むでしょう。

@table @asis
@cindex RCS, importing files from
@item RCS から
@sc{rcs} を使用してきた場合、@sc{rcs} ファイルを見付けて下さい---
通常 @file{foo.c} という名前のファイルには、
@file{RCS/foo.c,v} という @sc{rcs} ファイルが対応します 
(他の場所にあるかもしれませんので、
詳細は @sc{rcs} の文書を調べて下さい)。
次に、@sc{cvs} リポジトリに適当なディレクトリを作成して下さい。
そして @sc{cvs} リポジトリの当該ディレクトリに、
ファイルをコピーして下さい 
(リポジトリ中のファイル名は、
ソース・ファイルに @samp{,v} が付加されたものでなくてはならず、
またファイルは @file{RCS} サブディレクトリではなく、
当該ディレクトリに直接置いて下さい)。
この例のように、@sc{cvs} コマンドを利用せず、
@sc{cvs} リポジトリを直接利用するほうが適当な場合が稀にあります。
以上で作業コピーを新たに取り出す準備ができました。
@c Someday there probably should be a "cvs import -t
@c rcs" or some such.  It could even create magic
@c branches.  It could also do something about the case
@c where the RCS file had a (non-magic) "0" branch.

@sc{rcs} ファイルを @sc{cvs} に移動するときに、
ロックされていてはいけません。
ロックされている場合には、@sc{cvs} での操作に支障を来します。
@c What is the easiest way to unlock your files if you
@c have them locked?  Especially if you have a lot of them?
@c This is a CVS bug/misfeature; importing RCS files
@c should ignore whether they are locked and leave them in
@c an unlocked state.  Yet another reason for a separate
@c "import RCS file" command.

@c How many is "many"? Or do they just import RCS files?
@item 他のバージョン管理システムから
多くのバージョン管理システムは、
標準形式の @sc{rcs} ファイルを出力する機能を持っています。
これが可能ならば、@sc{rcs} ファイルを出力して、
前項の説明に従って下さい。

それが駄目なら、おそらく一番良いのは他のシステムのコマンド行のインター
フェースを使って一回に一つのリビジョンを取り出し、それを @sc{cvs} に格
納するスクリプトを書くことでしょう。下の @file{sccs2rs} スクリプトはそ
のために役に立つ例でしょう。

@cindex SCCS, importing files from
@item From SCCS
@item SCCS から
@sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
@file{sccs2rcs} という名前のスクリプトがあります。
これを用いて @sc{sccs} ファイルを @sc{rcs} ファイルに変換できます。
注意: @sc{sccs} と @sc{rcs} の両方を持つマシンで実行する必要があり、
また @file{contrib} 内の他の全てと同様に動作保証はされません 
(使用者によって評価は異なるでしょう)。

@cindex PVCS, importing files from
@item From PVCS
@sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
@file{pvcs_to_rcs} という名前のスクリプトがあります。
これを用いて @sc{pvcs} アーカイブを @sc{rcs} ファイルに変換できます。
@sc{pvcs} と @sc{rcs} のあるマシンで実行する必要があり、
また @file{contrib} 内の他の全てと同様に動作保証はされません
(使用者によって評価は異なるでしょう)。
詳細はスクリプト中のコメントを読んでください。
@end table
@c CMZ and/or PATCHY were systems that were used in the
@c high energy physics community (especially for
@c CERNLIB).  CERN has replaced them with CVS, but the
@c CAR format seems to live on as a way to submit
@c changes.  There is a program car2cvs which converts
@c but I'm not sure where one gets a copy.
@c Not sure it is worth mentioning here, since it would
@c appear to affect only one particular community.
@c Best page for more information is:
@c http://wwwcn1.cern.ch/asd/cvs/index.html
@c See also:
@c http://ecponion.cern.ch/ecpsa/cernlib.html

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node From scratch
@subsection ゼロからディレクトリを作る

@c Also/instead should be documenting
@c $ cvs co -l .
@c $ mkdir tc
@c $ cvs add tc
@c $ cd tc
@c $ mkdir man
@c $ cvs add man
@c etc.
@c Using import to create the directories only is
@c probably a somewhat confusing concept.
新しいプロジェクトを始める場合、
まず次のように空のディレクトリを作ります。

@example
$ mkdir tc
$ mkdir tc/man
$ mkdir tc/testing
@end example

その後 @code{import} コマンドを使って、
リポジトリに各々の (空の) ディレクトリを登録(作成)します:

@example
$ cd tc
$ cvs import -m "Created directory structure" yoyodyne/@var{dir} yoyo start
@end example

そして @code{add} コマンドで、
ファイル (と新しいディレクトリ) を加えていきます。

その時、 @samp{$CVSROOT} の中のファイルの使用許可が、
正しいものかどうかを確認すると良いでしょう。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Defining the module
@section モジュールの定義
@cindex Defining a module
@cindex Editing the modules file
@cindex Module, defining
@cindex Modules file, changing

二歩目は @file{modules} ファイルにモジュールの定義をする事です。
必ずしも必要ではありませんが、
関連するファイルやディレクトリをグループ化するのに便利です。

モジュールを定義する簡単な手順を示します。

@enumerate
@item
ファイル modules の作業コピーを取ってきます。

@example
$ cvs checkout CVSROOT/modules
$ cd CVSROOT
@end example

@item
ファイルを編集し、モジュールの定義を加えます。
導入は @xref{Intro administrative files}.
詳細な記述は @ref{modules} 参照。
モジュール @samp{tc} を定義するには次の行を加えます:

@example
tc   yoyodyne/tc
@end example

@item
modules ファイルに変更を格納します。

@example
$ cvs commit -m "Added the tc module." modules
@end example

@item
モジュール modules をリリースします。

@example
$ cd ..
$ cvs release -d CVSROOT
@end example
@end enumerate

@c ---------------------------------------------------------------------
@node Revisions
@chapter リビジョン

@sc{cvs} の多くの利用ではあまりリビジョン番号について心配する必要はあ
りません。@sc{cvs} は @code{1.1}, @code{1.2} などのような番号を割当て、
それだけが皆が知る必要のあることです。しかし、@sc{cvs} がリビジョン番
号を割当てる方法に関してより知識を持ち、より制御したい人もいます。

どのリビジョンが特定のリリースになったか、などの 1 つより多くのファイ
ルを含むリビジョンの組を追いかけたいときは、@dfn{タグ} を使います。そ
れはそれぞれのファイルの数字リビジョンに割当てることのできるリビジョン
名です。

@menu
* Revision numbers::            リビジョン番号の意味
* Versions revisions releases::  このマニュアルでの用語
* Assigning revisions::         リビジョンの割当て
* Tags::                        タグ--文字によるリビジョン
* Sticky tags::                 貼り付いたタグ
* Tagging the working directory::  cvs tag コマンド
* Tagging by date/tag::         cvs rtag コマンド
* Modifying tags::              タグの追加、改名、削除
* Tagging add/remove::          ファイルの追加と削除を伴うタグ
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Revision numbers
@section リビジョン番号
@cindex Revision numbers
@cindex Revision tree
@cindex Linear development
@cindex Number, revision-
@cindex Decimal revision number
@cindex Branch number
@cindex Number, branch

各バージョンのファイルはそれぞれ一意な@dfn{リビジョン番号} 
(@dfn{revision number}) を持ちます。
@samp{1.1}, @samp{1.2} とか @samp{1.3.2.2} とか 
@samp{1.3.2.2.4.5} なんてのもあります。
リビジョン番号はピリオドで分けられた偶数個の十進整数です。
初期設定ではファイルの最初のリビジョンは 1.1 で、
リビジョンが新しくなると一番右の番号が1つ増えます。
次の絵は、新しいリビジョンを右にして少しリビジョンを図示しています。

@example
       +-----+    +-----+    +-----+    +-----+    +-----+
       ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
       +-----+    +-----+    +-----+    +-----+    +-----+
@end example

2 つ以上のピリオドを含む番号になることもあります。例えば、
@samp{1.3.2.2} です。そのようなリビジョンは枝のリビジョンを表します 
(@pxref{Branching and merging})。そのようなリビジョン番号は 
@ref{Branching and merging} で詳しく説明されています。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Versions revisions releases
@section バージョン、リビジョン、リリース
@cindex Revisions, versions and releases
@cindex Versions, revisions and releases
@cindex Releases, revisions and versions

上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト
ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ
く @samp{4.1.1} のようなバージョン番号を付けられます。

バージョンには二つの意味があり、
最初のものはこの文書で@dfn{リビジョン}と呼ばれるものです。
二番目は@dfn{リリース}と呼ばれるものです。
混乱を避けるために、
この文書ではなるべく@dfn{バージョン}という単語は使わないようにします。

@node Assigning revisions
@section リビジョンの割当て

@c We avoid the "major revision" terminology.  It seems
@c like jargon.  Hopefully "first number" is clear enough.
初期設定では、@sc{cvs} は最初の番号を同じにして 2番目の番号を増加させ
ることにより数字リビジョンを割当てます。例えば、@code{1.1},
@code{1.2}, @code{1.3} のように。

新しいファイルを加えるときは、2番目の番号は常に 1 で、最初の番号はその
ディレクトリの中のファイルの最初の番号の一番大きいものと等しくなります。
例えば、現在のディレクトリの一番大きい番号が @code{1.7}, @code{3.1},
@code{4.12} であると、追加されたファイルの数字リビジョンは @code{4.1}
になります。

@c This is sort of redundant with something we said a
@c while ago.  Somewhere we need a better way of
@c introducing how the first number can be anything
@c except "1", perhaps.  Also I don't think this
@c presentation is clear on why we are discussing releases
@c and first numbers of numeric revisions in the same
@c breath.
普通はリビジョン番号を気にかける必要はありません---それを @sc{cvs} が
維持している内部番号のように扱う方が簡単で、タグは製品リリース 1 とリ
リース 2 のような間を区別するより良い手段です (@pxref{Tags})。 しかし、
数字リビジョンを設定したいのであれば、@code{cvs commit} の @samp{-r}
オプションですることができます。@samp{-r} オプションは @samp{-f} オプ
ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
ということになります。

例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな
いものも含めて)、次のように実行するかもしれません:

@example
$ cvs commit -r 3.0
@end example

@samp{-r} で指定する番号は存在するリビジョン番号より大きくなければなら
ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、
@samp{cvs commit -r 1.3} とはできないということです。複数のリリースを
並行して維持したいときは、枝を使う必要があります (@pxref{Branching and
merging}).

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Tags
@section タグ--文字によるリビジョン
@cindex Tags

リビジョン番号は開発に従って徐々に増えていきますが、
ソフトウェア製品のリリース番号とは全く何の関係もありません。
@sc{cvs} の使い方にもよりますが、
異なる二つのリリースにおけるリビジョン番号は異なっているでしょう。
例えば @sc{rcs} 5.6 を作るソース・ファイルは、
次のようなリビジョン番号を持ちます:
@cindex RCS revision numbers

@example
ci.c            5.21
co.c            5.9
ident.c         5.3
rcs.c           5.12
rcsbase.h       5.11
rcsdiff.c       5.10
rcsedit.c       5.11
rcsfcmp.c       5.9
rcsgen.c        5.10
rcslex.c        5.11
rcsmap.c        5.2
rcsutil.c       5.10
@end example

@cindex tag, command, introduction
@cindex Tag, symbolic name
@cindex Symbolic name (tag)
@cindex Name, symbolic (tag)
@cindex HEAD, as reserved tag name
@cindex BASE, as reserved tag name
@code{tag} コマンドを使えば、
特定のリビジョンに名前 (タグ名) を付けることができます。
各ファイルに付けられた全てのタグと
対応するリビジョン番号を調べたい場合は、
@code{status} コマンドに @samp{-v} フラグを付けて下さい。
タグには、大文字と小文字で始まる必要があり、大文字, 小文字, 数字,
@samp{-}, @samp{_} が使用可能です。
@code{BASE} と @code{HEAD} の二つのタグ名は、
@sc{cvs} が使用するために予約されています。
将来使われる @sc{cvs} にとって特別な名前は、実際のタグ名との衝突を避け
るために @code{BASE} や @code{HEAD} などのような名前ではなく、例えば 
@samp{.} で始まるような特別な方法で命名されることが望まれています。
@c Including a character such as % or = has also been
@c suggested as the naming convention for future
@c special tag names.  Starting with . is nice because
@c that is not a legal tag name as far as RCS is concerned.
@c FIXME: CVS actually accepts quite a few characters
@c in tag names, not just the ones documented above
@c (see RCS_check_tag).  RCS
@c defines legitimate tag names by listing illegal
@c characters rather than legal ones.  CVS is said to lose its
@c mind if you try to use "/" (try making such a tag sticky
@c and using "cvs status" client/server--see remote
@c protocol format for entries line for probable cause).
@c TODO: The testsuite
@c should test for whatever are documented above as
@c officially-OK tag names, and CVS should at least reject
@c characters that won't work, like "/".

タグの命名にプログラムの名前とリリースのバージョン番号のような情報に基
いた何らかの習慣を選びたいでしょう。例えば、CVS 1.9 が @code{cvs1-9} 
という名前でタグ付けされるように、まずプログラムの名前を使い、その直後
にバージョン番号の @samp{.} を @samp{-} に変更したものを続けるかもしれ
ません。同じ習慣を続ければ、常にタグが @code{cvs-1-9} や @code{cvs1_9}
や他のものであったかを推測する必要はなくなります。taginfo ファイルでそ
の習慣を強制することさえ考えるかもしれません (@pxref{user-defined
logging}).
@c Might be nice to say more about using taginfo this
@c way, like giving an example, or pointing out any particular
@c issues which arise.

@cindex Adding a tag
@cindex tag, example
次の例は、ファイルにタグを付ける方法を示したものです。
コマンドはあなたの作業ディレクトリで実行して下さい。
すなわち、@file{backend.c} があるディレクトリでコマンドを実行すべきで
ある、ということです。

@example
$ cvs tag rel-0-4 backend.c
T backend.c
$ cvs status -v backend.c
===================================================================
File: backend.c         Status: Up-to-date

    Version:            1.4     Tue Dec  1 14:39:01 1992
    RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
    Sticky Tag:         (none)
    Sticky Date:        (none)
    Sticky Options:     (none)

    Existing Tags:
        rel-0-4                     (revision: 1.4)

@end example

@code{cvs tag} の構文の完全なまとめと、いろいろなオプションの説明は
@ref{Invoking CVS} を参照してください。

単独のファイルにタグを付けるべき理由はほとんどありません。
タグの主な使い途は、
モジュールを構成する全てのファイルに同じタグを付け、
開発の流れの重要点 (リリース時等) を示すことです。

@example
$ cvs tag rel-1-0 .
cvs tag: Tagging .
T Makefile
T backend.c
T driver.c
T frontend.c
T parser.c
@end example

(@sc{cvs} に対する引数にディレクトリを指定した場合は、
そのディレクトリに含まれる全てのファイルにタグが付けられます。
そのディレクトリ以下の全てのサブディレクトリに対しても
(再帰的に) 動作します。@xref{Recursive behavior}.)

@cindex Retrieving an old revision using tags
@cindex Tag, retrieving old revisions
@code{checkout} コマンドの @samp{-r} フラグに、
モジュールから取り出すリビジョンを指定します。
このフラグを用いて、
モジュール @samp{ tc} のリリース 1.0 を作るソースを、
将来のいつでも簡単に復元することができます:

@example
$ cvs checkout -r rel-1-0 tc
@end example

@noindent
リリース時にタグを付けるようにしておけば、
過去のリリースにバグが発見されたが最新版には無い、
という場合などに非常に便利です。

任意の時間を指定してモジュールを復元することもできます。 
@xref{checkout options}. @samp{-r} をこれらのコマンドのどれかに指定す
るときは、貼り付きタグに注意する必要があります。@ref{Sticky tags} 参照。

複数のファイルに同じタグを付けるという事を、
「ファイル名とリビジョン番号の行列の中に線を引く」
と考えると良いでしょう。
以下のリビジョンの五つのファイルがあるとしましょう:

@example
@group
        file1   file2   file3   file4   file5

        1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
        1.2*-   1.2     1.2    -1.2*-
        1.3  \- 1.3*-   1.3   / 1.3
        1.4          \  1.4  /  1.4
                      \-1.5*-   1.5
                        1.6
@end group
@end example

過去の何らかの時点で、
@code{*} の付けられたバージョンにタグが付けられています。
上図では @samp{*} の付いたリビジョンにタグが付けられています。
仮にタグ名を「タグ付きリビジョンを結んだ紐」と考えると、
@code{checkout} の @samp{-r} は
「紐を引くとタグ付きリビジョン全てが釣れる」などと解釈できるでしょう。
あるいはタグ付きリビジョンを水平に並べた方が、分り易いかも知れません:

@example
@group
        file1   file2   file3   file4   file5

                        1.1
                        1.2
                1.1     1.3                       _
        1.1     1.2     1.4     1.1              /
        1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- ここを見る
        1.3             1.6     1.3              \_
        1.4                     1.4
                                1.5
@end group
@end example

@node Tagging the working directory
@section 作業ディレクトリからどれをタグ付けするかを指定する

@cindex Tag (subcommand)
前の節の例は、どのリビジョンにタグを付けるかを選ぶ一番普通の方法を表し
ています。つまり、引数無しの @code{cvs tag} コマンドでは、@sc{cvs} は
現在の作業ディレクトリに取り出されたリビジョンを選択します。例えば、作
業ディレクトリの @file{backend.c} がリビジョン1.4から取り出されたので
あれば、@sc{cvs} はリビジョン1.4にタグを付けます。タグはリポジトリのリ
ビジョン1.4にすぐに適用されることに注意してくさい。タグ付けはファイル
の修正とは違いますし、まず作業ディレクトリを修正してそれから @code{cvs
commit} を実行して修正をリポジトリに送信するような他の操作とも違います。

@code{cvs tag} がリポジトリに作用するという事実による、もしかすると驚
くかもしれない側面に、格納されたリビジョンにタグを付けていて、それは作
業ディレクトリにあるローカルで修正されているファイルと違うかもしれない、
というものがあります。間違ってそうしてしまわないようにするには、
@code{cvs tag} に @samp{-c} オプションを指定します。もしローカルで修正
されたファイルがあれば、@sc{cvs} はファイルをタグ付けする前にエラーを
出し、異常終了します:

@example
$ cvs tag -c rel-0-4
cvs tag: backend.c is locally modified
cvs [tag aborted]: correct the above errors first!
@end example

@node Tagging by date/tag
@section どれにタグを付けるかを日付やリビジョンで指定する
@cindex Rtag (subcommand)

@code{cvs rtag} コマンドは特定の日付や時間のリポジトリにタグを付けます
(もしくは最新のリビジョンにタグを付けることに使うことができます)。
@code{rtag} はリポジトリの内容に直接作用します (コマンドの前に取り出す
ことを要求しませんし、作業ディレクトリを見に行きません)。

以下のオプションはタグを付ける日付やリビジョンを指定します。完全な説明
は @ref{Common options} 参照。

@table @code
@item -D @var{date}
@var{date} 以前の一番新しいリビジョンにタグを付けます。

@item -f
@samp{-D @var{date}} や @samp{-r @var{tag}} と一緒のときにだけ役に立ち
ます。合致するリビジョンが見つからなければ、(ファイルを無視する代わり
に) 一番新しいリビジョンを使います。

@item -r @var{tag}
存在するタグ @var{tag} を含むファイルにのみタグを付けます。
@end table

@code{cvs tag} コマンドは同じ @samp{-r}, @samp{-D}, @samp{-f} オプショ
ンを使って、ファイルをリビジョンや日付により指定することもできるように
なっています。しかし、この機能はおそらくあなたが望むものではないでしょ
う。その理由は、@code{cvs tag} は与えられたタグ/日付ではなく、存在する
作業ディレクトリに基づいてタグを付けるファイルを選ぶからです。ですから、
普通は @code{cvs rtag} を使う方がうまくいくでしょう。例外はこのような
場合です:

@example
cvs tag -r 1.4 backend.c
@end example

@node Modifying tags
@section タグの削除、移動、改名

@c Also see:
@c  "How do I move or rename a magic branch tag?"
@c in the FAQ (I think the issues it talks about still
@c apply, but this could use some sanity.sh work).

普通はタグを修正しません。それはリポジトリの履歴を記録するために存在し
ており、削除したり意味を変えたりすることは、普通は望むことではないでしょ
う。

しかし、一時的にタグを使用したり、偶然に間違った場所に付けてしまったり
する場合もあるでしょう。ですから、タグを削除、移動、改名するかもしれま
せん。警告: この節のコマンドは危険です。それは履歴情報を永遠に捨て去り、
エラーからの復帰が難しくなるか、不可能になります。あなたが @sc{cvs} の
管理者なら、これらのコマンドを taginfo で制限することを考えるかもしれ
ません (@pxref{user-defined logging})。

@cindex deleting tags
@cindex removing tags
@cindex tags, deleting
タグを削除するには、@samp{-d} オプションを @code{cvs tag} か
@code{rtag} に指定します。例えば:

@example
cvs rtag -d rel-0-4 tc
@end example

はモジュール @code{tc} からタグ @code{rel-0-4} を削除します。

@cindex moving tags
@cindex tags, moving
@dfn{移動} とは、同じ名前を違うリビジョンを指すようにすることです。例
えば、@code{stable} タグは現時点で @file{backend.c} のリビジョン1.4を
指しており、おそらくそれをリビジョン1.6を指すようにしたいと思っている
かもしれません。タグを移動するには、@samp{-F} オプションを @code{cvs
tag} か@code{cvs rtag} に指定します。例えば、今書いた作業は以下のもの
で達成できます:

@example
cvs tag -r 1.6 -F stable backend.c
@end example

@cindex renaming tags
@cindex tags, renaming
タグの @dfn{改名} とは、違った名前を古いタグと同じリビジョンを指すよう
にすることです。例えば、タグ名の綴りを間違えて、修正したいと思っている
かもしれません (できれば他の人が古い綴りに頼る前に)。タグを改名するた
めには、まず @samp{-r} オプションを @code{cvs rtag} に与えて新しいタグ
を作り、それから古い名前を削除します。これは新しいタグを古いタグと全く
同じファイルにつけることになります。例えば:

@example
cvs rtag -r old-name-0-4 rel-0-4 tc
cvs rtag -d old-name-0-4 tc
@end example

@node Tagging add/remove
@section タグ付けとファイルの追加、削除

タグ付けがどのようにファイルの追加と削除と関連して動作するかの正確な議
題は少し複雑です。たいていの場合、@sc{cvs} はファイルが存在したかどう
かをたいして苦労することなく追い掛けることができます。既定では、タグは
タグ付けされたリビジョンに対応するファイルだけに適用されます。ファイル
がまだ存在していないか、既に削除されていると、単にタグを省略し、
@sc{cvs} はタグが無いものは、そのタグではファイルが存在しないという意
味に扱うことを知っています。

ところが、これは少し情報を失います。例えば、ファイルが追加されて、それ
から削除されたとしましょう。そして、タグがそのファイルになければ、その
タグがファイルの追加前のときか、削除の後かどちらを参照するかを知る方法
はありません。@samp{-r} オプションを @code{cvs rtag} に指定すれば、
@sc{cvs} は削除されたファイルにタグを付け、この問題を回避することがで
きます。例えば、先頭のリビジョンにタグを付けるために @code{-r HEAD} を
指定するかもしれません。

ファイルの追加と削除という題に関して、@code{cvs rtag} コマンドには他の
方法ではタグ付けされない、削除されたファイルのタグを消去する @samp{-a} 
オプションがあります。例えば、タグを移動しているときに @samp{-F} と共
に指定するでしょう。@samp{-a} 無しでタグを移動すれば、削除されたファイ
ルはファイルが削除されたという事実を反映せずに、まだ古いリビジョンを参
照しているでしょう。私は上に書いてあるように @samp{-r} が指定されてい
るときはこれは必要ではないと思います。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Sticky tags
@section 貼り付いたタグ
@cindex Sticky tags
@cindex Tags, sticky

@c A somewhat related issue is per-directory sticky
@c tags (see comment at CVS/Tag in node Working
@c directory storage); we probably want to say
@c something like "you can set a sticky tag for only
@c some files, but you don't want to" or some such.

作業コピーのリビジョンには関連した追加のデータがあることがあります。例
えば、枝であったり (@pxref{Branching and merging})、@samp{checkout -D}
か @samp{update -D} によって特定の日時より前のバージョンに制限されてい
るかもしれません。このデータは永続しますので -- すなわち、作業コピーの
残りのコマンドに適用されます -- 我々はそれを @dfn{貼り付けられた} と表
現しました。

たいていの場合、貼り付きは考える必要のない @sc{cvs} の隠れた側面です。
しかし、この機能を使いたくないとしても、貼り付けられたタグに関して 
@emph{何か} 知る必要があるかもしれません (例えば、それを避ける方法!).

@dfn{貼り付いたタグ} (@dfn{sticky tag}) や日付を調べるには、
@code{status} コマンドを使用します:

@example
$ cvs status driver.c
===================================================================
File: driver.c          Status: Up-to-date

    Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
    RCS Version:        1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
    Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
    Sticky Date:        (none)
    Sticky Options:     (none)

@end example

@cindex Resetting sticky tags
@cindex Sticky tags, resetting
@cindex Deleting sticky tags
作業ファイルに貼り付いたタグは、
@samp{cvs update -A} を使って削除するまで残ります。
オプション @samp{-A} は、ファイルを幹の先頭のバージョンに戻し、
貼り付いたタグ, 日付, オプションを全て剥します。

@cindex sticky date
貼り付けられたタグの一番普通の使用法は、@ref{Accessing branches} で説
明されているようにどの枝で作業しているかを確認することです。しかし、枝
でない貼り付きタグにも利用法はあります。
ここでは、他人の変更が安定しているかどうか分らないので、
作業ディレクトリを更新したくない場合を例に挙げて考えます。
もちろんこの場合、@code{cvs update} の実行を控えれば済みます。
しかし、更新したくないのが大きなツリー構造の一部分だけならば、
そこにリビジョンを貼り付ければ良いのです。
ソースを取り出す際に (1.4 などと) リビジョンを指定すれば、
そのリビジョンを貼り付けることができます。
以後、@samp{cvs update -A} によってタグを剥がすまで、
@code{cvs update} を実行しても
最新リビジョンに更新されることはありません。
同様にオプション @samp{-D} を @code{update} や @code{checkout} に使うと、
@dfn{貼り付いた日付} (@dfn{sticky date}) が設定され、
これ以降のコマンドにその日付が与えられます。

古いバージョンのファイルを取り出す際に、
タグを貼り付けたくない場合も多いと思います。
@code{checkout} や @code{update} にオプション @samp{-p} を付けると、
ファイルの内容が標準出力に送られるので、これを利用します。
例えば:

@example
$ cvs update -p -r 1.1 file1 >file1
===================================================================
Checking out file1
RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
VERS: 1.1
***************
$
@end example

しかし、あなたの尋ねていることが前の格納に戻す (この例では、
@file{file1} をリビジョン1.1であったときに戻す) 方法なら、これが一番簡
単な方法ではありません。その場合は @code{update -j} オプションを
@code{update} に付けるのが良いでしょう。さらなる議論は、@ref{Merging
two revisions} 参照。

@c ---------------------------------------------------------------------
@node Branching and merging
@chapter 枝とマージ
@cindex Branching
@cindex Merging
@cindex Copying changes
@cindex Main trunk and branches
@cindex Revision tree, making branches
@cindex Branches, copying changes between
@cindex Changes, copying between branches
@cindex Modifications, copying between branches

CVS では変更を @dfn{枝} (@dfn{branch}) として知られる別の開発ラインに
分けることができます。枝のファイルを変更しても、その変更は幹や他の枝に
は現れません。

後程、@dfn{マージ} (@dfn{merging}) によって変更をある枝から別の枝 (も
しくは幹) に移動することができます。マージはまず @code{cvs update -j}
を実行して、変更を作業ディレクトリに混ぜることから始まります。それから
そのリビジョンを格納することができ、こうして効果的に変更を別の枝にコピー
することができます。

@menu
* Branches motivation::         枝は何の役に立つか
* Creating a branch::           枝の作成
* Accessing branches::          枝の更新と取り出し
* Branches and revisions::      枝はリビジョン番号に反映される
* Magic branch numbers::        魔法の枝番号
* Merging a branch::            枝全体をマージする
* Merging more than once::      枝から何度もマージする
* Merging two revisions::       二つのリビジョン間の差分をマージする
* Merging adds and removals::   ファイルが追加/削除された場合はどうか?
* Merging and keywords::        キーワード置換による衝突を回避する
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Branches motivation
@section 枝は何の役に立つか
@cindex Branches motivation
@cindex What branches are good for
@cindex Motivation for branches

@c FIXME: this node mentions one way to use branches,
@c but it is by no means the only way.  For example,
@c the technique of committing a new feature on a branch,
@c until it is ready for the main trunk.  The whole
@c thing is generally speaking more akin to the
@c "Revision management" node although it isn't clear to
@c me whether policy matters should be centralized or
@c distributed throughout the relevant sections.
tc のリリース 1.0 ができたとしましょう。tc の開発を継続していて、数ヶ
月の間にリリース 1.1 を作成する計画を立てています。しばらくして、顧客
が致命的なバグについて文句を言ってくるようになりました。リリース 1.0を
取り出し (@pxref{Tags})、バグを見つけました (結局些細な修正に終わりま
した)。しかし、ソースの現在のリビジョンは流動的で、少くとも1ヶ月は安定
しない状態です。最新のソースに基づくバグ修正リリースはとても作成できま
せん。

この様な状況でするべきことは tc のリリース 1.0 の全てのファイルのリビ
ジョンツリーに基づく @dfn{枝} (@dfn{branch}) を作成することです。そう
すれば幹の邪魔をすることなく枝に修正を加えることができます。修正が終わっ
たときに、幹に取り込むか、枝に残しておくかを選択することができます。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Creating a branch
@section 枝の作成
@cindex Creating a branch
@cindex Branch, creating a
@cindex tag, creating a branch using
@cindex rtag, creating a branch using

@code{tag -b} で枝を作成することができます。例えば、作業コピーのところ
にいるとしましょう:

@example
$ cvs tag -b rel-1-0-patches
@end example

@c FIXME: we should be more explicit about the value of
@c having a tag on the branchpoint.  For example
@c "cvs tag rel-1-0-patches-branchpoint" before
@c the "cvs tag -b".  This points out that
@c rel-1-0-patches is a pretty awkward name for
@c this example (more so than for the rtag example
@c below).

これは作業コピーの現在のリビジョンに基づいた枝を別に作成し、その枝に名
前 @samp{rel-1-0-patches} を割当てます。

枝はリポジトリに作成されているのであって、作業コピーに作成されているの
ではないということを理解することは重要です。上記の例の様に、現在のリビ
ジョンに基づいた枝を作成することは、自動的に作業コピーを新しい枝に切り
換えることは @emph{しません}。それをする方法に関する情報は 
@ref{Accessing branches} を参照してください。

@code{rtag} を使って、作業コピーへの参照無しに枝を作ることもできます:

@example
$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
@end example

@samp{-r rel-1-0} はこの枝がタグ @samp{rel-1-0} に対応するリビジョンを
根とするということを指定します。最新のリビジョンである必要はありません 
-- 古いリビジョンから枝を生やすことが役に立つことがしばしばあります
(例えば、他の部分は安定していることが知られている過去のリリースのバグ
を修正するとき)。

@samp{tag} と同様に @samp{-b} フラグは @code{rtag} に枝を作成するよう
に指示します (単なるリビジョン名ではなく)。@samp{rel-1-0} に対応する数
字リビジョン番号はファイル毎に違うことを注意してください。

ですから、命令の完全な効果は新しい枝を作成することです -- モジュール 
@samp{tc} で、@samp{rel-1-0} でタグ付けされたリビジョンツリーを根元と
する -- @samp{rel-1-0-patches} という名前のものを。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Accessing branches
@section 枝のアクセス
@cindex Check out a branch
@cindex Retrieve a branch
@cindex Access a branch
@cindex Identifying a branch
@cindex Branch, check out
@cindex Branch, retrieving
@cindex Branch, accessing
@cindex Branch, identifying

2 つの方法のどちらかで枝を取得することができます: リポジトリから新しく
取り出すか、存在する作業コピーをその枝に切り換える方法です。

リポジトリから枝を取り出すには @samp{checkout} をフラグ @samp{-r} と、
その後に枝のタグ名を続けて起動します (@pxref{Creating a branch})。

@example
$ cvs checkout -r rel-1-0-patches tc
@end example

もしくは、既に作業コピーを持っていれば、@samp{update -r} で任意の枝に
切り換えることができます:

@example
$ cvs update -r rel-1-0-patches tc
@end example

もしくは、それと等価な:

@example
$ cd tc
$ cvs update -r rel-1-0-patches
@end example

作業コピーが元々幹にあったか他の枝にあったかは関係ありません -- 上のコ
マンドはそれを指定された名前の枝に切り換えます。普通の @samp{update}
コマンドと同様に、@samp{update -r} は全ての変更をマージし、衝突がどこ
で起こったかを知らせます。

一度特定の枝に結び付けられた作業コピーを手に入れると、指示しない限りそ
こに残り続けます。これは、作業コピーから格納された変更はその枝に新しい
リビジョンを加えますが、幹と他の枝には影響を及ぼさないということです。

@cindex Branches, sticky
作業コピーがどの枝であるかを知るために、コマンド @samp{status} を使う
ことができます。その出力で、@samp{Sticky tag} という名前の場所を探して
ください (@pxref{Sticky tags}) -- それは現在の作業ファイルに、もし枝が
あれば、それを教える @sc{cvs} の方法です:

@example
$ cvs status -v driver.c backend.c
===================================================================
File: driver.c          Status: Up-to-date

    Version:            1.7     Sat Dec  5 18:25:54 1992
    RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
    Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
    Sticky Date:        (none)
    Sticky Options:     (none)

    Existing Tags:
        rel-1-0-patches             (branch: 1.7.2)
        rel-1-0                     (revision: 1.7)

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

    Version:            1.4     Tue Dec  1 14:39:01 1992
    RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
    Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
    Sticky Date:        (none)
    Sticky Options:     (none)

    Existing Tags:
        rel-1-0-patches             (branch: 1.4.2)
        rel-1-0                     (revision: 1.4)
        rel-0-4                     (revision: 1.4)

@end example

それぞれのファイルの枝番号が違うという事実に混乱しないでください 
(それぞれ @samp{1.7.1} と @samp{1.4.2} です)。枝タグは同じ 
@samp{rel-1-0-patches} で、ファイルは実際に同じ枝にあります。番号は単
に枝が作られたときのそれぞれのファイルのリビジョン履歴を反映しています。
上の例では、この枝が作成される前に、@samp{driver.c} が 
@samp{backend.c} よりも多くの変更が成されたということを導き出すことが
できます。

枝番号が作成される方法の詳細は @ref{Branches and revisions} を参照して
ください。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Branches and revisions
@section 枝とリビジョン
@cindex Branch number
@cindex Number, branch
@cindex Revision numbers (branches)

普通はファイルのリビジョン履歴は線形増加です (@pxref{Revision
numbers}):

@example
       +-----+    +-----+    +-----+    +-----+    +-----+
       ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
       +-----+    +-----+    +-----+    +-----+    +-----+
@end example

しかし、@sc{cvs} は線形の開発に限られているわけではありません。@dfn{リ
ビジョン・ツリー} は @dfn{枝} に分割することができ、それぞれの枝は別に
維持された開発ラインです。枝になされた変更は簡単に幹に戻すことができま
す。

それぞれの枝には @dfn{枝番号} があり、ピリオドで分けられた奇数個の10進
整数から成ります。枝番号は枝が分岐した元の枝に対応するリビジョン番号に
整数を追加することによって作成されます。枝番号により、特定のリビジョン
から 1 つ以上の枝を枝分かれすることができます。

@need 3500
枝の全てのリビジョンは枝番号に普通の数字を追加することで形成されます。
下図に、前述の例から枝が発展した例を示します。

@example
@c This example used to have a 1.2.2.4 revision, which
@c might help clarify that development can continue on
@c 1.2.2.  Might be worth reinstating if it can be done
@c without overfull hboxes.
@group
                                                      +-------------+
                           Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
                                                    / +-------------+
                                                   /
                                                  /
                 +---------+    +---------+    +---------+
Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
               / +---------+    +---------+    +---------+
              /
             /
+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !
                !
                !   +---------+    +---------+    +---------+
Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
                    +---------+    +---------+    +---------+

@end group
@end example

@c --   However, at least for me the figure is not enough.  I suggest more
@c --   text to accompany it.  "A picture is worth a thousand words", so you
@c --   have to make sure the reader notices the couple of hundred words
@c --   *you* had in mind more than the others!

@c --   Why an even number of segments?  This section implies that this is
@c --   how the main trunk is distinguished from branch roots, but you never
@c --   explicitly say that this is the purpose of the [by itself rather
@c --   surprising] restriction to an even number of segments.

枝番号が作成される厳密な詳細は普通は気にしなくて良いのですが、以下が動
作の方法です: @sc{cvs} が枝番号を作成するときは、2 から始まる最初の未
使用の偶数を選びます。ですから、リビジョン 6.4 から枝を作成したいとき
は、それは 6.4.2 という番号になるでしょう。零で終わる全ての枝番号 
(6.4.0 のように) は @sc{cvs} の内部で使用されます (@pxref{Magic branch
numbers})。枝 1.1.1 は特別な意味を持ちます。@xref{Tracking sources}.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Magic branch numbers
@section 魔法の枝番号

@c Want xref to here from "log"?

この部分は @dfn{魔法の枝} (@dfn{magic brandh}) と呼ばれる @sc{cvs} の
機能を説明します。たいていの目的のためには魔法の枝を心配する必要はあり
ません。@sc{cvs} が代わりに扱ってくれます。しかし、特定の状況ではそれ
が見えていることもありますので、いくらか動作の仕方を知っていると役に立
つかもしれません。

表面的には、枝番号はドットで分けられた奇数個の10進の整数です。 
@xref{Revision numbers}.  しかし、これは真実の姿ではありません。
@sc{cvs} は能率のために、余分な 0 を右から2番目の位置に挿入することが
あります(1.2.3 は 1.2.0.3 となり、8.9.10.11.12 は 8.9.10.11.0.12 にな
ります)。

この魔法の枝と呼ばれるものを、@sc{cvs} はうまく隠しています。しかし、
完璧に隠し切れていないところも数ヶ所あります。

@itemize @bullet
@ignore
@c This is in ignore as I'm taking their word for it,
@c that this was fixed
@c a long time ago.  But before deleting this
@c entirely, I'd rather verify it (and add a test
@c case to the testsuite).
@item
@sc{cvs} 1.3 で、
魔法の枝番号が @code{cvs status} の出力に現われてしまう。
これは @sc{cvs} 1.3-s2 では修復されました。

@end ignore
@item
魔法の枝番号が @code{cvs log} の出力に現われてしまう。
@c What output should appear instead?

@item
@code{cvs admin} で枝のタグ名が指定できない。

@end itemize

@c Can CVS do this automatically the first time
@c you check something in to that branch?  Should
@c it?
@code{admin} コマンドを使用して、
@sc{rcs} が枝のタグ名を理解できるように再設定する方法があります。
@code{R4patches} というタグ名が、
ファイル @file{number.c} の枝 1.4.2 に付けられている場合
(魔法の枝番号は 1.4.0.2 です)、
次のようにします:

@example
$ cvs admin -NR4patches:1.4.2 numbers.c
@end example

この方法を用いる場合は、1つ以上のリビジョンが、
既に枝に格納されている必要があります。
タグに間違った番号を設定しないように、注意しなくてはいけません。
(実行以前にタグがどう設定されていたかを調べる方法はありません)。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Merging a branch
@section 枝全体をマージする
@cindex Merging a branch
@cindex -j (merging branches)

@code{update} コマンドに @samp{-j @var{branch}} フラグを付けると、
枝に加えられた変更を作業コピーに反映することができます。
@samp{-j @var{branch}} オプションが1つだけだと、
枝の分岐点と枝の最新リビジョン間の違いを 
(あなたの作業コピーに) マージします。

@cindex Join
@samp{-j} は、``join'' の略です。

@cindex Branch merge example
@cindex Example, branch merge
@cindex Merge, branch example
次のリビジョン・ツリーを考えます。

@example
+-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+
                !
                !
                !   +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                    +---------+    +---------+
@end example

@noindent
枝 1.2.2 には @samp{R1fix} というタグ (文字列) が付けられています。次
は @file{m.c} というファイル1つを含むモジュール @samp{mod} の例です。

@example
$ cvs checkout mod               # @r{最新のリビジョン 1.4 を取り出す}

$ cvs update -j R1fix m.c        # @r{枝で行なわれた変更(リビジョン 1.2}
                                 # @r{と 1.2.2.2 の差分)を作業コピーに追加}

$ cvs commit -m "Included R1fix" # @r{リビジョン 1.5 を作成}
@end example

マージ作業で衝突が起きることもありますが、衝突が起きた場合は、それを解
決してから新しいリビジョンを格納して下さい。 @xref{Conflicts example}.

もしソースファイルにキーワードがあれば (@pxref{Keyword substitution}),
本当に必要なものよりも余分に衝突を得るかもしれません。これを回避する方
法は @ref{Merging and keywords} を参照してください。

@code{checkout} コマンドでもフラグ @samp{-j @var{branch}} を使用できます。
以下の様にして上記と同じ効果を得ることができます:

@example
$ cvs checkout -j R1fix mod
$ cvs commit -m "Included R1fix"
@end example

@node Merging more than once
@section 枝から何度もマージする

前節の例を続けると、
現在のリビジョン・ツリーは次の様になっています:

@example
+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !                           *
                !                          *
                !   +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                    +---------+    +---------+
@end example

前節で枝 @samp{R1fix} を幹にマージした事を、ここでは星線で表します。

次に、枝 @samp{R1fix} で開発が続けられたと仮定します:

@example
+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !                           *
                !                          *
                !   +---------+    +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
                    +---------+    +---------+    +---------+
@end example

そしてこの新しい変更を幹にマージしたくなりました。
ここで再び @code{cvs update -j R1fix m.c} コマンドを用いた場合、
@sc{cvs} は既にマージされた変更点を重ねてマージしようとして、
望ましくない結果をもたらします。

そこで、
未だ幹にマージされてない変更点だけマージしたい旨を、
明示する必要があります。
これには、@samp{-j} オプションで二つのリビジョンを指定します。
@sc{cvs} は、
最初のリビジョンから次のリビジョンまでの変更をマージします。
例えば、この場合、最も簡単な方法は次の様になります。

@example
cvs update -j 1.2.2.2 -j R1fix m.c    # @r{1.2.2.2 から、枝 R1fix の}
                                      # @r{先頭までの変更をマージする}
@end example

この方法の問題点は、リビジョン 1.2.2.2 を自分で指定する必要がある事です。
最後にマージが行われた日時を使用する方が、少しましでしょう:

@example
cvs update -j R1fix:yesterday -j R1fix m.c
@end example

さらに良いのは、
変更点を幹にマージする度に、
枝 @samp{R1fix} にタグを振っておき、
後でマージする時にそのタグを用いる方法です:

@example
cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Merging two revisions
@section 二つのリビジョン間の差分をマージする
@cindex Merging two revisions
@cindex Revisions, merging differences between
@cindex Differences, merging

@code{update} (と @code{checkout}) コマンドに @samp{-j @var{revision}} 
フラグを二つ付けることで、任意の二つのリビジョン間の違いをあなたの作業
コピーに加えることができます。

@cindex Undoing a change
@cindex Removing a change
@example
$ cvs update -j 1.5 -j 1.3 backend.c
@end example

@noindent
このようにするとリビジョン 1.3 と 1.5 間の変更を
全て@emph{元に戻す}ことになります。
リビジョンを指定する順序に十分注意して下さい!

複数のファイルに対してこのオプションを指定する場合は、
ファイルごとにリビジョン番号が全く異なるであろうことを思い出して下さい。
複数のファイルを操作する場合には、
リビジョン番号ではなく、
必ずタグ名を用いるようにして下さい。

@cindex Restoring old version of removed file
@cindex Resurrecting old version of dead file
2つ @samp{-j} オプションを指定すると、追加や削除を元に戻すこともできま
す。例えば、リビジョン1.1として存在していた @file{file1} という名前の
ファイルがあり、それを消去した (つまり、死んだリビジョン1.2を追加しま
した) としましょう。今、またそれを以前と同じ内容で追加したいと思ったと
しましょう。これがそれをする方法です:

@example
$ cvs update -j 1.2 -j 1.1 file1
U file1
$ cvs commit -m test
Checking in file1;
/tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
new revision: 1.3; previous revision: 1.2
done
$
@end example

@node Merging adds and removals
@section ファイルの追加や削除もマージできる

マージする変更点に、ファイルの削除や追加が伴なう場合でも、
@code{update -j} は削除や追加を反映します。

@c FIXME: This example needs a lot more explanation.
@c We also need other examples for some of the other
@c cases (not all--there are too many--as long as we present a
@c coherent general principle).
実行例:
@example
cvs update -A
touch a b c
cvs add a b c ; cvs ci -m "added" a b c
cvs tag -b branchtag
cvs update -r branchtag
touch d ; cvs add d
rm a ; cvs rm a
cvs ci -m "added d, removed a"
cvs update -A
cvs update -jbranchtag
@end example

これらのコマンドが実行され、@samp{cvs commit} がなされた後、幹ではファ
イル @file{a} は削除され、ファイル@file{d} は追加されます
@c (which was determined by trying it)

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Merging and keywords
@section マージとキーワード
@cindex Merging, and keyword substitution
@cindex Keyword substitution, and merging
@cindex -j (merging branches), and keyword substitution
@cindex -kk, to avoid conflicts during a merge

キーワードを含むファイルをマージすると (@pxref{Keyword substitution}、
通常マージの間に数多くの衝突が起こります。なぜなら、キーワードはマージ
中のリビジョンで違う様に展開されているからです。

ですから、しばしばマージのコマンド行で @samp{-kk} (@pxref{Substitution
modes}) スイッチを指定したいと思うでしょう。キーワードの展開された値を
展開するのでは無く、キーワードの名前だけを置換することによって、このオ
プションはマージしているリビジョンがそれぞれ同じことを確実にして、見せ
かけの衝突を回避します。

例えば、このようなファイルがあるとしましょう:

@example
       +---------+
      _! 1.1.2.1 !   <-  br1
     / +---------+
    /
   /
+-----+    +-----+
! 1.1 !----! 1.2 !
+-----+    +-----+
@end example

そして、作業ディレクトリは現在幹 (revision 1.2) にあります。そうすると、
以下の結果をマージから得るでしょう:

@example
$ cat file1
key $@asis{}Revision: 1.2 $
. . .
$ cvs update -j br1
U file1
RCS file: /cvsroot/first-dir/file1,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into file1
rcsmerge: warning: conflicts during merge
$ cat file1
@asis{}<<<<<<< file1
key $@asis{}Revision: 1.2 $
@asis{}=======
key $@asis{}Revision: 1.1.2.1 $
@asis{}>>>>>>> 1.1.2.1
. . .
@end example

これで起こったことは、merge が 1.1 と 1.1.2.1 間の差分を作業ディレクト
リにマージしようとした、ということです。キーワードは@code{Revision:
1.1} から @code{Revision: 1.1.2.1} へと変わっているので、@sc{cvs} はそ
の変更を作業ディレクトリにマージしようとして、それは作業ディレクトリが 
@code{Revision: 1.2} を含んでいた、という事実と衝突をしました。

これは @samp{-kk} を使用したときにに起こることです:

@example
$ cat file1
key $@asis{}Revision: 1.2 $
. . .
$ cvs update -kk -j br1
U file1
RCS file: /cvsroot/first-dir/file1,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into file1
$ cat file1
key $@asis{}Revision$
. . .
@end example

ここでは、リビジョン 1.1 とリビジョン 1.1.2.1 の両方ともが 
@code{Revision} に展開され、それらの変更を作業コピーにマージすることは
何も変更しません。ですから、衝突は起こりません。

しかしながら、マージで @samp{-kk} を使うことには一つ大きな注意がありま
す。つまり、それは普通は @sc{cvs} が使っていたであろうキーワード展開の
様式を上書きします。特に、これは、バイナリファイルのために様式が 
@samp{-kb} であったときに問題になります。ですので、リポジトリにバイナ
リファイルがあるときは、@samp{-kk} を使用するよりは、衝突に対処する必
要があるでしょう。

@ignore
The following seems rather confusing, possibly buggy,
and in general, in need of much more thought before it
is a recommended technique.  For one thing, does it
apply on Windows as well as on Unix?

Unchanged binary files will undergo the same keyword substitution
but will not be checked in on a subsequent
@code{cvs commit}.  Be aware that binary files containing keyword
strings which are present in or below the working directory
will most likely remain corrupt until repaired, however.  A simple 
@code{cvs update -A} is sufficient to fix these otherwise unaltered binary files
if the merge is being done to the main branch but
this must be done after the merge has been committed or the merge itself
will be lost.

For Example:
@example
cvs update -Akk -jbranchtag
cvs commit
cvs update -A
@end example

@noindent
will update the current directory from the main trunk of the
repository, substituting the base keyword strings for keywords,
and merge changes made on the branch @samp{branchtag} into the new
work files, performing the same keyword substitution on that file set before
comparing the two sets.  The final @code{cvs update -A} will restore any
corrupted binary files as well as resetting the sticky @samp{-kk} tags which
were present on the files in and below the working directory.
Unfortunately, this doesn't work as well with an arbitrary branch tag, as the
@samp{-r @var{branchtag}} switch does not reset the sticky @samp{-kk}
switches attached to the working files as @samp{-A} does.  The workaround
for this is to release the working directory after the merge has been
committed and check it out again.
@end ignore

@c ---------------------------------------------------------------------
@node Recursive behavior
@chapter 再帰的動作
@cindex Recursive (directory descending)
@cindex Directory, descending
@cindex Descending directories
@cindex Subdirectories

ほとんど全ての @sc{cvs} のコマンドは、
ディレクトリを引数に取ったときに再帰的に動作します。
例えば、次のディレクトリ構造を考えます。

@example
      @code{$HOME}
        |
        +--@t{tc}
        |   |
            +--@t{CVS}
            |      (内部 @sc{cvs} ファイル)
            +--@t{Makefile}
            +--@t{backend.c}
            +--@t{driver.c}
            +--@t{frontend.c}
            +--@t{parser.c}
            +--@t{man}
            |    |
            |    +--@t{CVS}
            |    |  (内部 @sc{cvs} ファイル)
            |    +--@t{tc.1}
            |
            +--@t{testing}
                 |
                 +--@t{CVS}
                 |  (内部 @sc{cvs} ファイル)
                 +--@t{testpgm.t}
                 +--@t{test2.t}
@end example

@noindent
現在のディレクトリが @samp{tc} であれば、
以下が成立します:

@itemize @bullet
@item
@samp{cvs update testing} は

@example
cvs update testing/testpgm.t testing/test2.t
@end example
と等価です。

@item
@samp{cvs update testing man} は
サブディレクトリ中の全てのファイルを更新します。

@item
@samp{cvs update .} 又は @samp{cvs update} は、
ディレクトリ @code{tc} 中の全てのファイルを更新します。
@end itemize

引数を付けない @code{update} コマンドは現在の作業ディレクトリと全ての
サブディレクトリを更新します。言い替えると、@file{.} は @code{update} 
の既定引数です。これは @code{update} コマンドだけではなく、たいていの 
@sc{cvs} のコマンドにも当てはまります。

@samp{-l} オプションを付けることによって、
@sc{cvs} の再帰的な動作を抑止することができます。
逆に、@samp{-R} オプションは @file{~/.cvsrc} で @samp{-l} が指定されて
いるときに再帰的動作を強制するために使うことができます
(@pxref{~/.cvsrc})。

@example
$ cvs update -l         # @r{サブディレクトリのファイルは更新しない。}
@end example

@c ---------------------------------------------------------------------
@node Adding and removing
@chapter ファイルとディレクトリの追加、削除、改名

プロジェクトの最中では、よく新しいファイルを追加します。削除や改名、も
しくはディレクトリも同様です。心に留めておく総合的な概念は、元に戻せな
い変更をする代わりに、存在するファイルの修正のように、@sc{cvs} に変更
が発生したという事実を記録させたい、ということです。@sc{cvs} でこれを
する厳密な機構は状況に依り異ります。

@menu
* Adding files::                ファイルの追加
* Removing files::              ファイルの削除
* Removing directories::        ディレクトリの削除
* Moving files::                ファイルの移動と改名
* Moving directories::          ディレクトリの移動と改名
@end menu

@node Adding files
@section ディレクトリにファイルを加える
@cindex Adding files

ディレクトリにファイルを加える手順を説明します。

@itemize @bullet
@item
ディレクトリの作業コピーが必要です。@xref{Getting the source}.

@item
ディレクトリの作業コピーの中に、
新しいファイルを作ります。

@item
@samp{cvs add @var{filename}} を用いて、
バージョン管理に加えたいファイルを @sc{cvs} に伝えます。
ファイルがバイナリ・データを含んでいる場合には、
@samp{-kb} を指定して下さい (@pxref{Binary files})。

@item
@samp{cvs commit @var{filename}} を用いて、
実際にリポジトリにファイルを格納します。
この手順を行なうまでは、他の開発者はファイルを見ることができません。
@end itemize

@code{add} コマンドは、
新しいディレクトリを加える場合にも使用します。
@c FIXCVS and/or FIXME: Adding a directory doesn't
@c require the commit step.  This probably can be
@c considered a CVS bug, but it is possible we should
@c warn people since this behavior probably won't be
@c changing right away.

他のほとんどのコマンドと異なり、
@code{add} コマンドは再帰的に動作しません。
@samp{cvs add foo/bar} とタイプすることさえできません。
代りに、
次のようにする必要があります。
@c FIXCVS: This is, of course, not a feature.  It is
@c just that no one has gotten around to fixing "cvs add
@c foo/bar".

@example
$ cd foo
$ cvs add bar
@end example

@cindex add (subcommand)
@deffn コマンド {cvs add} [@code{-k} kflag] [@code{-m} message] files @dots{}

@var{files} が加えられた事をリポジトリに伝えます。
@code{add} で指定するファイルやディレクトリは、
現在のディレクトリに存在している必要があります。
新しいディレクトリ階層の全てをリポジトリに加える場合は 
(例えばサード・パーティーからのファイル等)、
代りに @code{import} コマンドを使用した方が良いでしょう。@xref{import}.

内容を @code{commit} で格納するまで、
ここで加えたファイルは実際にはリポジトリに置かれません。
@code{remove} コマンドで削除されたファイルに対して、
@code{commit} を発行する前に @code{add} を実行した場合、
@code{remove} が無効になります。
例は @xref{Removing files}.

オプション @samp{-k} には、
このファイルを取り出すときの置換モードを指定します。
詳細は @ref{Substitution modes} 参照。

@c As noted in BUGS, -m is broken client/server (Nov
@c 96).  Also see testsuite log2-* tests.
@samp{-m} オプションには、ファイルの説明文を記述します。
(ログ情報を記録する設定ならば)この説明文が
ファイル @file{history} に記録されます (@pxref{history file})。
またファイルを格納する際、リポジトリの履歴ファイルにも記録されます。
この説明文は @code{log} コマンドの出力で確認できます。
変更するには @samp{admin -t} を用います。@xref{admin}.
フラグ @samp{-m @var{description}} を省略した場合、
空の文字列が使用され、説明を記述するように促されることはありません。
@end deffn

例えば、以下のコマンドでファイル @file{backend.c} が
リポジトリに加えられます:

@c This example used to specify
@c     -m "Optimizer and code generation passes."
@c to the cvs add command, but that doesn't work
@c client/server (see log2 in sanity.sh).  Should fix CVS,
@c but also seems strange to document things which
@c don't work...
@example
$ cvs add backend.c
$ cvs commit -m "Early version. Not yet compilable." backend.c
@end example

加えたファイルは、作業中の枝だけに加えられます 
(@pxref{Branching and merging})。
他の枝にも加えたい場合は、後でマージすることができます 
(@pxref{Merging adds and removals})。
@c Should we mention that earlier versions of CVS
@c lacked this feature (1.3) or implemented it in a buggy
@c way (well, 1.8 had many bugs in cvs update -j)?
@c Should we mention the bug/limitation regarding a
@c file being a regular file on one branch and a directory
@c on another?
@c FIXME: This needs an example, or several, here or
@c elsewhere, for it to make much sense.
@c Somewhere we need to discuss the aspects of death
@c support which don't involve branching, I guess.
@c Like the ability to re-create a release from a tag.

@c ---------------------------------------------------------------------
@node Removing files
@section ファイルを削除する
@cindex Removing files
@cindex Deleting files

@c FIXME: this node wants to be split into several
@c smaller nodes.  Could make these children of
@c "Adding and removing", probably (death support could
@c be its own section, for example, as could the
@c various bits about undoing mistakes in adding and
@c removing).
ディレクトリは変わります。
新しいファイルが加えられ、古いファイルが削除されます。
しかし、モジュールの古いバージョンの、
正確なコピーを復元できるようにしておきたいと思うでしょう。

ここでは、モジュールからファイルを削除した後も、
古いバージョンの復元を可能にする手順を説明します:

@itemize @bullet
@c FIXME: should probably be saying something about
@c having a working directory in the first place.
@item
未格納の修正がファイルに残ってないことを確認する必要があります。
確認方法は @xref{Viewing differences}.
また @code{status} や @code{update} といった
コマンドを使用しても確認できます。
修正を格納せずにファイルを消した場合、
当然ですが以前の状態に復元することはできません。

@item
モジュールの作業コピーからファイルを削除します。
例えば、@code{rm} などを使っても良いでしょう。

@item
ファイルを本当に削除するという意思を @sc{cvs} に伝えるために、
@samp{cvs remove @var{filename}} を使います。

@item
リポジトリからファイルを実際に削除するために、
@samp{cvs commit @var{filename}} を使います。
@end itemize

@c FIXME: Somehow this should be linked in with a more
@c general discussion of death support.  I don't know
@c whether we want to use the term "death support" or
@c not (we can perhaps get by without it), but we do
@c need to discuss the "dead" state in "cvs log" and
@c related subjects.  The current discussion is
@c scattered around, and not xref'd to each other.
@c FIXME: I think this paragraph wants to be moved
@c later down, at least after the first example.
ファイルの削除を格納する場合、@sc{cvs} は、
ファイルがもう無いという事実を記録します。
ファイルが他の枝に存在していても良いし、
後で別のファイルを同じ名前で加えても構いません。
@code{checkout} や @code{update} に指定する
オプション @samp{-r} や @samp{-D} に応じて、
@sc{cvs} が正しくファイルを作成したり、しなかったりします。

@c FIXME: This style seems to clash with how we
@c document things in general.
@cindex Remove (subcommand)
@deffn コマンド {cvs remove} [options] files @dots{}

ファイルが削除された事実をリポジトリに伝えます 
(作業ディレクトリから未削除のファイルは処理されません)。
このコマンドを実行しても、リポジトリのファイルは、
削除が格納されるまで実際には削除されません。
オプションの完全な一覧は @ref{Invoking CVS} を参照してください。
@end deffn

以下に、幾つかファイルを削除する例を挙げます:

@example
$ cd test
$ rm *.c
$ cvs remove
cvs remove: Removing .
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files"
cvs commit: Examining .
cvs commit: Committing .
@end example

利便性のために、@samp{-f} オプションを指定することでファイルの削除と 
@code{cvs remove} を一度に行うことができます。例えば、上の例はこのよう
にすることもできます:

@example
$ cd test
$ cvs remove -f *.c
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files"
cvs commit: Examining .
cvs commit: Committing .
@end example

ファイルに @code{remove} を実行したけれど、
格納前に気が変わったのなら、@code{add} コマンドを用いて、
簡単にファイルを復活させることができます。
@ignore
@c is this worth saying or not?  Somehow it seems
@c confusing to me.
もちろん、作業ディレクトリからファイルのコピーを削除しましたので、
@sc{cvs} は必ずしも @code{remove} を実行する前のファイルの内容に戻すわ
けではありません。代わりにリポジトリからもう一度ファイルを取得します。
@end ignore

@c FIXME: what if you change your mind after you commit
@c it?  (answer is also "cvs add" but we don't say that...).
@c We need some index entries for thinks like "undoing
@c removal" too.

@example
$ ls
CVS   ja.h  oj.c
$ rm oj.c
$ cvs remove oj.c
cvs remove: scheduling oj.c for removal
cvs remove: use 'cvs commit' to remove this file permanently
$ cvs add oj.c
U oj.c
cvs add: oj.c, version 1.1.1.1, resurrected
@end example

@code{remove} コマンドを実行する前に失敗に気付いた場合、
@code{update} コマンドを用いてファイルを復活できます:

@example
$ rm oj.c
$ cvs update oj.c
cvs update: warning: oj.c was lost
U oj.c
@end example

削除したファイルは、作業中の枝だけから削除されます 
(@pxref{Branching and merging})。
他の枝からも削除したい場合は、後でマージすることができます 
(@pxref{Merging adds and removals})。

@node Removing directories
@section ディレクトリを削除する
@cindex removing directories
@cindex directories, removing

概念上では、ディレクトリの削除はファイルの削除と似ています---現在の作
業ディレクトリからそのディレクトリを消したいけれど、ディレクトリが存在
した古いリリースも取得できるようにしたい、と思うでしょう。

ディレクトリを削除する方法は、その中の全てのファイルを削除することです。
ディレクトリ自身は削除しません。そうする方法はありません。代わりに、
@code{cvs update}, @code{cvs checkout}, @code{cvs export} に @samp{-P} 
オプションを指定して、作業ディレクトリから空のディレクトリを削除するよ
うにします。おそらく最良の方法は常に @samp{-P} を指定することです。空
のディレクトリが欲しければ、削除されないように、ダミーファイルを作って
ください (例えば、 @file{.keepme})。

@c I'd try to give a rationale for this, but I'm not
@c sure there is a particularly convincing one.  What
@c we would _like_ is for CVS to do a better job of version
@c controlling whether directories exist, to eliminate the
@c need for -P and so that a file can be a directory in
@c one revision and a regular file in another.
@code{checkout} と @code{export} の @samp{-r} と @samp{-D} のオプショ
ンでは @samp{-P} が暗黙に含まれていることに注意してください。この方法
により @sc{cvs} は正しくディレクトリを作ることができ、又、取り出した特
定のバージョンのそのディレクトリにファイルがあるかどうかに左右されなく
なります。

@c ---------------------------------------------------------------------
@node Moving files
@section ファイルの改名と移動
@cindex Moving files
@cindex Renaming files
@cindex Files, moving

ファイルを他のディレクトリに移動したり、改名したりするのは、
難しくはありません。
しかし、難解な方法でこれを実現するものがあります。
(ディレクトリの移動と改名は、
より困難です。@xref{Moving directories}.)。

以降の例では、
@var{old} というファイルを @var{new} に改名します。

@menu
* Outside::                     通常の改名方法
* Inside::                      小技を使った別の方法
* Rename by copying::           別の小技を使った方法
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Outside
@subsection 通常の改名方法

@c More rename issues.  Not sure whether these are
@c worth documenting; I'm putting them here because
@c it seems to be as good a place as any to try to
@c set down the issues.
@c * "cvs annotate" will annotate either the new
@c file or the old file; it cannot annotate _each
@c line_ based on whether it was last changed in the
@c new or old file.  Unlike "cvs log", where the
@c consequences of having to select either the new
@c or old name seem fairly benign, this may be a
@c real advantage to having CVS know about renames
@c other than as a deletion and an addition.

ファイルを移動する通常の方法は、
@var{old} を @var{new} にコピーして、
普通の @sc{cvs} コマンドで @var{old} をリポジトリから削除し、
@var{new} を加えることです。
@c The following sentence is not true: one must cd into
@c the directory to run "cvs add".
@c  (Both @var{old} and @var{new} could
@c contain relative paths, for example @file{foo/bar.c}).

@example
$ mv @var{old} @var{new}
$ cvs remove @var{old}
$ cvs add @var{new}
$ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new}
@end example

これがファイルを移動する最も単純な方法であり、
間違いがなく、この操作の履歴も記録されます。
このファイルの履歴を利用する際、
古い名前か、新しい名前のどちらかを指定して、
履歴のどの部分が欲しいのか知らせなくてはいけません。
例えば、@code{cvs log @var{old}} を実行しても、
改名が行なわれた時までのログ情報しか得られません。

@var{new} が格納される場合には、
リビジョン番号は普通は 1.1 から再び始まります。
それが嫌ならば、格納時にオプション @samp{-r rev}
を用いると良いでしょう。詳しい情報は @ref{Assigning revisions} を参照
してください。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Inside
@subsection 履歴ファイルを移動する

この方法は、リポジトリ中のファイルの移動を含むため、
さらに危険です。
この節を全部読んでから実行して下さい。

@example
$ cd $CVSROOT/@var{dir}
$ mv @var{old},v @var{new},v
@end example

@noindent
利点:

@itemize @bullet
@item
変更の記録が完全に保たれる。

@item
リビジョン番号に影響がない。
@end itemize

@noindent
欠点:

@itemize @bullet
@item
リポジトリから、古いリリースを簡単に復元できない。
(改名される以前のリビジョンでもファイルの名前が @var{new} になる。)

@item
ファイルがいつ改名されたかの記録がない。

@item
ファイルの移動の最中に、
誰かが履歴ファイルにアクセスした場合、酷いことが起きる。
あなたがファイルを移動させている間は、
誰にも @sc{cvs} コマンドを発行させてはいけません。
@end itemize

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Rename by copying
@subsection 履歴ファイルをコピーする

この方法も、リポジトリ中のファイルの移動を含みます。
欠点が無い訳ではありませんが、安全です。

@example
# @r{リポジトリ中の @sc{rcs} ファイルをコピーする}
$ cd $CVSROOT/@var{dir}
$ cp @var{old},v @var{new},v
# @r{以前のファイルを削除する}
$ cd ~/@var{dir}
$ rm @var{old}
$ cvs remove @var{old}
$ cvs commit @var{old}
# @r{@var{new} の全てのタグを削除する}
$ cvs update @var{new}
$ cvs log @var{new}             # @r{枝でないタグ名を思い出す}
$ cvs tag -d @var{tag1} @var{new}
$ cvs tag -d @var{tag2} @var{new}
@dots{}
@end example

タグを削除することで、
以前のリビジョンを復元することができます。

@noindent
利点:

@itemize @bullet
@item
@c FIXME: Is this true about -D now that we have death
@c support?  See 5B.3 in the FAQ.
リビジョンの取得に @samp{-D@var{date}} を使わないで、
@samp{-r@var{tag}} を使う限り、以前のリビジョンのファイルを正しく復元
できる。

@item
変更の記録を完全に維持できる。

@item
リビジョン番号に影響しない。
@end itemize

@noindent
欠点:

@itemize @bullet
@item
改名の前後で履歴を辿ることが困難である。

@ignore
@c Is this true?  I don't see how the revision numbers
@c _could_ start over, when new,v is just old,v with
@c the tags deleted.
@c If there is some need to reinstate this text,
@c it is "usually 1.1", not "1.0" and it needs an
@c xref to Assigning revisions
@item
@samp{-r rev} フラグを付けて @code{commit} しないと、
@var{new} のリビジョン番号はまた 1.0 から始まる
(@pxref{commit options})。
@end ignore
@end itemize

@c ---------------------------------------------------------------------
@node Moving directories
@section ディレクトリの改名と移動
@cindex Moving directories
@cindex Renaming directories
@cindex Directories, moving

ディレクトリの改名と移動の普通の方法は @ref{Outside} で説明されている
ようにその中のそれぞれのファイルを改名もしくは移動することです。それか
ら @ref{Removing directories} に説明されているように @samp{-P} オプショ
ンを付けて取り出します。

本当にリポジトリの中身を変更してディレクトリを改名したり削除したければ、
次のようにしてください:

@enumerate
@item
ディレクトリを改名する前に、
ディレクトリの作業コピーを取り出している全ての人に、
その旨を知らせます。
次のステップに進む前に、彼等全員が変更内容を格納し、
作業コピーを削除しなければなりません。

@item
リポジトリ中のディレクトリを改名します。

@example
$ cd $CVSROOT/@var{parent-dir}
$ mv @var{old-dir} @var{new-dir}
@end example

@item
@sc{cvs} の管理用ファイルを修正します。
(例えばモジュール名を改名する場合等)。

@item
再び取り出して作業を続けられることを、
全員に知らせます。

@end enumerate

誰かが作業コピーを消さずに持っていた場合、
彼がリポジトリから消されたディレクトリを削除するまで、
彼の発行する @sc{cvs} コマンドは無視されます。

ディレクトリを移動させるよりは、
ディレクトリ中のファイルを移動させる方を推奨します。
ディレクトリを移動させれば、
ディレクトリ名に依存している古いリリースを正確に復元する事は、
ほとんど不可能になります。

@c ---------------------------------------------------------------------
@node History browsing
@chapter 履歴の閲覧
@cindex History browsing
@cindex Traceability
@cindex Isolation

@ignore
@c This is too long for an introduction (goal is
@c one 20x80 character screen), and also mixes up a
@c variety of issues (parallel development, history,
@c maybe even touches on process control).

@c -- @quote{To lose ones history is to lose ones soul.}
@c -- ///
@c -- ///Those who cannot remember the past are condemned to repeat it.
@c -- ///               -- George Santayana
@c -- ///

@sc{cvs} tries to make it easy for a group of people to work
together.  This is done in two ways:

@itemize @bullet
@item
Isolation---You have your own working copy of the
source.  You are not affected by modifications made by
others until you decide to incorporate those changes
(via the @code{update} command---@pxref{update}).

@item 
Traceability---When something has changed, you can
always see @emph{exactly} what changed.
@end itemize

There are several features of @sc{cvs} that together lead
to traceability:

@itemize @bullet
@item
Each revision of a file has an accompanying log
message.

@item
All commits are optionally logged to a central history
database.

@item
Logging information can be sent to a user-defined
program (@pxref{loginfo}).
@end itemize

@c -- More text here.

This chapter should talk about the history file, the
@code{log} command, the usefulness of ChangeLogs
even when you run @sc{cvs}, and things like that.

@end ignore

@c kind of lame, in a lot of ways the above text inside
@c the @ignore motivates this chapter better
何時、誰が、どのように、どのファイルを変更したか、
といったバージョン管理の履歴を @sc{cvs} を使って保存してきたならば、
様々な機構を用いてこの履歴を調べることができます。

@c FIXME: should also be talking about how you look at
@c old revisions (e.g. "cvs update -p -r 1.2 foo.c").
@menu
* log messages::                ログ・メッセージ
* history database::            履歴データベース
* user-defined logging::        ログ方法を使用者自身が設定する
* annotate::                    各行がどのリビジョンで変更されたか?
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node log messages
@section ログ・メッセージ

@c FIXME: @xref to place where we talk about how to
@c specify message to commit.
ファイルを格納する時には、必ずログ・メッセージを記述します。

@c FIXME: bring the information here, and get rid of or
@c greatly shrink the "log" node.
各リビジョンの格納時に記述されたログ・メッセージを調べる場合、
@code{cvs log} コマンドを使用します (@pxref{log})。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node history database
@section 履歴データベース

@c FIXME: bring the information from the history file
@c and history nodes here.  Rewrite it to be motivated
@c better (start out by clearly explaining what gets
@c logged in history, for example).
様々な @sc{cvs} の実行履歴を記録するために、
ファイル @file{history} が使用できます (@pxref{history file})。
ファイル @file{history} の情報を検索するには、
@code{cvs history} コマンドを使用して下さい (@pxref{history})。
@c
@c The history database has many problems:
@c * It is very unclear what field means what.  This
@c could be improved greatly by better documentation,
@c but there are still non-orthogonalities (for
@c example, tag does not record the "repository"
@c field but most records do).
@c * Confusion about files, directories, and modules.
@c Some commands record one, some record others.
@c * File removal is not logged.  There is an 'R'
@c record type documented, but CVS never uses it.
@c * Tags are only logged for the "cvs rtag" command,
@c not "cvs tag".  The fix for this is not completely
@c clear (see above about modules vs. files).
@c * Are there other cases of operations that are not
@c logged?  One would hope for all changes to the
@c repository to be logged somehow (particularly
@c operations like tagging, "cvs admin -k", and other
@c operations which do not record a history that one
@c can get with "cvs log").  Operations on the working
@c directory, like export, get, and release, are a
@c second category also covered by the current "cvs
@c history".
@c * The history file does not record the options given
@c to a command.  The most serious manifestation of
@c this is perhaps that it doesn't record whether a command
@c was recursive.  It is not clear to me whether one
@c wants to log at a level very close to the command
@c line, as a sort of way of logging each command
@c (more or less), or whether one wants
@c to log more at the level of what was changed (or
@c something in between), but either way the current
@c information has pretty big gaps.
@c * Further details about a tag--like whether it is a
@c branch tag or, if a non-branch tag, which branch it
@c is on.  One can find out this information about the
@c tag as it exists _now_, but if the tag has been
@c moved, one doesn't know what it was like at the time
@c the history record was written.
@c * Whether operating on a particular tag, date, or
@c options was implicit (sticky) or explicit.
@c
@c Another item, only somewhat related to the above, is a
@c way to control what is logged in the history file.
@c This is probably the only good way to handle
@c different people having different ideas about
@c information/space tradeoffs.
@c
@c It isn't really clear that it makes sense to try to
@c patch up the history file format as it exists now to
@c include all that stuff.  It might be better to
@c design a whole new CVSROOT/nhistory file and "cvs
@c nhistory" command, or some such, or in some other
@c way trying to come up with a clean break from the
@c past, which can address the above concerns.  Another
@c open question is how/whether this relates to
@c taginfo/loginfo/etc.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node user-defined logging
@section ログ方法を使用者自身が設定する

@c FIXME: should probably also mention the fact the -l
@c global option can disable most of the mechanisms
@c discussed here (why?  What is the -l global option for?).
@c
@c FIXME: probably should centralize this information
@c here, at least to some extent.  Maybe by moving the
@c loginfo, etc., nodes here and replacing
@c the "user-defined logging" node with one node for
@c each method.
@sc{cvs} を用いた様々な作業の履歴は、
利用者自身が選択する方法で記録されます。
@sc{cvs} は、様々な場面でスクリプトを実行し、
この機構を実現します。
これらのスクリプトには、
ログ・ファイルに情報を追記したり、
開発者グループにメールを送ったり、
特定のニュース・グループに記事を投稿したりするものがあります。
格納時のログ方法は @file{loginfo} で設定します(@pxref{loginfo})。
@c FIXME: What is difference between doing it in the
@c modules file and using loginfo/taginfo?  Why should
@c user use one or the other?
commit, checkout, export, tag
等を実行した時のログ方法は、
各々オプション @samp{-i}, @samp{-o}, @samp{-e}, @samp{-t} を用いて、
modules ファイルに設定できます。
これらのスクリプトほどのものは必要としない使用者にも、
@code{cvs watch add} コマンドを使用して、
様々な告知をする弾力的な方法を提供します(@pxref{Getting Notified})。
この方法は @code{cvs watch on} を使用していない場合でも利用できます。

@cindex taginfo
@cindex exit status, of taginfo
誰かが @code{tag} か @code{rtag} コマンドを実行した時に
実行されるプログラムを、@file{taginfo} ファイルに設定します。
管理用ファイルの標準書式に従い(@pxref{Administrative files})、
@file{taginfo} の各行には、
正規表現に続いて実行されるコマンドが記述されます。
コマンドに渡される引数を順に挙げると、
@var{タグ名}, @var{操作}(@code{tag} なら @code{add},
@code{tag -F} なら @code{mov}, @code{tag -d} なら @code{del}),
@var{リポジトリ}, 残りは全て @var{ファイル名} と @var{リビジョン} の組
です。
フィルタ・プログラムが非零で終了した場合は、
タグ処理が中止されます。

これは taginfo を使って tag と rtag コマンドのログを取る例です。
taginfo ファイルには以下のものを入れます:

@example
ALL /usr/local/cvsroot/CVSROOT/loggit
@end example

@file{/usr/local/cvsroot/CVSROOT/loggit} は以下のスクリプトになってい
ます:

@example
#!/bin/sh
echo "$@@" >>/home/kingdon/cvsroot/CVSROOT/taglog
@end example

@node annotate
@section コマンド annotate
@cindex annotate (subcommand)

@deffn コマンド {cvs annotate} [@code{-flR}] [@code{-r rev}|@code{-D date}] files @dots{}

@var{files} で指定された各ファイルについて、
幹の先頭リビジョンの内容と、各行が最後に修正された時の情報を、
併せて表示します。
以下に例示します:

@example
$ cvs annotate ssfile
Annotations for ssfile
***************
1.1          (mary     27-Mar-96): ssfile line 1
1.2          (joe      28-Mar-96): ssfile line 2
@end example

ファイル @file{ssfile} は現在 2行から成り、
@code{ssfile line 1} という行は 3月 27日に @code{mary} が格納しました。
そして 3月 28日に @code{joe} が、
@code{ssfile line 1} という行を修正せずに、
@code{ssfile line 2} という行を格納しました。
この報告では、削除されたり修正された行については何も分らないので、
@code{cvs diff} を用いる必要があるでしょう(@pxref{diff})。

@end deffn

@code{cvs annotate} へのオプションは @ref{Invoking CVS} で一覧にされて
ていて、annotate するファイルとリビジョンを選択するために使うことがで
きます。オプションは @ref{Common options} でより詳しく説明されています。

@c FIXME: maybe an example using the options?  Just
@c what it means to select a revision might be worth a
@c few words of explanation ("you want to see who
@c changed this line *before* 1.4"...).

@c ---------------------------------------------------------------------
@node Binary files
@chapter バイナリ・ファイルの扱い
@cindex Binary files

最も普通の @sc{cvs} の使用はテキスト・ファイルの保管です。テキスト・ファ
イルでは、@sc{cvs} はリビジョンをマージしたり、リビジョン間の違いを人
間が読める形式で表示したり、他の似たような操作をすることができます。し
かし、これらの中のいくつかの機能を諦めることで、@sc{cvs} はバイナリ・
ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ
画像の両方からなるウェブサイトを @sc{cvs} で保管するかもしれません。

@menu
* Binary why::     バイナリ・ファイルの問題の詳細
* Binary howto::   保管方法
@end menu

@node Binary why
@section バイナリ・ファイルの問題

普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必
要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ
せます。

バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。
例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して
いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ
イルには、@sc{cvs} は @code{cvs diff} コマンドでこの機能を提供します。
バイナリ・ファイルには、2つのリビジョンを取り出して、@sc{cvs} の外部に
あるプログラムで比較することができるでしょう (例えば、ワープロにはよく
そのような機能があります)。もしそのようなツールがなければ、人に良いロ
グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実
際にした変更が本当にそうしたいと思っている変更そのものであることを期待
しなければなりません。

バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。
@sc{cvs} ではこれは2つの文脈で発生します。1つめは使用者が分離された作
業ディレクトリで変更をしたときです (@pxref{Multiple developers})。2つ
目は @samp{update -j} コマンドで明示的にマージしたときです 
(@pxref{Branching and merging})。

テキスト・ファイルの場合は、@sc{cvs} は独立になされた変更をマージでき、
変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、
@sc{cvs} にできることは、せいぜい2つの違ったファイルのコピーを出して、
使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー
を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール
があればそれを実行するかもしれません。使用者にマージをさせることは、主
に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して
おり、エラーが発生する可能性が高いということに注意してください。

この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別
の作業ディレクトリによるマージを避けるためには、@ref{Multiple
developers} の独占取得 (ファイル占有) の議論を参照してください。枝によ
るマージを避けるためには、枝の使用を制限してください。

@node Binary howto
@section バイナリ・ファイルを保管する方法

@sc{cvs} でバイナリ・ファイルを保管する際の問題点が二つあります。
一つ目は、@sc{cvs} がファイルを取り出す際に、
リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、
クライアント側のオペレーティングシステムに適した形式に変換する事です 
(例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり
ます)。

二つ目の問題点は、キーワードと同じデータが
偶然バイナリ・ファイルに含まれる可能性がある事です 
(@pxref{Keyword substitution})。
そのためキーワード展開を無効にする必要があります。

@c FIXME: the third is that one can't do merges with
@c binary files.  xref to Multiple Developers and the
@c reserved checkout issues.

幾つかの @sc{cvs} コマンドで @samp{-kb} オプションを用いれば、
確実に行末変換とキーワード展開を止めることができます。

@samp{-kb} フラグを用いて新しいファイルを登録する方法を、
以下に例示します:

@example
$ echo '$@asis{}Id$' > kotest
$ cvs add -kb -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest
@end example

ふと油断して @samp{-kb} 無しでファイルを加えてしまった場合、
@code{cvs admin} コマンドを使用して正常な状態に戻す必要があります。
以下に例示します:

@example
$ echo '$@asis{}Id$' > kotest
$ cvs add -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest
$ cvs admin -kb kotest
$ cvs update -A kotest
# @r{For non-unix systems:}
# @r{Copy in a good copy of the file from outside CVS}
$ cvs commit -m "make it binary" kotest
@end example

@c Trying to describe this for both unix and non-unix
@c in the same description is very confusing.  Might
@c want to split the two, or just ditch the unix "shortcut"
@c (unixheads don't do much with binary files, anyway).
@c This used to say "(Try the above example, and do a
@c @code{cat kotest} after every command)".  But that
@c only really makes sense for the unix case.
ファイル @file{kotest} を格納した時はファイルはバイナリ・ファイルとし
ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ
たからです。
@samp{cvs admin -kb} コマンドでファイルの置換モードを設定しますが、
既にある作業コピーは変更してくれません。
行末を適切に処理する必要がある場合 (@sc{cvs} のクライアントとして 
unix 以外のシステムを使用している場合) は、
上記の例に示した @code{cvs commit} コマンドのように、
新たにファイルのコピーを格納する必要があります。
Unix では、@samp{cvs update -A} で十分です。
@c FIXME: should also describe what the *other users*
@c need to do, if they have checked out copies which
@c have been corrupted by lack of -kb.  I think maybe
@c "cvs update -kb" or "cvs
@c update -A" would suffice, although the user who
@c reported this suggested removing the file, manually
@c removing it from CVS/Entries, and then "cvs update"

ここで、@samp{cvs admin -k} を用いて置換モードを変更しても、
この置換モードはバージョン管理されないことを認識しておいて下さい。
これは例えば古いリリースにテキスト・ファイルがあり、
新しいリリースに同じ名前のバイナリ・ファイルがあった場合、
バージョンによってテキストとバイナリを区別して取り出す方法を、
@sc{cvs} が備えていないことを意味しています。
この問題を解決する方法は今のところありません。

@code{cvs add} や @code{cvs import} を実行する際、
既定でバイナリとして扱うかどうかを、
ファイルの名前によって判断するように設定もできます。
例えば、ファイル名が @samp{.exe} で終わるファイルを
バイナリと判断するように設定できます。@xref{Wrappers}.
現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ
ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの
区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに
応じてかなり異なるであろうということです。
@c For example, it would be good on MS-DOS-family OSes
@c for anything containing ^Z to be binary.  Having
@c characters with the 8th bit set imply binary is almost
@c surely a bad idea in the context of ISO-8859-* and
@c other such character sets.  On VMS or the Mac, we
@c could use the OS's file typing.  This is a
@c commonly-desired feature, and something of this sort
@c may make sense.  But there are a lot of pitfalls here.
@c
@c Another, probably better, way to tell is to read the
@c file in text mode, write it to a temp file in text
@c mode, and then do a binary mode compare of the two
@c files.  If they differ, it is a binary file.  This
@c might have problems on VMS (or some other system
@c with several different text modes), but in general
@c should be relatively portable.  The only other
@c downside I can think of is that it would be fairly
@c slow, but that is perhaps a small price to pay for
@c not having your files corrupted.  Another issue is
@c what happens if you import a text file with bare
@c linefeeds on Windows.  Such files will show up on
@c Windows sometimes (I think some native windows
@c programs even write them, on occasion).  Perhaps it
@c is reasonable to treat such files as binary; after
@c all it is something of a presumption to assume that
@c the user would want the linefeeds converted to CRLF.

@c ---------------------------------------------------------------------
@node Multiple developers
@chapter 複数の開発者
@cindex Multiple developers
@cindex Team of developers
@cindex File locking
@cindex Locking files
@cindex Working copy
@cindex reserved checkouts
@cindex unreserved checkouts
@cindex RCS-style locking

複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。
例えば二人の人物が、
同じファイルを同時に編集しようとすることがよくあります。
解決策の一つは、
@dfn{ファイル占有} (@dfn{file locking}) または @dfn{独占取得} 
(@dfn{reserved checkouts}) と呼ばれるもので、
同時にファイルを編集できる人数を一人に制限するものです。
@sc{rcs} や @sc{sccs} 等の履歴管理システムでは、
これが唯一の方法です。
現時点では @sc{cvs} で独占取得をする普通の方法は @code{cvs admin -l}
コマンドです (@pxref{admin options})。これは後述する監視機能のように 
@sc{cvs} によく実装されてはいませんが、独占取得を必要なほとんどの人は
十分だと思うでしょう。
@c Or "find it better than worrying about implementing
@c nicely integrated reserved checkouts" or ...?
また後述する監視機構を適切な手順を踏んで用いることでも (ソフトウェアか
らは強制されません)、同時編集を避けることが可能でしょう。

@c Our unreserved checkout model might not
@c be quite the same as others.  For example, I
@c think that some systems will tend to create a branch
@c in the case where CVS prints "up-to-date check failed".
@c It isn't clear to me whether we should try to
@c explore these subtleties; it could easily just
@c confuse people.
@sc{cvs} の既定モデルは@dfn{無条件取得} 
(@dfn{unreserved checkouts}) と呼ばれるものです。
このモデルでは、
開発者がそれぞれ自分の @dfn{作業コピー} 
(@dfn{working copy}) のファイルを同時に編集できます。
最初に変更を格納した人物は、
他の人物が編集を始めたことが自動的には分りません。
二番目の人物が格納する時にはエラー表示を受けますから、
@sc{cvs} コマンドを用いて、
自分の作業コピーをリポジトリのリビジョンの最新のものにする
必要があります。
この手順はほぼ自動化されています。

@c FIXME? should probably use the word "watch" here, to
@c tie this into the text below and above.
@sc{cvs} は、独占取得がするような規則を強制することなく、
種々の意志疎通を容易にする仕組みを用意しています。

この章の残りでは、色々なモデルの動作方法と、
各モデルの選択に伴なう問題点について述べます。

@ignore
Here is a draft reserved checkout design or discussion
of the issues.  This seems like as good a place as any
for this.

Might want a cvs lock/cvs unlock--in which the names
differ from edit/unedit because the network must be up
for these to work.  unedit gives an error if there is a
reserved checkout in place (so that people don't
accidentally leave locks around); unlock gives an error
if one is not in place (this is more arguable; perhaps
it should act like unedit in that case).

On the other hand, might want it so that emacs,
scripts, etc., can get ready to edit a file without
having to know which model is in use.  In that case we
would have a "cvs watch lock" (or .cvsrc?) (that is,
three settings, "on", "off", and "lock").  Having cvs
watch lock set would cause a get to record in the CVS
directory which model is in use, and cause "cvs edit"
to change behaviors.  We'd want a way to query which
setting is in effect (this would be handy even if it is
only "on" or "off" as presently).  If lock is in
effect, then commit would require a lock before
allowing a checkin; chmod wouldn't suffice (might be
debatable--see chmod comment below, in watches--but it
is the way people expect RCS to work and I can't think
of any significant downside.  On the other hand, maybe
it isn't worth bothering, because people who are used
to RCS wouldn't think to use chmod anyway).

Implementation: use file attributes or use RCS
locking.  The former avoids more dependence on RCS
behaviors we will need to reimplement as we librarify
RCS, and makes it easier to import/export RCS files (in
that context, want to ignore the locker field).  But
note that RCS locks are per-branch, which is the
correct behavior (this is also an issue for the "watch
on" features; they should be per-branch too).

Here are a few more random notes about implementation
details, assuming "cvs watch lock" and

CVS/Watched file?  Or try to fit this into CVS/Entries somehow?
Cases: (1) file is checked out (unreserved or with watch on) by old
version of CVS, now we do something with new one, (2) file is checked
out by new version, now we do something with old one.

Remote protocol would have a "Watched" analogous to "Mode".  Of course
it would apply to all Updated-like requests.  How do we keep this
setting up to date?  I guess that there wants to be a Watched request,
and the server would send a new one if it isn't up to date? (Ugh--hard
to implement and slows down "cvs -q update"--is there an easier way?)

"cvs edit"--checks CVS/Watched, and if watch lock, then sends
"edit-lock" request.  Which comes back with a Checked-in with
appropriate Watched (off, on, lock, locked, or some such?), or error
message if already locked.

"cvs commit"--only will commit if off/on/locked.  lock is not OK.

Doc:
note that "cvs edit" must be connected to network if watch lock is in
effect.

Talk about what to do if someone has locked a file and you want to
edit that file.  (breaking locks, or lack thereof).


One other idea (which could work along with the
existing "cvs admin -l" reserved checkouts, as well as
the above):

"cvs editors" could show who has the file locked, if
someone does.

@end ignore

@menu
* File status::                 ファイルは幾つかの状態を取る
* Updating a file::             ファイルを最新にする
* Conflicts example::           有益な実行例
* Informing others::            協力のために他の人にお知らせする
* Concurrency::                 リポジトリの同時利用
* Watches::                     ファイル編集者の追跡機構
* Choosing a model::            独占取得か無条件取得か?
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node File status
@section ファイル状態
@cindex File status
@cindex Status of a file

@c Shouldn't this start with an example or something,
@c introducing the unreserved checkout model?  Before we
@c dive into listing states?
取り出した後にあなたが加えた操作や、
他の人物がリポジトリに加えた操作によって、
ファイルを幾つかの状態に分類します。
@code{status} コマンドによって報告される状態を以下に挙げます:

@c The order of items is chosen to group logically
@c similar outputs together.
@c People who want alphabetical can use the index...
@table @asis
@cindex Up-to-date
@item Up-to-date
このファイルが、
使用している枝の最新リビジョンと同じであることを示します。
@c FIXME: should we clarify "in use"?  The answer is
@c sticky tags, and trying to distinguish branch sticky
@c tags from non-branch sticky tags seems rather awkward
@c here.
@c FIXME: What happens with non-branch sticky tags?  Is
@c a stuck file "Up-to-date" or "Needs checkout" or what?

@item Locally Modified
@cindex Locally Modified
このファイルを修正したが、まだ変更内容を格納してないことを示します。

@item Locally Added
@cindex Locally Added
@code{add} コマンドによりファイルを加えたが、
まだその内容を格納してないことを示します。
@c There are many cases involving the file being
@c added/removed/modified in the working directory, and
@c added/removed/modified in the repository, which we
@c don't try to describe here.  I'm not sure that "cvs
@c status" produces a non-confusing output in most of
@c those cases.

@item Locally Removed
@cindex Locally Removed
@code{remove} コマンドによりファイルを削除したが、
まだその変更を格納してないことを示します。

@item Needs Checkout
@cindex Needs Checkout
他の人物が新しいリビジョンをリポジトリに格納したことを示します。
この表示は少し紛らわしいのですが、
新しいリビジョンを取り出す際には、@code{checkout} ではなく、
@code{update} を使用するのが普通です。

@item Needs Patch
@cindex Needs Patch
@c See also newb-123j0 in sanity.sh (although that case
@c should probably be changed rather than documented).
Needs Checkout と似たようなものですが、
@sc{cvs} のサーバは、ファイル全てではなく差分を送ります。
差分を送る場合も、ファイル全てを送る場合と結果は同じです。

@item Needs Merge
@cindex Needs Merge
他の人物が新しいリビジョンをリポジトリに格納したが、
作業ファイルも修正されていたため、マージする必要があることを示します。

@item File had conflicts on merge
@cindex File had conflicts on merge
@c is it worth saying that this message was "Unresolved
@c Conflict" in CVS 1.9 and earlier?  I'm inclined to
@c think that is unnecessarily confusing to new users.
Locally Modified と似ていますが、先の @code{update} コマンドの結果、
変更点の衝突が発見されたことを示します。
衝突を解消する方法は @ref{Conflicts example} 参照。

@item Unknown
@cindex Unknown
このファイルについて @sc{cvs} が何も知らないことを示します。
例えば新たなファイルを作成したが、@code{add} を実行していない場合などです。
@c
@c "Entry Invalid" and "Classify Error" are also in the
@c status.c.  The latter definitely indicates a CVS bug
@c (should it be worded more like "internal error" so
@c people submit bug reports if they see it?).  The former
@c I'm not as sure; I haven't tracked down whether/when it
@c appears in "cvs status" output.

@end table

@code{status} は、ファイル状態を分類する際の補助として、
作業中のファイルの由来となるリビジョン
を示す @samp{Working revision} と、
使用中の枝のリポジトリにおける最新リビジョン
を示す @samp{Repository revision} とも報告します。
@c FIXME: should we clarify "in use"?  The answer is
@c sticky tags, and trying to distinguish branch sticky
@c tags from non-branch sticky tags seems rather awkward
@c here.
@c FIXME: What happens with non-branch sticky tags?
@c What is the Repository Revision there?  See the
@c comment at vn_rcs in cvs.h, which is kind of
@c confused--we really need to document better what this
@c field contains.
@c Q: Should we document "New file!" and other such
@c outputs or are they self-explanatory?
@c FIXME: what about the date to the right of "Working
@c revision"?  It doesn't appear with client/server and
@c seems unnecessary (redundant with "ls -l") so
@c perhaps it should be removed for non-client/server too?
@c FIXME: Need some examples.
@c FIXME: Working revision can also be something like
@c "-1.3" for a locally removed file.  Not at all
@c self-explanatory (and it is possible that CVS should
@c be changed rather than documenting this).

@c Would be nice to have an @example showing output
@c from cvs status, with comments showing the xref
@c where each part of the output is described.  This
@c might fit in nicely if it is desirable to split this
@c node in two; one to introduce "cvs status" and one
@c to list each of the states.
@code{status} コマンドのオプションについての情報は、@ref{Invoking CVS}
参照。
@samp{Sticky tag} と @samp{Sticky date} についての
情報は、@ref{Sticky tags} 参照。
@samp{Sticky options} の情報は、@ref{update options} 
の @samp{-k} オプションを参照して下さい。

@code{status} と @code{update} コマンドは補完するようなものとして考え
ることができます。ファイルを最新にするためには @code{update} を使い、
@code{status} で @code{update} が何をするかをある程度知ることができま
す (もちろん、リポジトリの状態は実際に @code{update} を実行するまでに
変化するかもしれません)。実際は、@code{status} コマンドで表示されるよ
り短い形式でコマンドに表示させたければ、次を実行することができます

@cindex update, to display file status
@example
$ cvs -n -q update
@end example

@samp{-n} オプションは実際に update をしないが、状態を表示するだけであ
る、ということです。@samp{-q} オプションはそれぞれのディレクトリ名の印
字を避けます。@code{update} コマンドとこれらのオプションの情報は、
@ref{Invoking CVS} を参照してください。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Updating a file
@section ファイルを最新にする
@cindex Bringing a file up to date
@cindex Updating a file
@cindex Merging a file
@cindex update, introduction

ファイルを更新もしくはマージしたい場合には、
@code{update} コマンドを使用します。
これは最新でないファイルに対しては @code{checkout} コマンドとほとんど
等価です。
つまり、ファイルの最新リビジョンをリポジトリから取り出して、
作業ディレクトリに置きます。

@code{update} コマンドを使用しても、
あなたの修正が失なわれることはありません。
より新しいバージョンが無い場合には、@code{update} は何もしません。
新しいバージョンが存在し、かつ作業ファイルが修正されている場合、
@sc{cvs} は全ての変更を作業コピーにマージします。

例えばリビジョン 1.4 を取り出して、編集を始めたとします。
その合間に他の人物がバージョン 1.5 を格納し、
またすぐに 1.6 になったとします。
ここで @code{update} コマンドを使用した場合、
@sc{cvs} は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。

@cindex Overlap
1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、
@dfn{重複} (@dfn{overlap}) が起きます。
そして警告が表示され、ファイルには重複した行が両方並記されて、
特別なマークで囲まれます。
@code{update} コマンドの詳細は @xref{update}.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Conflicts example
@section 衝突の例
@cindex Merge, an example
@cindex Example of merge
@cindex driver.c (merge example)

リビジョン 1.4 の @file{drive.c} は次のような内容とします:

@example
#include <stdio.h>

void main()
@{
    parse();
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(nerr == 0 ? 0 : 1);
@}
@end example

@noindent
リビジョン 1.6 では @file{drive.c} は次のようになっています:

@example
#include <stdio.h>

int main(int argc,
         char **argv)
@{
    parse();
    if (argc != 1)
    @{
        fprintf(stderr, "tc: No args expected.\n");
        exit(1);
    @}
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(!!nerr);
@}
@end example

@noindent
リビジョン 1.4 を元にしたあなたの @file{driver.c} の作業コピーは、
@samp{cvs update} の前に次ようになっています:
@c -- Really include "cvs"?

@example
#include <stdlib.h>
#include <stdio.h>

void main()
@{
    init_scanner();
    parse();
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
@}
@end example

@noindent
この時 @samp{cvs update} を実行してみます:
@c -- Really include "cvs"?

@example
$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c
@end example

@noindent
@cindex Conflicts (merge example)
@sc{cvs} は上記のように、衝突が起きたことが報告します。
あなたが編集したオリジナルのファイルは、
無修正で @file{.#driver.c.1.4} という名前で保存されます。
@file{driver.c} の新しいバージョンは次のようになります:

@example
#include <stdlib.h>
#include <stdio.h>

int main(int argc,
         char **argv)
@{
    init_scanner();
    parse();
    if (argc != 1)
    @{
        fprintf(stderr, "tc: No args expected.\n");
        exit(1);
    @}
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
@asis{}<<<<<<< driver.c
    exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
@asis{}=======
    exit(!!nerr);
@asis{}>>>>>>> 1.6
@}
@end example

@noindent
@cindex Markers, conflict
@cindex Conflict markers
@cindex <<<<<<<
@cindex >>>>>>>
@cindex =======

重複しなかった修正がどの様に作業コピーに組み込まれているか注意して下さ
い。
重複した部分は
@samp{<<<<<<<}, @samp{=======} 及び @samp{>>>>>>>} 
ではっきりと囲まれています。

@cindex Resolving a conflict
@cindex Conflict resolution
ファイルを編集して衝突が起きた部分を解決し、
マークと間違った行を消します。
最終的に次のようになったとします:
@c -- Add xref to the pcl-cvs manual when it talks
@c -- about this.
@example
#include <stdlib.h>
#include <stdio.h>

int main(int argc,
         char **argv)
@{
    init_scanner();
    parse();
    if (argc != 1)
    @{
        fprintf(stderr, "tc: No args expected.\n");
        exit(1);
    @}
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
@}
@end example

@noindent
今やこのファイルを格納してリビジョン 1.7 とすることができます。

@example
$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
new revision: 1.7; previous revision: 1.6
done
@end example

衝突が起きたが未解決であるファイルは、安全を考慮して、
@sc{cvs} が格納することを拒否します。
衝突を解決するとき、ファイルの編集時間を変更する必要があります。
前のバージョンの @sc{cvs} では、ファイルに衝突マークがないことを確認す
る必要もありました。ファイルには正しく衝突マークがあるかもしれませんの
で (すなわち、行頭にある @samp{>>>>>>> } は衝突の印ではありません)、現
在のバージョンの @sc{cvs} は警告を印字してファイルの格納を実行します。
@c The old behavior was really icky; the only way out
@c was to start hacking on
@c the @code{CVS/Entries} file or other such workarounds.
@c
@c If the timestamp thing isn't considered nice enough,
@c maybe there should be a "cvs resolved" command
@c which clears the conflict indication.  For a nice user
@c interface, this should be invoked by an interactive
@c merge tool like emerge rather than by the user
@c directly--such a tool can verify that the user has
@c really dealt with each conflict.

@cindex emerge
もしあなたが pcl-cvs (@sc{gnu} Emacs 用 @sc{cvs} フロントエンド) の、
1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに 
emerge という Emacs パッケージが利用できます。
pcl-cvs の文書を見て下さい。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Informing others
@section 格納したことを他の人に知らせる
@cindex Informing others
@cindex Spreading information
@cindex Mail, automatic mail on commit

新しいリビジョンが格納されたときに、
それを開発者全員に通知するようにしておくと便利でしょう。
@file{moduels} か @file{loginfo} ファイルの 
@samp{-i} オプションにより、この手順を自動化することができます 
@xref{modules}. @xref{loginfo}.
この機構により、例えば全ての開発者にメールを出したり、
ニュースに記事を投稿したりすることができます。
@c -- More text would be nice here.

@node Concurrency
@section 同時に CVS の実行を試みる複数の開発者

@cindex locks, cvs, introduction
@c For a discussion of *why* CVS creates locks, see
@c the comment at the start of src/lock.c
複数の開発者が同時に @sc{cvs} を実行しようとした場合、
次のようなメッセージが表示されます:

@example
[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
@end example

@cindex #cvs.rfl, removing
@cindex #cvs.wfl, removing
@cindex #cvs.lock, removing
@sc{cvs} は 30秒毎に実行を試み、
まだ待つ必要があれば再度メッセージを表示し、
そうでなければ処理を続けます。
不適当な程長く待ち続けているようならば、
ロックさせている人物を見付けて、
実行中の cvs コマンドを訊いてみて下さい。
cvs コマンドが実行されてないのならば、メッセージで書かれているリポジト
リディレクトリを見て、彼等が所有している 
@file{#cvs.tfl}, @file{#cvs.rfl}, @file{#cvs.wfl} 
という名前で始まるファイルを捜して、削除して下さい。

このロックは @sc{cvs} の内部データ構造を保護するもので、
@sc{rcs} で使用される@dfn{ロック} (@dfn{lock}) 
という言葉とは全く何の関係もないことに注意してください。
@sc{rcs} のロックについては、
独占取得についての記述を参照して下さい (@pxref{Multiple developers})。

任意のリポジトリから何人でも、
同時に読み出すことが可能です。
誰かが書き込み中の場合にだけ、
他の人の読み出しや書き込みが禁止されます。

@cindex Atomic transactions, lack of
@cindex Transactions, atomic, lack of
@c the following talks about what one might call commit/update
@c atomicity.
@c Probably also should say something about
@c commit/commit atomicity, that is, "An update will
@c not get partial versions of more than one commit".
@c CVS currently has this property and I guess we can
@c make it a documented feature.
@c For example one person commits
@c a/one.c and b/four.c and another commits a/two.c and
@c b/three.c.  Then an update cannot get the new a/one.c
@c and a/two.c and the old b/four.c and b/three.c.
次に示すような動作を望む人がいるでしょう

@example
ある人物が一つの cvs コマンドで複数のファイルに対する変更点を
格納した時、他の誰かが同時に update を実行すると、全てのファイルが
更新されるか、全く更新されないかのどちらかである。
@end example

が、@sc{cvs} はこのように動作@emph{しません}。
例えば以下のファイルがあるとして、

@example
a/one.c
a/two.c
b/three.c
b/four.c
@end example

ある人物が次のコマンドを実行した時、

@example
cvs ci a/two.c b/three.c
@end example

同時に他の誰かが @code{cvs update} を実行した場合、
@code{update} を実行している人は @file{b/three.c} の変更点のみが更新さ
れ、
@file{a/two.c} の変更点は更新されないでしょう。

@node Watches
@section ファイル編集者の追跡機構
@cindex Watches

多くのグループが @sc{cvs} を既定状態で使用していますが、
ほぼ完全に満足しているようです。
しかし時には、自分と他人の修正点が重複する事があり、
この重複を処理して再び格納しなくてはいけません。
あるグループでは、
誰がどのファイルを編集中か分るようにしています。
従って、二人で同じファイルを編集する場合、
誰が何時何をするのか相談できるため、
格納時に驚かされずに済みます。
この節では、
このような調整作業を行なう機能について説明しますが、
二人の開発者が同時に同じファイルを編集する能力は維持されます。

@c Some people might ask why CVS does not enforce the
@c rule on chmod, by requiring a cvs edit before a cvs
@c commit.  The main reason is that it could always be
@c circumvented--one could edit the file, and
@c then when ready to check it in, do the cvs edit and put
@c in the new contents and do the cvs commit.  One
@c implementation note: if we _do_ want to have cvs commit
@c require a cvs edit, we should store the state on
@c whether the cvs edit has occurred in the working
@c directory, rather than having the server try to keep
@c track of what working directories exist.
@c FIXME: should the above discussion be part of the
@c manual proper, somewhere, not just in a comment?
開発者は、
編集するファイルを読み書き可能にする時に、
(@code{chmod} でなく) @code{cvs edit} を使用し、
もう使用しない作業ディレクトリを処分する時に、
(@code{rm} でなく) @code{cvs release} を使用することが推奨されます。
しかし、@sc{cvs} はこれらの手順を強制する事は出来ません。

@c I'm a little dissatisfied with this presentation,
@c because "watch on"/"edit"/"editors" are one set of
@c functionality, and "watch add"/"watchers" is another
@c which is somewhat orthogonal even though they interact in
@c various ways.  But I think it might be
@c confusing to describe them separately (e.g. "watch
@c add" with loginfo).  I don't know.

@menu
* Setting a watch::             監視するファイルを CVS に教える
* Getting Notified::            誰に通知するか CVS に教える
* Editing files::               監視下にあるファイルの編集方法
* Watch information::           誰が監視や編集をしているか
* Watches Compatibility::       監視は CVS 1.6 以前と上手く協調しない
@end menu

@node Setting a watch
@subsection 監視するファイルを CVS に教える

監視機能を有効にするには、
まずそのファイルを監視するように指示する必要があります。

@cindex watch on (subcommand)
@deffn コマンド {cvs watch on} [@code{-lR}] files @dots{}

@cindex read-only files, and watches
この指定以降、@var{files} を編集しようとする開発者は 
@code{cvs edit} を実行する必要があります。
開発者が編集前に @code{cvs edit} の実行を忘れない様に、
@sc{cvs} は @var{files} の読み込みだけを許可します。

@var{files} がディレクトリを含む場合、
リポジトリの対応するディレクトリ内の全てのファイルに加えて、
将来ディレクトリに追加されるファイル全てが 
@sc{cvs} の監視対象になります。
この動作を利用して、ディレクトリ毎に通知方針を設定することができます。
またオプション @samp{-l} を指定しない場合、
ディレクトリ以下が再帰的に処理されます。
@code{-l} オプションが @file{~/.cvsrc} で設定されている場合は 
@code{-R} オプションを使って再帰を強制することができます 
(@pxref{~/.cvsrc})。

@var{files} を省略した場合、
現在のディレクトリが指定されたと解釈します。

@cindex watch off (subcommand)
@end deffn

@deffn コマンド {cvs watch off} [@code{-lR}] files @dots{}

@var{files} が編集された時の通知を行ないません。
@sc{cvs} は @var{files} の作業コピーを読み書き可能にします。

@var{files} や引数指定時の振舞いは、
@code{cvs watch on} の場合と同じです。

@end deffn

@node Getting Notified
@subsection 誰に通知するか CVS に教える

あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、
その旨を @sc{cvs} に知らせます。
そのファイルに対して @code{cvs watch on} を用いなくても、
通知の要求は可能です。
しかし、開発者がコマンド @code{cvs edit} を用いるとは限らないため、
通常は @code{cvs watch on} を用いた方が良いでしょう。

@cindex watch add (subcommand)
@deffn コマンド {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{}

現在の使用者を、 @var{files} に対して操作が行なわれた時に
通知を受けとる人の一覧に追加します。

オプション @samp{-a} には、
通知して欲しい操作の種類を指定します。
@var{action} は次のうちのどれかです:

@table @code

@item edit
あなた以外の人物が、
ファイルに対してコマンド @code{cvs edit} (後述) を適用した場合。

@item unedit
あなた以外の人物が、
ファイルに対してコマンド @code{cvs unedit} (後述) または 
@code{cvs release} を適用した場合。
また、ファイルが消されて @code{cvs update} により再度生成された場合。

@item commit
あなた以外の人物が、ファイルに対する変更を格納した場合。

@item all
上記全て。

@item none
上記以外。
(これは後述の @code{cvs edit} で使用すると便利です。)

@end table

オプション @samp{-a} は何度指定しても良いし、
全く指定しなくても構いません。
省略した場合には、@code{all} が指定されたと解釈します。

@var{files} や引数指定時の振舞いは、
@code{cvs watch on} の場合と同じです。

@end deffn


@cindex watch remove (subcommand)
@deffn コマンド {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{}

@code{cvs watch add} で設定した通知要求を取り下げます。
引数は同じです。
オプション @samp{-a} を用いた場合、
指定された事項に対する通知のみを停止します。

@end deffn

@cindex notify (admin file)
通知すべき状態が発生した時、
@sc{cvs} は管理用ファイル @file{notify} を見ます。
@file{notify} は他の管理用ファイルと同じように編集して下さい。
(@pxref{Intro administrative files})。
管理用ファイルの慣例に従って (@pxref{syntax})、このファイルの各行には、
正規表現に続けて実行したいコマンドを記述します。
コマンドの引数には、(通知すべき使用者に置換される) 
@samp{%s} という文字列を一つだけ指定する必要があり、
通知内容はコマンドの標準入力に与えられます。
ファイル @code{notify} に書く標準のものは次の一行です:

@example
ALL mail %s -s \"CVS notification\"
@end example

この記述により、使用者に電子メールで通知が行なわれます。
@c FIXME: should it be this hard to set up this
@c behavior (and the result when one fails to do so,
@c silent failure to notify, so non-obvious)?  Should
@c CVS give a warning if no line in notify matches (and
@c document the use of "DEFAULT :" for the case where
@c skipping the notification is indeed desired)?

@cindex users (admin file)
上記の行をそのまま記述した場合、
使用者はサーバ上で通知を受ける事に注意して下さい。
他の場所に通知したい場合には、
もちろん @file{notify} に記述しても良いのですが、
@sc{cvs} ではもっと簡単に各使用者の通知先を設定できます。
@file{CVSROOT} に @file{users} というファイルを作成し、
@var{user}:@var{value} という書式で、
各使用者について一行ずつ記述して下さい。
@sc{cvs} は、@file{notify} に記述された @var{user} の代りに、
@var{value} (通常は別のマシンのメールアドレス) に通知します。

@sc{Cvs} はあなた自身の変更は通知しません。現時点では、この照合は通知
を発生させる動作をしている人の使用者名が通知を受ける人の使用者名と合う
かどうかに基づいてなされています。実際のところ、一般的に、監視機構はそ
れぞれの使用者の一つの編集だけを追跡します。おそらく、監視がそれぞれの
作業ディレクトリを別に追跡するとより便利なので、この振舞いは変更する
価値があるでしょう。
@c "behavior might be worth changing" is an effort to
@c point to future directions while also not promising
@c that "they" (as in "why don't they fix CVS to....")
@c will do this.
@c one implementation issue is identifying whether a
@c working directory is same or different.  Comparing
@c pathnames/hostnames is hopeless, but having the server
@c supply a serial number which the client stores in the
@c CVS directory as a magic cookie should work.

@node Editing files
@subsection 監視下にあるファイルの編集方法

@cindex checkout, as term for getting ready to edit
監視下にあるファイルを取り出した場合、
読み込みだけが許可されるため、単純に編集はできません。
読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、
@code{cvs edit} コマンドを使用して下さい。
上記の作業を @dfn{checkout} と呼ぶシステムもありますが、
@sc{cvs} ではこの用語をソースのコピーを得る (@dfn{取り出す}) 
という意味で用います (@pxref{Getting the source})。
他のシステムでは、この操作は @dfn{get} とか @dfn{fetch} と呼ばれます。
@c Issue to think about: should we transition CVS
@c towards the "get" terminology?  "cvs get" is already a
@c synonym for "cvs checkout" and that section of the
@c manual refers to "Getting the source".  If this is
@c done, needs to be done gingerly (for example, we should
@c still accept "checkout" in .cvsrc files indefinitely
@c even if the CVS's messages are changed from "cvs checkout: "
@c to "cvs get: ").
@c There is a concern about whether "get" is not as
@c good for novices because it is a more general term
@c than "checkout" (and thus arguably harder to assign
@c a technical meaning for).

@cindex edit (subcommand)
@deffn コマンド {cvs edit} [options] files @dots{}

作業ファイル @var{files} を編集する準備をします。
@sc{cvs} は @var{files} の読み書きを許可し、
@var{files} に対する @code{edit} 通知を求める使用者に通知します。

@code{cvs edit} コマンドに、
@code{cvs watch add} コマンドと同じ @var{options} を使用すれば、
一時的に @var{files} を監視することができます。
@sc{cvs} は、
@var{files} が @code{unedit} もしくは @code{commit} されたときに、
監視を止めます。
通知を受けたくない場合には、@samp{-a none} を指定して下さい。

@var{files} や引数指定時の振舞いは、
@code{cvs watch} の場合と同じです。

@strong{注意:} @code{PreservePermissions} オプションがリポジトリで使用
可になっていると (@pxref{config})、CVS はどの @var{files} の使用許可も
変更しません。この変更の理由は @samp{cvs edit} の使用が CVS リポジトリ
のファイル使用許可を保管する機能と干渉しないようにするということです。

@end deffn

変更を全て終了したら、通常は @code{cvs commit} を用いて、
監視下にあるファイルの変更点を格納し、
読み込みだけが許可された状態に戻します。
しかし、途中で変更を止めたり、何も変更しないと決めた場合には、
@code{cvs unedit} コマンドを使用します。

@cindex unedit (subcommand)
@cindex abandoning work
@cindex reverting to repository version
@deffn コマンド {cvs unedit} [@code{-lR}] files @dots{}

作業ファイル @var{files} に加えた変更を捨て、
変更前のリポジトリのバージョンに戻します。
@var{files} に対して、@code{cvs watch on} による通知要求がある場合、
@sc{cvs} は @var{files} の読み込みだけを許可します。
また @var{files} に対する @code{unedit} 通知を求める使用者に通知します。

@var{files} や引数指定時の振舞いは、
@code{cvs watch} の場合と同じです。

ファイルが監視されてないときにはおそらく 
@code{unedit} コマンドが動作しないため、
リポジトリのバージョンに戻したい場合は、ファイルを削除してから 
@code{cvs update} で新たにコピーを取得して下さい。
これは厳密には同じ意味ではなく、削除して更新した場合には、
あなたが最後に更新した後にリポジトリに加えられた変更も付随します。
@c It would be a useful enhancement to CVS to make
@c unedit work in the non-watch case as well.
@end deffn

@sc{cvs} のクライアント/サーバを使用していて、
サーバとうまく接続できなかった場合でも、
@code{cvs edit} や @code{cvs unedit} コマンドが使用できます。
次に @sc{cvs} コマンドが成功した時に、
一緒に通知が行なわれます。

@node Watch information
@subsection 誰が監視や編集をしているか

@cindex watchers (subcommand)
@deffn コマンド {cvs watchers} [@code{-lR}] files @dots{}

現在、@var{files} の変更を監視している人物の一覧を表示します。
監視されているファイルと、各監視者のメールアドレスを報告します。

@var{files} や引数指定時の振舞いは、
@code{cvs watch} の場合と同じです。

@end deffn


@cindex editors (subcommand)
@deffn コマンド {cvs editors} [@code{-lR}] files @dots{}

現在、@var{files} を編集している人物の一覧を表示します。
各編集者のメールアドレス、編集作業を開始した時間、
ファイルが置かれた作業ディレクトリのパス名とホスト名を報告します。

@var{files} や引数指定時の振舞いは、
@code{cvs watch} の場合と同じです。

@end deffn

@node Watches Compatibility
@subsection 古いバージョンの CVS と監視機能

@cindex CVS 1.6, and watches
監視機能を使用している場合、
リポジトリに @file{CVS} というディレクトリが作成され、
このディレクトリに監視情報が格納されます。
このリポジトリに対して @sc{cvs} 1.6 以前のものを使用した場合には、
以下のエラー・メッセージが出力されます (全て一行にでます):

@example
cvs update: cannot open CVS/Entries for reading:
No such file or directory
@end example

そして、操作が途中で終了します。
監視機能を使用するためには、
このリポジトリを利用するクライアント/サーバ両方で、
@sc{cvs} を新しいものと交換する必要があります。
もし新しいものと交換できない場合には、
@code{watch off} と @code{watch remove} コマンドを用いて
監視を全て停止すれば、
リポジトリを @sc{cvs} 1.6 が利用できる状態に再構築できます。

@node Choosing a model
@section 独占取得と無条件取得の選択
@cindex choosing, reserved or unreserved checkouts

独占取得、無条件取得それぞれに一長一短があります。
ここでは、この問題を簡単に説明しますが、
残りの多くは個人的な見解の相違や、
各グループの作業スタイルの相違だと思います。
開発者チームを構成するには様々な方法があります。
@sc{cvs} は特定の構成を強制せず、
各々を実現する機能を提供するだけです。

独占取得には、非常に非生産的な部分があります。
二人が同じファイルを編集する場合でも、編集部分が異なる場合には、
どちらか一方の編集を禁止する必要は全くありません。
また、ファイルを編集するためにロックした後、
ロック解除を忘れてしまうことが、普通に起こり得ます。

@c "many groups"?  specifics?  cites to papers on this?
@c some way to weasel-word it a bit more so we don't
@c need facts :-)?
独占取得に特別な安心感を持つ人々は、
無条件取得を用いた場合の衝突の多さや、
それを解決する困難さをよく訴えます。
しかし多くのグループの経験から言うと、
衝突は稀であり、解決も普通は比較的簡単なものです。

衝突は2人の開発者がコードの与えられた部分の適切な設計について
意見が食い違っているときにのみ起こることを理解するまで、
深刻な衝突の発生の少なさは驚きでしょう。
このような衝突は、そもそもチーム内での意思疎通が上手く行っていないこと
を示しています。
@emph{どのような}ソース管理方法を採るにしても、
開発者が共同で作業する際には、
システム全体の設計方針に従わなければいけません。
きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。

無条件取得が、全く不適当な場合があります。
管理下にあるファイルの形式をマージする道具が無く 
(例えばワード・プロセッサによるファイルや、
CAD プログラムで編集されたファイル等)、
マージ可能なデータ書式を使用するようにプログラムを変更できない場合、
悪夢のような衝突解決をするよりは、
普通は独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。

上の @ref{Watches} で記述された監視機構は、
独占取得と無条件取得の中間的なものと考えられます。
ファイルを編集する前に、
他の誰がファイルを編集中なのか調べることができます。
これは単純に双方の同時編集を禁止するのではなく、
現況を報告し、それが問題かどうかは自分で判断してもらいます。
これを適切に使用すれば、
独占取得と無条件取得の中でも最善の選択となるでしょう。

@c ---------------------------------------------------------------------
@node Revision management
@chapter リビジョン管理
@cindex Revision management

@c -- This chapter could be expanded a lot.
@c -- Experiences are very welcome!

ここまで読んだあなたは、
@sc{cvs} を使って何ができるかを、もう随分理解しているでしょう。
ここでは、あなたが決めるべき事柄について少し説明します。

あなたが一人で @sc{cvs} を使用して開発しているならば、
ここは読み飛ばして結構です。
複数の人物が同じリポジトリを使って作業する場合に、
ここで説明する問題が重要になってきます。

@menu
* When to commit::              この問題の論議
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node When to commit
@section いつ格納すべきか?
@cindex When to commit
@cindex Commit, when to
@cindex Policy

あなたのグループは、格納の時期に関して、
どのような方針を採るか決めておく必要があります。
幾つかの方針が可能であり、@sc{cvs} での経験を重ねることによって、
独自の方法を見付けることができるでしょう。

とにかく早く格納することにして、
コンパイルもせずに格納してしまったとします。
あなたの同僚が、作業ソースを更新して
あなたのバギーなファイルを取り込んだ場合、
彼はコンパイルができません。
逆にめったに格納しない場合、
同僚はあなたがコードに加えた改良の利益を得ることができず、
衝突がより多くなるでしょう。

コンパイルできるかどうか確認したファイルだけを
格納する方法がよく採られます。
あるサイトでは、ファイルが検査に合格することを要求します。
@file{commitinfo} ファイルを使用して (@pxref{commitinfo})、
このような方針を強制できますが、その前によく考えなくてはいけません。
十分過ぎる程管理された開発環境を作ると、
厳格になり過ぎて、非生産的になり、
ソフトウェアを書くという目的が果たせなくなります。

@c ---------------------------------------------------------------------
@node Keyword substitution
@chapter キーワード置換
@cindex Keyword substitution
@cindex Keyword expansion
@cindex Identifying files

@comment   この章を編集する場合には十分注意して下さい。
@comment   このファイルはバージョン管理されており、
@comment   有効なキーワードが、文中に含まれないように
@comment   注意しなくてはいけません。

作業ファイルを編集している間は、
いつでも @samp{cvs status} や @samp{cvs log} を使って
そのファイルの状態を調べることができます。
しかし開発環境から取り出した場合は、
各ファイルのリビジョンを識別するのが難しくなります。

CVSは、@dfn{キーワード置換} (@dfn{keyword substitution}) 
(もしくは@dfn{キーワード展開} (@dfn{keyword expansion}))
と呼ばれる機構により、ファイルの識別を補助します。
ファイル中に @code{$@var{keyword}$}, 
@code{$@var{keyword}:@dots{}$} といった書式で
埋め込まれた文字列を、ファイルを取り出すときに 
@code{$@var{keyword}:@var{value}$} といった書式の文字列に置き換えます。

@menu
* Keyword list::                キーワード
* Using keywords::              キーワードの使用
* Avoiding substitution::       置換を止めるには
* Substitution modes::          置換モード
* Log keyword::                 キーワード $@asis{}Log$ の問題点
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Keyword list
@section キーワード一覧
@cindex Keyword List

@c FIXME: need some kind of example here I think,
@c perhaps in a
@c "Keyword intro" node.  The intro in the "Keyword
@c substitution" node itself seems OK, but to launch
@c into a list of the keywords somehow seems too abrupt.

これはキーワードの利用の一覧です:

@table @code
@cindex Author keyword
@item $@asis{Author}$
そのリビジョンを格納したユーザのログイン名。

@cindex Date keyword
@item $@asis{Date}$
そのリビジョンを格納した日付と時間 (UTC)。

@cindex Header keyword
@item $@asis{Header}$
標準のヘッダは、@sc{rcs} ファイルのフルパス名, 
リビジョン番号, 日付 (UTC), 最終変更者, ファイル状態, 
(ロックされているならば) ロックしている人物という情報で
構成されます。
@sc{cvs} を使用する場合、普通ファイルはロックされません。

@cindex Id keyword
@item $@asis{Id}$
@sc{rcs} ファイル名がフルパスでないことを除けば、
@code{$@asis{Header}$} と同じです。

@cindex Name keyword
@item $@asis{Name}$
このファイルを取り出すときに使用したタグ名。キーワードは明示的なタグ名
で取り出したときにのみ展開されます。例えば、コマンド @code{cvs co -r
first} を実行すると、キーワードを @samp{Name: first} に展開します。

@cindex Locker keyword
@item $@asis{Locker}$
そのリビジョンをロックしている人物のログイン名。
(ロックされていなければ空で、@code{cvs admin -l} が使われていなければ
それが普通です。)

@cindex Log keyword
@item $@asis{Log}$
@sc{rcs} ファイル名, リビジョン番号, 最終変更者, 
日付 (UTC) から構成されるヘッダ行に続けて、
格納時のログ・メッセージを挿入します。
以前に挿入されたログ・メッセージを置き換えるのでは@emph{なく}、
新しいメッセージを @code{$@asis{Log:@dots{}}$} の次の行に挿入します。
それぞれの新しい行には @code{$Log} キーワードの前にあるものと
同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。

@example
  /* Here is what people have been up to:
   *
   * $@asis{}Log: frob.c,v $
   * Revision 1.1  1997/01/03 14:23:51  joe
   * Add the superfrobnicate option
   *
   */
@end example

@noindent
そうすると、@code{$Log} を展開するときに追加される行はその前に 
@samp{  * } が付きます。以前のバージョンの @sc{cvs}、@sc{rcs} と違って、
@sc{rcs} ファイル の @dfn{註釈符} (@dfn{comment leader}) は使用されま
せん。
@code{$Log} キーワードは、
ソース・ファイルに全てのログを残したい場合には便利ですが、
問題点も幾つかあります (@pxref{Log keyword})。

@cindex RCSfile keyword
@item $@asis{RCSfile}$
パスを含まない @sc{rcs} ファイル名。

@cindex Revision keyword
@item $@asis{Revision}$
そのリビジョンを表わすリビジョン番号。

@cindex Source keyword
@item $@asis{Source}$
RCS ファイルのフルパス名。

@cindex State keyword
@item $@asis{State}$
そのリビジョンの状態。
各リビジョンの状態は、@samp{cvs admin -s} で割り当てることができます---
@ref{admin options} 参照。

@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Using keywords
@section キーワードの使用

キーワードを使いたい場合は、@code{$@asis{Id}$} などの適当な文字列を
ファイルに記述してから格納するだけです。
@sc{cvs} は格納操作の一環として自動的に文字列を展開します。

@code{$@asis{}Id$} 文字列をソースファイルに入れて、生成されるファイル
にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために 
@code{#pragma ident} 命令が使用できるコンパイラもあります。もしくは、
文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
れません。

@c Would be nice to give an example, but doing this in
@c portable C is not possible and the problem with
@c picking any one language (VMS HELP files, Ada,
@c troff, whatever) is that people use CVS for all
@c kinds of files.

@cindex Ident (shell command)
@code{ident} コマンド (@sc{rcs} パッケージの一部) を使用して、
ファイルからキーワードとその値を抜き出すことができます。
もちろんテキスト・ファイルにも使えますが、
バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。

@example
$ ident samp.c
samp.c:
     $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
$ gcc samp.c
$ ident a.out
a.out:
     $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
@end example

@cindex What (shell command)
別のリビジョン管理システムとして有名なものに @sc{sccs} があります。
@sc{sccs} には、@code{ident} と非常によく似た
同じ用途のコマンド @code{what} が含まれます。
@sc{rcs} を持たないサイトの多くは @sc{sccs} を使っています。
@code{what} コマンドは @code{@@(#)} という文字列を探すため、
両方のコマンドに対応するキーワードを含めるのは簡単です。
キーワードの前に、
簡単な @sc{sccs} の魔法の呪文を唱えるだけで良いのです:

@example
static char *id="@@(#) $@asis{}Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Avoiding substitution
@section 置換を止めるには

キーワード置換にも欠点があります。
ファイル中に表われる文字列 @samp{$@asis{}Author$} は、
@sc{rcs} によってキーワードと見倣されます。
この文字列を @samp{$@asis{}Author: ceder $} などと解釈させずに、
そのまま使いたい事があるでしょう。

不幸なことに、選択的にキーワード置換を止めることはできません。
@samp{-ko} によって完全にキーワード置換を止めることができます 
(@pxref{Substitution modes})。

@sc{rcs} キーワードが最終製品に現われるとしても、
ソース・ファイル中には使いたくない場合が多くあります。
例えばこのマニュアルのソースには @samp{$@asis{}Author$} ではなく、
@samp{$@@asis@{@}Author$} と記述しています。
@code{nroff} や @code{troff} であれば、
ヌル文字である @code{\&} をキーワード中に埋め込めば
同様の効果を発揮します。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Substitution modes
@section 置換モード
@cindex keyword substitution, changing modes
@cindex -k (keyword substitution)
@cindex Kflag

@c FIXME: This could be made more coherent, by expanding it
@c with more examples or something.
各ファイルには既定の置換モードが設定されており、
作業ディレクトリの各ファイルの置換モードも別々に設定できます。
前者は @code{cvs add} や @code{cvs admin} に
オプション @samp{-k} を付けて設定します。
後者は @code{cvs checkout} や @code{cvs update} に
オプション @samp{-k} や @samp{-A} を付けて設定します。
@code{cvs diff} にも @samp{-k} オプションがあります。
例が幾つかありますので、@ref{Binary files} と @ref{Merging and
keywords} 参照。
@c The fact that -A is overloaded to mean both reset
@c sticky options and reset sticky tags/dates is
@c somewhat questionable.  Perhaps there should be
@c separate options to reset sticky options (e.g. -k
@c A") and tags/dates (someone suggested -r HEAD could
@c do this instead of setting a sticky tag of "HEAD"
@c as in the status quo but I haven't thought much
@c about that idea.  Of course -r .reset or something
@c could be coined if this needs to be a new option).
@c On the other hand, having -A mean "get things back
@c into the state after a fresh checkout" has a certain
@c appeal, and maybe there is no sufficient reason for
@c creeping featurism in this area.

利用できるモードを以下に示します:

@table @samp
@item -kkv
既定形式でキーワード文字列を生成します。
例えば、キーワード @code{Revision} に対して 
@code{$@asis{}Revision: 5.7 $} が生成されます。

@item -kkvl
@samp{-kkv} とほぼ同様ですが、
指定されたリビジョンがロックされていれば、
ロックしている人物の名前を挿入します。
ロックしている人物名は @code{cvs admin -l} が使用されているときだけ関
係があります。

@item -kk
キーワード文字列からキーワードのみを生成し、その値は省略されます。
例えば、キーワード @code{Revision} に対して、
@code{$@asis{}Revision: 5.7 $} ではなく、
@code{$@asis{}Revision$} が生成されます。
このオプションは、リビジョン間の違いを比較する時、
キーワードによる違いを無視するのに便利です (@pxref{Merging and
keywords})。

@item -ko
そのファイルが格納される前の、
古いキーワード文字列を生成します。
例えば、キーワード @code{Revision} に対して、
@code{$@asis{}Revision: 5.7 $} ではなく、
ファイルが格納された時の文字列である 
@code{$@asis{}Revision: 1.1 $} が生成されます。

@item -kb
@samp{-ko} と同様ですが、
リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、
クライアント側のオペレーティングシステムに適した形式へ変換しません。
行端にラインフィードのみが使用されるシステム (unix 等) では、
このオプションは @samp{-ko} と同じです。
バイナリ・ファイルの詳細情報は @ref{Binary files} 参照。

@item -kv
キーワードの値のみを生成します。
例えば、キーワード @code{Revision} に対して、
@code{$@asis{}Revision: 5.7 $} ではなく、
@code{5.7} が生成されます。
これは、@code{$@asis{}Revision: $} といった、
キーワード識別子を除くのが困難な
プログラミング言語のファイルを生成する時に便利です。
しかし、キーワード名が削除されてしまうために、
これ以後はキーワード置換を行うことができません。
従って使用には注意が必要です。

オプション @samp{-kv} は、@code{cvs export} で使用される事が
多くあります---@pxref{export}。
しかしモジュールがバイナリ・ファイルを含む場合は、
うまく処理できないので使用しない方が賢明です。

@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Log keyword
@section キーワード $@asis{}Log$ の問題点

キーワード @code{$@asis{}Log$} にはちょっと問題があります。
開発環境で作業をしているならば、
キーワード @code{$@asis{}Log$} を使用しなくても、
@code{cvs log} を使えば同じ情報が簡単に手に入ります。
いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。

さらに重要な問題は、枝を幹にマージするときに、
@sc{rcs} が @code{$@asis{}Log$} の項目をうまく扱えないことです。
このマージ操作の結果、衝突が起きることがよくあります。
@c Might want to check whether the CVS implementation
@c of RCS_merge has this problem the same way rcsmerge
@c does.  I would assume so....

またファイル中のログ・メッセージは、@emph{修復}される傾向にあります。
(綴の間違いやほんとの間違い等)。
しかしこの結果、
@code{cvs log} の情報とファイルの中身が一致しないことになります。
これも問題といえば問題でしょう。

どうしてもキーワード @code{$@asis{}Log$} を使うのならば、
ファイルの先頭ではなく、
ファイルの @emph{最後} に挿入することを推奨します。
この方法ならば、
長い変更メッセージを毎日眺めなくて済みます。

@c ---------------------------------------------------------------------
@node Tracking sources
@chapter サード・パーティーのソースの追っかけ
@cindex Third-party sources
@cindex Tracking sources

@c FIXME: Need discussion of added and removed files.
@c FIXME: This doesn't really adequately introduce the
@c concepts of "vendor" and "you".  They don't *have*
@c to be separate organizations or separate people.
@c We want a description which is somewhat more based on
@c the technical issues of which sources go where, but
@c also with enough examples of how this relates to
@c relationships like customer-supplier, developer-QA,
@c maintainer-contributor, or whatever, to make it
@c seem concrete.
あなたのサイトに合わせてプログラムを修正した場合、
そのプログラムの次のリリースにも同じ修正を加えたいでしょう。
@sc{cvs} を用いてこの作業を自動化することができます。

@cindex Vendor
@cindex Vendor branch
@cindex Branch, vendor-
@sc{cvs} の用語では、プログラムの開発元を@dfn{ベンダー} 
(@dfn{vendor}) と呼びます。
ベンダーの配布物は、
修正を加えずに @dfn{ベンダー枝} (@dfn{vendor branch}) という枝に格納します。
@sc{cvs} はこの為に 1.1.1 という番号を予約しています。

あなたがソースを修正して格納した場合、
そのリビジョンは幹に入ります。
ベンダーから新しいリリースが届いたら、
それをベンダー枝に加えて、修正を幹にコピーします。

ベンダー枝を作り、更新するには、
@code{import} コマンドを使用します。
新しいファイルを import すると、
ベンダー枝に `最初' のリビジョンが作られ、
@code{checkout} する人は誰でもそのリビジョンを取得します。
格納されたローカルな修正は幹に置かれ、
`最初' のリビジョンが作られます。

@menu
* First import::                初めて持ち込む
* Update imports::              import コマンドで更新する
* Reverting local changes::     最新のベンダーリリースに戻す
* Binary files in imports::     バイナリ・ファイルには特別な操作が必要
* Keywords in imports::         キーワード置換は望ましくない
* Multiple vendor branches::    複数の場所からソースを取得すると?
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node First import
@section 初めて持ち込む
@cindex Importing modules

@c Should mention naming conventions for vendor tags,
@c release tags, and perhaps directory names.
まず最初に、@code{import} コマンドを使ってソースを登録します。
@code{import} コマンドでサード・パーティーの追っかけをする場合には、
@dfn{ベンダー・タグ} (@dfn{vendor tag}) と
@dfn{リリース・タグ} (@dfn{release tag}) を用いると良いでしょう。
@dfn{ベンダー・タグ}は枝のタグ名です 
(@samp{-b @var{branch}} フラグを使用しなければ、
枝のリビジョンは常に 1.1.1 です---@xref{Multiple vendor branches}.)。
@dfn{リリース・タグ}は特定のリリースを指すタグ名で、
ここでは @samp{FSF_0_04} とします。

@c I'm not completely sure this belongs here.  But
@c we need to say it _somewhere_ reasonably obvious; it
@c is a common misconception among people first learning CVS
@code{import} は起動されたディレクトリを変更 @emph{しない} ことに注意
してください。特に、そのディレクトリが @sc{cvs} の作業ディレクトリとし
て設定されることはありません。ソースに作業をしたいなら、まずそれを持ち
込んで、それから違うディレクトリに取り出してください (@pxref{Getting
the source})。

@cindex Wdiff (import example)
ディレクトリ @file{wdiff-0.04} に @code{wdiff} というプログラムのソー
スがあるとします。将来に新しいリリースがなされたときでも適用したい個人
的な修正を加えようとしています。まず、リポジトリに @code{wdiff} のソー
スを加えることから始めましょう:

@example
$ cd wdiff-0.04
$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
@end example

上の例では、ベンダー・タグを @samp{FSF_DIST} とし、
唯一のリリース・タグを @samp{WDIFF_0_04} としています。
@c FIXME: Need to say where fsf/wdiff comes from.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Update imports
@section import コマンドで更新する

新しいリリースのソースが届いたら、
それを最初と同じく @code{import} コマンドでリポジトリに加えます。
違いは、最初と異なるリリース・タグを用いることだけです。

@example
$ tar xfz wdiff-0.05.tar.gz
$ cd wdiff-0.05
$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
@end example

ファイルがローカルな修正を受けてなければ、
今加えたものが最初のリビジョンになります。
ローカルな変更を加えていれば、
@code{import} コマンドは変更を幹にマージするように警告を出し、
@samp{checkout -j} を使うように促します。

@c FIXME: why "wdiff" here and "fsf/wdiff" in the
@c "import"?  I think the assumption is that one has
@c "wdiff fsf/wdiff" or some such in modules, but it
@c would be better to not use modules in this example.
@example
$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
@end example

@noindent
このコマンドで @samp{wdiff} の最新のリビジョンが取り出され、
@samp{yesterday} 以降にベンダー枝 @samp{FSF_DIST} に加えられた変更を、
作業コピーにマージします。
マージの過程で衝突が起きれば、通常の方法で解決して下さい 
(@pxref{Conflicts example})。
その後、変更したファイルを格納します。

上記の実行例のように日時を使用する場合、
一日に一つ以上のリリースを @code{import} しないと仮定しています。
この仮定に反するならば、次のようにして下さい:

@example
$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
@end example

@noindent
今の例では、上の二つのコマンドは等価です。

@node Reverting local changes
@section 最新のベンダーリリースに戻す

全てのファイルで `先頭' のリビジョンを変更してベンダー枝に戻すことで
ローカルの変更を完全に復旧し、最新のベンダーリリースに戻ることができま
す。例えば、ソースの取り出したコピーを @file{~/work.d/wdiff} に置いて
いて、そのディレクトリの全てのファイルをベンダーのバージョンに戻したい
のなら、次のように入力します:

@example
$ cd ~/work.d/wdiff
$ cvs admin -bWDIFF .
@end example

@noindent
@samp{-bWDIFF} は @samp{-b} の後空白を入れないで指定しなければなりませ
ん。@xref{admin options}.

@node Binary files in imports
@section cvs import でバイナリ・ファイルを扱う方法

@samp{-k} wrapper 機能オプションを使って、どのファイルがバイナリである
かを教えます。@xref{Wrappers}.

@node Keywords in imports
@section cvs import でキーワード置換を扱う方法

持ち込んでいるソースにキーワードがある場合があります (@pxref{Keyword
substitution})。例えば、ベンダーは @sc{cvs} や他の似たキーワード展開構
文を使うシステムを使っているかもしれません。既定の方法でファイルを持ち
込んだだけでは、ベンダーのキーワード展開があなた自身の @sc{cvs} コピー
でも行われます。この情報はベンダーから持ち込んだソースの情報であること
がありますから、ベンダーの展開を維持した方がより便利でしょう。

ベンダーのキーワード展開を維持するためには、最初にファイルを持ち込むと
きに @code{cvs import} に @samp{-ko} オプションを付けます。こうすると、
そのファイルのキーワード展開を完全に止めます。もっと選択的な方法を望む
場合は、@code{cvs update} や @code{cvs admin} に適切に @samp{-k} オプ
ションを使用します。
@c Supplying -ko to import if the file already existed
@c has no effect.  Not clear to me whether it should
@c or not.

@node Multiple vendor branches
@section 複数のベンダー枝

今までの例はソースを取得しているベンダーは一つだけだと仮定しています。
いろいろな場所からソースを得るような場合もあります。例えば、多くの違っ
た人やチームがソフトウェアを修正しているプロジェクトに関係しているとし
ます。これを扱う方法はいろいろありますが、たくさんのソースツリーが散ら
ばっていて、とりあえずやりたいことはそれら全てを CVS に放り込んで少な
くとも一箇所にまとめることだ、ということがあります。

複数のベンダーがある状況を扱うために、@code{cvs import} に @samp{-b}
オプションを指定できます。その引数は持ち込むベンダー枝です。既定値は
@samp{-b 1.1.1} です。

例えば、赤チームと青チームの2つのチームがあり、あなたにソースを送って
くるとします。赤チームが努力したものを枝 1.1.1 に持ち込んで、ベンダー
タグ RED を使いたいと思っています。青チームが努力したものは枝 1.1.3 に
持ち込んで、ベンダータグ BLUE を使おうとしています。使用するコマンドは
以下のようになります。

@example
$ cvs import dir RED RED_1-0
$ cvs import -b 1.1.3 dir BLUE BLUE_1-5
@end example

ベンダータグ が @samp{-b} オプションと合わなくても、CVS は発見しないこ
とに注意してください。例えば、

@example
$ cvs import -b 1.1.3 dir RED RED_1-0
@end example

@noindent
慎重に; この種類の不適当な組合せは混乱や、よりひどいことへの種になりま
す。不釣合いを指定することでの便利な使用をここでは考え付きません。もし
そのような使用を発見しても、使わないでください。CVS は将来のリリースで
はそれをエラーにするでしょう。

@c Probably should say more about the semantics of
@c multiple branches.  What about the default branch?
@c What about joining (perhaps not as useful with
@c multiple branches, or perhaps it is.  Either way
@c should be mentioned).

@c I'm not sure about the best location for this.  In
@c one sense, it might belong right after we've introduced
@c CVS's basic version control model, because people need
@c to figure out builds right away.  The current location
@c is based on the theory that it kind of akin to the
@c "Revision management" section.
@node Builds
@chapter 構築システムと CVS の関係方法
@cindex builds
@cindex make

紹介で書かれているように、@sc{cvs} にはソースコードからソフトウェアを
構築するためのソフトウェアはありません。この部分は構築システムが
@sc{cvs} と協調するかもしれない種々の側面を説明します。

@c Is there a way to discuss this without reference to
@c tools other than CVS?  I'm not sure there is; I
@c wouldn't think that people who learn CVS first would
@c even have this concern.
@sc{rcs} に慣れている人からの特に多い、よくある質問は、どうすれば構築
機構が最新のソースのコピーを手に入れることができるか、ということです。
@sc{cvs} では2重になります。まず最初に、@sc{cvs} はディレクトリを再帰
的に辿ることができますので、各ファイルが最新であることを確認するために 
@file{Makefile} (もしくは、構築ツールが使う設定ファイルの名前) を修正
する必要はありません。その代わりに、まず @code{cvs -q update} として、
それから @code{make} や構築ツールを起動するコマンドを実行するという2つ
のコマンドだけを使います。2番目に、あなた自身の作業が終わるまで、誰か
の変更したコピーを取得@emph{したい} と思わないかもしれません。1つの方
法はまずソースを更新して、それから実装、構築し、考えていた変更を試して
からソースを格納する (必要ならまず更新します) というものです。定期的に
(変更の合間に、さっき書いた方法で) 木全体を更新することで、ソースが十
分に新しいことを保証できます。

@cindex bill of materials
よくある要求は、どのソースファイルのどのリビジョンが特定の構築に相当す
るかを記録することです。このような種類の機能は @dfn{bill of materials} 
などと呼ばれることがあります。@sc{cvs} で実現する最良の方法は 
@code{tag}コマンドがどのバージョンが与えられた構築に相当するかを記録す
ることです (@pxref{Tags})。

@sc{cvs} を一番素直な方法で使うと、それぞれの開発者は特定の構築に使わ
れるソースツリー全体のコピーを持っています。ソースツリーが小さかったり、
開発者が地理的に離れたところにいるのなら、これが好ましい解決方法です。
実のところ、大きなプロジェクトを遂行する手段の一つはプロジェクトを小さ
な分割してコンパイルされるサブシステムに分け、開発者に必要なことは主に
作業しているサブシステムだけを取り出すだけにするように、内部でリリース
する方法を作ることです。
@c I say subsystem instead of module because they may or
@c may not use the modules file.

別の手段は、開発者にいくつかのファイルのコピーだけの所有をして、他のファ
イルには中央管理下のソースファイルを見に行くことができるようにする機構
を設定することです。多くの人は、大部分のオペレーティング・システムにあ
るシンボリックリンクや、@code{make} の多くのバージョンにある 
@code{VPATH} 機能を使う様な解決法に到達しました。
@c two such people are paul@sander.cupertino.ca.us (for
@c a previous employer)
@c and gtornblo@senet.abb.se (spicm and related tools),
@c but as far as I know
@c no one has nicely packaged or released such a system (or
@c instructions for constructing one).
このような種類のものを助けるために設計された構築ツールに Odin というも
のがあります (@code{ftp://ftp.cs.colorado.edu/pub/distribs/odin} 参照)。
@c Should we be saying more about Odin?  Or how you use
@c it with CVS?  Also, the Prime Time Freeware for Unix
@c disk (see http://www.ptf.com/) has Odin (with a nice
@c paragraph summarizing it on the web), so that might be a
@c semi-"official" place to point people.
@c
@c Of course, many non-CVS systems have this kind of
@c functionality, for example OSF's ODE
@c (http://www.osf.org/ode/) or mk
@c (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
@c He has changed providers in the past; a search engine search
@c for "Peter Ziobrzynski" probably won't get too many
@c spurious hits :-).  A more stable URL might be
@c ftp://ftp.uu.net/pub/cmvc/mk).  But I'm not sure
@c there is any point in mentioning them here unless they
@c can work with CVS.

@c ---------------------------------------------------------------------
@node Special Files
@chapter 特別なファイル

@cindex special files
@cindex device nodes
@cindex ownership, saving in CVS
@cindex permissions, saving in CVS
@cindex hard links
@cindex symbolic links

普通の環境では、CVS は普通のファイルでのみ動作します。プロジェクトの全
てのファイルは永続すると仮定されています。開き、読み込み、閉じるという
操作などが可能でなければなりません。また、CVS はファイルの使用許可と所
有権を無視します。そのような問題はインストール時に開発者によって解決さ
れる必要があります。言い換えれば、デバイスを "格納" することは不可能で
す。デバイスファイルを開けなければ、CVS はそれを扱うことを拒否します。
ファイルはリポジトリの取り扱い中にも所有権や使用許可を失います。

リポジトリで設定変数 @code{PreservePermissions} (@pxref{config}) が設
定されていると、CVS は以下のファイルの特性をリポジトリに記録します:

@itemize @bullet
@item 使用者とグループの所有権
@item 使用許可
@item 主・副デバイス番号
@item シンボリックリンク
@item ハードリンク機構
@end itemize

@code{PreservePermissions} オプションを使うと CVS の振舞いにいくつか影
響します。まず、CVS で使用可能になった新しい操作の中に、全ての使用者に
は使用可能でないものができます。特に、ファイルの所有権と特別なファイル
の特性とはスーパーユーザにだけ変更できるものでしょう。ですから、
@code{PreservePermissions} 設定変数が設定されていると、使用者は CVS の
操作をうるために `root' になる必要があるでしょう。

@code{PreservePermissions} が使用されていると、CVS の操作の中には 
(@samp{cvs status} のように) ファイルのハードリンク構造を認識せず、合っ
ていないハードリンクに関して見せかけの警告を出力します。これは CVS の
内部構造がハードリンクに必要なデータ全てを集めるのを難しくしており、そ
のために不正確なデータでファイルの衝突を調べるからです。

CVS はファイルの内容が変更されたときのみ、それが変更されたと考えること
による、より微妙な違いがあります (特に、作業ファイルの修正時刻がリポジ
トリのそのファイルと合わないとき)。ですから、使用許可、所有権、ハード
リンクが変わったり、デバイスの主、副番号が変わったとしても、CVS は報告
しません。そのような変更をリポジトリに格納するためには、@samp{cvs
commit -f} で格納を強制する必要があります。これは、ファイルの使用許可
が変わっていて、リポジトリのファイルが作業コピーより新しいと、
@samp{cvs update} の実行は、知らない間に作業コピーの使用許可を変更して
いるということでもあります。

CVS リポジトリでのハードリンクの変更は特に慎重な扱いが必要です。
@file{foo} がファイル @file{old} にリンクされていたけれど、後でファイ
ル @file{new} にリンクされ直したとしましょう。@file{foo}, @file{old},
@file{new} は全て中のリンクパターンは変更されているけれど、@file{foo} 
と @file{new} だけが修正されていて、そのために @file{old} は格納の候補
としてみなされない、という変な状況になることがあります。このような方法
により整合しない結果は非常に簡単に作られます。ですから、ハードリンクを
リポジトリに保存するのが重要なときは、賢明な動作方法は最後の格納からリ
ンクや状態が変わったファイル全てに @code{touch} することです。実際、複
雑なハードリンク構造のディレクトリを格納する前には @code{touch *} をす
るのが賢いかもしれません。

おそらく明らかである理由により、普通のファイルだけがマージできるという
ことを書いておくのも意味のあることでしょう。もし @samp{cvs update} や 
@samp{cvs checkout -j} がシンボリックリンクを普通のファイルとマージし
ようとしたり、2つのデバイスファイルが違った種類のデバイスのためのもの
であったりすると、CVS は衝突を報告して、マージの実行を拒否します。また、
テキストがないファイル上でのテキスト比較は無意味なので、@samp{cvs
diff} はこれらのファイル間の相違を報告しません。

@code{PreservePermissions} 機能はクライアント/サーバの @sc{cvs} では動
作しません。別の制限に、ハードリンクは同じディレクトリの他のファイルへ
のリンクでなければならない、というものがあります。ディレクトリをまたい
だハードリンクは使用できません。

@c ---------------------------------------------------------------------
@node CVS commands
@appendix CVS のコマンド便覧

この付録は @sc{cvs} コマンドの全体構造の説明をし、いくつかのコマンドは
詳しく説明します (他のものは別のところで説明されています。@sc{cvs} コ
マンドの簡単な便覧は、@pxref{Invoking CVS})。
@c The idea is that we want to move the commands which
@c are described here into the main body of the manual,
@c in the process reorganizing the manual to be
@c organized around what the user wants to do, not
@c organized around CVS commands.
@c
@c Note that many users do expect a manual which is
@c organized by command.  At least some users do.
@c One good addition to the "organized by command"
@c section (if any) would be "see also" links.
@c The awk manual might be a good example; it has a
@c reference manual which is more verbose than Invoking
@c CVS but probably somewhat less verbose than CVS
@c Commands.

@menu
* Structure::                   CVS コマンド構造の全て
* Exit status::                 CVS の成功か失敗を示す
* ~/.cvsrc::                    既定オプションと ~/.cvsrc ファイル
* Global options::              cvs_command の左側に付けるオプション
* Common options::              cvs_command の右側に付けるオプション
* admin::                       管理
* checkout::                    編集の為にソースを取り出す
* commit::                      ファイルをリポジトリに格納する
* diff::                        リビジョン間の差分を見る
* export::                      CVS からソースを取り出す, checkout に類似
* history::                     ファイルと使用者の状態を表示
* import::                      CVS にソースを取り込む, ベンダー枝を使用
* log::                         ファイルのログ情報を表示
* rdiff::                       リリース間の `patch' 形式の差分
* release::                     ディレクトリの放棄を表明する
* update::                      作業コピーをリポジトリと一致させる
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Structure
@appendixsec CVS コマンド構造の全て
@cindex Structure
@cindex CVS command structure
@cindex Command structure
@cindex Format of CVS commands

@sc{cvs} のコマンド全体の書式を示します:

@example
cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
@end example

@table @code
@item cvs
@sc{cvs} プログラムの名前です。

@item cvs_options
@sc{cvs} のサブコマンド全体に適用されるオプションです。以下で説明され
ています。

@item cvs_command
いくつかの違ったサブコマンドの一つです。
幾つかのコマンドでは別名が使用できます。別名はそのコマンドの便覧マニュ
アルのところで書かれています。
次の二つの場合にだけ @samp{cvs_command} を省略できます。
つまり @samp{cvs -H} として利用可能なコマンドのリストを得る場合か、
@samp{cvs -v} として @sc{cvs} 自身のバージョン情報を得る場合です。

@item command_options
コマンド固有のオプションです。

@item command_args
コマンドの引数です。
@end table

不幸な事に、
@code{cvs_options} と @code{command_options} の間で幾つか混乱があります。
@samp{-l} は @code{cvs_option} として使われたときいくつかのコマンドに
影響します。@code{command_option} として使されたときは、より多くのコマ
ンドで意味を持ちます。つまり、上の分類をあまり深刻に受けとめないでくだ
さい。代わりに文書を見るようにしましょう。

@node Exit status
@appendixsec CVS の終了状態
@cindex exit status, of CVS

CVS はそれ呼んだ環境に @dfn{終了状態} (@dfn{exit status}) を設定するこ
とで、成功したか失敗したかを示すことができます。
終了状態を調べる正確な方法はオペレーティング・システムごとに異なります。
例えば、unix のシェルスクリプトでは、最後のコマンドが成功終了状態を返
せば変数 @samp{$?} は0で、終了状態が失敗を示していれば、0より大きくな
ります。

CVS が成功した場合は、成功状態を返します。エラーがあれば、エラーメッセー
ジを印字して、失敗状態を返します。@code{cvs diff} コマンドはこの例外で
す。違いが見つからなければ成功状態を返し、違いが見つかるか、エラーが発
生したときに失敗状態を返します。この振舞いはエラーの検知には良くないの
で、将来では @code{cvs diff} が他の @sc{cvs} コマンドと同じように振舞
うように変更される可能性があります。
@c It might seem like checking whether cvs -q diff
@c produces empty or non-empty output can tell whether
@c there were differences or not.  But it seems like
@c there are cases with output but no differences
@c (testsuite basica-8b).  It is not clear to me how
@c useful it is for a script to be able to check
@c whether there were differences.
@c FIXCVS? In previous versions of CVS, cvs diff
@c returned 0 for no differences, 1 for differences, or
@c 2 for errors.  Is this behavior worth trying to
@c bring back (but what does it mean for VMS?)?

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node ~/.cvsrc
@appendixsec 既定オプションと ~/.cvsrc ファイル
@cindex .cvsrc file
@cindex option defaults

よく使用する @code{command_option} が幾つかあり、
そのオプションを必ず指定するように設定したいことがあります。
例えば (実際に .cvsrc を実装した要因の一つですが) 
多くの人には @samp{diff} の既定出力は大変読みにくく、
context 形式か unidiff 形式のほうが遥かに分かりやすいでしょう。

シェル・スクリプトやエイリアスに頼らなくても、
@file{~/.cvsrc} ファイルを用いて @code{cvs_commands} 各々に
既定のオプションを加えることができます。

@file{~/.cvsrc} の書式は簡単です。
実行された @code{cvs_command} と同じ名前で始まる行が検索されます。
一致した行を発見したら、行の残りの部分をオプションに分割し (空白のとこ
ろで)、
コマンド行からのオプションを与える@emph{前に}、
得られたオプションをコマンドの引数として与えます。
コマンドが別名を持つ場合 (例えば、@code{checkout} と @code{co})、
コマンド行で使われるものとは限りませんが、公的な名前がファイルとの
合致時に使用されます。
例えば @file{~/.cvsrc} の内容が次の様であった場合:

@example
log -N
diff -u
update -P
checkout -P
@end example

@noindent
@samp{cvs co foo} も、コマンド @samp{cvs checkout foo} と同様に 
@samp{-P} が引数として与えられます。

上記の例では @samp{cvs diff foobar} の出力は unidiff 形式になります。
@samp{cvs diff -c foobar} だと指定通り context 形式になります。
@samp{diff} には "古い" 形式で出力するためのオプションが無いため、
"古い" 形式を使いたい場合には少し面倒ですが 
@samp{cvs -f diff foobar} とする必要があります。

コマンド名の部分に @code{cvs} と記述すれば、
広域オプションを指定することができます (@pxref{Global options})。
例えば @file{.cvsrc} 中の以下の行は、

@example
cvs -z6
@end example

@sc{cvs} が圧縮レベル 6 を用いるように指定しています。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Global options
@appendixsec 広域オプション
@cindex Options, global
@cindex Global options
@cindex Left-hand options

@samp{cvs_options} (@samp{cvs_command} の左側に与えられる) 
として利用できるものを以下に示します:

@table @code
@item --allow-root=@var{rootdir}
正しい @sc{cvsroot} ディレクトリを指定します。@ref{Password
authentication server} 参照。

@cindex authentication, stream
@cindex stream authentication
@item -a
クライアントとサーバの全ての通信を認証します。@sc{cvs} クライアントで
だけ意味をもちます。これを書いている時点では、GSSAPI 接続を行う場合だ
けに実装されています (@pxref{GSSAPI authenticated})。認証は流れている 
@sc{tcp} 接続のハイジャックというような攻撃から身を守ることができます。
認証を使用しても暗号化は使用されません。

@cindex RCSBIN, overriding
@cindex Overriding RCSBIN
@item -b @var{bindir}
@sc{cvs} 1.9.18 以前では、これは @sc{rcs} プログラムが @var{bindir} ディ
レクトリにあることを指定していました。現在のバージョンの @sc{cvs} は 
@sc{rcs} プログラムを実行しません。互換性のためにこのオプションがあり
ますが、指定しても何もしません。

@cindex TMPDIR, overriding
@cindex Overriding TMPDIR
@item -T @var{tempdir}
一時ファイルが置かれるディレクトリを @var{tempdir} とします。
環境変数 @code{$TMPDIR} の設定や、
コンパイル時のディレクトリ設定よりも優先されます。
この値は絶対パス名で指定して下さい。

@cindex CVSROOT, overriding
@cindex Overriding CVSROOT
@item -d @var{cvs_root_directory}
リポジトリのルートディレクトリのパス名を @var{cvs_root_directory} とし
ます。
環境変数 @code{$CVSROOT} よりも優先します。@xref{Repository}.

@cindex EDITOR, overriding
@cindex Overriding EDITOR
@item -e @var{editor}
リビジョンのログ情報の入力に @var{editor} を使用します。
環境変数 @code{$CVSEDITOR} や @code{$EDITOR} よりも優先します。
詳しい情報は @ref{Committing your changes} 参照。

@item -f
@file{~/.cvsrc} を読みません。
このオプションが最も良く使われるのは、
@sc{cvs} のオプション設定に直交性がない時です。
例えば @samp{cvs log} のオプション @samp{-N} (タグの表示を抑制します)
に対応する表示を行なうオプションはありません。
従って、@file{~/.cvsrc} の @samp{log} エントリに @samp{-N} があったとき、
タグを表示するには @samp{-f} を使用する他ありません。

@item -H
@itemx --help
指定された @samp{cvs_command} の使用法を表示します 
(コマンドが実際に実行されることはありません)。
コマンド名を指定しない場合には、
@samp{cvs -H} は他のヘルプオプションの一覧などを含む、@sc{cvs} の全体
のヘルプを表示します。
@c It seems to me it is better to document it this way
@c rather than trying to update this documentation
@c every time that we add a --help-foo option.  But
@c perhaps that is confusing...

@item -l
@samp{cvs_command} をコマンド履歴に記録しません 
(しかしコマンドは実行されます)。
コマンド履歴の情報は @xref{history}.

@cindex Read-only mode
@item -n
ファイルを更新しません。
@samp{cvs_command} を実行した場合の表示だけが行なわれます。
既存のファイルを削除, 更新, マージしたり、
新しいファイルを作成することはありません。

@sc{cvs} は必ずしも @samp{-n} を付けなかったときと全く同じ出力をするわ
けではないことに注意してください。ときどき、出力が同じ場合がありますが、
他の場合では、@sc{cvs} は正確に同じ出力をするために必要な実行を飛ばし
ます。

@item -Q
コマンドの出力が完全に抑止され、
重大な問題が発生した場合にのみ出力が行なわれます。

@item -q
コマンドの出力を減らします。
再帰的にサブディレクトリを辿る時の報告などの補助情報は抑止されます。

@cindex read-only files, and -r
@item -r
新たな作業ファイルを読み込み専用にします。
環境変数 @code{$CVSREAD} を設定するのと同じ効果があります 
(@pxref{Environment variables})。
既定では、そのファイルが監視されてない限り作業ファイルへの書き込みが許
可されます (@pxref{Watches})。

@item -s @var{variable}=@var{value}
ユーザ変数を設定します (@pxref{Variables})。

@cindex Trace
@item -t
プログラムの実行状態をトレースします。
@sc{cvs} が実行する各ステップの情報を表示します。
@samp{-n} オプションと共に使用し、
不慣れなコマンドの潜在的な影響を調べるのに便利です。

@item -v
@item --version
@sc{cvs} のバージョンと著作権情報を表示します。

@cindex CVSREAD, overriding
@cindex Overriding CVSREAD
@item -w
新しい作業ファイルを読み書き可能にします。
環境変数 @code{$CVSREAD} の設定を無効にします。
@code{$CVSREAD} が設定されておらず、
@samp{-r} オプションも無い場合には、
作成されるファイルは読み書き可能とされます。
@c Note that -w only overrides -r and CVSREAD; it has
@c no effect on files which are readonly because of
@c "cvs watch on".  My guess is that is the way it
@c should be (or should "cvs -w get" on a watched file
@c be the same as a get and a cvs edit?), but I'm not
@c completely sure whether to document it this way.

@cindex encryption
@item -x
クライアントとサーバ間の全ての通信を暗号化します。これは @sc{cvs} クラ
イアントでだけ意味を持ち、また現時点では GSSAPI 接続を用いる場合 
(@pxref{GSSAPI authenticated}) かケルベロス接続 (@pxref{Kerberos
authenticated}) を用いる場合にしか実装されていません。暗号化を使用する
ということは送信されるメッセージも認証されるということです。既定状態で
は暗号化機能は使用できません。特別に @file{--enable-encryption} を指定
して @sc{cvs} を構築する必要があります。

@item -z @var{gzip-level}
圧縮レベルを設定します。
@sc{cvs} クライアントでだけ意味を持ちます。

@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Common options
@appendixsec 共通のコマンド・オプション
@cindex Common options
@cindex Right-hand options

ここでは、複数の @sc{cvs} コマンドで共通に使用できる 
@samp{command_options} について説明します。
これらのオプションは、
必ず @samp{cvs_command} の右側に付けられます。
以下に示すオプションは、全てのコマンドで使えるわけではありません。
各オプションは、それが意味をなすコマンドにおいてのみ使用可能です。
しかし以下のオプションを持つコマンドがあるならば、
そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。
(各コマンドの固有オプションのほとんどは、
他の @sc{cvs} コマンドのものとは異なる意味を持っています。)

 @strong{警告:} @samp{history} コマンドは例外です。このコマンドには、
ここに示す標準オプションと重複する固有オプションが多くあります。

@table @code
@cindex Dates
@cindex Time
@cindex Specifying dates
@item -D @var{date_spec}
@var{date_spec} 以前のリビジョンのうち、最新のものを使用します。
@var{date_spec} には、過去の日付を示すものを一つだけ指定します。

このオプションを用いて作業ファイルを取り出すと、
指定した日付が@dfn{貼り付け}られます。
つまり @samp{-D} オプションの引数が記録され、
これ以後の @code{update} の際に同じ日付が用いられます 
(貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
@samp{-D} は以下のコマンドで利用できます:
@code{checkout}, @code{diff}, @code{export}, @code{history},
@code{rdiff}, @code{rtag}, @code{update}.
(@code{history} コマンドはこのオプションを少し違った方法で使用します。
@pxref{history options}).

@c What other formats should we accept?  I don't want
@c to start accepting a whole mess of non-standard
@c new formats (there are a lot which are in wide use in
@c one context or another), but practicality does
@c dictate some level of flexibility.
@c * POSIX.2 (e.g. touch, ls output, date) and other
@c POSIX and/or de facto unix standards (e.g. at).  The
@c practice here is too inconsistent to be of any use.
@c * VMS dates.  This is not a formal standard, but
@c there is a published specification (see SYS$ASCTIM
@c and SYS$BINTIM in the _VMS System Services Reference
@c Manual_), it is implemented consistently in VMS
@c utilities, and VMS users will expect CVS running on
@c VMS to support this format (and if we're going to do
@c that, better to make CVS support it on all
@c platforms.  Maybe).
@c
@c NOTE: The tar manual has some documentation for
@c getdate.y (just for our info; we don't want to
@c attempt to document all the formats accepted by
@c getdate.y).
@c
@c One more note: In output, CVS should consistently
@c use one date format, and that format should be one that
@c it accepts in input as well.  The former isn't
@c really true (see survey below), and I'm not
@c sure that either of those formats is accepted in
@c input.
@c
@c cvs log
@c   current 1996/01/02 13:45:31
@c   Internet 02 Jan 1996 13:45:31 UT
@c   ISO 1996-01-02 13:45:31
@c cvs ann
@c   current 02-Jan-96
@c   Internet-like 02 Jan 96
@c   ISO 96-01-02
@c cvs status
@c   current Tue Jun 11 02:54:53 1996
@c   Internet [Tue,] 11 Jun 1996 02:54:53
@c   ISO 1996-06-11 02:54:53
@c   note: date possibly should be omitted entirely for
@c   other reasons.
@c cvs editors
@c   current Tue Jun 11 02:54:53 1996 GMT
@c cvs history
@c   current 06/11 02:54 +0000
@c any others?
@c There is a good chance the proper solution has to
@c involve at least some level of letting the user
@c decide which format (with the default being the
@c formats CVS has always used; changing these might be
@c _very_ disruptive since scripts may very well be
@c parsing them).
@c
@c Another random bit of prior art concerning dates is
@c the strptime function which takes templates such as
@c "%m/%d/%y", and apparent a variant of getdate()
@c which also honors them.  See
@c X/Open CAE Specification, System Interfaces and
@c Headers Issue 4, Version 2 (September 1994), in the
@c entry for getdate() on page 231

@cindex timezone, in input
@cindex zone, time, in input
@sc{cvs} では、様々な形式で日付を指定できます。
最も標準的なものは (International Standards Organization による) 
ISO8601 と (RFC 822 で規定され、RFC1123 で修正された) Internet e-mail
の標準です。

@c Probably should be doing more to spell out just what
@c the rules are, rather than just giving examples.
@c But I want to keep this simple too.
@c So I don't know....
@c A few specific issues: (1) Maybe should reassure
@c people that years after 2000
@c work (they are in the testsuite, so they do indeed
@c work).  (2) What do two digit years
@c mean?  Where do we accept them?  (3) Local times can
@c be ambiguous or nonexistent if they fall during the
@c hour when daylight savings time goes into or out of
@c effect.  Pretty obscure, so I'm not at all sure we
@c should be documenting the behavior in that case.
ISO8601 はいろんな異種があります。すこし例を挙げます:

@example
1972-09-24
1972-09-24 20:05
@end example
@c I doubt we really accept all ISO8601 format dates
@c (for example, decimal hours like 1972-09-24 20,2)
@c I'm not sure we should, many of them are pretty
@c bizarre and it has lots of gratuitous multiple ways
@c to specify the same thing.

ISO8601 の日付様式にはいろいろなものがあり、CVS はそれらの多くを受け付
けますが、おそらくながーい話し@emph{全部}を聞きたいとは思わないでしょ
う :-)。

@c Citing a URL here is kind of problematic given how
@c much they change and people who have old versions of
@c this manual, but in case we want to reinstate an
@c ISO8601 URL, a few are:
@c http://www.saqqara.demon.co.uk/datefmt.htm
@c http://www.cl.cam.ac.uk/~mgk25/iso-time.html
@c Citing some other ISO8601 source is probably even
@c worse :-).

Internet e-mail で使用が認められている日付に加えて、
@sc{cvs} では、いくつかのフィールドが省略されたものも使えます。
例えば、以下のようなものです:
@c FIXME: Need to figure out better, and document,
@c what we want to allow the user to omit.
@c NOTE: "omit" does not imply "reorder".
@c FIXME: Need to cite a web page describing how to get
@c RFC's.

@example
24 Sep 1972 20:05
24 Sep
@end example

特定の標準時が指定されていない場合は、日付はローカルの標準時として解釈
されます。

この2つの書式の使用が好まれます。しかし、@sc{cvs} は今は他の日付の書式
を幅広く受け付けます。それらはここでは故意に詳しくは説明されておらず、
@sc{cvs} の将来のバージョンはそれら全ては受け付けないかもしれません。
@c We should document and testsuite "now" and
@c "yesterday".  "now" is mentioned in the FAQ and
@c "yesterday" is mentioned in this document (and the
@c message from "cvs import" suggesting a merge
@c command).  What else?  Probably some/all of the "3
@c weeks ago" family.
@c
@c Maybe at
@c some point have CVS start give warnings on "unofficial"
@c formats (many of which might be typos or user
@c misunderstandings, and/or formats people never/rarely
@c use to specify dates)?

そのような書式の中に
@code{@var{月}/@var{日}/@var{年}}.  というものがあります。
これは月と日が逆の順番になっているものに慣れている人を混乱させます。
@samp{1/4/96} は1月4日であり、4月1日ではありません。

シェルは空白を引数の区切りにするので、
@samp{-D} の引数を引用符で囲むのを忘れてはいけません。
@samp{-D} オプションを付けたコマンド行は、次の様になるでしょう:

@example
$ cvs diff -D "1 hour ago" cvs.texinfo
@end example

@cindex Forcing a tag match
@item -f
日付やタグ名を指定して @sc{cvs} コマンドを用いた場合、
そのタグ名を持たない (その時には存在しなかった) ファイルは、
普通は無視されます。
タグでも日付でも引っ掛からなかったファイルを復元したい場合に、
@samp{-f} オプションを使用します 
(そのファイルの最新のリビジョンが取り出されます)。

@samp{-f} のときでさえ、指定したタグは存在していなければならないことに
注意してください (すなわち、必ずしも全てのファイルというわけではなく、
いくつかのファイルにおいて)。 これは @sc{cvs} が、名前の入力を間違えた
ときにエラーを出すことを続けられるようにするためです。

@need 800
@samp{-f} は以下のコマンドで利用できます: 
@code{annotate}, @code{checkout}, 
@code{export}, @code{rdiff}, @code{rtag}, @code{update}.

@strong{警告:} @code{commit} と @code{remove} コマンドにも @samp{-f} 
オプションがありますが、異なる動作をします。@xref{commit options}, 
@ref{Removing files} 参照。

@item -k @var{kflag}
既定のキーワード置換モードを変更します。
@var{kflag} の詳細は @ref{Substitution modes} 参照。

このオプションを用いて作業ファイルを取り出すと、
@var{kflag} が@dfn{貼り付け}られます。
つまり、このオプションを @code{checkout} や @code{update} コマンドに
用いた場合、@sc{cvs} は指定した @var{kflag} をそのファイルに結合します。
これ以後、同ファイルに対する @code{update} コマンドには 
@var{kflag} が使用され続けます。
この効果は別の指定を行なうまで止みません。

@samp{-k} オプションは以下のコマンドで利用できます: @code{add}, 
@code{checkout}, @code{diff}, @code{import}, @code{update}.

@item -l
Local の頭文字です。再帰的にサブディレクトリを辿らず、
カレントディレクトリでのみコマンドを実行します。

@strong{警告:} @samp{cvs_command} の左側に指定する 
@samp{cvs -l} と混同しないようにして下さい。

以下のコマンドで利用できます: @code{annotate}, @code{checkout},
@code{commit}, @code{diff}, @code{edit}, @code{editors},
@code{export}, @code{log}, @code{rdiff}, @code{remove}, @code{rtag},
@code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
and @code{watchers}.

@cindex Editor, avoiding invocation of
@cindex Avoiding editor invocation
@item -m @var{message}
@item -m @var{message}
エディタを起動せず、ログ情報を @var{message} に記述します。

以下のコマンドで利用できます: @code{add}, 
@code{commit}, @code{import}.

@item -n
@code{checkout}/@code{commit}/@code{rtag} コマンド実行時に、
常には実行されるプログラムを実行しません。
各コマンド実行時のプログラムは、
管理用ファイル @file{modules} に記述されます 
(@pxref{modules})。
つまり、このオプションは @file{modules} の記述を無効にします。

@strong{警告:} @samp{cvs_command} の左側に指定する 
@samp{cvs -n} と混同しないようにして下さい。

以下のコマンドで利用できます:
@code{checkout}, @code{commit}, @code{export}, 
@code{rtag}.

@item -P
空のディレクトリを削除 (prune) します。@ref{Removing directories} 参照。

@item -p
リポジトリから取得したファイルを、カレントディレクトリに置かず、
標準出力に送り (pipe) ます。

以下のコマンドで利用できます: @code{checkout}, @code{update}.

@item -R
再帰的にディレクトリを辿って実行します。これは指定しなくても実行されま
す。

以下のコマンドで使用可能です: @code{annotate}, @code{checkout},
@code{commit}, @code{diff}, @code{edit}, @code{editors},
@code{export}, @code{rdiff}, @code{remove}, @code{rtag},
@code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
@code{watchers}.

@item -r @var{tag}
@cindex HEAD, special tag
@cindex BASE, special tag
既定の@dfn{先頭} (@dfn{head}) リビジョンの代りに、
引数 @var{tag} で指定されたリビジョンを使用します。
@code{tag} か @code{rtag} コマンドで任意に定義されたタグの他に、
二つの特別なタグ @samp{HEAD} と @samp{BASE} が常に利用できます。
@samp{HEAD} は、リポジトリにある最新のリビジョンを参照します。
@samp{BASE} は、作業コピーの由来となるリビジョンを参照します。

@c FIXME: What does HEAD really mean?  I believe that
@c the current answer is the head of the default branch
@c for all cvs commands except diff.  For diff, it
@c seems to be (a) the head of the trunk (or the default
@c branch?) if there is no sticky tag, (b) the head of the
@c branch for the sticky tag, if there is a sticky tag.
@c (b) is ugly as it differs
@c from what HEAD means for other commands, but people
@c and/or scripts are quite possibly used to it.
@c See "head" tests in sanity.sh.
@c Probably the best fix is to introduce two new
@c special tags, ".thead" for the head of the trunk,
@c and ".bhead" for the head of the current branch.
@c Then deprecate HEAD.  This has the advantage of
@c not suprising people with a change to HEAD, and a
@c side benefit of also phasing out the poorly-named
@c HEAD (see discussion of reserved tag names in node
@c "Tags").  Of course, .thead and .bhead should be
@c carefully implemented (with the implementation the
@c same for "diff" as for everyone else), test cases
@c written (similar to the ones in "head"), new tests
@c cases written for things like default branches, &c.

タグを指定して @code{checkout} や @code{update} コマンドを実行し、
自分の作業ファイルを作った場合、そのタグは貼り付けられます。
つまりこのタグが記録され、以後他のものを指定するまで 
@code{update} に同じタグが使われ続けます 
(貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。

@var{tag} には、@ref{Tags} で説明されているような文字列や、
@ref{Branching and merging} で説明されているような枝の名前のどちらであ
ることもできます。

コマンド・オプション @samp{-r} と一緒に
広域オプション @samp{-q} を指定すると、
@sc{rcs} ファイルが指定したタグを含まない場合に、
警告出力が抑止されるので便利です。

@strong{警告:} @samp{cvs_command} の左側に指定する 
@samp{cvs -r} と混同しないようにして下さい!

@samp{-r} は以下のコマンドで利用できます :@code{checkout},
@code{commit}, @code{diff}, @code{history}, @code{export},
@code{rdiff}, @code{rtag}, @code{update}.

@item -W
フィルタを適用したいファイルを指定します。
フィルタを適用したいファイルが複数あるときは、
このオプションを何個並べても構いません。
ファイル @file{.cvswrappers} での指定方法と同じ形式で指定します。

以下のコマンドで利用できます: @code{import}, @code{update}.

@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node admin
@appendixsec admin---管理
@cindex Admin (subcommand)

@itemize @bullet
@item
必須: リポジトリ, 作業ディレクトリ
@item
変更: リポジトリ
@item
別名: rcs
@end itemize

これは雑多な管理機構への @sc{cvs} のインターフェースです。@sc{cvs} で
は役に立つか疑わしいようなものもありますが、歴史的な互換性の目的のため
に存在しています。このコマンドは@emph{必ず}再帰的に動作するため、使用
の際には細心の注意を払って下さい。

@cindex cvsadmin
Unix ではグループ名 @code{cvsadmin} が存在する場合、
そのグループの一員だけが @code{cvs admin} を利用できます
(誰にで実行できる @code{cvs admin -k} コマンドを除きます)。
このグループはサーバ側か、非クライアント/サーバの @sc{cvs} を実行してい
る全てのシステムで存在している必要があります。
その名前で無人のグループを作成すれば、
@code{cvs admin} の使用を全面的に禁止できます。
NT では、@code{cvsadmin} 機能は存在せず、全ての使用者が @code{cvs
admin} を実行できます。

@menu
* admin options::               admin のオプション
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node admin options
@appendixsubsec admin のオプション

これらのオプションの中には @sc{cvs} での有用性に疑問符が付くものもあり
ますが、歴史的な互換性のために存在しています。中には、効果を解除するま
で、@sc{cvs} を使えなくなるものもあります!

@table @code
@item -A@var{oldfile}
@sc{cvs} では使用されません。@var{oldfile} の利用者一覧を、
指定した @sc{rcs} ファイルの利用者一覧に追加します。

@item -a@var{logins}
@sc{cvs} では使用されません。@sc{rcs} ファイルの利用者一覧に、
@var{logins} で指定された利用者を追加します。
@var{logins} はカンマで区切った利用者の一覧です。

@item -b[@var{rev}]
既定の枝を @var{rev} に設定します。@sc{cvs} では、普通は既定の枝は操作
しません。貼り付いたタグ (@pxref{Sticky tags}) を使うのがどの枝で作業
をするかを決める良い方法です。@code{cvs admin -b} を実行する理由は一つ
だけあります: ベンダー枝を使用しているときに、ベンダーのバージョンに戻
すため、です (@pxref{Reverting local changes})。@samp{-b} と引数の間に
空白があってはいけません。
@c Hmm, we don't document the usage where rev is
@c omitted.  Maybe that usage can/should be deprecated
@c (and replaced with -bHEAD or something?) (so we can toss
@c the optional argument).  Note that -bHEAD does not
@c work, as of 17 Sep 1997, but probably will once "cvs
@c admin" is internal to CVS.

@cindex comment leader
@item -c@var{string}
註釈符を @var{string} にします。註釈符は現在のバージョンの @sc{cvs} で
も、@sc{rcs} 5.7 でも使用されていません。ですから、心配する必要は全く
ありません。@xref{Keyword substitution}.

@item -e[@var{logins}]
@sc{cvs} では使用されません。@var{logins} に含まれる利用者を、
@sc{rcs} ファイルの利用者一覧から削除します。
@var{logins} が省略された場合は、利用者一覧を全て削除します。
@samp{-e} と引数の間に空白があってはいけません。

@item -I
標準入力が端末でない場合でも対話的に動作します。
このオプションはクライアント/サーバの @sc{cvs} では動作せず、将来の
@sc{cvs} のリリースからは消えるでしょう。

@item -i
@sc{cvs} では無意味です。これはリビジョンを作成することなく、新しい 
@sc{rcs} ファイルを作成して、初期化します。@sc{cvs} では、@code{cvs
add} コマンドでファイルを加えてください (@pxref{Adding files})。

@item -k@var{subst}
既定のキーワード置換モードを 
@var{subst} にします。@xref{Substitution modes}.
ここで既定とした方法よりも、
@code{cvs update}, @code{cvs export}, @code{cvs checkout}
での @samp{-k} オプションが優先されます。

@item -l[@var{rev}]
リビジョン @var{rev} をロックします。
枝番号が与えられた場合、その枝の最新リビジョンをロックします。
@var{rev} が省略された場合は、
既定の枝の最新リビジョンをロックします。
引数 と @samp{-l} の間にスペースがあってはいけません。

@sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
@file{rcslock.pl} という名前のスクリプトがあります。
これを用いて上記のロック状態を、
@sc{cvs} における独占取得 (一時に一人だけがファイル編集可能な状態) 
に置き換えることができます。
詳細はスクリプトの註釈を参照して下さい 
(寄贈物の支援と権利の放棄声明文が書かれたファイル @file{README} 
も一読して下さい)。
その註釈によれば、厳格ロックモード (既定) に設定しておく必要があります。

@item -L
厳格にロックを求める設定 (厳格ロックモード) にします。
厳格ロックモードだと、@sc{rcs} ファイルの所有者であっても、
ロックしていないファイルは格納できません。
@sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
上記 @samp{-l} オプションの説明も参照して下さい。

@cindex Changing a log message
@cindex Replacing a log message
@cindex Correcting a log message
@cindex Fixing a log message
@cindex Log message, correcting
@item -m@var{rev}:@var{msg}
リビジョン @var{rev} のログ・メッセージを @var{msg} に替えます。

@c The rcs -M option, to suppress sending mail, has never been
@c documented as a cvs admin option.

@item -N@var{name}[:[@var{rev}]]
これ以前の @var{name} の設定を無効にすることを除けば、
@samp{-n} と同じように働きます。
魔法の枝での使用法は @ref{Magic branch numbers} を参照してください。

@item -n@var{name}[:[@var{rev}]]
枝またはリビジョン @var{rev} にタグ名 @var{name} を付けます。
通常は @samp{cvs tag} か @samp{cvs rtag} を代わりに用いると良いでしょう。
@samp{:} と @var{rev} の両方を省略すると、タグ名が削除されます。
また @var{name} が既に使用されていた場合は、
エラー・メッセージが出力されます。
@var{rev} がタグ名のときは、相当する番号に置換されます。
枝番号の後に @samp{.} を付けて @var{rev} に指定した場合、
その枝の現時点での最新リビジョンになります。
@samp{:} だけで @var{rev} を指定しなかった場合、
既定の枝 (通常は幹) の現時点での最新リビジョンになります。
例えば @samp{cvs admin -n@var{name}: RCS/*} は、
指定された全ての RCS ファイルの、
現時点での最新リビジョンに @var{name} というタグ名を付けます。
一方 @samp{cvs admin -n@var{name}:$ RCS/*} では、
各作業ファイルのキーワード文字列に含まれる
リビジョンに @var{name} というタグ名を付けます。

@cindex Deleting revisions
@cindex Outdating revisions
@cindex Saving space
@item -o@var{range}

@var{range} の範囲のリビジョンを消去 (@dfn{過去のものにする}) します。

このコマンドは何をしているかを @emph{正確に} 知っていないと非常に危険
であることに注意してください (例えば、以下の @var{rev1:}@var{rev2} と
いう構文がいかに間違いやすいかという警告を読んでください)。

ディスクの容量が少ないなら、このオプションは役に立つかもしれません。し
かし、使う前によく考えてください---このコマンドを取り消すためには最後
のバックアップで復元するしかありません! 不注意や、(天が禁止している) 
CVS のバグによって、計画していたものと違うリビジョンを消してしまったら、
リビジョンが消去される前のエラーを修正する機会はありません。おそらく、
まずリポジトリのコピーで試すというのは良い考えでしょう。

以下のどれかで @var{range} を指定します:

@table @code
@item @var{rev1}::@var{rev2}
CVS が rev1 から rev2 に関連付けられた差分だけを保存し、間の段階を保存
しないように、rev1 と rev2 間の全てのリビジョンを壊します。例えば、
@samp{-o 1.3::1.5} の後では、リビジョン 1.3, リビジョン 1.5, 1.3 から 
1.5 の差分を取得することができますが、リビジョン 1.4 や 1.3 と 1.4 の
差分を取得することはできません。他の例です: @samp{-o 1.3::1.4} と
@samp{-o 1.3::1.3} は間に消去するリビジョンが無いので、何の効果もあり
ません。

@item ::@var{rev}
@var{rev} のある枝と @var{rev} 自身の間のリビジョンを壊します。枝の始
点と @var{rev} はそのまま残ります。例えば、@samp{-o ::1.3.2.6} はリビ
ジョン 1.3.2.1, リビジョン 1.3.2.5, とその間の全てのものを消去しますが、
1.3 と 1.3.2.6 はそのまま残します。

@item @var{rev}::
@var{rev} と @var{rev} のある枝の最後との間のリビジョンを壊します。リ
ビジョン @var{rev} はそのまま残りますが、先頭のリビジョンは消去されま
す。

@item @var{rev}
リビジョン @var{rev} を消去します。例えば、@samp{-o 1.3} は @samp{-o
1.2::1.4} と等価です。

@item @var{rev1}:@var{rev2}
同じ枝の @var{rev1} から @var{rev2} のリビジョンを、それを含めて消去し
ます。@var{rev1} や @var{rev2} やその間の全てのリビジョンを取得するこ
とはできなくなります。例えば、コマンド @samp{cvs admin -oR_1_01:R_1_02
.} はほとんど役に立ちません。それは、タグ R_1_02 までのリビジョンを、
それを含めて消去するということです。でも注意してください! R_1_02 と 
R_1_03 で変更されていないファイルがあれば、そのファイルはタグ R_1_02 
と R_1_03 で@emph{同じ}数値リビジョン番号になっています。ですから、
R_1_02 を取得できなるだけではありません。R_1_03 もテープから復元しなけ
ればならなくなります! たいていの場合、代わりに @var{rev}::@var{rev2}
と指定しようと思うでしょう。

@item :@var{rev}
@var{rev} のある枝の最初から、@var{rev} までのリビジョンを、それを含め
て消去します。

@item @var{rev}:
@var{rev} のある枝の最後から、@var{rev} までのリビジョンを、それを含め
て消去します。
@end table

消去されるべきリビジョンは全て枝やロックを持っていてはいけません。

消去されるべきリビジョンにタグ名があり、@samp{::} 構文のどれかを指定
すると、@sc{cvs} はエラーを出して、どのリビジョンも消去されません。タ
グ名とリビジョンの両方を消去したいなら、まず @code{cvs tag -d} でタグ
名を消去し、それから @code{cvs admin -o} を実行します。@samp{::} でな
い構文をいてい すると、@sc{cvs} はリビジョンを消去しますが、タグ名を存
在しないリビジョン指すタグ名として残します。この振舞いは @sc{cvs} の以
前のバージョンとの互換性のために残されています。しかし、これは便利では
ありませんので、将来は @samp{::} の場合と同様の振舞いに変更されるかも
しれません。

@sc{cvs} が枝を扱う方法のために、@var{rev} は、もし枝であれば名前で指
定することはできません。説明は、@xref{Magic branch numbers}.
@c FIXME: is this still true?  I suspect not.

だれも壊したリビジョンのコピーを取り出していないことを確認してください。
誰かがそれを編集して、格納し直そうとすると、変なことが起こります。この
ため、このオプションは無駄な格納を戻すためには良い方法ではありません。
代わりにその変更を元に戻すための新しいリビジョンを格納してください 
(@pxref{Merging two revisions})。

@item -q
簡素な (quiet) 表示、つまり実行時に診断情報を表示しません。

@item -s@var{state}[:@var{rev}]
@sc{cvs} でも使用します。
リビジョン @var{rev} の状態を識別する文字列を @var{state} にします。
@var{rev} が枝番号の場合、その枝の最新リビジョンの状態を変更します。
@var{rev} を省略すると、既定の枝の最新リビジョンを変更します。
@var{state} には、どのような文字列を用いても構いません。
通常使用されるのは、@samp{Exp} (実験段階), @samp{Stab} (安定動作), 
@samp{Rel} (出荷済) といった組み合わせです。
既定では、新しく作成されたリビジョンの状態は @samp{Exp} にされます。
各リビジョンの状態は、@samp{cvs log} (@pxref{log}) の出力や、
キーワード @samp{$@asis{}Log$}, @samp{$@asis{}State$}
(@pxref{Keyword substitution}) の内容で確認できます。
ここで、@sc{cvs} が @code{dead} という状態を
独自の目的で用いることに注意して下さい。
@code{dead} 状態を扱う際には、@code{cvs remove} 
や @code{cvs add} といったコマンドを使用し、
@samp{cvs admin -s} を使用してはいけません。

@item -t[@var{file}]
@sc{cvs} でも使用します。
@sc{rcs} ファイルの説明文を @var{file} の内容に書き換えます。
@var{file} のパス名は @samp{-} で始まってはいけません。
各ファイルの説明文は @samp{cvs log} (@pxref{log}) の出力で確認できます。
@samp{-t} と引数の間に空白があってはいけません。

@var{file} が省略された場合、標準入力が用いられ、
ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
対話的動作が可能なら入力促進も可能です。@samp{-I} を参照してださい。
クライアント/サーバの @sc{cvs} では標準入力からの読み込みは動作せず、
将来の @sc{cvs} のリリースでは変更されるかもしれません。
@c Changing it to doeditor() is the most obvious thing
@c (but with a different syntax, as we would like to
@c phase out optional arguments).  I don't know.  I'm
@c tempted to say the whole concept is unnecessary.

@item -t-@var{string}
@samp{-t@var{file}} と同様です。
@sc{rcs} ファイルの説明文を @var{string} に書き換えます。
@samp{-t} と引数の間に空白があってはいけません。

@c The rcs -T option, do not update last-mod time for
@c minor changes, has never been documented as a
@c cvs admin option.

@item -U
厳格にはロックしない設定 (非厳格ロックモード) にします。
非厳格ロックモードだと、@sc{rcs} ファイルの所有者ならば、
ロックしていないファイルも格納できます。
@sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
上記 @samp{-l} オプションの説明も参照して下さい。

@item -u[@var{rev}]
このオプションを @sc{cvs} で使用する際の説明は、
上記 @samp{-l} オプションを参照して下さい。
リビジョン @var{rev} のロックを解除します。
枝を指定した場合、その枝の最新リビジョンのロックを解除します。
@var{rev} を省略すると、その人物が行なった最後のロックを解除します。
通常は、ロックを掛けた人物だけがロックを解除できます。
誰か他の人物がロックを解除した場合には、
ロックを掛けた人物にメールが送信されます。
このメールにはロックを解除した理由等が書き添えられます。
連絡文はロックを解除した人物が入力し、
ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
@samp{-u} とその引数の間に空白があってはいけません。
@c In the future "send mail" probably will go via the
@c CVSROOT/notify mechanism.  But for now it means
@c whatever it means to "rcs".

@item -V@var{n}
前のバージョンの @sc{cvs} ではこのオプションはバージョン @var{n} の 
@sc{rcs} ファイルが認識できる @sc{rcs} ファイルを書くことを意味してい
ましたが、今は旧式となり、それを指定するとエラーを起こします。
@c Note that -V without an argument has never been
@c documented as a cvs admin option.

@item -x@var{suffixes}
前のバージョンの @sc{cvs} では、これは @sc{rcs} ファイルの名前を指定す
るための方法として説明されていました。しかし、@sc{cvs} は常に @sc{cvs} 
で使用される @sc{rcs} ファイルは @samp{,v} で終わることを要求してきま
したので、このオプションは今まで役に立ったことはありません。

@c The rcs -z option, to specify the timezone, has
@c never been documented as a cvs admin option.
@end table


@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node checkout
@appendixsec checkout---編集の為にソースを取り出す
@cindex Checkout (subcommand)
@cindex Co (subcommand)

@itemize @bullet
@item
書式: checkout [options] modules@dots{}
@item
必須: リポジトリ
@item
変更: 作業ディレクトリ
@item
別名: co, get
@end itemize

@var{modules} で指定されたモジュールの作業ディレクトリを作成、
もしくは更新し、
その中にソース・ファイルをコピーします。
@sc{cvs} のほとんどのコマンドは作業ディレクトリを扱うものなので、
まず @code{checkout} を実行しておく必要があります。

@var{modules} は、
リポジトリ中のディレクトリやファイルへの相対パスだけでなく、
ディレクトリやファイルの集合に対する別名でも構いません。
別名は管理用ファイル @file{modules} で定義します 
@xref{modules}.
@c Needs an example, particularly of the non-"modules"
@c case but probably of both.

@c FIXME: this seems like a very odd place to introduce
@c people to how CVS works.  The bit about unreserved
@c checkouts is also misleading as it depends on how
@c things are set up.
指定したモジュールにもよりますが、
@code{checkout} は再帰的にディレクトリを作成し、
そこに適切なソース・ファイルを入れていきます。
そして (他の開発者が各自のコピーを編集しているかどうかに関わらず)、
好きなときに自分のソース・ファイルを編集し、
他人の変更を取り入れるために更新したり、
自分の変更をリポジトリに反映するために格納したりします。

@code{checkout} で作成されるディレクトリに注意して下さい。
最上位のディレクトリは、
必ず @code{checkout} を実行したディレクトリに追加され、
通常は指定したモジュールと同じ名前になります。
モジュールに別名が定義されている場合、
サブディレクトリは違う名前になりますが心配は要りません。
@code{checkout} の処理中、各ファイルを作業領域に展開したと同時に
その相対パスが表示されますから、
この表示でサブディレクトリを確認して下さい 
(広域オプション @samp{-Q} を付けた場合は表示がありません)。

@sc{cvs} にオプション @samp{-r} が付けられた場合 
(@pxref{Global options})、
環境変数 @code{CVSREAD} が設定されていた場合 
(@pxref{Environment variables})、
ファイルが監視されていた場合 
(@pxref{Watches}) を除いて、
@code{checkout} が作成するファイルは読み書き可能な状態になります。

@code{checkout} で作成したディレクトリの上で、
再度 @code{checkout} を実行しても構わないということに注意してください。
これはリポジトリに作成された新しいディレクトリが作業領域に現れるという
点で、@code{update} コマンドに @samp{-d} オプションを付けるのと同様の
効果があります。しかし、@code{update} は引数にディレクトリ名を取ります
が、@code{checkout} は引数にモジュール名を取ります。@code{checkout} を
この様に使うためには、最上位のディレクトリから実行しなければなりません
ので (普段 @code{checkout} を実行する場所です)、存在するディレクトリを
更新するために @code{checkout} を実行する前に、ディレクトリを最上位の
ディレクトリに変更することを忘れないでください。

@code{checkout} コマンドの出力は @ref{update output} を参照して下さい。

@menu
* checkout options::            checkout のオプション
* checkout examples::           checkout の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node checkout options
@appendixsubsec checkout のオプション

@code{checkout} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -D @var{date}
@var{date} 以前の最も新しいリビジョンを取り出します。
このオプションは貼り付けられ、
勝手に @samp{-P} オプションも実行されます。
貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.

@item -f
@samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを取り出します。

@item -k @var{kflag}
キーワード置換モードを @var{kflag} に指定します。
詳細は @ref{Substitution modes} を参照。
このオプションは貼り付けられます。つまりこれ以後、
この作業ディレクトリでファイルが更新されるときには、
同じ @var{kflag} が使用され続けます。
@code{status} コマンドを用いて
貼り付いたオプションを見ることができます。
@code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。

@item -n
ファイルを取り出したとき、普段は実行されるプログラムを実行しません。
このプログラムは管理用ファイル @file{modules} の
オプション @samp{-o} で指定されます (@pxref{modules})。

@item -P
空になったディレクトリを削除 (prune) します。@ref{Moving directories}
を参照してください。

@item -p
ファイルを標準出力に送り (pipe) ます。

@item -R
ディレクトリを再帰的に取り出します。このオプションは指定しなくても実行
されます。

@item -r @var{tag}
@var{tag} で指定されたリビジョンを取り出します。
このオプションは貼り付けられ、
@samp{-P} オプションも勝手に実行されます。
貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
@end table

さらに @code{checkout} では次の固有オプションも使用可能です:

@table @code
@item -A
全ての貼り付いたタグや日付、
また @samp{-k} オプションの指定を剥がします。
貼り付いたタグ/日付についての詳細は @ref{Sticky tags} を参照してくだ
さい。

@item -c
管理用ファイル @file{modules} の内容を、
アルファベット順に並べて標準出力に出します。
作業ディレクトリは全く変更されません。

@item -d @var{dir}
モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
一般的に、このフラグは @samp{mkdir @var{dir}; cd @var{dir}} の後に 
@samp{-d} フラグ無しで checkout コマンドを実行することと同じです。

しかし、重要な例外があります。単独の項目を取り出しているときには、出力
に間に空のディレクトリが無いディレクトリが現れた方がとても便利です。こ
の場合@emph{のみ}、CVS は空のディレクトリを避けるためにパス名を ``短く'' 
します。

例えば、ファイル @samp{bar.c} がある @samp{foo} というモジュールがある
とすると、コマンド @samp{cvs co -d dir foo} はディレクトリ @samp{dir}
を作成し、中に @samp{bar.c} を置きます。同様に、サブディレクトリ 
@samp{baz} があり、その中に @samp{quux.c} のあるモジュール @samp{bar} 
があるとすると、コマンド @samp{cvs -d dir co bar/baz} はディレクトリ 
@samp{dir} 作成し、その中に @samp{quux.c} を置きます。

@samp{-N} フラグを使うと、この振舞いは抑制されます。上と同じモジュール
の定義で、@samp{cvs co -N -d dir foo} はディレクトリ @samp{dir/foo} を
作成してその中に @samp{bar.c} を置き、@samp{cvs co -N -d dir bar/baz}
はディクトリ @samp{dir/bar/baz} を作成してその中に @samp{quux.c} を置
きます。

@item -j @var{tag}
@samp{-j} オプションを二つ指定した場合、
最初に指定したリビションから次に指定したリビジョンへの変更を、
作業ディレクトリにマージします。

@samp{-j} オプションが一つの場合、
その分岐リビジョンから指定したリビジョンへの変更を、
作業ディレクトリにマージします。
分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
@samp{-j} で指定したリビジョンとの共通の祖先です。

@samp{-j} オプションに枝を指定する場合、
日付の指定を付加することができます。
このとき選択されるリビジョンは、指定日以前のものに制限されます。
日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
@samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。

@xref{Branching and merging}.

@item -N
@samp{-d @var{dir}} と併用した場合にのみ有効です。
このオプションを指定した場合、
単独モジュールを取り出したときに、
作業ディレクトリのモジュールパスを ``短く'' しません。例と説明は 
@samp{-d} フラグを参照してください。

@item -s
@samp{-c} と同様ですが、全てのモジュールの状態を
アルファベット順に並べて標準出力に出します。
モジュールの状態を設定するために管理用ファイル @file{modules} の中で使
われるオプション @samp{-s} の情報は、@xref{modules}.
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node checkout examples
@appendixsubsec checkout の使用例

モジュール @samp{tc} のコピーを取り出します:

@example
$ cvs checkout tc
@end example

モジュール @samp{tc} を昨日の状態で取り出します:

@example
$ cvs checkout -D yesterday tc
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node commit
@appendixsec commit---ファイルをリポジトリに格納する
@cindex Commit (subcommand)

@itemize @bullet
@item
書式: commit [-lnRf] [-m 'log_message' |
-F file] [-r revision] [files@dots{}]
@item
必須: 作業ディレクトリ, リポジトリ
@item
変更: リポジトリ
@item
別名: ci
@end itemize

@code{commit} は、作業ファイルに対する変更を
リポジトリに組み入れる際に使用します。

格納するファイルを特に指定しなければ、
現在の作業ディレクトリの全ファイルが調査され、
変更が加えられたファイルだけがリポジトリに格納されます。
既定 (もしくは明示的にオプション @samp{-R} が指定された場合) では、
サブディレクトリのファイルも調査され、変更されていれば格納されます。
オプション @samp{-l} を指定して、
@code{commit} の動作を現在のディレクトリだけに留めることも可能です。

@code{commit} は、選択されたファイルが
リポジトリの最新リビジョンであるかどうか確認します。
指定されたファイルの中に @code{update} (@pxref{update}) 
が必要なものが一つでもあれば、その旨が表示され、
格納せずに終了します。
@code{commit} はあえて @code{update} コマンドを呼び出さず、
開発者自身に適切な時期を判断してもらいます。

全てが正常ならば、ログ・メッセージを記すためにエディタが起動されます。
ログ・メッセージは幾つかの処理プログラムに送られると同時に 
(@ref{modules} と @ref{loginfo} を参照)、
リポジトリ中の @sc{rcs} ファイルにも記録されます。
このログ・メッセージを参照するには @code{log} コマンドを
用いて下さい。@ref{log} 参照。
オプション @samp{-m @var{message}} で
コマンド行にログ・メッセージを記述したり、
オプション @samp{-F @var{file}} で
ログ・メッセージを記述したファイルを指定すれば、
エディタを起動しなくて済みます。

@menu
* commit options::              commit のオプション
* commit examples::             commit の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node commit options
@appendixsubsec commit のオプション

@code{commit} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。

@item -n
モジュールのプログラムを実行しません。

@item -R
ディレクトリを再帰的に格納します。
このオプションは指定しなくても実行されます。

@item -r @var{revision}
@var{revision} に格納します。
@var{revision} には、枝もしくは、
既存の全てのリビジョン番号よりも大きい番号を持つ
幹上のリビジョンを指定しなくてはいけません 
(@pxref{Assigning revisions})。
枝上のリビジョンを指定して格納することはできません。
@c FIXME: Need xref for branch case.
@end table

さらに @code{commit} では以下のオプションも使用可能です:

@table @code
@item -F @var{file}
エディタを起動せず @var{file} からログ・メッセージを読み込みます。

@item -f
これは @ref{Common options} のオプション @samp{-f} に記述される
標準的な動作とは異なることに注意して下さい。

作業ファイルに何も変更を加えていない場合でも、
無理矢理新しいリビジョンとして格納します。
現在の @var{file} のリビジョンを 1.7 と仮定したとき、
次の二つのコマンドの実行結果は同じになります:

@example
$ cvs commit -f @var{file}
$ cvs commit -r 1.8 @var{file}
@end example

@c This is odd, but it's how CVS has worked for some
@c time.
@samp{-f} オプションは再帰を使いません (すなわち、@samp{-l} を含んでい
ます)。全てのサブディレクトリの全てのファイルの新しいリビジョンの格納
を @sc{cvs} 強制するには、@samp{-f -R} を使用する必要があります。

@item -m @var{message}
エディタを起動せず、@var{message} をログ・メッセージとします。
@end table

@need 2000
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node commit examples
@appendixsubsec commit の使用例

@c FIXME: this material wants to be somewhere
@c in "Branching and merging".

@appendixsubsubsec 枝に対して格納する

オプション @samp{-r} を用いて、枝リビジョン (リビジョン番号が
偶数個のドットを含むもの) に格納することができます。
枝リビジョンは @code{rtag} か @code{tag} コマンドに
オプション @samp{-b} を指定して作成します 
(@pxref{Branching and merging})。
そして @code{checkout} か @code{update} で、
新しく作成した枝からソースを取り出します。
その結果、この作業ソースに対する変更を @code{commit} すると、
全て自動的に枝リビジョンの方に追加され、
幹の開発系統は全く影響を受けません。
例えば、バージョン 1.2 の製品に対するパッチを作成する必要があるけれど、
既にバージョン 2.0 の開発が始まっているような場合、
以下のようにします:

@example
$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
$ cvs checkout -r FCS1_2_Patch product_module
$ cd product_module
[[ hack away ]]
$ cvs commit
@end example

@noindent
オプション @samp{-r} は作業ディレクトリに貼り付けられるため、
これを指定する必要はありません。

@appendixsubsubsec 編集後に枝を作成する

例えば、先週取り出したリビジョンを元にして、
極めて実験的な変更をソフトウェアに加えてきたとします。
ここで実験に他の開発者を加えたいけれど、
幹の開発系統を妨げたくない場合は、
その変更点を新しい枝に格納すれば良いでしょう。
すると他の開発者も実験中のコードを取り出して、
@sc{cvs} の衝突解決の恩恵を全て受けることができます。
このシナリオは次のようになるでしょう:

@c FIXME: Should we be recommending tagging the branchpoint?
@example
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs update -r EXPR1
$ cvs commit
@end example

@code{update} コマンドで、全てのファイルに
オプション @samp{-r EXPR1} が貼り付けられます。
このとき、@code{update} コマンドでは
ファイルに対する変更が削除されないことに注意して下さい。
@samp{-r} が貼り付けられているため、
@code{commit} すれば自動的に正しい枝に変更が格納されます。
これは次の手順もあります:

@c FIXME: Should we be recommending tagging the branchpoint?
@example
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs commit -r EXPR1
@end example

@noindent
しかしこの場合、
変更されていたファイルだけに @samp{-r EXPR1} が貼り付けられます。
従って別のファイルを変更して、フラグ @samp{-r EXPR1} を付けずに
格納した場合、誤って幹に格納されてしまいます。

他の開発者が実験に参加する際には、
単純に以下のようにして下さい:

@example
$ cvs checkout -r EXPR1 whatever_module
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node diff
@appendixsec diff---リビジョン間の差分の表示
@cindex Diff (subcommand)

@itemize @bullet
@item
書式: diff [-lR] [format_options] [[-r rev1 | -D date1] [-r rev2 |  -D date2]] [files@dots{}]
@item
必須: 作業ディレクトリ, リポジトリ
@item
変更: なし
@end itemize

@code{diff} コマンドは、
別々のリビジョン間の差異を比較するのに使用します。
特にオプションを指定しない場合、
作業ファイルをその由来となったリビジョンと比較し、
検出された全ての差異を報告します。

ファイル名を指定した場合、そのファイルについてのみ比較します。
ディレクトリを指定した場合、その下の全てのファイルを比較します。

diff の終了状態は他の @sc{cvs} コマンドと違います。詳細は @ref{Exit
status} を参照してください。

@menu
* diff options::                diff のオプション
* diff examples::               diff の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node diff options
@appendixsubsec diff のオプション

@code{diff} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -D @var{date}
@var{date} 以前の最も新しいリビジョンを利用します。
このオプションを比較に用いた時の効果は @samp{-r} を参照して下さい。

@item -k @var{kflag}
@var{kfalg} に従ってキーワード置換を行います。@ref{Keyword
substitution}, 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。

@item -R
ディレクトリを再帰的に調べます。
このオプションは指定しなくても実行されます。

@item -r @var{tag}
リビジョン @var{tag} と比較します。
オプション @samp{-r} は最大二つまで使用できます。
オプション @samp{-r} を指定しない場合、
作業ファイルをその由来となったリビジョンと比較します。
オプション @samp{-r} を一つ指定した場合、
指定したリビジョンと作業ファイルとを比較します。
オプション @samp{-r} を二つ指定した場合、
指定した二つのリビジョンを比較します 
(作業ファイルが結果に影響を与えることはありません)。
@c We should be a lot more explicit, with examples,
@c about the difference between "cvs diff" and "cvs
@c diff -r HEAD".  This often confuses new users.

一つもしくは両方のオプション @samp{-r} を、前述の
オプション @samp{-D @var{date}} と交換することができます。
@end table

@c Conceptually, this is a disaster.  There are 3
@c zillion diff formats that we support via the diff
@c library.  It is not obvious to me that we should
@c document them all.  Maybe just the most common ones
@c like -c and -u, and think about phasing out the
@c obscure ones.
@c FIXCVS: also should be a way to specify an external
@c diff program (which can be different for different
@c file types) and pass through
@c arbitrary options, so that the user can do
@c "--pass=-Z --pass=foo" or something even if CVS
@c doesn't know about the "-Z foo" option to diff.
@c This would fit nicely with deprecating/eliminating
@c the obscure options of the diff library, because it
@c would let people specify an external GNU diff if
@c they are into that sort of thing.
以下のオプションは出力の書式を指定します。
意味は GNU diff と同じです。

@example
-0 -1 -2 -3 -4 -5 -6 -7 -8 -9
--binary
--brief
--changed-group-format=@var{arg}
-c
  -C @var{nlines}
  --context[=@var{lines}]
-e --ed
-t --expand-tabs
-f --forward-ed
--horizon-lines=@var{arg}
--ifdef=@var{arg}
-w --ignore-all-space
-B --ignore-blank-lines
-i --ignore-case
-I @var{regexp}
   --ignore-matching-lines=@var{regexp}
-h
-b --ignore-space-change
-T --initial-tab
-L @var{label}
  --label=@var{label}
--left-column
-d --minimal
-N --new-file
--new-line-format=@var{arg}
--old-line-format=@var{arg}
--paginate
-n --rcs
-s --report-identical-files
-p
--show-c-function
-y --side-by-side
-F @var{regexp}
--show-function-line=@var{regexp}
-H --speed-large-files
--suppress-common-lines
-a --text
--unchanged-group-format=@var{arg}
-u
  -U @var{nlines}
  --unified[=@var{lines}]
@c FIXCVS: This option is accepted by src/diff.c but
@c not diff/diff.c; it would appear that any attempt to
@c use it would get an error.
-V @var{arg}
-W @var{columns}
  --width=@var{columns}
@end example

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node diff examples
@appendixsubsec diff の使用例

次の実行例は、@file{backend.c} のリビジョン 1.14 と 1.19 間の差分を、
unidiff 形式 (フラグ @samp{-u}) で出力します。
またキーワード置換を止めるために @samp{-kk} を指定し、
キーワード置換による差分を無視します。

@example
$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
@end example

タグ RELEASE_1_0 が付けられたファイルの集合から、
実験用の枝 EXPR1 が派生していると仮定します。
この枝に加えられた変更を見るには、次のようにします:

@example
$ cvs diff -r RELEASE_1_0 -r EXPR1
@end example

次の実行例では、二つのリリース間の差分を context 形式で出力します:

@example
$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
@end example

ChangeLogs を運用している場合、
変更を格納する前に次の行のようなコマンドを実行すると、
ChangeLogs の記載事項を入力するのに役立つでしょう。
作業ファイルに加えた変更点のうち、格納していないもの全てを表示します。

@example
$ cvs diff -u | less
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node export
@appendixsec export---CVS からソースを取り出す, checkout に類似
@cindex Export (subcommand)

@itemize @bullet
@item
書式: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
@item
必須: リポジトリ
@item
変更: 現在のディレクトリ
@end itemize

このコマンドは @code{checkout} の変形で、
@var{module} のソースのコピーを、
@sc{cvs} の管理用ディレクトリを除いた状態で取り出します。
例えば出荷用のソースを準備するときなどに @code{export} を使います。
出荷したソースを後で再現できることを確認するため、使用の際には 
(@samp{-D} か @samp{-r} による) 日付かタグの指定が要求されます。

@code{cvs export} に @samp{-kv} を指定すると便利です。
この指定で全てのキーワードが展開されるため、
出荷先で @code{import} されても
キーワードによるリビジョン情報が失われません。
しかしモジュールがバイナリ・ファイルを含む場合は、
正しく処理されない可能性があるので注意が必要です。
また @samp{-kv} を使用した後では、@code{ident} コマンド (@sc{rcs} を
構成するコマンドの一つです---@samp{ident(1)} を参照) を使用して、
キーワード文字列を抜き出すことができません。
従って @code{ident} を使用するつもりなら、
@samp{-kv} を指定してはいけません。

@menu
* export options::              export のオプション
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node export options
@appendixsubsec export のオプション

@code{export} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -D @var{date}
@var{date} 以前の最も新しいリビジョンを取り出します。

@item -f
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを取り出します。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。

@item -n
ファイルを取り出したとき、通常実行されるプログラムを実行しません。

@item -R
ディレクトリを再帰的に取り出します。
このオプションは指定しなくても実行されます。

@item -r @var{tag}
@var{tag} で指定されたリビジョンを取り出します。
@end table

さらに (@code{checkout} と @code{export} で共通な) 
以下のオプションも使用可能です:

@table @code
@item -d @var{dir}
モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
@sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.

@item -k @var{subst}
キーワード置換モードを設定します (@pxref{Substitution modes})。

@item -N
@samp{-d @var{dir}} と併用した場合にのみ有効です。
@sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
@end table

@ignore
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@c @node export examples
@appendixsubsec export examples

Contributed examples are gratefully accepted.
@c -- Examples here!!
@end ignore

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node history
@appendixsec history---ファイルと使用者の状態を表示
@cindex History (subcommand)

@itemize @bullet
@item
書式:     history [-report] [-flags] [-options args] [files@dots{}]
@item
必須: ファイル @file{$CVSROOT/CVSROOT/history}
@item
変更: なし
@end itemize

@sc{cvs} は、@code{checkout}, @code{commit}, @code{rtag}, 
@code{update}, @code{release} コマンドの実行履歴を、
ファイル @file{history} に記録しています。
@code{history} を使って、様々な形式で
この情報を表示することができます。

ログを記録したい場合は、ファイル @file{$CVSROOT/CVSROOT/history} を
作成する必要があります。

@strong{警告:} @code{history} は、@samp{-f}, @samp{-l}, @samp{-n}, 
@samp{-p} を通常の @sc{cvs} コマンドで用いられるものとは
異なる意味で使用しています (@pxref{Common options})。

@menu
* history options::             history のオプション
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node history options
@appendixsubsec history のオプション

次のオプション (コマンド書式で @samp{-report} の部分) によって、
生成する報告の種類を決定します:

@table @code
@item -c
現在までに使用された @code{commit} (つまりリポジトリの変更) 
について報告します。

@item -e
全て (全記録種別) を報告します。全ての記録種別に @samp{-x} を指定する
ことと等価です。もちろん、@samp{-e} は将来のバージョンの @sc{cvs} に加
えられた記録種別も含みます。特定の記録種別だけを扱うことのできるスクリ
プトを書いているなら、@samp{-x} を指定する方が良いでしょう。

@item -m @var{module}
特定のモジュールについて報告します 
(必要ならば複数の @samp{-m} をコマンド行に並べても構いません)。

@item -o
取り出されたモジュールについて報告します。

@item -T
全てのタグについて報告します。

@item -x @var{type}
報告を受けたい記録種別の組を @var{type} に指定して、
@sc{cvs} の実行履歴から取り出します。
種別は各々一文字で表され、これを組み合わせて指定します。

以下のコマンドには、各々一つの記録種別を割り当てています:

@table @code
@item F
release
@item O
checkout
@item E
export
@item T
rtag
@end table

@noindent
更新の結果は、以下の四つの記録種別のうちのどれかになります:

@table @code
@item C
マージを実行した結果、衝突が検出された場合 (手動でのマージが必要)。
@item G
マージを実行して成功した場合。
@item U
作業ファイルがリポジトリからコピーされた場合。
@item W
(リポジトリから相当するファイルが削除されたため) 
更新の際に作業ファイルが削除された場合。
@end table

@noindent
格納の結果は、以下の三つの記録種別のうちのどれかになります:

@table @code
@item A
ファイルが初めて追加された場合。
@item M
ファイルが修正された場合。
@item R
ファイルが削除された場合。
@end table
@end table

次のオプション (コマンド書式で @samp{-flags} の部分) によって、
報告の範囲を限定もしくは拡大します。引数はありません:

@table @code
@item -a
全ての使用者の情報を表示します 
(既定では @code{history} を実行した人物の情報のみを表示します)。

@item -l
最後の変更のみを表示します。

@item -w
@code{history} を実行したのと同じ作業ディレクトリから行われた
変更に関する記録のみを表示します。
@end table

次のオプション (コマンド書式で @samp{-options @var{args}} の部分) は、
引数に基づいて報告の範囲を限定します:

@table @code
@item -b @var{str}
モジュール名, ファイル名, リポジトリのパスのいずれかに、
文字列 @var{str} が含まれる記録のみを表示します。

@item -D @var{date}
@var{date} 以降のデータを表示します。
普通の @samp{-D @var{date}} は @var{date} 以前の
最新リビジョンを選択しますから、少し意味が違います。

@item -p @var{repository}
指定したリポジトリのデータを表示します 
(必要ならば複数の @samp{-p} をコマンド行に並べても構いません。)

@item -r @var{rev}
リビジョンもしくはタグを @var{rev} に指定して、
このリビジョン以降の記録を表示します。
実行時に全ての @sc{rcs} ファイルについて @var{rev} を検索します。

@item -t @var{tag}
履歴ファイルにタグ @var{tag} が
追加された後の記録を表示します。
このオプションを指定した場合、@sc{rcs} ファイルを検索せず、
履歴ファイルのみを参照するため、
オプション @samp{-r} の場合よりもかなり高速です。

@item -u @var{name}
@var{name} で指定された使用者の記録を表示します。
@end table

@ignore
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@c @node history examples
@appendixsubsec history examples

Contributed examples will gratefully be accepted.
@c -- Examples here!
@end ignore

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node import
@appendixsec import---CVS にソースを取り込む, ベンダー枝を使用
@cindex Import (subcommand)

@c FIXME: This node is way too long for one which has subnodes.

@itemize @bullet
@item
書式: import [-options] repository vendortag releasetag@dots{}
@item
必須: リポジトリ, ソースの配布ディレクトリ
@item
変更: リポジトリ
@end itemize

@code{import} を用いて、外部の供給元 (例えばソース・ベンダー) 
からのソース配布物全体を、自分のリポジトリに取り入れることができます。
リポジトリを最初に作成する場合と、外部の供給元がモジュールを
大幅に更新した場合の両方でこのコマンドを用います。
この件については @xref{Tracking sources}.

@var{repository} には、リポジトリにするディレクトリの名前 
(もしくは、ディレクトリへのパス) を、
@sc{cvs} のルート・ディレクトリからの相対パス名で指定します。
指定したディレクトリが存在しなくても自動的に作成されます。

(前回の import から) ずっと変更を加えてきたリポジトリに対し、
ソースを更新するために import を用いると、
互いの開発系統間で衝突が発生したファイル全てが報告されます。
この時 import から具体的な指示がありますので、
それを参考にしながら @samp{checkout -j} を使って変更点を取り入れて下さい。

@sc{cvs} は無視するように設定されたファイルは (@pxref{cvsignore})、
取り込まず、無視したことを示すため 
@samp{I } に続けてファイル名を表示します 
(出力に関する完全な説明は @pxref{import output})。

@file{$CVSROOT/CVSROOT/cvswrappers} が存在する場合、
このファイルの記述に合致するファイルやディレクトリは
各々一括して扱われ、リポジトリに取り込まれる前に、
適切なフィルタが適用されます。@xref{Wrappers}.

外部からのソースは第一層の枝、既定だと 1.1.1 に保存されます。
以降の更新は全てこの枝の葉となります。
例えば最初に取り込んだソース集合のファイルは
リビジョン 1.1.1.1 になり、次の取り込みで
そのファイルが更新された場合には 1.1.1.2 となり、以下同様に続きます。

少なくとも次の三つの引数を指定する必要があります。
まずソース集合を識別するために @var{repository} が必要です。
次の @var{vendortag} は枝全体 (例えば 1.1.1) を示すタグ名です。
そして @code{import} を実行する度に作成される葉のうち、
どの葉のファイルかを識別するため、
最低一つの @var{releasetag} を指定しなくてはいけません。

@c I'm not completely sure this belongs here.  But
@c we need to say it _somewhere_ reasonably obvious; it
@c is a common misconception among people first learning CVS
@code{import} はそれを起動したディレクトリを変更 @emph{しない} という
ことに注意してください。特に、ディレクトリを @sc{cvs} の作業ディレクト
リとして設定しないことに注意してください。もし作業をしたいなら、まずソー
スを取り込んで、それから違うディレクトリに取り出してください 
(@pxref{Getting the source})。

@menu
* import options::              import のオプション
* import output::               import の出力
* import examples::             import の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node import options
@appendixsubsec import のオプション

@code{import} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -m @var{message}
エディタを立ち上げる代りに、@var{message} をログ情報に指定します。
@end table

以下のような追加の特別なオプションがあります。

@table @code
@item -b @var{branch}
@ref{Multiple vendor branches} 参照。

@item -k @var{subst}
希望するキーワード置換モードを指定します。
この設定は、新たに取り入れる全てのファイルに適用されますが、
リポジトリに既に存在するファイルには適用されません。
@samp{-k} に使用できる設定の一覧は @ref{Substitution modes} 参照。

@item -I @var{name}
取り込む際に無視するファイル名を指定します。
無視したいファイルが複数あるときは、
このオプションを何個並べても構いません。
全てのファイルを無視したくない場合は、
(それらは既定では無視されるとしても) `-I !' と指定して下さい。

@var{name} には、ファイル @file{.cvsignore} と同じ
ファイル名形式が使用できます。@xref{cvsignore}.
@c -- Is this really true?

@item -W @var{spec}
取り込む際に、
フィルタを適用したいファイル名を指定します。
フィルタを適用したいファイルが複数あるときは、
このオプションを何個並べても構いません。

@var{spec} には、ファイル @file{.cvswrappers} と同じ
ファイル名形式が使用できます。@xref{Wrappers}.
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node import output
@appendixsubsec import の出力

@code{import} の進行状況を知らせるために、
処理中のファイル名が一行ずつ表示され、
行頭にはファイルの状態を示す文字が付加されます:

@table @code
@item U @var{file}
このファイルが既にリポジトリに存在し、かつ変更されてないことを示します。
(必要ならば) 新しいリビジョンが作成されます。

@item N @var{file}
このファイルが新規であり、リポジトリに追加されたことを示します。

@item C @var{file}
このファイルが既にリポジトリに存在し、かつ変更されていて、
マージが必要であることを示します。

@item I @var{file}
このファイルが無視されることを示します (@pxref{cvsignore})。

@cindex symbolic link, importing
@cindex link, symbolic, importing
@c FIXME: also (somewhere else) probably
@c should be documenting what happens if you "cvs add"
@c a symbolic link.  Also maybe what happens if
@c you manually create symbolic links within the
@c repository (? - not sure why we'd want to suggest
@c doing that).
@item L @var{file}
このファイルがシンボリック・リンクであることを示します。
@code{cvs import} はシンボリック・リンクを無視します。いろんな人が定期
的にこの振舞いは変更されるべきだと提案しますが、どれに変更されるべきか
についての同意があるとすれば、それは明らかでないように思われます。
(管理用ファイル @file{modules} の各種オプションを checkout や update
等でシンボリック・リンクを再生成するために使うことができます。
@pxref{modules}。)
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node import examples
@appendixsubsec import の使用例

@ref{Tracking sources} と @ref{From files} を参照して下さい。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node log
@appendixsec log---ファイルのログ情報を表示
@cindex Log (subcommand)

@itemize @bullet
@item
書式: log [options] [files@dots{}]
@item
必須: リポジトリ, 作業ディレクトリ
@item
変更: なし
@end itemize

ファイルのログ情報を表示します。以前の @code{log} は 
@sc{rcs} のコマンド @code{rlog} を呼び出していましたが、
現在はそうではありません。しかしこのような経緯から、
このコマンドの出力やオプションは、
他の @sc{cvs} コマンドとは異なったものになっています。

@cindex timezone, in output
@cindex zone, time, in output
@c Kind of a funny place to document the timezone used
@c in output from commands other than @code{log}.
@c There is also more we need to say about this,
@c including what happens in a client/server environment.
このコマンドの出力には、@sc{rcs} ファイルの所在、
@dfn{先頭}リビジョン (幹の最新リビジョン)、
全てのタグ名などが含まれます。
各リビジョンに対しては、リビジョン番号、格納者、
追加/削除された行数、ログ・メッセージが表示されます。
また時間は全て協定世界時 (UTC) で表示されます。
(@sc{cvs} の他の部分では地方時間帯による時刻を表示します。)
@c FIXCVS: need a better way to control the timezone
@c used in output.  Previous/current versions of CVS did/do
@c sometimes support -z in RCSINIT, and/or an
@c undocumented (except by reference to 'rlog') -z option
@c to cvs log, but this has not been a consistent,
@c documented feature.  Perhaps a new global option,
@c where LT means the client's timezone, which the
@c client then communicates to the server, is the
@c right solution.

@strong{警告:} @code{log} は @samp{-R} を @sc{cvs} 普通の使用と衝突す
る方法で使います (@pxref{Common options})。

@menu
* log options::                 log のオプション
* log examples::                log の例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node log options
@appendixsubsec log のオプション

オプションを指定しなければ、@code{log} は利用できる全ての
情報を表示します。つまりオプションは全て出力を制限するものです。

@table @code
@item -b
既定の枝 (通常は幹で最も大きな番号の枝) に関する情報を表示します。

@item -d @var{dates}
@var{dates} に示されたリビジョンの情報を表示します。
@var{dates} には格納日時の範囲をセミコロンで区切って記述します。
日時の表現形式は他の @sc{cvs} コマンドの 
@samp{-D} オプションと同じです (@pxref{Common options})。
それを次のように組み合わせて、格納日時の範囲を表現します:

@c Should we be thinking about accepting ISO8601
@c ranges?  For example "1972-09-10/1972-09-12".
@table @code
@item @var{d1}<@var{d2}
@itemx @var{d2}>@var{d1}
@var{d1} から @var{d2} までの間に格納されたリビジョンを選択します。

@item <@var{d}
@itemx @var{d}>
@var{d} より前に格納された全てのリビジョンを選択します。

@item @var{d}<
@itemx >@var{d}
@var{d} より後に格納された全てのリビジョンを選択します。

@item @var{d}
@var{d} 以前の最新のリビジョンを一つ選択します。
@end table

@samp{>} や @samp{<} の後に @samp{=} を付ければ、端を含まない
範囲指定ではなく、端を含むような範囲指定が可能です。

要素の区切りがセミコロン @samp{;} であることに注意して下さい。

@item -h
@sc{rcs} ファイルの名前, 作業ディレクトリのファイル名, 先頭リビジョン,
既定の枝, 利用者一覧, ロックモード, タグ名, 拡張子を表示します。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。(これを指定しない場合再帰的に実行されます)。

@item -N
このファイルではタグ名の一覧を表示しません。
タグ名を多く使用していると、その表示だけで3ページ以上のタグ情報を 
"more" することになります。
タグ名を省略したログ情報でも構わないときは、
このオプションを指定すると便利です。

@item -R
@sc{rcs} ファイルの名前だけを表示します。

@c Note that using a bare revision (in addition to not
@c being explicitly documented here) is potentially
@c confusing; it shows the log message to get from the
@c previous revision to that revision.  "-r1.3 -r1.6"
@c (equivalent to "-r1.3,1.6") is even worse; it
@c prints the messages to get from 1.2 to 1.3 and 1.5
@c to 1.6.  By analogy with "cvs diff", users might
@c expect that it is more like specifying a range.
@c It is not 100% clear to me how much of this should
@c be documented (for example, multiple -r options
@c perhaps could/should be deprecated given the false
@c analogy with "cvs diff").
@c In general, this section should be rewritten to talk
@c about messages to get from revision rev1 to rev2,
@c rather than messages for revision rev2 (that is, the
@c messages are associated with a change not a static
@c revision and failing to make this distinction causes
@c much confusion).
@item -r@var{revisions}
@var{revisions} に示されたリビジョンの情報を表示します。
@var{revisions} にはリビジョンの範囲をカンマで区切って記述します。
利用可能な範囲指定の書式を次に示します:

@table @code
@item @var{rev1}:@var{rev2}
@var{rev1} から @var{rev2} までのリビジョンを選択します (同じ枝である
必要があります)。

@item :@var{rev}
枝の最初から @var{rev} までのリビジョンを選択します。

@item @var{rev}:
@var{rev} から同じ枝の最後のリビジョンまでを選択します。

@item @var{branch}
枝 @var{branch} にある全てのリビジョンを選択します。

@item @var{branch1}:@var{branch2}
この範囲内の枝にある全てのリビジョンを選択します。

@item @var{branch}.
枝 @var{branch} の最新リビジョンを選択します。
@end table

リビジョンを指定せず @samp{-r} だけを指定した場合、
既定の枝、通常は幹の最新リビジョンを選択します。
従って @samp{-r} と引数との間に空白を入れないようにして下さい。

@item -s @var{states}
@var{states} と状態が一致するリビジョンの情報を表示します。
@var{states} にはファイルの状態をカンマで区切って記述します。

@item -t
@samp{-h} の情報に、ファイルの説明文を追加して表示します。

@item -w@var{logins}
@var{logins} に示された使用者が格納したリビジョンの情報を表示します。
@var{logins} には使用者名をカンマで区切って記述します。
@var{logins} を省略した場合、コマンドを起動した人物の
使用者名が用いられます。
従って @samp{-w} と引数との間に空白を入れないようにして下さい。
@end table

@code{log} は、オプション @samp{-d}, @samp{-s}, @samp{-w} の
全てに適合し、かつ @samp{-b}, @samp{-r} のいずれかに適合した
リビジョンに関する情報を表示します。

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node log examples
@appendixsubsec log の使用例

使用例を募集しています。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node rdiff
@appendixsec rdiff---リリース間の `patch' 形式の差分
@cindex Rdiff (subcommand)

@itemize @bullet
@item
書式: rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules@dots{}
@item
必須: リポジトリ
@item
変更: なし
@item
別名: patch
@end itemize

二つのリリース間の差分を、
Larry Wall の @samp{patch(1)} ファイル形式で生成します。
この出力を直接 @code{patch} プログラムに食わせて、
古いリリースを新しいリリースに更新できます。
(これは作業ディレクトリを必要とせず、直接リポジトリを操作する
数少ない @sc{cvs} コマンドの一つです。) 
このコマンドの実行結果は標準出力に送られます。

一つないし二つのリビジョンか日付の組み合わせを 
(標準オプション @samp{-r} や @samp{-D} を用いて) 
指定することができます。
リビジョンか日付を一つだけ指定した場合、
指定したものと @sc{rcs} ファイルの先頭リビジョンとの差分が
パッチ・ファイルとして出力されます。

ソフトウェア配布物が複数のディレクトリから構成される場合、
別のディレクトリに置かれた古いソースを参照するために、
@code{patch} コマンドにオプション @samp{-p} を
指定する必要があるかも知れません。

@menu
* rdiff options::               rdiff のオプション
* rdiff examples::              rdiff の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node rdiff options
@appendixsubsec rdiff のオプション

@code{rdiff} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -D @var{date}
@var{date} 以前の最も新しいリビジョンを利用します。

@item -f
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを用います。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。

@item -R
ディレクトリを再帰的に検査します。
このオプションは指定しなくても実行されます。

@item -r @var{tag}
@var{tag} で指定されたリビジョンを用います。
@end table

さらに以下のオプションも使用可能です:

@table @code
@item -c
Context 形式で出力します。
これが既定形式なので指定する必要はありません。

@item -s
パッチの代りに変更要旨だけが報告されます。
指定したリリース間で変更されたり追加されたファイルの情報が
標準出力に送られます。
これは例えば、二つの日付やリビジョン間で変更された
ファイルを一覧するのに便利です。

@item -t
先頭にある二つのリビジョン間の差分を標準出力に送ります。
これは、そのファイルの最新の変更点を見るときに使います。

@item -u
Context 形式ではなく、unidiff 形式を用います。
古いバージョンの @code{patch} プログラムは unidiff 形式を扱えないので、
パッチをネットに投稿するつもりならば、
@samp{-u} を使用しない方が賢明でしょう。

@item -V @var{vn}
@sc{rcs} のバージョン @var{vn} における展開方法に従って、
 キーワードを展開します 
(@sc{rcs} のバージョン 5 で展開方法が変更されました)。
このオプションはもう使用できないことに注意してください。
CVS は @sc{rcs} バージョン 5 がするように常にキーワードを展開します。
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node rdiff examples
@appendixsubsec rdiff の使用例

@t{foo@@example.net} から、
コンパイラ @samp{tc} をリリース 1.2 から 1.4 へ更新したい、
というメールを受け取ったと仮定します。
手元にそんなパッチがない場合でも、
@sc{cvs} なら次のようなコマンドを使って簡単に対応できます:

@example
$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
$$ Mail -s 'The patches you asked for' foo@@example.net
@end example

リリース 1.3 のバグ修正用に枝 @samp{R_1_3fix} を作成し、
修正後のリリース 1.3.1 にタグ @samp{R_1_3_1} を付けたと仮定します。
この枝に対して、修正版以降に加えられた開発の概略を知りたい場合は、
次のようなコマンドを使います:

@example
$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
cvs rdiff: Diffing module-name
File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
File bar.h,v changed from revision 1.29.2.1 to 1.2
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node release
@appendixsec release---モジュールの放棄を表明する
@cindex Release (subcommand)

@itemize @bullet
@item
書式: release [-d] directories@dots{}
@item
必須: 作業ディレクトリ
@item
変更: 作業ディレクトリ, history のログ情報
@end itemize

このコマンドは @samp{cvs checkout} の効果を安全に消し去ります。
@sc{cvs} はファイルをロックしないため、
このコマンドが絶対に必要なわけではありません。
作業ディレクトリを単に削除したいなら、それでも構いません。
ただしこの場合、うっかりすると変更内容を失う恐れがあります。
またファイル @file{history} (@pxref{history file}) にも、
作業ディレクトリを放棄したという情報が残りません。

これらの問題を避けるためにも @samp{cvs release} を使用して下さい。
このコマンドは、未格納の変更点が残ってないかどうか調べます。
次に @sc{cvs} の作業ディレクトリのすぐ上で実行しているかどうか調べます。
さらに作業ディレクトリに記録されたリポジトリが、
モジュールに定義されているリポジトリと等しいかどうか調べます。

上記全ての条件が満たされた場合にだけ、
(作業ディレクトリを故意に放棄した証拠として) 
@sc{cvs} の履歴ログ に @samp{cvs release} の実行記録が残されます。

@menu
* release options::             release のオプション
* release output::              release の出力
* release examples::            release の使用例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node release options
@appendixsubsec release のオプション

@code{release} ではオプションが一つだけ利用できます:

@table @code
@item -d
放棄判定に成功したとき、作業ディレクトリを削除します。
このフラグを指定しない場合、
作業ディレクトリはそのまま残されます。

@strong{警告:}  @code{release} コマンドは
全てのディレクトリとファイルを再帰的に削除していきます。
これには重篤な副作用があり、作業ディレクトリに作成したけれど、
リポジトリには追加してないディレクトリ全てが、
(@code{add} コマンド使って。@pxref{Adding files})
何の表示も無く削除されます---その中身が空でなくても!
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node release output
@appendixsubsec release の出力

@code{release} によって作業ディレクトリを放棄する前に、
最新でないファイルそれぞれについて一行ずつ状態を表示します。

@strong{警告:}  作成はしたけれど、@code{add} コマンドを用いて 
(@pxref{Adding files}) @sc{cvs} のディレクトリ階層に
加えてないディレクトリは、全て中身があっても完全に無視され 
(@samp{-d} が指定されていれば削除され) ます。
@c FIXCVS: This is a bug.  But is it true?  I think
@c maybe they print "? dir" now.

@table @code
@item U @var{file}
@itemx P @var{file}
より新しいリビジョンがリポジトリに存在し、
かつ作業ファイルが編集されてないことを示します。
(@samp{U} と @samp{P} は同じです。)

@item A @var{file}
作業ディレクトリにファイルが追加されたけれど、
まだリポジトリには格納されてないことを示します。
作業ディレクトリを削除すれば、このファイルは失なわれます。

@item R @var{file}
作業ファイルは削除されているけれど、まだこの変更が格納されてないため、
リポジトリからは削除されてないことを示します。@xref{commit}.

@item M @var{file}
作業ディレクトでファイルが修正されています。リポジトリにも新しいリビジョ
ンがあるかもしれません。

@item ? @var{file}
作業ディレクトリに @var{file} というファイルがあるが、
リポジトリには対応するファイルが無く、
@sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
(@samp{-I} オプションの説明の参照と、@pxref{cvsignore})。
作業ディレクトリを削除すれば、このファイルは失なわれます。
@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node release examples
@appendixsubsec release の使用例

ディレクトリ @file{tc} の放棄判定をしてから作業ディレクトリを削除しま
す。

@example
$ cd ..         # @r{@samp{cvs release} は作業ディレクトリの}
                # @r{すぐ上で実行しなくてはいけません。}
$ cvs release -d tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': y
$
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node update
@appendixsec update---作業コピーをリポジトリと一致させる
@cindex Update (subcommand)

@itemize @bullet
@item
書式: update [-AdflPpR] [-d] [-r tag|-D date] files@dots{}
@item
必須: リポジトリ, 作業ディレクトリ
@item
変更: 作業ディレクトリ
@end itemize

共有するリポジトリから作業コピーを取り出した後でも、
他の開発者はリポジトリのソースを変更し続けるでしょう。
開発工程の然るべき時に @code{update} コマンドを使えば、
最後の @code{checkout} や @code{update} 以降の、
どのリビジョンでも取り入れることができます。

@menu
* update options::              update のオプション
* update output::               update の出力
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node update options
@appendixsubsec update のオプション

@code{update} では、以下の標準オプションが利用できます 
(完全な記述は @pxref{Common options}):

@table @code
@item -D date
@var{date} 以前の最も新しいリビジョンを利用します。
このオプションは貼り付けられ、
勝手に @samp{-P} オプションも実行されます。
貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.

@item -f
@samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを取り出します。

@item -k @var{kflag}
キーワード置換モードを @var{kflag} に指定します。
詳細は @ref{Substitution modes} を参照。
このオプションは貼り付けられます。つまりこれ以後、
この作業ディレクトリでファイルが更新されるときには、
同じ @var{kflag} が使用され続けます。
@code{status} コマンドを用いて
貼り付いたオプションを見ることができます。
@code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@xref{Recursive behavior}.

@item -P
空になったディレクトリを削除 (prune) します。
@ref{Moving directories} 参照。

@item -p
ファイルを標準出力に送り (pipe) ます。

@item -R
ディレクトリを再帰的に更新します (既定)。@xref{Recursive behavior}.

@item -r rev
@var{tag} で指定されたリビジョン/タグを取り出します。
このオプションは貼り付けられ、
@samp{-P} オプションも勝手に実行されます。
貼り付いたタグ/日付についての詳細は @pxref{Sticky tags}.
@end table

@need 800
さらに @code{update} では次の固有オプションも使用可能です。

@table @code
@item -A
貼り付いた全てのタグや日付、
また @samp{-k} オプションの指定を剥がします。
貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.

@item -d
リポジトリに存在し、
作業ディレクトリに無いディレクトリを作成します。
通常は作業ディレクトリに既に存在するものだけが、
@code{update} の対象となります。

最初に @code{checkout} した後にリポジトリに作成された、
新たなディレクトリを取り出すときに使用します。
しかし残念なことに副作用があります。
作業ディレクトリを作成するときに、
(モジュール名を利用したり、
コマンド行で望みのファイルやディレクトリを明示したりして) 
特定のディレクトリを故意に避けていた場合、
@samp{-d} を使用すると余計なディレクトリまで作成されてしまいます。

@item -I @var{name}
@code{update} の際に、
@var{name} と一致するファイル名が無視されます。
無視したいファイルが複数あるときは、
コマンド行に @samp{-I} を必要なだけ並べても構いません。
全てのファイルを無視したくない場合は、
@samp{-I !} と指定して下さい。
@sc{cvs} にファイルを無視させる他の方法は @xref{cvsignore}.

@item -W@var{spec}
@code{update} の際に、
フィルタを掛けるべきファイル名を指定します。
このオプションは繰り返し利用することができます。

@file{.cvswrappers} と同じ形式を用いて、
@var{spec} にファイル名を指定します。@xref{Wrappers}.

@item -j@var{revision}
@samp{-j} オプションを二つ指定した場合、
最初に指定したリビションから次に指定したリビジョンへの変更を、
作業ディレクトリにマージします。

@samp{-j} オプションが一つの場合、
その分岐リビジョンから指定したリビジョンへの変更を、
作業ディレクトリにマージします。
分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
@samp{-j} で指定したリビジョンとの共通の祖先です。

@samp{-j} オプションに枝を指定する場合、
日付の指定を付加することができます。
このとき選択されるリビジョンは、指定日以前のものに制限されます。
日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
@samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。

@xref{Branching and merging}.

@end table

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node update output
@appendixsubsec update の出力

@code{update} や @code{checkout} の進行状況を知らせるために、
処理中のファイル名が一行ずつ表示され、
行頭にはファイルの状態を示す文字が付加されます:

@table @code
@item U @var{file}
リポジトリと一致するようにファイルが更新されたことを示します。
リポジトリに存在するファイルが作業ディレクトリに無かった場合や、
修正していない作業コピーよりも新しいバージョンが
リポジトリに格納されていた場合の処理です。

@item P @var{file}
@samp{U} と同様ですが、@sc{cvs} サーバはファイル全体ではなく、パッチを
送ります。2つ共結果は同じです。

@item A @var{file}
作業ディレクトリにファイルが加えられ、それをリポジトリに
反映するために @samp{commit} の実行が必要な状態を示します。
つまりファイルの格納を忘れないように注意を促しています。

@item R @var{file}
作業ディレクトリからファイルが削除され、それをリポジトリに
反映するために @samp{commit} の実行が必要な状態を示します。
つまりファイルの格納を忘れないように注意を促しています。

@item M @var{file}
作業ディレクトリで修正されたファイルであることを示します。

@samp{M} は、ファイルに対する次の二つの修正状態のうちの一方を示します。
一つ目は、リポジトリの当該ファイルが修正されていないため、
このファイルはあなたが最後に見たときと同じ状態にある場合です。
二つ目は、作業コピーと同様に、
リポジトリの当該ファイルも修正されていたため、
これらを作業ディレクトリでマージした結果、
衝突することなく正常に処理された場合です。

ファイルのマージが行われるとその旨が表示され、
(@code{update} が実行される前と同じ内容の) 
作業ファイルのバックアップ・コピーが生成されます。
@code{update} の実行中にそのファイルの名前もちゃんと表示されます。

@item C @var{file}
@cindex .# files
@cindex __ files (VMS)
@var{file} の作業コピーへの変更とリポジトリでの変更をマージした際に、
衝突が見つかったことを示します。
@var{file} (作業コピー) は
2つのリビジョンをマージしようとした結果に置き換えられ、
元のファイルは @file{.#@var{file}.@var{revision}} という名前で、
作業ディレクトリに保存されます。ここで @var{revision} は、
ファイルの修正を開始した時点での @sc{rcs} 
リビジョンです。@ref{Conflicts example} の説明を参考にして
衝突を解決して下さい。
@c "some systems" as in out-of-the-box OSes?  Not as
@c far as I know.  We need to advise sysadmins as well
@c as users how to set up this kind of purge, if that is
@c what they want.
@c We also might want to think about cleaner solutions,
@c like having CVS remove the .# file once the conflict
@c has been resolved or something like that.
(@file{.#} で始まるファイルを数日間利用しなかった場合、
自動的に削除するシステムがあることに注意して下さい。
元のファイルを保存したい場合は名前を変更すると良いでしょう。) 
@sc{vms} ではファイル名の先頭に、
@file{.#} ではなく @file{__} を使用します。

@item ? @var{file}
作業ディレクトリに @var{file} というファイルがあるけれど、
リポジトリには対応するファイルが無く、
@sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
(@samp{-I} オプションの説明及び @pxref{cvsignore} を参照)。
@end table

@node Invoking CVS
@appendix CVS コマンドの簡単な便覧
@cindex Command reference
@cindex Reference, commands
@cindex Invoking CVS

この付録は、それぞれのコマンドや機能が詳しく説明されているところへの参
照とともに、@sc{cvs} の実行のしかたを説明します。他の参照は、@code{cvs
--help} コマンドを実行するか、@ref{Index} を参照してください。

@sc{cvs} コマンドは以下の様になります:

@example
cvs [ @var{global_options} ] @var{command} [ @var{command_options} ] [ @var{command_args} ]
@end example

標準オプション:

@table @code
@item --allow-root=@var{rootdir}
正しい @sc{cvsroot} ディレクトリを指定します (サーバのみ) (@sc{cvs} 
1.9 以前にはありません)。 @ref{Password authentication server} 参照。

@item -a
全ての通信を認証します (クライアントのみ) (@sc{cvs} 1.9 以前にはありま
せん)。@ref{Global options} 参照。

@item -b
RCS の位置を指定します (@sc{cvs} 1.9 以前)。@ref{Global options} 参照。

@item -d @var{root}
@sc{cvsroot} を指定します。@ref{Repository} 参照。

@item -e @var{editor}
@var{editor} でメッセージを編集します。@ref{Committing your changes} 
参照。

@item -f
@file{~/.cvsrc} ファイルを読み込みません。@ref{Global options} 参照。

@item -H
@itemx --help
ヘルプメッセージを印字します。@ref{Global options} 参照。

@item -l
CVSROOT/history ファイルにログを残しません。@ref{Global options} 参照。

@item -n
どのファイルも変更しません。@ref{Global options} 参照。

@item -Q
本当に出力を抑えます。@ref{Global options} 参照。

@item -q
少しばかり出力を抑えます。@ref{Global options} 参照。

@item -r
新しい作業ファイルを読み込み専用にします。@ref{Global options} 参照。

@item -s @var{variable}=@var{value}
使用者変数を設定します。@ref{Variables} 参照。

@item -T @var{tempdir}
一時ファイルを @var{tempdir} に置きます。@ref{Global options} 参照。

@item -t
@sc{cvs} の実行を追跡します。@ref{Global options} 参照。

@item -v
@item --version
@sc{cvs} のバージョンと著作権情報を表示します。

@item -w
新しいファイルを読み込み書き込み可にします。@ref{Global options} 参照。

@item -x
全ての通信を暗号化します (クライアントのみ)。@ref{Global options} 参照。

@item -z @var{gzip-level}
圧縮の度合を設定します (クライアントのみ)。
@c FIXME: what are the valid values for gzip-level.
@c And shouldn't this be documented in at least a
@c little bit of detail somewhere?

@end table

キーワード展開モード (@pxref{Substitution modes}):

@example
-kkv  $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
-kkvl $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
-kk   $@asis{}Id$
-kv   file1,v 1.1 1993/12/09 03:21:13 joe Exp
-ko   @i{非展開}
-kb   @i{非展開、ファイルはバイナリ}
@end example

キーワード (@pxref{Keyword list}):

@example
$@asis{}Author: joe $
$@asis{}Date: 1993/12/09 03:21:13 $
$@asis{}Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
$@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
$@asis{}Locker: harry $
$@asis{}Name: snapshot_1_14 $
$@asis{}RCSfile: file1,v $
$@asis{}Revision: 1.1 $
$@asis{}Source: /home/files/file1,v $
$@asis{}State: Exp $
$@asis{}Log: file1,v $
Revision 1.1  1993/12/09 03:30:17  joe
Initial revision

@end example

@c The idea behind this table is that we want each item
@c to be a sentence or two at most.  Preferably a
@c single line.
@c
@c In some cases refs to "foo options" are just to get
@c this thing written quickly, not because the "foo
@c options" node is really the best place to point.
コマンド、コマンドのオプション、コマンドの引数:

@table @code
@item add [@var{options}] [@var{files}@dots{}]
新しいファイル/ディレクトリを加えます。@ref{Adding files} 参照。

@table @code
@item -k @var{kflag}
キーワード展開を設定します。

@item -m @var{msg}
ファイルの説明を設定します。
@end table

@item admin [@var{options}] [@var{files}@dots{}]
リポジトリの履歴ファイルの管理です。@ref{admin} 参照。
@c This list omits those options which are not
@c documented as being useful with CVS.  That might be
@c a mistake...

@table @code
@item -b[@var{rev}]
既定枝を設定します。@ref{Reverting local changes} 参照。

@item -c@var{string}
註釈符を設定します。

@item -k@var{subst}
キーワード置換を設定します。@ref{Keyword substitution} 参照。

@item -l[@var{rev}]
@var{rev} か、最新のリビジョンをロックします。

@item -m@var{rev}:@var{msg}
リビジョン @var{rev} のログメッセージを @var{msg} で置換します。

@item -o@var{range}
リポジトリからリビジョンを消去します。@ref{admin options} 参照。

@item -q
静かに実行します。診断情報を印字しません。

@item -s@var{state}[:@var{rev}]
状態を設定します。

@c Does not work for client/server CVS
@item -t
標準入力からファイルの説明を設定します。

@item -t@var{file}
ファイルの説明を @var{file} から設定します。

@item -t-@var{string}
ファイルの説明を @var{string} にします。

@item -u[@var{rev}]
リビジョン @var{rev} か、最新のリビジョンのロックを外します。
@end table

@item annotate [@var{options}] [@var{files}@dots{}]
それぞれの行が修正された最新のリビジョンを表示します。@ref{annotate}
参照。

@table @code
@item -D @var{date}
@var{date} 以前で一番新しいリビジョンを annotate します。@ref{Common
options} 参照。

@item -f
タグ/日付が見つからない場合は先頭のリビジョンを使います。@ref{Common
options} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@xref{Recursive behavior}.

@item -R
再帰的に動作します (既定動作)。@xref{Recursive behavior}.

@item -r @var{tag}
リビジョン @var{tag} を annotate します。@ref{Common options} 参照。
@end table

@item checkout [@var{options}] @var{modules}@dots{}
ソースのコピーを取得します。@ref{checkout} 参照。

@table @code
@item -A
貼り付いたタグ/日付/オプションを元に戻します。@ref{Sticky tags} と 
@ref{Keyword substitution} 参照。

@item -c
モジュールデータベースを出力します。@ref{checkout options}.

@item -D @var{date}
@var{date} のリビジョンを取り出します (貼り付きます)。@ref{Common
options} 参照。

@item -d @var{dir}
@var{dir} に取り出します。@ref{checkout options} 参照。

@item -f
タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
options} 参照。

@c Probably want to use rev1/rev2 style like for diff
@c -r.  Here and in on-line help.
@item -j @var{rev}
変更をマージします。@ref{checkout options} 参照。

@item -k @var{kflag}
@var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@xref{Recursive behavior}.

@item -N
-d が指定されたときにモジュールパスを ``短く'' しません。@ref{checkout
options} 参照。

@item -n
モジュールプログラム (もしあれば) を実行しません。@ref{checkout
options} 参照。

@item -P
空のディレクトリを削除します。@ref{Moving directories} 参照。

@item -p
ファイルを標準出力に取り出します (貼り付きを避けます)。@ref{checkout
options}。

@item -R
再帰的に動作します(既定動作です)。@xref{Recursive behavior}.

@item -r @var{tag}
リビジョン @var{tag} を取り出します。@ref{Common options} 参照。

@item -s
-c と似ていますが、モジュールの状態を含みます。@ref{checkout options} 
参照。
@end table

@item commit [@var{options}] [@var{files}@dots{}]
変更をリポジトリに格納します。@ref{commit} 参照。

@table @code
@item -F @var{file}
@var{file} からログメッセージを読み込みます。@ref{commit options} 参照。

@item -f
@c What is this "disables recursion"?  It is from the
@c on-line help; is it documented in this manual?
ファイルを強制的に格納します。再帰的動作を使用不可にします。
@ref{commit options} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@xref{Recursive behavior}.

@item -m @var{msg}
@var{msg} をログメッセージとして使います。@ref{commit options} 参照。

@item -n
モジュールプログラム (もしあれば) を実行しません。@ref{commit options}
参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{rev}
@var{rev} に格納します。@ref{commit options} 参照。
@c FIXME: should be dragging over text from
@c commit options, especially if it can be cleaned up
@c and made concise enough.
@end table

@item diff [@var{options}] [@var{files}@dots{}]
リビジョン間の差分を表示します。@ref{diff} 参照。以下のオプションに加
えて、出力様式を変更するいろいろなオプションを受け付けます。例えば、
context diff のための @samp{-c} です。

@table @code
@item -D @var{date1}
作業ディレクトと日付のリビジョンの差分を取ります。@ref{diff options}
参照。

@item -D @var{date2}
@var{rev1}/@var{date1} と @var{date2} 間の差分を取ります。@ref{diff
options} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -N
追加されたり削除されたりしたファイルの差分も含みます。@ref{diff
options} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{rev1}
リビジョン @var{rev1} と作業ファイル間の差分を取ります。@ref{diff
options} 参照。

@item -r @var{rev2}
@var{rev1}/@var{date1} と @var{rev2} 間の差分を取ります。@ref{diff
options} 参照。
@end table

@item edit [@var{options}] [@var{files}@dots{}]
監視下のファイルを編集する準備をします。@ref{Editing files} 参照。

@table @code
@item -a @var{actions}
一時監視のための動作を指定します。引数は @code{actions}, @code{edit},
@code{unedit}, @code{commit}, @code{all}, @code{none} のどれかです。
@ref{Editing files} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@xref{Recursive behavior}.

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@item editors [@var{options}] [@var{files}@dots{}]
誰が監視下のファイルを編集しているを見ます。@ref{Watch information} 参
照。

@table @code
@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@item export [@var{options}] @var{modules}@dots{}
CVS からフィルを export するときに使います。@ref{export} 参照。

@table @code
@item -D @var{date}
@var{date} のリビジョンを取り出します。@ref{Common options} 参照。

@item -d @var{dir}
@var{dir} に取り出します。@ref{export options} 参照。

@item -f
タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
options} 参照。

@item -k @var{kflag}
@var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -N
-d が指定されたときにモジュールパスを ``短く'' しません。@ref{export
options} 参照。

@item -n
モジュールプログラム (もしあっても) を実行しません。@ref{export
options} 参照。

@item -P
空のディレクトリを削除します。@ref{Moving directories} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{tag}
リビジョン @var{tag} を取り出します。@ref{Common options} 参照。
@end table

@item history [@var{options}] [@var{files}@dots{}]
リポジトリ接続履歴を表示します。@ref{history} 参照。

@table @code
@item -a
全ての使用者にします (既定は自分自身です)。@ref{history options} 参照。

@item -b @var{str}
モジュール名, ファイル名, リポジトリのパスのいずれかに、
文字列 @var{str} が含まれる記録のみを表示します。@ref{history options}
参照。

@item -c
格納された (修正された) ファイルについて報告します。@ref{history
options} 参照。

@item -D @var{date}
@var{date} から。@ref{history options} 参照。

@item -e
全ての記録種別について報告します。@ref{history options} 参照。

@item -l
最後に修正された (格納されたか、修正されたという報告) もの。
@ref{history options} 参照。

@item -m @var{module}
@var{module} について報告します (繰り返し可能)。@ref{history options}
参照。

@item -n @var{module}
@var{module} だけ。@ref{history options} 参照。

@item -o
取り出されたモジュールについて報告します。@ref{history options} 参照。

@item -r @var{rev}
リビジョン @var{rev} から。@ref{history options} 参照。
Since revision @var{rev}.  See @ref{history options}.

@item -T
@c What the @#$@# is a TAG?  Same as a tag?  This
@c wording is also in the online-line help.
全てのタグについて報告します。@ref{history options} 参照。

@item -t @var{tag}
tag の記録が履歴ファイルに (誰かによって) 置かれてから。@ref{history
options} 参照。

@item -u @var{user}
使用者 @var{user} (繰り返し可能)。@ref{history options} 参照。

@item -w
作業ディレクトリが合わなくてはいけません。@ref{history options} 参照。

@item -x @var{types}
@var{types} について報告します。@code{TOEFWUCGMAR} から1つ以上指定しま
す。@ref{history options} 参照。

@item -z @var{zone}
標準時間帯 @var{zone} で出力します。@ref{history options} 参照。
@end table

@item import [@var{options}] @var{repository} @var{vendor-tag} @var{release-tags}@dots{}
ベンダー枝を使用して CVS にファイルを持ち込みます。@ref{import} 参照。

@table @code
@item -b @var{bra}
ベンダー枝 @var{bra} に持ち込みます。@ref{Multiple vendor branches} 参
照。

@item -d
ファイルの修正時刻を持ち込みの時間として使用します。@ref{import
options} 参照。

@item -k @var{kflag}
既定のキーワード置換モードを設定します。@ref{import options} 参照。

@item -m @var{msg}
@var{msg} をログメッセージに使います。@ref{import options} 参照。

@item -I @var{ign}
無視するファイルです (無効にするためには ! を使います)。@ref{import
options} 参照。

@item -W @var{spec}
ラッパーです。@ref{import options} 参照。
@end table

@item init
存在しない場合は CVS リポジトリを作成します。@ref{Creating a
repository} 参照。

@item log [@var{options}] [@var{files}@dots{}]
ファイルの履歴情報を印字します。@ref{log} 参照。

@table @code
@item -b
既定枝のリビジョンのみを一覧表示します。@ref{log options} 参照。

@item -d @var{dates}
日付を指定します (範囲は @var{d1}<@var{d2} で、それ以前の最新は 
@var{d} で)。@ref{log options} 参照。
Specify dates (@var{d1}<@var{d2} for range, @var{d} for
latest before).  See @ref{log options}.

@item -h
ヘッダーのみを印字します。@ref{log options} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -N
タグを一覧表示しません。@ref{log options} 参照。

@item -R
RCS ファイルの名前のみを印字します。@ref{log options} 参照。

@item -r@var{revs}
リビジョン @var{revs} のみを一覧表示します。@ref{log options} 参照。

@item -s @var{states}
指定された状態のリビジョンのみを一覧表示します。@ref{log options} 参照。

@item -t
ヘッダーと説明文のみを印字します。@ref{log options} 参照。

@item -w@var{logins}
logins で指定された使用者が格納したリビジョンのみを一覧表示します。
@ref{log options} 参照。
@end table

@item login
認証サーバのパスワードの入力を促進します。@ref{Password authentication
client} 参照。

@item logout
保存されている認証サーバのパスワードを消去します。
@ref{Password authentication client} 参照。

@item rdiff [@var{options}] @var{modules}@dots{}
リリース間の差分を表示します。@ref{rdiff} 参照。

@table @code
@item -c
Context diff 出力様式です (既定)。@ref{rdiff options} 参照。

@item -D @var{date}
@var{date} に基づいたリビジョンを選択します。@ref{Common options} 参照。

@item -f
タグ/日付が見つからない場合は先頭のリビジョンを使用します。@ref{Common
options} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{rev}
@var{rev} に基づいたリビジョンを選択します。@ref{Common options} 参照。

@item -s
短いパッチです - ファイルにつき一行です。@ref{rdiff options} 参照。

@item -t
先頭の2つの差分です - ファイルへの最後の変更です。@ref{diff options}
参照。

@item -u
Unidiff 出力様式です。@ref{rdiff options} 参照。

@item -V @var{vers}
RCS バージョン @var{vers} をキーワード展開に使用します (旧式)。
@ref{rdiff options} 参照。
@end table

@item release [@var{options}] @var{directory}
ディレクトリがもう使われていないことを示します。@ref{release} 参照。

@table @code
@item -d
与えられたディレクトリを消去します。@ref{release options} 参照。
@end table

@item remove [@var{options}] [@var{files}@dots{}]
リポジトリから登録を消去します。@ref{Removing files} 参照。

@table @code
@item -f
削除する前にファイルを消去します。@ref{Removing files} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@item rtag [@var{options}] @var{tag} @var{modules}@dots{}
モジュールにタグ名を追加します。@ref{Revisions} と @ref{Branching and
merging} 参照。

@table @code
@item -a
削除されたファイルからそうでない場合に付いているタグを消去します。
@ref{Tagging add/remove} 参照。

@item -b
@var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。

@item -D @var{date}
@var{date} のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。

@item -d
@var{タグ} を消去します。@ref{Modifying tags} 参照。

@item -F
既に @var{タグ} が存在していれば移動します。@ref{Modifying tags} 参照。

@item -f
タグ/日付が見つからなければ、先頭のリビジョンとの合致を強制します。
@ref{Tagging by date/tag} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -n
タグプログラムを実行しません。@ref{Common options} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{rev}
存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参照。
@end table

@item status [@var{options}] @var{files}@dots{}
作業ディレクトリの状態の情報を表示します。@ref{File status} 参照。

@table @code
@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -v
ファイルにタグ情報を含めます。@ref{Tags} 参照。
@end table

@item tag [@var{options}] @var{tag} [@var{files}@dots{}]
ファイルの取り出されたリビジョンにタグ名を追加します。@ref{Revisions}
と @ref{Branching and merging} 参照。

@table @code
@item -b
@var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。

@item -c
作業ファイルが無修正かどうかを調べます。@ref{Tagging the working
directory} 参照。

@item -D @var{date}
@var{date} の時点のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。

@item -d
@var{タグ} を消去します。@ref{Modifying tags} 参照。

@item -F
タグが存在していればそれを移動します。@ref{Tagging by date/tag} 参照。

@item -f
タグ/日付が見つからなければ先頭のリビジョンとの合致を強制します。
@ref{Tagging by date/tag} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{rev}
存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参
照。
@end table

@item unedit [@var{options}] [@var{files}@dots{}]
edit コマンドの効果を取り消します。@ref{Editing files} 参照。

@table @code
@item -a @var{actions}
@var{actions} は @code{edit}, @code{unedit}, @code{commit},
@code{all},  @code{none} のどれかです。@ref{Editing files} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@item update [@var{options}] [@var{files}@dots{}]
作業木とリポジトリとの同期を取ります。@ref{update} 参照。

@table @code
@item -A
貼り付いたタグ/日付/オプションを取ります。@ref{Sticky tags} と
@ref{Keyword substitution} 参照。

@item -D @var{date}
@var{date} 時点でのリビジョンを取り出します (貼り付きます)。
@ref{Common options} 参照。

@item -d
ディレクトリを作成します。@ref{update options} 参照。

@item -f
タグ/日付が見つからなければ先頭のリビジョンを使用します。@ref{Common
options} 参照。

@item -I @var{ign}
ファイルを無視します (無効にするためには ! を使います)。@ref{import
options} 参照。

@c Probably want to use rev1/rev2 style like for diff
@c -r.  Here and in on-line help.
@item -j @var{rev}
変更をマージします。@ref{update options} 参照。

@item -k @var{kflag}
@var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -P
空のディレクトリを削除します。@ref{Moving directories} 参照。

@item -p
ファイルを標準出力に取り出します (貼り付きを回避します)。@ref{update
options} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.

@item -r @var{tag}
リビジョン @var{tag} を取り出します (貼り付きます)。@ref{Common
options} 参照。

@item -W @var{spec}
ラッパーです。@ref{import options} 参照。
@end table

@item watch [on|off|add|remove] [@var{options}] [@var{files}@dots{}]

on/off: ファイルの読み込み専用取り出しを on/off します。@ref{Setting a
watch} 参照。

add/remove: 動作の通知を追加削除します。@ref{Getting Notified} 参照。

@table @code
@item -a @var{actions}
一時監視への動作を指定します。
@var{actions} は @code{edit}, @code{unedit},
@code{commit}, @code{all}, @code{none} のどれかです。
@ref{Editing files} 参照。

@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@item watchers [@var{options}] [@var{files}@dots{}]
誰がファイル監視しているかを見ます。@ref{Watch information} 参照。

@table @code
@item -l
Local、つまり現在の作業ディレクトリでのみコマンドが
実行されます。@ref{Recursive behavior} 参照。

@item -R
再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
@end table

@end table

@c ---------------------------------------------------------------------
@node Administrative files
@appendix 管理用ファイル便覧
@cindex Administrative files (reference)
@cindex Files, reference manual
@cindex Reference manual (files)
@cindex CVSROOT (file)

@c FIXME?  Somewhere there needs to be a more "how-to"
@c guide to writing these.  I think the triggers
@c (commitinfo, loginfo, taginfo, &c) are perhaps a
@c different case than files like modules.  One
@c particular issue that people sometimes are
@c (unnecessarily?) worried about is performance, and
@c the impact of writing in perl or sh or ____.
リポジトリ中のディレクトリ @file{$CVSROOT/CVSROOT} に、
@sc{cvs} を支援する多くのファイルが置かれます。
これらのファイルが無いと @sc{cvs} の能力が制限されてしまいますが、
適切に設定すれば種々の操作を簡略化することができます。
これらを編集する方法は @ref{Intro administrative files} 参照。

これらの内で最も重要なファイルは @file{modules} で、
リポジトリ内のモジュールを定義します。

@menu
* modules::                     モジュールを定義する
* Wrappers::                    ファイル名の応じてバイナリかどうかを指定する
* commit files::                格納を支援するファイル
* commitinfo::                  格納前にチェックする
* verifymsg::                   ログメッセージはどのように評価されるのか?
* editinfo::                    ログ・メッセージの作成方法を指示
                                (旧式)
* loginfo::                     ログ・メッセージをどこに送るか?
* rcsinfo::                     ログ・メッセージの雛型
* cvsignore::                   無視するファイルを設定する
* checkoutlist::                自分自身の管理ファイルを追加する
* history file::                履歴情報を記録する
* Variables::                   各種変数の展開
* config::                      その他の CVS の設定
@end menu

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node modules
@appendixsec The modules file
@cindex Modules (admin file)
@cindex Defining modules (reference manual)

管理用ファイル @file{modules} には、
ソース・コードの集合体の名前の定義を記述します。
新たな定義を @sc{cvs} に理解させるには、
@sc{cvs} を用いてファイル @file{modules} を修正して下さい 
(@code{add}, @code{commit} など普通のコマンドを使用します)。

ファイル @file{modules} には、モジュールの定義だけでなく、
空白行や註釈行 (@samp{#} で始まる行) も記述できます。
またバックスラッシュ (@samp{\}) を行の最後に加えて、
長い行を次の行にまで続けることができます。

モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア
ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト
リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには 
@file{first-dir} というディレクトリがあり、そこには @file{file1} と 
@file{file2} というファイルがあり、@file{sdir} というディレクトリがあ
ります。@file{first-dir/sdir} には @file{sfile} というファイルがありま
す。

@c FIXME: should test all the examples in this section.

@menu
* Alias modules::             一番簡単なモジュール
* Regular modules::
* Ampersand modules::
* Excluding directories::     モジュールからディレクトリを除外する
* Module options::            一般とアンドモジュールはオプションを取れる
@end menu

@node Alias modules
@appendixsubsec 別名モジュール
@cindex Alias modules
@cindex -a, in modules file

別名モジュールが一番簡単な種類のモジュールです:

@table @code
@item @var{mname} -a @var{aliases}@dots{}
これはモジュール @var{mname} の最も簡単な定義方法を表わします。
@samp{-a} フラグは単純に別名の定義を行います:
@sc{cvs} に (コマンドの引数として) @var{mname} が与えられると、
@var{aliases} に記述された名前の一覧を代りに使用します。
@var{aliases} は他のモジュール名もしくはパス名から構成します。
@var{aliases} にパス名を使用した場合、
@sc{cvs} の引数にパス名を明示した場合と同じく、
@code{checkout} したとき途中の全てのディレクトリが
作業ディレクトリに作成されます。
@end table

例えば、モジュールファイルの内容が以下のようであると:

@example
amodule -a first-dir
@end example

@noindent
次の2つのコマンドは等価です:

@example
$ cvs co amodule
$ cvs co first-dir
@end example

@noindent
そして、それらは以下のような出力を出します:

@example
cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile
@end example

@node Regular modules
@appendixsubsec 一般モジュール
@cindex Regular modules

@table @code
@item @var{mname} [ options ] @var{dir} [ @var{files}@dots{} ]
この形式のモジュール定義を最も単純にすると、
@samp{@var{mname} @var{dir}} となります。
これはディレクトリ @var{dir} の全てのファイルを、
モジュール @var{mname} と定義します。
@var{dir} は (@code{$CVSROOT} から) 
ソースのあるディレクトリへの相対パス名です。
この場合にソースを取り出すと、
@var{mname} というディレクトリだけが作業ディレクトリに作成されます。
つまり @var{dir} が複数のディレクトリ階層から成るパス名であっても、
既定では途中のディレクトリ階層は使用されません。
@end table

例えば、モジュールが以下で定義されていると:

@example
regmodule first-dir
@end example

@noindent
regmodule は first-dir のファイルを含みます:

@example
$ cvs co regmodule
cvs checkout: Updating regmodule
U regmodule/file1
U regmodule/file2
cvs checkout: Updating regmodule/sdir
U regmodule/sdir/sfile
$
@end example

@var{dir} の後で明示的にモジュールを指定することで、特定のファイルをディ
レクトリ @var{dir} から選択することができます。例:

@example
regfiles first-dir/sdir sfile
@end example

@noindent
この定義により、regfiles モジュールを取得すると、一覧に挙げられたファ
イルがある単独のディレクトリ @file{regfiles} を作成し、それは @sc{cvs}
のソースリポジトリのより深いディレクトリから来ています。

@example
$ cvs co regfiles
U regfiles/sfile
$
@end example

@node Ampersand modules
@appendixsubsec アンドモジュール
@cindex Ampersand modules
@cindex &, in modules file

モジュール定義は定義に @samp{&@var{module}} を含めることで他のモジュー
ルを参照することができます。
@example
@var{mname} [ options ] @var{&module}@dots{}
@end example

そうすると、モジュールを取得したときに、モジュールのあるディレクトリで、
それぞれのモジュールのためのサブディレクトリを作成します。

@example
ampermod &first-dir
@end example

そうすると、checkout は @code{ampermod} ディレクトリを作成し、それには 
@code{first-dir} というディレクトリがあり、それは今度は自分の全てのファ
イルとディレクトリを持っています。例えば、コマンド

@example
$ cvs co ampermod
@end example

@noindent
は以下のファイルを作成します:

@example
ampermod/first-dir/file1
ampermod/first-dir/file2
ampermod/first-dir/sdir/sfile
@end example

ここには、一つ癖/バグがあります: @sc{cvs} が印字するメッセージは 
@file{ampermod} を省略するので、ファイルが取り出された位置を正確に表示
しません。

@example
$ cvs co ampermod
cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile
$
@end example

このバグっぽい動作に頼らないでください。@sc{cvs} の将来のリリースでは
修正されているかもしれません。

@c FIXCVS: What happens if regular and & modules are
@c combined, as in "ampermodule first-dir &second-dir"?
@c When I tried it, it seemed to just ignore the
@c "first-dir".  I think perhaps it should be an error
@c (but this needs further investigation).
@c In addition to discussing what each one does, we
@c should put in a few words about why you would use one or
@c the other in various situations.

@node Excluding directories
@appendixsubsec ディレクトリの除外
@cindex excluding directories, in modules file
@cindex !, in modules file

別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符 
(@samp{!}) を付けることで、特定のディレクトリを除外することができます。

例えば、モジュールファイルが以下のようになっていると:

@example
exmodule -a !first-dir/sdir first-dir
@end example

モジュール @samp{exmodule} を取り出すと、サブディレクトリ 
@samp{first-dir/sdir} にあるファイル以外の全てを取り出します。
@c Note that the "!first-dir/sdir" sometimes must be listed
@c before "first-dir".  That seems like a probable bug, in which
@c case perhaps it should be fixed (to allow either
@c order) rather than documented.  See modules4 in testsuite.

@node Module options
@appendixsubsec モジュールのオプション
@cindex options, in modules file

標準モジュールとアンドモジュールのどちらもオプションを含むことができ、
それはモジュールの追加情報を提供します。

@table @code
@cindex -d, in modules file
@item -d @var{name}
作業ディレクトリの名前をモジュール名とは別のものにします。
@c FIXME: Needs a bunch of examples, analogous to the
@c examples for alias, regular, and ampersand modules
@c which show where the files go without -d.

@cindex Export program
@cindex -e, in modules file
@item -e @var{prog}
モジュールのファイルが export されたときに常に実行されるプログラム
@var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
行されます。
@c FIXME: Is it run on server? client?

@cindex Checkin program
@cindex -i, in modules file
@item -i @var{prog}
モジュールのファイルが格納されたときに常に実行されるプログラム 
@var{prog} を指定します。@var{prog} はソースリポジトリの影響を受けるディ
レクトリのフルパス名である唯一の引数と共に実行されます。
@file{commitinfo}, @file{loginfo}, @file{veryfymsg} ファイルは格納時に
プログラムを呼ぶ他の方法を提供します。
@c FIXME: Is it run on server? client?

@cindex Checkout program
@cindex -o, in modules file
@item -o @var{prog}
ファイルのモジュールが取り出されたときに常に実行されるプログラム 
@var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
行されます。
@c FIXME: Is it run on server? client?

@cindex Status of a module
@cindex Module status
@cindex -s, in modules file
@item -s @var{status}
モジュールに状態を割当てます。モジュールファイルが @samp{cvs checkout
-s} で印字されると、モジュールが主モジュール状態に従って並び換えられ、
それからモジュール名に従って並び換えられます。このオプションは他に意味
はありません。状態以外のいくつかのことにこのオプションを使うことができ
ます: 例えば、このモジュールに責任のある人の一覧などです。

@cindex Tag program
@cindex -t, in modules file
@item -t @var{prog}
モジュールのファイルが @code{rtag} でタグ付けされたとに常に実行される
プログラム @var{prog} を指定します。@var{prog} は2つの引数と共に実行さ
れます: モジュール名と @code{rtag} に指定されたタグ名です。@code{tag} 
が行われたときは実行されません。一般的に、taginfo の方が良い解決法です 
(@pxref{user-defined logging})。
@c FIXME: Is it run on server? client?
@c Problems with -t include:
@c * It is run after the tag not before
@c * It doesn't get passed all the information that
@c   taginfo does ("mov", &c).
@c * It only is run for rtag, not tag.

@cindex Update program
@cindex -u, in modules file
@item -u @var{prog}
取り出されたモジュールの最上位のディレクトリで @samp{cvs} が行なわれた
ときに常に実行されるプログラム @var{protg} を指定します。@var{prog} は
単独の引数、このモジュールのソースリポジトリのフルパスとともに実行され
ます。
@c FIXME: Is it run on server? client?
@c One drawback of -u and -i are that CVS/Update.prog
@c and CVS/Checkin.prog only get updated on initial
@c checkout, and don't get updated if the modules file
@c changes.  Also, the user can edit them, which means
@c they are no good for security-type stuff.
@end table

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Wrappers
@appendixsec The cvswrappers file
@cindex cvswrappers (admin file)
@cindex CVSWRAPPERS, environment variable
@cindex Wrappers

@c FIXME: need some better way of separating this out
@c by functionality.  -t/-f is one feature, -m is
@c another, and -k is a third.  And this discussion
@c should be better motivated (e.g. start with the
@c problems, then explain how the feature solves it).

Wrapper とは操作中のファイル名に基づいて設定を制御することを可能にする
@sc{cvs} の機能のことです。設定は、バイナリ・ファイルには @samp{-k} で、
マージできないテキスト・ファイルには @samp{-m} です。

@ignore
Wrapper 機能を用いれば、ファイルを @sc{cvs} に取り込む/取り出す際に、
適切な方法で変換するように設定することができます。

管理用ファイル @file{cvswrappers} には、
ファイル名に合致する正規表現と、
そのファイルに対して実行されるスクリプトが記述されます。
個々のファイルやディレクトリに対して、二つのスクリプトが記述できます。
各々リポジトリに格納する前 (@samp{-t} フラグが付けられます) と、
リポジトリから取り出すとき (@samp{-f} フラグが付けられます) に
実行するものです。@samp{-t}/@samp{-f} 機能はクライアント/サーバの 
@sc{cvs} では動作しません。
@c I think maybe -t/-f works client/server if a single
@c file converts to/from a single file, as opposed to
@c the file<->directory case.  Could use more
@c investigation...
@end ignore

また、非バイナリ・ファイルを更新するときの
マージ方針について記述するオプション @samp{-m} があります。
@code{MERGE} は @sc{cvs} が通常用いる方法です:
ファイルをマージしようとすることを意味します。@code{COPY} は @code{cvs
update} はファイルのマージを拒否するという意味で、@samp{-kb} でバイナ
リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
されていれば、@samp{-m 'COPY'} を指定する必要はありません。
CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
ために使用者が @sc{cvs} の外の機構を使用することを要求します。
@strong{警告}: @sc{cvs} 1.9 以前では @code{COPY} を使わないでくださ
い---それらのバージョンの @sc{cvs} はあるバージョンを別の物の上にコピー
し、以前の内容を消し去ってしまいます。
@c Ordinarily we don't document the behavior of old
@c versions.  But this one is so dangerous, I think we
@c must.  I almost renamed it to -m 'NOMERGE' so we
@c could say "never use -m 'COPY'".
Wrapper オプション @samp{-m} は更新時のマージ方針にのみ影響し、
ファイルの格納方法には影響しません。
バイナリ・ファイルの詳細は @ref{Binary files} 参照。

管理用ファイル @file{cvswrappers} の基本的な書式:

@c FIXME: @example is all wrong for this.  Use @deffn or
@c something more sensible.
@example
ワイルドカード    [オプション 値][オプション 値]...

利用できるオプションを以下に挙げます。
@ignore
-f                取得時のフィルタ        値: フィルタのパス
-t                格納時のフィルタ        値: フィルタのパス
@end ignore
-m                マージ方針              値: MERGE か COPY
-k                キーワード展開          値: 置換モード

値は以下のように単引用符で囲みます。
@end example

@ignore
@example
*.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
*.c      -t 'indent %s %s'
@end example
@c When does the filter need to be an absolute pathname
@c and when will something like the above work?  I
@c suspect it relates to the PATH of the server (which
@c in turn depends on all kinds of stuff, e.g. inetd
@c for pserver).  I'm not sure whether/where to discuss
@c this.
@c FIXME: What do the %s's stand for?

@noindent
@file{cvswrappers} の上側の例では、
@samp{.nib} で終わる全てのファイル/ディレクトリを、
リポジトリに格納する前に @file{wrap} プログラムで
整形することが記述されています。
リポジトリから取り出す際には @file{unwrap} プログラムが用いられます。
またファイルを更新する際には
@code{COPY} する方針を採ることが記述されています 
(すなわち、マージを行いません)。

@c What pitfalls arise when using indent this way?  Is
@c it a winning thing to do?  Would be nice to at least
@c hint at those issues; we want our examples to tell
@c how to solve problems, not just to say that cvs can
@c do certain things.
最後の行の例では、@samp{.c} で終わるファイル全てを、
リポジトリに格納する前に @file{indent} で整形することが記述されています。
前の例とは異なり、リポジトリから取り出す際には整形されません。
@noindent
@samp{-t} に記述されるフィルタには二つの引数が与えられます。
最初は整形されるファイル/ディレクトリで、
次には整形された結果が出力されるファイルのパス名です。

@noindent
@samp{-f} に記述されるフィルタには、
整形されるファイル名が引数として与えられます。
整形された結果は、作業ディレクトリにファイルとして置かれます。

@samp{-t}/@samp{-f} 機能は CVS の操作の一部分---ファ
イルが修正されたとき---を便利に扱えません。CVS はまだファイル (もしく
はディレクトリ) が存在することを望み、その修正時刻をファイルが修正され
たかどうかを決定するために使います。もし CVS が間違ってファイルが未修
正であると考えれば (例えば、ディレクトリは無変更だけど、その中のファイ
ルのどれかが変更されたとき)、@code{cvs commit} に @samp{-f} オプション
を指定することでとにかくファイルの格納を強制できます (@pxref{commit
options})。
@c This is, of course, a serious design flaw in -t/-f.
@c Probably the whole functionality needs to be
@c redesigned (starting from requirements) to fix this.
@end ignore

@c FIXME: We don't document -W or point to where it is
@c documented.  Or .cvswrappers.
例えば、@samp{.exe} で終わるファイルをバイナリとして扱いながら、
ディレクトリを取り入れます:

@example
cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
@end example

@c Another good example, would be storing files
@c (e.g. binary files) compressed in the repository.
@c 	::::::::::::::::::
@c 	cvswrappers
@c 	::::::::::::::::::
@c 	*.t12 -m 'COPY'
@c 	*.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
@c
@c	::::::::::::::::::
@c	gunzipcp
@c	::::::::::::::::::
@c	:
@c	[ -f $1 ] || exit 1
@c	zcat $1 > /tmp/.#$1.$$
@c	mv /tmp/.#$1.$$ $1
@c
@c	::::::::::::::::::
@c	gzipcp
@c	::::::::::::::::::
@c	:
@c	DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
@c	if [ ! -d $DIRNAME ] ; then
@c	      DIRNAME=`echo $1 | sed -e "s|.*/||g"`
@c	fi
@c	gzip -c  $DIRNAME  > $2
@c One catch--"cvs diff" will not invoke the wrappers
@c (probably a CVS bug, although I haven't thought it out).

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node commit files
@appendixsec 格納を支援するファイル
@cindex Commit files

ファイル @file{modules} 中の @samp{-i} フラグは、
ファイルが格納された時に特定のプログラムを実行するのに用いられます 
(@pxref{modules})。
この節で説明するファイルは、
ファイルの格納時にプログラムを実行するための、
より柔軟な方法を提供します。

格納時に実行できるプログラムは三種類に分けられます。
これらのプログラムはリポジトリ中のファイルに記述されます。
次に示すのは、
ファイル名と、対応するプログラムに必要な機能を示したものです。

@table @file
@item commitinfo
ここに記述されるプログラムは、
格納が許されるかどうか判断する責任を持ちます。
このプログラムが正常終了しなければ、
格納が中止されます。

@item verifymsg
指定されたプログラムはログメッセージを評価するために使用され、それは全
ての要求部分を備えているかを検証するかもしれません。これはログメッセー
ジの雛型を保持することのできる @file{rcsinfo} ファイルと組合せて使うと
とても役に立ちます (@pxref{rcsinfo})。

@item editinfo
ここに記述されるプログラムは、
ログ・メッセージを編集するのに用いられ、
全ての要求される項目が含まれるかどうか可能な限り確かめます。
ログ・メッセージの雛型を記述する @file{rcsinfo} ファイルと
組み合せることで、より便利になります (@pxref{rcsinfo})。(旧式)

@item loginfo
ここに記述されるプログラムは、
格納が完了した時点で呼び出されます。
ログ・メッセージと追加情報とを受け取り、ファイルに格納するか、
特定の人物にメールとして出すか、またはニュース・グループに投稿するとか、
または@dots{} あなたの想像力だけがその制限です。
@end table

@menu
* syntax::                      共通の構文
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node syntax
@appendixsubsec 共通の構文
@cindex Info files (syntax)
@cindex Syntax of info files
@cindex Common syntax of info files

@c FIXME: having this so totally separate from the
@c Variables node is rather bogus.

@file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{editinfo},
@file{verifymsg}, などのような管理ファイルには共通の書式があります。
各ファイルの目的は後述します。
ここでは共通の構文について説明します。

@cindex regular expression syntax
各行は次の要素から構成されます:
@itemize @bullet
@item
@c Say anything about DEFAULT and ALL?  Right now we
@c leave that to the description of each file (and in fact
@c the practice is inconsistent which is really annoying).
正規表現。これは GNU emacs で使われる構文の基本正規表現です。
@c FIXME: What we probably should be saying is "POSIX Basic
@c Regular Expression with the following extensions (`\('
@c `\|' '+' etc)"
@c rather than define it with reference to emacs.
@c The reference to emacs is not strictly speaking
@c true, as we don't support \=, \s, or \S.  Also it isn't
@c clear we should document and/or promise to continue to
@c support all the obscure emacs extensions like \<.
@c Also need to better cite (or include) full
@c documentation for the syntax.
@c Also see comment in configure.in about what happens to the
@c syntax if we pick up a system-supplied regexp matcher.

@item
項目間の空白---一つ以上のスペース又はタブです。

@item
ファイル名又はコマンド行の形式。
@end itemize

@noindent
空白行は無視されます。
また @samp{#} という文字で始まる行は註釈行として扱われます。
残念ながら、長い行を複数行に分割することは@emph{できません}。

リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。
行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。

@c FIXME: need an example.  In particular, show what
@c the regular expression is matched against (one
@c ordinarily clueful person got confused about whether it
@c includes the filename--"directory name" above should be
@c unambiguous but there is nothing like an example to
@c confirm people's understanding of this sort of thing).

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node commitinfo
@appendixsec 管理用ファイル commitinfo
@cindex Commitinfo
@cindex Checking commits
@cindex Precommit checking

@samp{cvs commit} を実行する直前に必ず実行したいプログラムを、
ファイル @file{commitinfo} に記述します。
修正、追加、削除されたファイルを格納しても良いかどうか、
このプログラムを用いて格納前に判断します。
例えば、変更されたファイルがあなたのサイトの
コーディング・スタイルの標準に従っているか確かめることもできます。

前に書いたように、@file{commitinfo} の各行は、第一項の正規表現、
残りの部分のコマンド行形式から構成されます。
コマンド行の部分には、
プログラム名と適切な数の引数とを記述することができます。
また実行の際には、リポジトリのフルパスと
格納しようとするファイル名 (追加, 削除, 修正されたファイル名) 
がコマンド行の最後に与えられます。

@cindex exit status, of commitinfo
リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。
そしてコマンドが非零で終了した場合は、格納が中止されます。
@c FIXME: need example(s) of what "directory within the
@c repository" means.

@cindex DEFAULT in commitinfo
第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。

@cindex ALL in commitinfo
第一項が @samp{ALL} である行全てが、
最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。

注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
@file{commitinfo} に記述された行は、
クライアント側ではなく@emph{別のマシン} (サーバ) 側で実行されます 
(@pxref{Remote repositories})。

@c FIXME: should discuss using commitinfo to control
@c who has checkin access to what (e.g. Joe can check into
@c directories a, b, and c, and Mary can check into
@c directories b, c, and d--note this case cannot be
@c conveniently handled with unix groups).  Of course,
@c adding a new set of features to CVS might be a more
@c natural way to fix this problem than telling people to
@c use commitinfo.
@c FIXME: Should make some reference, especially in
@c the context of controlling who has access, to the fact
@c that commitinfo can be circumvented.  Perhaps
@c mention SETXID (but has it been carefully examined
@c for holes?).  This fits in with the discussion of
@c general CVS security in "Password authentication
@c security" (the bit which is not pserver-specific).

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node verifymsg
@appendixsec ログメッセージの検証
@cindex verifymsg (admin file)
@cindex log message, verifying

一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために
そのメッセージを評価することができます。ログメッセージを検証するための
プログラムを指定するために @file{verifymsg} ファイルを使用することがで
きます。このプログラムは入力されたメッセージに必要なフィールドがあるか
どうかを調べる簡単なスプリプトでも良いでしょう。

@file{verifymsg} ファイルは、ログメッセージの雛型を指定するために使う
ことのできる @file{rcsinfo} ファイルと一緒に使用されたときにとても役に
立つことが多いです。

@file{verifymsg} ファイルは正規表現とコマンド行の雛型から成ります。雛
型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで
きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加
されます。

一つ注意しなければならないのは、@samp{ALL} キーワードは使えないという
ことです。一行以上合致した場合、最初のものが使われます。これはディレク
トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき
に役に立ちます。

@cindex DEFAULT in verifymsg
リポジトリ名がこのファイルのどの正規表現にも合致しなければ、
@samp{DEFAULT} が指定されていると、それが使用されます。

@cindex exit status, of verifymsg
検証スクリプトが非零の値で終了すれば、格納は中止されます。

検証スクリプトはログメセージを変更できないことに注意してください。単に
受け入れるか拒否するかのどちらかです。
@c FIXME?  Is this an annoying limitation?  It would be
@c relatively easy to fix (although it would *not* be a
@c good idea for a verifymsg script to interact with the user
@c at least in the client/server case because of locks
@c and all that jazz).

以下は、@file{verifymsg} ファイルのちょっとしたばかげた例と、それに対
応する @file{rcsinfo} ファイル、ログメッセージの雛型と検証スクリプトで
す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの
最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの
です。以下の雛型ファイルは @file{/usr/cvssupport/tc.template} にありま
す。

@example
BugId:
@end example

スクリプト @file{/usr/cvssupoort/bugid.verify} はログメッセージの評価
に使われます。

@example
#!/bin/sh
#
#       bugid.verify filename
#
#  Verify that the log message contains a valid bugid
#  on the first line.
#
if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
    exit 0
else
    echo "No BugId found."
    exit 1
fi
@end example

@file{verifymsg} ファイルには以下の行があります:

@example
^tc     /usr/cvssupport/bugid.verify
@end example

@file{rcsinfo} ファイルには以下の行があります:

@example
^tc     /usr/cvssupport/tc.template
@end example



@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node editinfo
@appendixsec Editinfo
@cindex editinfo (admin file)
@cindex Editor, specifying per module
@cindex Per-module editor
@cindex Log messages, editing

@emph{注意:} @file{editinfo} 機能は旧式になっています。ログメッセージ
の既定のエディタを設定するためには、@code{EDITOR} 環境変数 
(@pxref{Environment variables}) か @samp{-e} 広域オプション
(@pxref{Global options}) を使用してください。ログメッセージを評価する
ための @file{verifymsg} 機能を使うための情報は @ref{verifymsg} を参照
してください。

いつも同じ形式でログ・メッセージを記録したい場合に、
ログ・メッセージを編集するプログラムを @file{editinfo} に
指定することができます。
指定するプログラムは、
ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、
エディタを呼び出して、入力されたメッセージが必要項目を
満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。

合致する行が @file{editinfo} になかった場合、
環境変数 @code{$CVSEDITOR} に指定されたエディタを使用します。
この環境変数が設定されていない場合には、
環境変数 @code{$EDITOR} に指定されたエディタを代わりにします。
そしてこの環境変数も設定されていない場合は、
既定のものが使われます。@ref{Committing your changes} 参照。

@file{rcsinfo} にログ・メッセージの雛型を指定すると、
より効果的に @file{editinfo} を利用できるでしょう。

@file{editinfo} の各行は、第一項の正規表現、
残りの部分のコマンド行形式から構成されます。
コマンド行の部分には、
プログラム名と適切な数の引数とを記述することができます。
また実行の際には、ログ・メッセージの雛型へのフルパス
がコマンド行の最後に与えられます。

@samp{ALL} が利用できないことに注意して下さい。
合致する行が複数あった場合は、最初の行が実行されます。
これは、モジュールの編集スクリプトが設定されていて、
サブディレクトリでは別のものを使用したい場合を考慮しています。

@cindex DEFAULT in editinfo
第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。

編集スクリプトが非零で終了した場合は、格納が中止されます。

注意: @sc{cvs} が別のマシンのリポジトリを利用している場合や、
@code{cvs commit} の @samp{-m} または @samp{-F} オプションを
使用した場合、@file{editinfo} は参照されません。
この問題を解決する良い方法は今のところありません。
代わりに @file{verifymsg} を使ってください。

@menu
* editinfo example::            editinfo 記述例
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node editinfo example
@appendixsubsec editinfo 記述例

次に、ちょっとアホくさい @file{editinfo} の使用例を、
対応する @file{rcsinfo}、ログ・メッセージの雛型、
エディタ・スクリプトと併わせて紹介します。
まずログ・メッセージの雛型ですが、
最初の行に必ずバグ番号を記録するように促し、
残りは自由に記述してもらいます。
この雛型は @file{/usr/cvssupport/tc.template} に置くことにします。

@example
BugId:
@end example

ログ・メッセージを編集するため、
次のスクリプト @file{/usr/cvssupport/bugid.edit} を使用します。

@example
#!/bin/sh
#
#       bugid.edit filename
#
#  Call $EDITOR on FILENAME, and verify that the
#  resulting file contains a valid bugid on the first
#  line.
if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
$CVSEDITOR $1
until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
do  echo -n  "No BugId found.  Edit again? ([y]/n)"
    read ans
    case $@{ans@} in
        n*) exit 1;;
    esac
    $CVSEDITOR $1
done
@end example

ファイル @file{editinfo} には次の行を記述します:

@example
^tc     /usr/cvssupport/bugid.edit
@end example

ファイル @file{rcsinfo} には次の行を記述します:

@example
^tc     /usr/cvssupport/tc.template
@end example

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node loginfo
@appendixsec 管理用ファイル loginfo
@cindex loginfo (admin file)
@cindex Storing log messages
@cindex Mailing log messages
@cindex Distributing log messages
@cindex Log messages

@c "cvs commit" is not quite right.  What we
@c mean is "when the repository gets changed" which
@c also includes "cvs import" and "cvs add" on a directory.
@file{loginfo} を用いて、
@samp{cvs commit} によるログ情報の送り先を管理します。
各行の第一項には正規表現が記述され、
行の残りの部分はフィルタでなくてはいけません。
変更を加えたディレクトリを 
@code{$CVSROOT} からの相対パスで表わしたものと、
各行の正規表現が合致するかどうか試されます。
合致した場合は、
その行の残りの部分であるフィルタ・プログラムの標準入力に、
ログ情報を与えます。

第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。

第一項が @samp{ALL} である行全てが、
最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。

正規表現が合致する最初の行が実行されます。

ファイル @file{loginfo} の構文についての記述は @xref{commit files}.

使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は 
@samp{%} の後に空白か、単独のフォーマット文字、もしくは分離器 
@samp{@{} と @samp{@}} に囲まれたいくつかのフォーマット文字が続いた物
です。フォーマット文字は:

@table @t
@item s
ファイル名
@item V
古いバージョン番号 (格納前)
@item v
新しいバージョン番号 (格納後)
@end table

フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます
(フィールドを分離するコンマはまだ提供されされています。)

例えば、有効なフォーマット文字列は @samp{%}, @samp{%s}, @samp{%@{s@}}, 
@samp{%@{sVv@}} などです。

出力は空白で区切られた語からなる文字列になります。下位互換のために、最
初の語はリポジトリ名になります。残りの語はフォーマット文字列で要求され
た情報をコンマで分けたリストです。例えば、@samp{/u/src/master} がリポ
ジトリで @samp{%@{sVv@}} がフォーマット文字列、3つのファイル
(@t{ChangeLog}, @t{Makefile}, @t{foo.c}) が修正されていると、出力は:

@example
/u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
@end example

別の例として、@samp{%@{@}} ではリポジトリ名のみが作成されます。

注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
@file{loginfo} はクライアント側ではなく、@emph{別のマシン} 
(サーバ) 側で実行されます 
(@pxref{Remote repositories})。

@menu
* loginfo example::             loginfo 記述例
* Keeping a checked out copy::  格納毎にディレクトリを更新
@end menu

@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node loginfo example
@appendixsubsec loginfo 記述例

ここで示す @file{loginfo} ファイルと付属のシェル・スクリプトは、
格納時に次のような動作をします。
まず全てのログ・メッセージを 
@file{$CVSROOT/CVSROOT/commitlog} に追記します。
次に全ての管理用ファイル (@file{CVSROOT} 内) の
格納時のログを @file{/usr/adm/cvsroot-log} に追記します。
@file{prog1} ディクトリへの格納は @t{ceder} にメールで送られます。

@c FIXME: is it a CVS feature or bug that only the
@c first matching line is used?  It is documented
@c above, but is it useful?  For example, if we wanted
@c to run both "cvs-log" and "Mail" for the CVSROOT
@c directory, it is kind of awkward if
@c only the first matching line is used.
@example
ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
^prog1          Mail -s %s ceder
@end example

シェル・スクリプト @file{/usr/local/bin/cvs-log} の内容:

@example
#!/bin/sh
(echo "------------------------------------------------------";
 echo -n $2"  ";
 date;
 echo;
 cat) >> $1
@end example

@node Keeping a checked out copy
@appendixsubsec 取得済のコピーを最新に保つ

@c What other index entries?  It seems like
@c people might want to use a lot of different
@c words for this functionality.
@cindex keeping a checked out copy
@cindex checked out copy, keeping
@cindex web pages, maintaining with CVS

あるディレクトリがリポジトリで管理されている場合、
そのディレクトリを常に最新にしておきたい事があるでしょう。
例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、
@sc{cvs} で保守されたウェブ・サイトのファイルを
格納毎に更新したい場合などです。
@c Can we offer more details on the web example?  Or
@c point the user at how to figure it out?  This text
@c strikes me as sufficient for someone who already has
@c some idea of what we mean but not enough for the naive
@c user/sysadmin to understand it and set it up.

これを実現するため、
@code{cvs update} を実行するように @file{loginfo} を設定します。
しかし単純に設定するとロックの問題が発生するので、
@code{cvs update} をバックグラウンドで実行する必要があります。
@c Should we try to describe the problem with locks?
@c It seems like a digression for someone who just
@c wants to know how to make it work.
@c Another choice which might work for a single file
@c is to use "cvs -n update -p" which doesn't take
@c out locks (I think) but I don't see many advantages
@c of that and we might as well document something which
@c works for multiple files.
Unix での例を以下に示します (実際は一行です):

@example
^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
 cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
@end example

リポジトリ中の @code{cyclic-pages} で始まるディレクトリに
ファイルが格納された時、
取得済みのディレクトリ @file{/u/www/local-docs} を更新します。
@c More info on some of the details?  The "sleep 2" is
@c so if we are lucky the lock will be gone by the time
@c we start and we can wait 2 seconds instead of 30.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node rcsinfo
@appendixsec 管理用ファイル rcsinfo
@cindex rcsinfo (admin file)
@cindex Form for log message
@cindex Log message template
@cindex Template for log message

@file{rcsinfo} には、格納時にログ・メッセージを
書き込むための書式を指定します。@file{rcsinfo} の
構文は @file{verifymsg}, @file{commitinfo}, @file{loginfo} 
とほぼ同じです。@xref{syntax}.
しかし他のファイルと異なり、
第二項はコマンド行形式では@emph{ありません}。
正規表現の次の部分は、ログ・メッセージの雛型を記した
ファイルへのフルパス名でなくてはいけません。

第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。

第一項が @samp{ALL} である行全てが、
最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。

@c FIXME: should be offering advice, somewhere around
@c here, about where to put the template file.  The
@c verifymsg example uses /usr/cvssupport but doesn't
@c say anything about what that directory is for or
@c whether it is hardwired into CVS or who creates
@c it or anything.  In particular we should say
@c how to version control the template file.  A
@c probably better answer than the /usr/cvssupport
@c stuff is to use checkoutlist (with xref to the
@c checkoutlist doc).
@c Also I am starting to see a connection between
@c this and the Keeping a checked out copy node.
@c Probably want to say something about that.
ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。
しかし、@samp{cvs commit -m @var{message}} や @samp{cvs commit -f
@var{file}} によってログ・メッセージを指定した場合、
こちらが優先されます。

@file{rcsinfo} ファイルの記述例は @xref{verifymsg}.

@sc{CVS} が別のマシンのリポジトリを利用している場合、
最初に作業ディレクトリを取り出した時に @file{rcsinfo} に
記述されていた雛型が使用され、以後変更されません。
@file{rcsinfo} や雛型を変更した場合には、
新たに作業ディレクトリを取り出す必要があります。
@c Would be nice to fix CVS so this isn't needed.  For
@c example, a mechanism analogous to CVS/Entries, where
@c the client keeps track of what version of the template
@c it has.

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node cvsignore
@appendixsec cvsignore でファイルを無視する
@cindex cvsignore (admin file), global
@cindex Global cvsignore
@cindex Ignoring files
@c -- This chapter should maybe be moved to the
@c tutorial part of the manual?

作業コピーの中に、いつも決まった名前のファイルがあるけれど、
@sc{cvs} の管理下には置きたくないという場合がよくあります。
例えば、ソースのコンパイル時に生成される
オブジェクト・ファイルなどです。
@samp{cvs update} を実行した場合には通常、
これらのファイル各々に対して、
知らないファイルがあったと出力されます 
(@pxref{update output})。

@sc{cvs} は、@code{update}, @code{import}, @code{release}
@c -- 影響があるのはこの三つで全部か?
の実行時に無視すべきファイルのリストを 
(sh(1) のファイル名形式で) 保持します
このリストは、以下の方法で構築されます。

@itemize @bullet
@item
リストは以下のファイル名形式で初期化されます: 
これらは、@sc{cvs} の管理に関するものの他、
他のソース管理システムと共通のもの、
一般的なパッチ・ファイル名、オブジェクト・ファイル、
書庫ファイル、エディタのバックアップ・ファイル、
他のユーティリティの通常の生成ファイル名等から構成されます。
現在、既定で無視されるファイル名形式のリストを以下に挙げます:

@cindex Ignored files
@cindex Automatically ignored files
@example
    RCS     SCCS    CVS     CVS.adm
    RCSLOG  cvslog.*
    tags    TAGS
    .make.state     .nse_depinfo
    *~      #*      .#*     ,*      _$*     *$
    *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
    *.a     *.olb   *.o     *.obj   *.so    *.exe
    *.Z     *.elc   *.ln
    core
@end example

@item
リポジトリ毎のリスト 
@file{$CVSROOT/CVSROOT/cvsignore} が存在すれば、
その内容がリストに付加されます。

@item
使用者毎のリスト @file{.cvsignore} が
あなたのホーム・ディレクトリに存在すれば、
その内容がリストに付加されます。

@item
環境変数 @code{$CVSIGNORE} の内容全てがリストに付加されます。

@item
@samp{-I} オプションによって @sc{cvs} に与えられた内容が、
リストに付加されます。

@item
作業ディレクトリを一通り見て @file{.cvsignore} があれば、
その内容をリストに付加します。
@file{.cvsignore} 内の形式は、
それが含まれるディレクトリのみで有効であり、
サブディレクトリに対しては効果を持ちません。
@end itemize

上記五つのファイル内で単感嘆符 (@samp{!}) を記述すると、
無視するファイルのリストが空になります。
これは、通常は @sc{cvs} に無視されるファイルを、
リポジトリに格納したい場合に使用します。

@code{cvs import} に @samp{-I !} を指定すると、全てを持ち込み、それは
素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
るのがわかると思います。もし配布に @file{.cvsignore} ファイルがあると、
そのファイルの形式は @samp{-I !} が指定されたとしても実行されます。唯
一の対策は持ち込むために、@file{.cvsigonre} ファイルを消去することです。
これはやっかいなので、将来は @samp{-I !} はそれぞれのディレクトリの
@file{.cvsignore} ファイルを上書きするように修正されるかもしれません。

無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ
れぞれの行が続いたものであることに注意してください。これは空白のある
ファイル名を指定する綺麗な方法を提供しませんが、@file{foo bar} という
名前のファイルに合致させるために @file{foo?bar} のような対策を使うこと
ができます (@file{fooxbar} などにも合致します)。また、現在は註釈を指定
する方法が無いことにも注意してください。
@c FIXCVS?  I don't _like_ this syntax at all, but
@c changing it raises all the usual compatibility
@c issues and I'm also not sure what to change it to.

@node checkoutlist
@appendixsec checkoutlist ファイル
@cindex checkoutlist

@sc{cvs} を使って自分自身のファイルを @file{CVSROOT} ディレクトリに維
持することは役に立つかもしれません。例えば、@file{logcommit.pl} という
スクリプトがあり、それは以下の行を @file{commitinfo} 管理ファイルに含
めることにより実行するとしましょう:

@example
ALL $CVSROOT/CVSROOT/logcommit.pl
@end example

@sc{cvs} で @file{logcommit.pl} を維持するためには、以下の行を 
@file{checkoutlist} 管理ファイルに追加します:

@example
logcommit.pl
@end example

@file{checkoutlist} の形式は、一行につき @sc{cvs} を使って維持したいそ
れぞれのファイルのファイル名を書いたものです。

このように @file{checkoutlist} を設定した後で、そこに一覧として挙げら
れているファイルは @sc{cvs} の元からの管理ファイルと同じように機能しま
す。例えば、そのファイルの一つを格納するときは、次のようなメッセージを
得るでしょう:

@example
cvs commit: Rebuilding administrative file database
@end example

そして、@file{CVSROOT} ディレクトリに取り出されているコピーも更新され
ます。

@file{passed} (@pxref{Password authentication server}) を 
@file{checkoutlist} に載せるうことはセキュリティに関する理由により
推奨されないことに注意してください。

@file{checkoutlist} で提供されるよりも一般的な文脈で取り出したコピーを
維持するための情報は、@ref{Keeping a checked out copy} を参照してくだ
さい。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node history file
@appendixsec ファイル history
@cindex History file
@cindex Log information, saving

ファイル @file{$CVSROOT/CVSROOT/history} は、
@code{history} コマンドのためにログ情報を記録します 
(@pxref{history})。
ログを記録したい場合には、このファイルを作成する必要があります。
@code{cvs init} でリポジトリを準備すると、
自動的に作成されます (@pxref{Creating a repository})。

@file{history} ファイルの書式を説明したものは、
@sc{cvs} ソース・コード内の註釈しかありません。
@sc{cvs} の将来のリリースで書式が変更されるかも知れないので、
このファイルは必ず @code{cvs history} を通して利用して下さい。

@node Variables
@appendixsec 管理用ファイルにおける変数展開

管理用ファイルを記述するときに、@sc{cvs} の動作環境についての
色々な情報を利用したい場合があると思います。
ここでは、その実現方法を幾つか紹介します。

@sc{cvs} を実行した人物のホーム・ディレクトリを 
(環境変数 @code{HOME} から) 参照するには、
@samp{/} または行端の直前に @samp{~} を記述します。
同様に @var{user} のホーム・ディレクトリは、
@samp{~@var{user}} と記述します。
これらの変数はサーバ側で展開されるため、@code{pserver} 
(@pxref{Password authenticated}) を用いる場合には正しく展開されません。
この場合、@sc{cvs} を実行する人物が動作を変更できるように、
ユーザ変数 (下記参照) を用いると良いでしょう。
@c Based on these limitations, should we deprecate ~?
@c What is it good for?  Are people using it?

@sc{cvs} 内部の情報を参照したい場合もあると思います。
@sc{cvs} の内部変数は @code{$@{@var{variable}@}} という書式で参照できます。
この @var{variable} は文字で始まり、
アルファベットと @samp{_} から構成されます。
@var{variable} に続く文字がアルファベットや @samp{_} でない場合は、
@samp{@{} と @samp{@}} とを省略しても構いません。
参照可能な @sc{cvs} の内部変数には次のようなものがあります:

@table @code
@item CVSROOT
@sc{cvs} が使用中のルート・ディレクトリを示します。
ルート・ディレクトリの指定方法は、@xref{Repository}.

@item RCSBIN
@sc{cvs} 1.9.18 以前では、これは @sc{cvs} が @sc{rcs} プログラムを探す
場所を指定していました。@sc{cvs} はもう @sc{rcs} プログラムを実行しま
せんので、今はこの内部変数を指定するとエラーになります。

@item CVSEDITOR
@itemx VISUAL
@itemx EDITOR
これらは @sc{cvs} が使用するエディタを示し、
全て同じ値に展開されます。
指定方法の説明は、@xref{Global options}.

@item USER
@sc{cvs} を実行する人物の (@sc{cvs} サーバでの) 名前に展開されます。
@end table

ユーザ変数を用いれば、@sc{cvs} を実行する人物が、
管理用ファイルで用いる値を自由に設定できます。
ユーザ変数は、管理用ファイルに @code{$@{=@var{variable}@}} と記述します。
ユーザ変数の設定は、@sc{cvs} の広域オプション @samp{-s} に、
引数 @code{@var{variable}=@var{value}} を続けます。
このオプションは @file{.cvsrc} に記述しておくと良いでしょう 
(@pxref{~/.cvsrc})。

例として、実験用ディレクトリを管理用ファイルから参照するため、
ユーザ変数 @code{TESTDIR} を用います。それから、以下のように @sc{cvs}
を起動し、

@example
cvs -s TESTDIR=/work/local/tests
@end example

@noindent
管理ファイルに @code{sh $@{=TESTDIR@}/runtests} と書いてあれば、文字列
は @code{sh /work/local/tests/runtests} に展開されます。

@samp{$} が上記以外の解釈を受けることはありません。
また @samp{$} 自身を表現する別の方法も用意されてないため、
@samp{$} という文字を引用することはできません。

@node config
@appendixsec The CVSROOT/config configuration file

@cindex config, in CVSROOT
@cindex CVSROOT/config

管理ファイル @file{config} は @sc{cvs} の振舞いに影響するいろいろな雑
多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ
れません。@samp{#} で始まる行は註釈と解釈されます。
@c FIXME: where do we define comments for the other
@c administrative files.
他の行はキーワード、@samp{=}、値からなります。この構文は厳密であること
に注意してください。余分な空白やタブは使えません。
@c See comments in parseinfo.c:parse_config for more
@c discussion of this strictness.

現在定義されているキーワードは:

@table @code
@cindex RCSBIN, in CVSROOT/config
@item RCSBIN=@var{bindir}
@sc{cvs} 1.9.12 から 1.9.18 まで、この設定は @var{bindir} ディレクトリ
にある @sc{rcs} プログラムを探すように @sc{cvs} に教えるために使われて
いました。現在のバージョンの @sc{cvs} は @sc{rcs} プログラムを実行しま
せん。互換性のためのこの設定は可能になってますが、何も起こりません。

@cindex SystemAuth, in CVSROOT/config
@item SystemAuth=@var{value}
@var{value} が @samp{yes} であれば、pserver は使用者を調べるときに、
@file{CVSROOT/passwd} に見つからなければ、システムのデータベースを調べ
にいきます。@samp{no} であれば、全ての使用者は @file{CVSROOT/passwd} 
に存在している必要があります。既定値は @samp{yes} です。pserver につい
ては、@ref{Password authenticated} を参照してください。

@cindex PreservePermissions, in CVSROOT/config
@item PreservePermissions=@var{value}
リポジトリでの、特別なデバイスファイル、シンボリック・リンク、ファイル
仕様許可、所有権に関する機能を使用可にします。既定値は @samp{no} です。
このキーワード使用の完全な意味は @xref{Special Files}.

@cindex TopLevelAdmin, in CVSROOT/config
@item TopLevelAdmin=@var{value}
@samp{checkout} コマンドが取り出されたディレクトリ中に作成される 
@samp{CVS} に加えて、新しい作業ディレクトリの最上位にも @samp{CVS} ディ
レクトリを作成するように修正します。既定値は @samp{no} です。

このオプションは、取り出されたサブディレクトリではなく、最上位のディレ
クトリで多くのコマンドを実行するときに便利です。そこに作成される
@samp{CVS} ディレクトリにより、それぞれのコマンドに @samp{CVSROOT} を
指定する必要がなくなります。@samp{CVS/Template} ファイルの場所も提供し
ます (@pxref{Working directory storage})。

@cindex LockDir, in CVSROOT/config
@item LockDir=@var{directory}
CVS ロックファイルをリポジトリ中のディレクトリでなく、@var{directory}
に置きます。これは使用者にリポジトリから読み込みをさせたいけれど、リポ
ジトリには書き込み許可を与えたくなく、@var{directory} ディレクトリのみ
に書き込み許可を与えたいときに便利です。@var{directory} は作成する必要
がありますが、必要ならば CVS は @var{directory} のサブディレクトリを作
成します。CVS のロックに関する情報は @ref{Concurrency} を参照してくだ
さい。

@c Mention this in Compatibility section?
LockDir オプションを使用可にする前に、CVS 1.9 やそれ以前のもののコピー
を追跡して消去したことを確認してください。そのようなバージョンは
LockDir をサポートしていませんし、それをサポートしていないというエラー
を出すこともありません。結果として、もしこのようなことが起こってしまえ
ば、CVS の何人かの使用者はある場所にロックを置き、他は別の場所に置くと
いうことになり、リポジトリが壊れてしまう可能性があります。CVS 1.10 は
LockDir をサポートしていませんが、LockDir が使用されているリポジトリで
実行されると警告を印字します。
@end table

@c ---------------------------------------------------------------------
@node Environment variables
@appendix CVS に影響する全ての環境変数
@cindex Environment variables
@cindex Reference manual for variables

これは、@sc{cvs} に影響する全ての環境変数の
完全なリストです。

@table @code
@cindex CVSIGNORE, environment variable
@item $CVSIGNORE
@sc{cvs} が無視するファイル名を、
空白で区切ったリストです。@xref{cvsignore}.

@cindex CVSWRAPPERS, environment variable
@item $CVSWRAPPERS
@sc{cvs} が wrapper として扱うファイル名形式を
空白で区切ったリストです。@xref{Wrappers}.

@cindex CVSREAD, environment variable
@cindex read-only files, and CVSREAD
@item $CVSREAD
この変数が設定されていると、
@code{checkout} と @code{update} により作成される作業コピーが、
強制的に読み込み専用となります。
設定しなければ、作業ファイルの修正許可が与えられます。

@item $CVSUMASK
リポジトリのファイルの使用許可を制御します。@ref{File permissions} を
参照してください。

@item $CVSROOT
(@sc{rcs} のファイルが置かれる) 
@sc{cvs} のリポジトリのルート・ディレクトリを、
絶対パスで指定しなければいけません。
@sc{cvs} の大部分のコマンドを実行するときに、
この情報が利用されます。
@code{$CVSROOT} が設定されていない場合や、
他のものを優先させたい場合には、
コマンド行で @samp{cvs -d cvsroot cvs_command@dots{}} 
としてリポジトリを指定することができます。
一旦作業ディレクトリを取り出した後は、
@sc{cvs} が適切なリポジトリを (@file{CVS/Root} に) 記録します。
従って、最初に作業ディレクトリを取り出す時を除いて、
通常はこの値に注意する必要はありません。

@item $EDITOR
@itemx $CVSEDITOR
@itemx $VISUAL
格納時のログ・メッセージを記録する際に、使用するプログラムを指定します。
@code{$CVSEDITOR} は @code{$EDITOR} よりも優先されます。
@ref{Committing your changes} を参照してください。

@cindex PATH, environment variable
@item $PATH
@code{$RCSBIN} が設定されておらず、
@sc{cvs} にパス名が埋め込まれていない場合、
使用する全てのプログラムを捜す時に @code{$PATH} が使用されます。

@cindex HOME, environment variable
@item $HOME
@cindex HOMEPATH, environment variable
@item $HOMEPATH
@cindex HOMEDRIVE, environment variable
@item $HOMEDRIVE
これを使用して、@file{.cvsrc} やそのような他のファイルが置かれたディレ
クトリを捜します。Unix では、CVS は HOME だけを調べます。Windows NT で
は、システムは HOMEDRIVE を例えば @samp{d:} に、HOMEPATH を例えば 
@file{\joe} に設定します。Windows 95 ではおそらく自分自身で HOMEDRIVE
と HOMEPATH を設定する必要があるでしょう。
@c We are being vague about whether HOME works on
@c Windows; see long comment in windows-NT/filesubr.c.

@cindex CVS_RSH, environment variable
@item $CVS_RSH
接続経路に @code{:ext:} が指定された時、
@sc{cvs} が接続に使用する外部プログラムを
指定します。@pxref{Connecting via rsh}。

@item $CVS_SERVER
@sc{rsh} を用いたクライアント/サーバ・モードで、
別のマシンのリポジトリを利用する時に使用されます。
@sc{rsh} を用いて別のマシンのリポジトリを利用する時に、
サーバ側で起動するプログラムの名前を指定します。
既定値は @code{cvs} です。@pxref{Connecting via rsh}。

@item $CVS_PASSFILE
クライアント/サーバ・モードで、
@samp{cvs login @var{server}} が実行された時に使用されます。
既定値は @file{$HOME/.cvspass} です。
@pxref{Password authentication client}。

@item $CVS_CLIENT_PORT
ケルベロスを用いたクライアント/サーバ・モードで
使用されます。@pxref{Kerberos authenticated}。

@cindex CVS_RCMD_PORT, environment variable
@item $CVS_RCMD_PORT
クライアント/サーバ・モードで使用されます。
これを設定した場合、サーバの @sc{rcmd} デーモンを利用する時に、
ここで指定したポート番号が使用されます。
(現在 @sc{unix} クライアントでは使用されません)。

@cindex CVS_CLIENT_LOG, environment variable
@item $CVS_CLIENT_LOG
クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
これを設定した場合、
サーバに送られた全てが @file{@code{$CVS_CLIENT_LOG}.in} に記録され、
サーバから送られた全てが @file{@code{$CVS_CLIENT_LOG}.out} に
記録されます。

@cindex CVS_SERVER_SLEEP, environment variable
@item $CVS_SERVER_SLEEP
クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
これを設定して、子プロセスを起動する前に指定した秒数を待ち、
デバッガを応答させます。

@cindex CVS_IGNORE_REMOTE_ROOT, environment variable
@item $CVS_IGNORE_REMOTE_ROOT
@sc{cvs} 1.10 以前では、この変数を設定すると、@samp{-d} 広域オプション
が指定されているときに @file{CVS/Root} を上書きするのを抑制することが
できました。後のバージョンの @sc{cvs} は @file{CVS/Root} を再書き込み
しませんので、CVS_IGNORE_REMOTE_ROOT は効果はありません。

@cindex COMSPEC, environment variable
@item $COMSPEC
OS/2 だけで使用されます。コマンド解釈プログラムを指定します。
既定値は @sc{cmd.exe} です。

@cindex TMPDIR, environment variable
@item $TMPDIR
@cindex TMP, environment variable
@itemx $TMP
@cindex TEMP, environment variable
@itemx $TEMP
@cindex temporary files, location of
@c This is quite nuts.  We don't talk about tempnam
@c or mkstemp which we sometimes use.  The discussion
@c of "Global options" is semi-incoherent.
@c I'm not even sure those are the only inaccuracies.
@c Furthermore, the conventions are
@c pretty crazy and they should be simplified.
一時ファイルが置かれるディレクトリを指定します。
@sc{cvs} サーバは @code{TMPDIR} を使用します。
この指定方法は、@ref{Global options} 参照。
@sc{cvs} には、(システムが提供する @code{_tmpnam} 関数経由で) 
常に @file{/tmp} を使用する部分があります。

Windows NT では (システムが提供する @code{_tempnam} 関数経由で)、
@code{TMP} が使用されます。

@sc{cvs} のクライアントが用いる @code{patch} プログラムは、
@code{TMPDIR} を使用します。
設定されていない場合、(少なくとも GNU patch 2.1 は) 
@file{/tmp} を使用します。
サーバとクライアントの両方共が @sc{cvs} 1.9.10 以降を実行しているなら、
@sc{cvs} は外部の @code{patch} プログラムを呼び出しません。
@end table

@node Compatibility
@appendix CVS のバージョン間の互換性

@cindex CVS, versions of
@cindex versions, of CVS
@cindex compatibility, between CVS versions
@c We don't mention versions older than CVS 1.3
@c on the theory that it would clutter it up for the vast
@c majority of people, who don't have anything that old.
@c
リポジトリの形式は @sc{cvs} 1.3 から互換です。@sc{cvs} 1.6 以前を使っ
ていて、オプションの開発者間通信機能を使いたいときは、@ref{Watches
Compatibility} を参照してください。
@c If you "cvs rm" and commit using 1.3, then you'll
@c want to run "rcs -sdead <file,v>" on each of the
@c files in the Attic if you then want 1.5 and
@c later to recognize those files as dead (I think the
@c symptom if this is not done is that files reappear
@c in joins).  (Wait: the above will work but really to
@c be strictly correct we should suggest checking
@c in a new revision rather than just changing the
@c state of the head revision, shouldn't we?).
@c The old convert.sh script was for this, but it never
@c did get updated to reflect use of the RCS "dead"
@c state.
@c Note: this is tricky to document without confusing
@c people--need to carefully say what CVS version we
@c are talking about and keep in mind the distinction
@c between a
@c repository created with 1.3 and on which one now
@c uses 1.5+, and a repository on which one wants to
@c use both versions side by side (e.g. during a
@c transition period).
@c Wait, can't CVS just detect the case in which a file
@c is in the Attic but the head revision is not dead?
@c Not sure whether this should produce a warning or
@c something, and probably needs further thought, but
@c it would appear that the situation can be detected.
@c
@c We might want to separate out the 1.3 compatibility
@c section (for repository & working directory) from the
@c rest--that might help avoid confusing people who
@c are upgrading (for example) from 1.6 to 1.8.
@c
@c A minor incompatibility is if a current version of CVS
@c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
@c see this as if there is no tag.  Seems to me this is
@c too obscure to mention.

作業ディレクトリ形式は @sc{cvs} 1.5 から互換です。@sc{cvs} 1.3 と 
@sc{cvs} 1.5 の間で変更されました。@sc{cvs} 1.3 で取り出されたディレク
トリで @sc{cvs} 1.5 か、それより新しいものを実行すると、@sc{cvs} はそ
れを変換しますが、@sc{cvs} 1.3 に戻るためには、新しい作業ディレクトリ
を @sc{cvs} 1.3 で取り出す必要があります。

遠隔プロトコルは @sc{cvs} 1.5 から相互作用可能ですが、それ以前では無理
です (1.5 が遠隔プロトコルのある最初の公的リリースですが、古いバージョ
ンがまだあたりをうろついているかもしれません)。しかし、多くの場合、新
しい機能とバグ修正の利点を得るためにクライアントとサーバの両方を更新す
る必要があります。

@c Perhaps should be saying something here about the
@c "D" lines in Entries (written by CVS 1.9; 1.8 and
@c older don't use them).  These are supposed to be
@c compatible in both directions, but I'm not sure
@c they quite are 100%.  One common gripe is if you
@c "rm -r" a directory and 1.9 gets confused, as it
@c still sees it in Entries.  That one is fixed in
@c (say) 1.9.6.  Someone else reported problems with
@c starting with a directory which was checked out with
@c an old version, and then using a new version, and
@c some "D" lines appeared, but not for every
@c directory, causing some directories to be skipped.
@c They weren't sure how to reproduce this, though.

@c ---------------------------------------------------------------------
@node Troubleshooting
@appendix 問題の解決

@sc{cvs} の使用に問題があれば、この付録が役立つかもしれません。特定の
エラーメッセージが出ているなら、そのメッセージをアルファベット順に探す
ことができます。そうでない場合は、他の問題の章を眺めて説明されているか
どうかを知ることができます。

@menu
* Error messages::              CVS のエラーの部分的一覧
* Connection::                  CVS サーバへの接続での問題
* Other problems::              エラーメッセージで既に挙げられていない問題
@end menu

@ignore
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@c @node Bad administrative files
@appendixsec Bad administrative files

@c -- Give hints on how to fix them
@end ignore

@node Error messages
@appendixsec エラーメッセージの部分的一覧

これは @sc{cvs} で起こるかもしれないエラー・メッセージの部分的な一覧で
す。完全な一覧ではありません---@sc{cvs} はたくさん、たくさんのエラー・
メッセージを印字する能力があり、しばしば一部分はオペレーティング・シス
テムにより提供されます。しかし、ここでの意図はよくあるもの、混乱する可
能性のあるエラー・メッセージの、両方もしくはどちらかにあてはまるものの
一覧を挙げることです。

メッセージはアルファベット順ですが、@samp{cvs update: } のような前置き
の文章は順番にするときには省かれています。

この一覧は古いバージョンの @sc{cvs} で印字されるメッセージがある場合も
あります (使用者は特定の時にどのバージョンの @sc{cvs} を使用しているか
を必ずしも知らないというのが理由の一つです)。
@c If we want to start retiring messages, perhaps we
@c should pick a cutoff version (for example, no more
@c messages which are specific to versions before 1.9)
@c and then move the old messages to an "old messages"
@c node rather than deleting them completely.

@table @code
@c FIXME: What is the correct way to format a multiline
@c error message here?  Maybe @table is the wrong
@c choice?  Texinfo gurus?
@item cvs @var{command}: authorization failed: server @var{host} rejected access
これは pserver のサーバに接続しようとして、それが特定の理由を教えるこ
となく認証を拒否することを選んだときの一般的な反応です。指定された使用
者名とパスワードが正しいことと、指定された CVSROOT が inetd.conf の 
--allow-root で使用可になっているこを確認してください。

@item @var{file}:@var{line}: Assertion '@var{text}' failed
システムによってこのメッセージの正確な形式は異なります。これは 
@sc{cvs} のバグを示し、@ref{BUGS} で説明されているように扱うことができ
ます。

@item cvs @var{command}: conflict: removed @var{file} was modified by second party
このメッセージは、あなたがファイルを消去し、誰か別の人がそれを修正した
ということを示します。衝突を解消するために、まず @samp{cvs add
@var{file}} を実行します。それが望まれていれば、他の人々の修正を見てま
だそれを消したいかどうかを決定します。消したくなければ、ここで止めます。
消去したければ、 @samp{cvs remove @var{file}} を実行して、削除を格納し
ます。
@c Tests conflicts2-142b* in sanity.sh test for this.

@item cannot change permissions on temporary directory
@example
Operation not permitted
@end example
このメッセージは、Red Hat Linux 3.0.3 と 4.1 でクライアント/サーバのテ
スト一式を実行しているときいに、再現不可能な方法でときどき発生しました。
我々は何がそれを起こしたのか、また linux (もしくは、このマシンそのもの!) 
に特有かどうかも分かりません。他の unix でも問題が発生した場合は、おそ
らく @samp{Operation not permitted} は @samp{Not owner} や当のシステム
が unix の @code{EPERM} エラーで使用している他のものになっているでしょ
う。追加の情報があれば、@ref{BUGS} で説明されているように我々に知らせ
てください。もし @sc{cvs} を使用していてこのエラーを経験したときは、そ
れを発生させた操作をもう一度繰り返すとちゃんと動作するでしょう。

@item cvs [server aborted]: Cannot check out files into the repository itself
このメッセージの明らかな原因は (特にクライアント/サーバでない @sc{cvs} 
のときは)、@sc{cvs} のルートが例えば @file{/usr/local/cvsroot} で、
@file{/usr/local/cvsroot/test} のようなサブディレクトリにファイルを取
り出そうとしたことです。しかしながら、サーバの一時ディレクトリがルート
のサブディレクトリに設定されている (これも許可されていません) というよ
り微妙な場合もあります。これが問題の原因であるなら、一時ディレクトリを
別のところに設定してください。例えば、@file{/var/tmp} に。一時ディレク
トリの設定のしかたは、@ref{Environment variables} の @code{TMPDIR} を
参照してください。

@c This has been seen in a variety of tests, including
@c multibranch-2, multibranch-5, and basic1-24-rm-rm,
@c so it doesn't seem particularly specific to any one
@c test.

@c For one example see basica-1a10 in the testsuite
@c For another example, "cvs co ." on NT; see comment
@c at windows-NT/filesubr.c (expand_wild).
@c For another example, "cvs co foo/bar" where foo exists.
@item cannot open CVS/Entries for reading: No such file or directory
これは一般的に @sc{cvs} の内部エラーを示し、他の @sc{cvs} のバグと同様
に扱うことがきます (@pxref{BUGS})。たいていの場合、対策があります---正
確な方法は状況に依りますが、おそらく見付け出すことができるでしょう。

@c This is more obscure than it might sound; it only
@c happens if you run "cvs init" from a directory which
@c contains a CVS/Root file at the start.
@item cvs [init aborted]: cannot open CVS/Root: No such file or directory
このメッセージは無害です。もし他のエラーと一緒にでなければ、操作は成功
しています。現在のバージョンの @sc{cvs} では出ないはずですが、@sc{cvs}
1.9 以前のために説明されています。

@item cvs [checkout aborted]: cannot rename file @var{file} to CVS/,,@var{file}: Invalid argument
このメッセージは Solaris 2.5 上での CVS 1.9 でときどき発生することが報
告されています。原因は不明です。原因についてさらに知っていれば、
@ref{BUGS} で説明されているように我々に知らせてください。

@item cvs [@var{command} aborted]: cannot start server via rcmd
この残念ながらあまり詳しくないメッセージは、@sc{cvs} のクライアントを
実行していてサーバとの接続に問題があったときに @sc{cvs} 1.9 が印字しま
す。現在のバージョンの @sc{cvs} はもっと詳しいエラーメッセージを印字す
るようになっています。クライアントを実行しようとはしていないのにこのメッ
セージが出たときは、おそらく @ref{Repository} で説明されている方法で 
@code{:local:} を指定することを忘れたのでしょう。

@item ci: @var{file},v: bad diff output line: Binary files - and /tmp/T2a22651 differ
CVS 1.9 以前は @sc{rcs} が正しくインストールされていないときにバイナリ
ファイルを格納しようとしたときにこのメッセージを印字します。@sc{rcs} 
の配布とともに取得している指示をもう一度読んで、@sc{cvs} 配布の 
@sc{install} ファイルを読んでください。代替法として、@sc{rcs} を経由し
ないで自分自身でファイルを格納する現在のバージョンの @sc{cvs} に変更す
ることもできます。

@item cvs checkout: could not check out @var{file}
CVS 1.9 では、これは @code{co} プログラム (@sc{rcs} プログラムの一部で
す) が失敗の値を返したということです。他のエラーメッセージがその前にあ
るはずですが、別のエラーメッセージなしに発生することも確認されており、
原因はよくわかっていません。現在のバージョンの CVS は @code{co} を実行
しないので、このメッセージが別のエラーメッセージとともに現れなければ、
それは間違いなく CVS のバグです (@pxref{BUGS})。
@c My current suspicion is that the RCS in the rcs (not
@c cvs/winnt/rcs57nt.zip) directory on the _Practical_
@c CD is bad (remains to be confirmed).
@c There is also a report of something which looks
@c very similar on SGI, Irix 5.2, so I dunno.

@item cvs [update aborted]: unexpected EOF reading @var{file},v
@samp{EOF in key in RCS file} を参照。

@item cvs [login aborted]: could not find out home directory
これはホームデレクトリの位置を特定するために CVS が使用する環境変数を
設定する必要があるということです。@ref{Environment variables} の HOME,
HOMEDRIVE, HOMEPATH の議論を参照してください。

@item cvs update: could not merge revision @var{rev} of @var{file}: No such file or directory
CVS 1.9 以前は @code{rcsmerge} プログラムを見つけるときに問題が発生し
たときにこのメッセージを印字します。それが @code{PATH} にあることを確
認するか、外部 @code{rcsmerge} プログラムを必要としない現在のバージョ
ンの CVS に更新してください。

@item cvs [update aborted]: could not patch @var{file}: No such file or directory
これは @code{patch} プログラムの探索に問題があったということです。それ
が @code{PATH} 上にあるとを確認してください。メッセージの外観とは違っ
て、@var{file} を見つけるかどうかについて言っているのでは@emph{ない}こ
とに注意してください。クライアントとサーバが現在のバージョンの 
@sc{cvs} を実行しているなら、外部 patch プログラムは必要ではなく、この
メッセージを見ることはないでしょう。しかし、クライアントかサーバが 
@sc{cvs} 1.9 を実行していれば、@code{patch} が必要です。

@item cvs update: could not patch @var{file}; will refetch
これは、何らかの理由により、クライアントはサーバが送った patch を適用
できなかったということです。メッセージは心配するようなものではありませ
ん。これは、patch の適用ができなかったというのはちょっと作業を遅らせる
だけで、@sc{cvs} が実行することには影響しないからです。
@c xref to update output.  Or File status?
@c Or some place else that
@c explains this whole "patch"/P/Needs Patch thing?

@item dying gasps from @var{server} unexpected
@sc{cvs} 1.9.18 以前のサーバにはこれを発生する既知のバグがあります。私
は、@samp{-t} 広域オプションを使用しているときに再現可能です。もし興味
があれば、それは Andy Piper の1997年11月4日の src/filesubr.c への変更
で修正されました。このメッセージが出たときは、おそらく失敗した操作をた
だもう一度試すことができます。また、この原因に関して情報を発見したなら、
@ref{BUGS} に書かれているように我々に知らせてください。

@item end of file from server (consult above messages if any)
このメッセージの一番多い原因は、外部 @code{rsh} プログラムを使用してい
て、それがエラーを出して終了するというものです。この場合 @code{rsh}
プログラムは、上のメッセージの前にメッセージを印字しているはずです。
@sc{cvs} のクライアントとサーバの設定の情報は @ref{Remote
repositories} を参照してください。

@cindex mkmodules
@item cvs commit: Executing 'mkmodules'
これはリポジトリが @sc{cvs} 1.8 より前のバージョンの @sc{cvs} で設定さ
れているということです。@sc{cvs} 1.8 以降を使っていると、上記のメッセー
ジの前に以下のものがでます。

@example
cvs commit: Rebuilding administrative file database
@end example

両方のメッセージが表示されれば、データベースは2回再構築されていて、こ
れは不必要ですが、無害です。重複を避けたくて、@sc{cvs} 1.7 以前を使っ
ていないなら、@code{modules} ファイルにある全ての @code{-i mkmodules}
を消してください。@code{modules} ファイルの情報は @ref{modules} を参照
してください。

@c This messsage comes from "co", and I believe is
@c possible only with older versions of CVS which call
@c co.  The problem with being able to create the bogus
@c RCS file still exists, though (and I think maybe
@c there is a different symptom(s) now).
@c FIXME: Would be nice to have a more exact wording
@c for this message.
@item missing author
普通これは使用者名が空の RCS ファイルを作成したときに発生します。CVS
は、間違って author 部分に値のない不正な RCS ファイルを作成します。解
決策は、使用者名が空でないことを確認して、RCS フィルを再作成することで
す。
@c "make sure your username is set" is complicated in
@c and of itself, as there are the environment
@c variables the system login name, &c, and it depends
@c on the version of CVS.

@item *PANIC* administration files missing
これは普通は CVS という名前のディレクトリがあるけれど、CVS が CVS ディ
レクトリに置く管理ファイルがないということです。もし問題が CVS 以外の
何らかの機構で CVS ディレクトリを作ったというものであれば、CVS 以外の
名前を使ってください。もしそうでなければ、それは CVS のバグを示してい
ます (@pxref{BUGS})。

@item rcs error: Unknown option: -x,v/
このメッセージの後には @sc{rcs} の使用法のメッセージが続きます。それは
古いバージョンの @sc{rcs} (おそらくオペレーティングシステムと共に提供
されたものでしょう) があるということです。CVS は @sc{rcs} バージョン 5
以降でのみ動作します。
@c For more information on installing @sc{cvs}, see
@c (FIXME: where?  it depends on whether you are
@c getting binaries or sources or what).
@c The message can also say "ci error" or something
@c instead of "rcs error", I suspect.

@item cvs [server aborted]: received broken pipe signal
これは、@sc{cvs} かそれが実行されているシステムの追跡が困難なバグ (良
く判っていません---我々はまだ追いかけていません!) により発生するようで
す。@sc{cvs} コマンドが完了した後でのみ発生するようで、メッセージは無
視できます。しかしながら、その原因に関する情報を発見したなら、
@ref{BUGS} で説明されているように我々に知らせてください。

@item Too many arguments!
このメッセージは普通は @sc{cvs} のソース配布の @file{contrib} ディレク
トリにある @file{log.pl} スクリプトにより印字されます。@sc{cvs} のバー
ジョンには、@file{log.pl} が既定の @sc{cvs} インストールに含まれている
ものもあります。@file{log.pl} スクリプトは @file{loginfo} 管理ファイル
から呼ばれます。@file{loginfo} で渡されている引数があなたのバージョン
の @file{log.pl} が期待するものとあっているか調べてください。特に、
@sc{cvs} 1.3 以前の @file{log.pl} はログファイルを引数として期待します
が、@sc{cvs} 1.5 以降の @file{log.pl} はログファイルは @samp{-f} オプ
ションで指定されることを期待します。もちろん、@file{log.pl} が必要でな
ければ、@file{loginfo} 中で註釈にして、使用しないようにすることができ
ます。

@item cvs [login aborted]: unrecognized auth response from @var{server}
このメッセージは普通はサーバが適切に設定されていないことを意味します。
例えば、@file{inetd.conf} が存在しない cvs 実行ファイルを指していると
きです。これをデバッグするためには、inetd が書くログファイル
(@file{/var/log/messages} やあなたのシステムの inetd が使うその他のも
の) を見つけてください。詳細は @ref{Connection} と @ref{Password
authentication server} 参照。

@item cvs commit: Up-to-date check failed for `@var{file}'
これはあなたが最後に @code{cvs update} を実行した後に誰かが変更を格納
したということです。ですから、@code{cvs commit} を継続する前に 
@code{cvs update} をする必要があります。CVS はあなたのした変更と他の人
がした変更をマージします。衝突が発見されなれば、@samp{M cacErrCodes.h} 
のように報告され、@code{cvs commit} を実行する準備が整っています。もし
衝突が発見されれば、その由を印字し、@samp{C cacErrCodes.h} と報告され、
手で衝突を解消する必要があります。この過程の詳細は @ref{Conflicts
example} を参照してください。

@item Usage:	diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
@example
Only one of [exEX3] allowed
@end example
これは @code{diff3} と @code{rcsmerge} のインストールに問題があること
を示しています。特に @code{rcsmerge} は GNU diff3 を探すようにコンパイ
ルされているけれど、代わりに unix の diff3 が使われています。一番簡単
な解決法は外部の @code{rcsmerge} や @code{diff3} プログラムに頼らない
現在のバージョンの @sc{cvs} に更新することです。

@item warning: unrecognized response `@var{text}' from cvs server
もし @var{text} が有効な応答 (@samp{ok} のようなもの) で、続きに余分な
キャリッジリターンがあると (多くのシステムではこれはメッセージの2番目
の部分が1番目の部分を上書きします)、おそらく、既定では透過的なデータス
トリームを提供しない、多くの unix でない rsh のバージョンで 
@samp{:ext:} 接続方法を使用としているのでしょう。その様な場合はたぶん 
@samp{:ext:} の代わりに @samp{:server:} を試みるのが良いでしょう。
@var{text} が何か他のものなら、CVS サーバに問題があることを表します。
CVS サーバを設定するための指示を見てインストールを再度確認してください。

@item cvs commit: [@var{time}] waiting for @var{user}'s lock in @var{directory}
これは普通のメッセージであり、エラーではありません。詳細は
@ref{Concurrency} 参照。

@item cvs commit: warning: editor session failed
@cindex exit status, of editor
これは @sc{cvs} が使用しているエディタが非零の値で終了したということで
す。vi のバージョンにはファイルの編集に問題がなかったときでさえそうす
るものがあります。もしそうなら、環境変数 @sc{CVSEDITOR} を以下のような
小さなスクリプトを指すようにしてください:

@example
#!/bin/sh
vi $*
exit 0
@end example

@c "warning: foo was lost" and "no longer pertinent" (both normal).
@c Would be nice to write these up--they are
@c potentially confusing for the new user.
@end table

@node Connection
@appendixsec CVS サーバに接続をしようとするときの問題

この章は @sc{cvs} サーバに接続しようとしたときに問題が起こったときに何
をすれば良いかということを書いています。 Windows で @sc{cvs} コマンド
ライン・クライアントを実行しているなら、まず @sc{cvs} 1.9.12 以降に更
新してください。以前のバージョンのエラー報告は、問題がどうであったかに
ついて、ほとんど情報を提供しません。クライアントが Windows でなければ、
@sc{cvs} 1.9 は問題ありません。

問題を追いかけるためにエラー・メッセージが十分でなければ、次の手段は使
用している接続方法によってかなり異なります。

@table @code
@cindex :ext:, troubleshooting
@item :ext:
コマンド行からの rsh プログラムの実行を試してください。例えば: "rsh
servername cvs -v" は @sc{cvs} のバージョン情報を印字します。もしこれ
が動作しなければ、@sc{cvs} の問題を気にする前にそれを修正する必要があ
ります。

@cindex :server:, troubleshooting
@item :server:
この接続方法を使用するためにコマンド行の rsh プログラムは必要ではあり
ませんが、rsh プログラムがあれば、デバッグ道具として役に立つでしょう。:
ext: のところの指示に従ってください。

@cindex :pserver:, troubleshooting
@item :pserver:
良いデバッグ道具は "telnet servername 2401" です。接続後、任意のテキス
ト (例えば、"foo" リターン)。@sc{cvs} が正しく動作していれば、以下のよ
うに反応するはずです。

@example
cvs [pserver aborted]: bad auth protocol start: foo
@end example

これの動作に失敗すれば、inetd が正しく動作しているか確認してください。
inetd.conf での起動を cvs の代わりに echo プログラムに変更してください。
例えば:

@example
2401  stream  tcp  nowait  root /bin/echo echo hello
@end example

その変更をして、inetd に設定ファイルを再読み込みするように指示した後で
は、"telnet servername 2401" はテキスト hello を表示して、サーバが接続
を切るはずです。これが動作しなければ、@sc{cvs} の問題を気にする前にそ
れを修正してください。

AIX システムでは、システムにポート 2401 を使おうとするプログラムがあり
ます。これは、ポート 2401 は @sc{cvs} での使用に登録されているという点
で AIX の問題です。この問題を解決するために AIX のパッチがあるというこ
とを聞いたことがあります。

他の良いデバッグツールは inetd に @samp{-d} (debugging) オプションを付
けることです。詳しい情報はシステムの説明文書を調べてください。
@end table

@node Other problems
@appendixsec 他のよくある問題

これは上の分類には合わない問題の一覧です。順番には特に意味はありません。

@itemize @bullet
@item
Windows で、@sc{cvs} コマンドを実行したときに30秒くらいの遅れがあると
きは、ホームディレクトリが例えば @file{C:/} に設定されているということ
かもしれません (@ref{Environment variables}の @code{HOMEDRIVE} と
@code{HOMEPATH} 参照)。 CVS はホームディレクトリがスラッシュで終わらな
いことを期待しています。例えば、@file{C:} や @file{C:\cvcs} です。
@c FIXCVS: CVS should at least detect this and print an
@c error, presumably.

@item
@sc{cvs} 1.9.18 以前を実行していて、@ref{Conflicts example} で説明され
ているように、@code{cvs update} が衝突を発見し、マージを試みたけれど、
衝突があることを報告しなかったら、@sc{rcs} の古いバージョンが存在しま
す。一番簡単な解決は、おそらく外部 @sc{rcs} プログラムを使用しない現在
のバージョンの @sc{cvs} に変更することです。
@end itemize

@c ---------------------------------------------------------------------
@node Credits
@appendix Credits

@cindex Contributors (manual)
@cindex Credits (manual)
当時 Cygnus Support にいた Roland Pesch <@t{roland@@wrs.com}> 
は @sc{cvs} 1.3 とともに頒布されたマニュアルを書きました。
記述の多くは、彼の文章から受け継いでいます。
また彼にこのマニュアルの初期の草稿を読んでもらい、
多くのアイディアと訂正を頂きました。

メーリング・リスト @code{info-cvs} も時には有益でした。
私は以下の人物が行なった投稿による情報を含めました:
David G. Grubbs <@t{dgg@@think.com}>.

@sc{rcs} の man からいくつか文章を引用しています。

David G. Grubbs 氏による @sc{cvs} @sc{faq} は、
有用な素地を与えてくれました。
@sc{faq} はもうメンテナンスされていませんが、
このマニュアルが (少くとも @sc{cvs} の使用方法の文書化に関して)、
その後継に最も近いものでしょう。

また、次に挙げる人物が、私の誤りを訂正してくれました:

@display
Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
Karl Pingle <@t{pingle@@acuson.com}>,
Thomas A Peterson <@t{tap@@src.honeywell.com}>,
Inge Wallin <@t{ingwa@@signum.se}>,
Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>,
Michael Brown <@t{brown@@wi.extrel.com}>.
@end display

ここの貢献者の一覧は包括的なものであはありません。このマニュアルへの貢
献者のより完全な一覧は @sc{cvs} のソース配布のファイル 
@file{doc/ChangeLog} を見てください。

@c ---------------------------------------------------------------------
@node BUGS
@appendix CVS かこのマニュアルのバグに対処する

@cindex Bugs in this manual or CVS
@sc{cvs} もこのマニュアルも完璧ではなく、また永遠にそうならないでしょ
う。@sc{cvs} を使用していて問題にぶつかったり、バグを見つけたと思った
りしたときは、いろいろな方法があります。また、マニュアルにはっきりしな
いところがあれば、マニュアルのバグと考えられますので、これらの問題も 
@sc{cvs} 自身の問題と同様に行動をするに値します。

@cindex Reporting bugs
@cindex Bugs, reporting
@cindex Errors, reporting
@itemize @bullet
@item
報告したバグを誰かに修正して欲しい場合は、代金と交換にしてくれる会社が
あります。そのような会社は2つあります:

@cindex Signum Support
@cindex Cyclic Software
@cindex Support, getting CVS support
@example
Signum Support AB
Box 2044
S-580 02  Linkoping
Sweden
Email: info@@signum.se
Phone: +46 (0)13 - 21 46 00
Fax:   +46 (0)13 - 21 47 00
http://www.signum.se/

Cyclic Software
United States of America
http://www.cyclic.com/
info@@cyclic.com
@end example

@item
@sc{cvs} をオペレーティング・システムのベンダーやフリーウェアの 
@sc{cd-rom} のベンダーのような配布者から取得していれば、配布者がサポー
トを提供しているかどうかを知りたいでしょう。しばしば、サポートしなかっ
たり、最小限のサポートしか提供しないかもしれませんが、それは配布者によっ
て異なります。

@item
もし十分な技能と時間があれば、バグを自分自身で修正しようと思うでしょう。
その修正を将来の @sc{cvs} のリリース含めたいときは、@sc{cvs} のソース
配布にあるファイル @sc{hacking} を見てください。修正の提出方法に関する
たくさんの情報があります。

@item
ネット上に助けになるリソースがあるかもしれません。以下の2つは開始する
良い場所です:

@example
http://www.cyclic.com
http://www.loria.fr/~molli/cvs-index.html
@end example

もし非常にやる気になれば、ネット上での情報を増やすと感謝される可能性が
高いでしょう。例えば、標準の @sc{cvs} 配布が Windows 95 について作業を
する前に、@sc{cvs} を Windows 95 で実行するための説明とパッチのあるウェ
ブページがあり、色々な人がその題がメーリングリストやニュースグループで
出る度にそのページを知らせることで手助けをしていました。

訳註: 日本語のウェブページは以下のものが良いでしょう。

@example
http://www.cyclic.com/cvs/lang-jp.html
http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
@end example

@item
バグを @code{bug-cvs} に報告することもできます。誰かがあなたのバグ報告
に対して何かをしようと思うかもしれないし、思わないかもしれない、という
ことに注意してください---もし解決策が必要なら、上の方法のどれかを考慮
してください。ですが、おそらく人々は特に大変な結果になるバグと、簡単に
修正できるバグの両方、もしくはどちらかに該当するもに関心があるでしょう。
また、バグの本質と他の関係する情報を明確にすることで可能性を高めるこが
できます。バグを報告するためには @code{bug-cvs@@gnu.org} に email を送
ります。@code{bug-cvs} へ送ったものは @sc{gnu} Public License の条件の
下で配布されるかもしれないことに注意してください。もしこれを好まなけれ
ば、送らないでください。普通は、メールを @code{bug-cvs} ではなく、
@sc{cvs} の管理者に直接送ることの正当性はありません。そのようなバグ報
告に関心のある管理者は @code{bug-cvs} を読んできます。また、バグ報告を
他のメーリングリストやニュースグループに送ることは @code{bug-cvs} へ送
る代わりには@emph{ならない}ということにも注意してださい。@sc{cvs} のバ
グをどの場所でも好きなところで議論するのは良いことですが、
@code{bug-cvs} 以外に送られたバグ報告を管理者の誰かが読んでいるとは限
りません。
@end itemize

@cindex Known bugs in this manual or CVS
結構頻繁に、既知のバグの一覧や特定のバグが知られたものかどうかの一覧が
あるかどうかを尋ねられます。@sc{cvs} のソース配布の @sc{bugs} ファイル
は既知のバグのリストの一つですが、必ずしも包括的なものであろうとはして
いません。おそらく、既知のバグの包括的な、詳細な一覧は存在することはな
いでしょう。

@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Translation
@appendix 日本語訳について

この @sc{cvs} のマニュアルは、
@sc{cvs} @value{CVSVN} に付属していた、
@file{cvs.texinfo} を日本語訳したものです。
文書の構造やノード名等は(この節を除いて)そのまま使用しており、
文章は自分に可能な限り忠実に訳しています。
修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。

@flushright
廣保 誠 <@t{hiroyasu@@iedc.mke.mei.co.jp}>
@end flushright

@unnumberedsubsec 訳者からの謝辞

大阪大学の西田圭介さんが、引地夫妻に問い合わせてこの文書の
配布条件の推奨訳を入手したり、一部の下訳を送ってくれたりしました。
また @sc{cvs} について日本語で情報交換するためのメーリング・
リストを立ち上げました。現在このメーリング・リストは
京都工芸繊維大学の西本卓也さんが引き継いでいます。
詳細は @file{http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html} 
を参照して下さい。@sc{cvs} 1.9 から @sc{cvs} @value{CVSVN} への更新は
林芳樹 <g740685@@komaba.ecc.u-tokyo.ac.jp> が行いました。

@unnumberedsubsec 日本語訳の配布条件

この文書を修正・再配布する場合には、
原英文の配布条件に従って下さい。
以下に許諾文の参考訳を付けます。

Copyright @copyright{} 1992, 1993 Signum Support AB
Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.

上記の著作権表示と本許可告知が
すべての写しに前もって載せられている場合にのみ、
本マニュアルをそのまま複写し配布することを許可します。

@ignore
TeX による処理結果に本複写許可告知と同一のものが載せられている場合にのみ、
本マニュアルのファイルを TeX により出力することを許可します。
(ただし、本段落は TeX の処理結果には表れませんので、
実際の出力物に本段落は削除されることを除きます。)

@end ignore
本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件の
もとに配布される場合にのみ許可します。

本マニュアルの外国語 (英語以外の言語) への翻訳版の複写と配布は、
上記の修正版の場合に準じますが、
本許可告知は Free Software Foundation の許可を得た
翻訳でなければなりません。

@c ---------------------------------------------------------------------
@node Index
@unnumbered Index
@cindex Index

@printindex cp

@summarycontents

@contents

@bye

Local Variables:
fill-column: 70
End:
