File:  [Local Repository] / gnujdoc / cvs-1.10.8 / cvs-ja.texinfo
Revision 1.2: download - view: text, annotated - select for diffs
Sat Jun 11 11:25:01 2005 UTC (15 years, 4 months ago) by futoshi
Branches: MAIN
CVS tags: HEAD
comment out @documentlanguage

    1: \input texinfo  @c -*-texinfo-*-
    2: @comment Documentation for CVS.
    3: @comment Copyright (C) 1992, 1993, 1999 Signum Support AB
    4: @comment Copyright (C) 1993 Free Software Foundation, Inc.
    5: @comment Copyright (C) 1995-1999 Makoto Hiroyasu
    6: @comment Copyright (C) 1999 Yoshiki Hayashi
    7: 
    8: @comment This file is not part of the CVS distribution.
    9: 
   10: @comment CVS is free software; you can redistribute it and/or modify
   11: @comment it under the terms of the GNU General Public License as published by
   12: @comment the Free Software Foundation; either version 2, or (at your option)
   13: @comment any later version.
   14: 
   15: @comment CVS is distributed in the hope that it will be useful,
   16: @comment but WITHOUT ANY WARRANTY; without even the implied warranty of
   17: @comment MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   18: @comment GNU General Public License for more details.
   19: 
   20: @c See ../README for A4 vs. US letter size.
   21: @c When we provided A4 postscript, and people tried to
   22: @c print it on US letter, the usual complaint was that the
   23: @c page numbers would get cut off.
   24: @c If one prints US letter on A4, reportedly there is
   25: @c some extra space at the top and/or bottom, and the side
   26: @c margins are a bit narrow, but no text is lost.
   27: @c
   28: @c See
   29: @c http://www.ft.uni-erlangen.de/~mskuhn/iso-paper.html
   30: @c for more on paper sizes.  Insuring that margins are
   31: @c big enough to print on either A4 or US letter does
   32: @c indeed seem to be the usual approach (RFC2346).
   33: 
   34: @c This document seems to get overfull hboxes with some
   35: @c frequency (probably because the tendency is to
   36: @c sanity-check it with "make info" and run TeX less
   37: @c often).  The big ugly boxes just seem to add insult
   38: @c to injury, and I'm not aware of them helping to fix
   39: @c the overfull hboxes at all.
   40: @finalout
   41: 
   42: @setfilename cvs-ja.info
   43: @include CVSvn.texi
   44: @settitle CVS---Concurrent Versions System (in Japanese)
   45: @setchapternewpage odd
   46: @iftex
   47: @c @documentlanguage ja
   48: @documentencoding EUC-JP
   49: @end iftex
   50: @c FIXJA
   51: 
   52: @c -- TODO list:
   53: @c -- Fix all lines that match "^@c -- "
   54: @c -- Also places marked with FIXME should be manual
   55: @c problems (as opposed to FIXCVS for CVS problems).
   56: 
   57: @ifinfo
   58: @format
   59: START-INFO-DIR-ENTRY
   60: * CVS-JA: (cvs-ja).        Concurrent Versions System (Japanese)
   61: END-INFO-DIR-ENTRY
   62: @end format
   63: @end ifinfo
   64: 
   65: @ifinfo
   66: Copyright @copyright{} 1992, 1993 Signum Support AB
   67: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
   68: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
   69: Copyright @copyright{} 1999 Yoshiki Hayashi
   70: 
   71: Permission is granted to make and distribute verbatim copies of
   72: this manual provided the copyright notice and this permission notice
   73: are preserved on all copies.
   74: 
   75: @ignore
   76: Permission is granted to process this file through Tex and print the
   77: results, provided the printed document carries copying permission
   78: notice identical to this one except for the removal of this paragraph
   79: (this paragraph not being relevant to the printed manual).
   80: 
   81: @end ignore
   82: Permission is granted to copy and distribute modified versions of this
   83: manual under the conditions for verbatim copying, provided also that the
   84: entire resulting derived work is distributed under the terms of a
   85: permission notice identical to this one.
   86: 
   87: Permission is granted to copy and distribute translations of this manual
   88: into another language, under the above conditions for modified versions,
   89: except that this permission notice may be stated in a translation
   90: approved by the Free Software Foundation.
   91: @end ifinfo
   92: 
   93: @comment The titlepage section does not appear in the Info file.
   94: @titlepage
   95: @sp 4
   96: @comment The title is printed in a large font.
   97: @center @titlefont{CVSによるバージョン管理}
   98: @sp 2
   99: @center Version Management with CVS
  100: @center for @sc{cvs} @value{CVSVN}
  101: @center Per Cederqvist et al
  102: @sp 25
  103: @center 日本語訳 : 廣保 誠, 林 芳樹
  104: 
  105: @comment  The following two commands start the copyright page
  106: @comment  for the printed manual.  This will not appear in the Info file.
  107: @page
  108: @vskip 0pt plus 1filll
  109: Copyright @copyright{} 1992, 1993 Signum Support AB
  110: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
  111: Copyright @copyright{} 1999 Yoshiki Hayashi
  112: 
  113: Permission is granted to make and distribute verbatim copies of
  114: this manual provided the copyright notice and this permission notice
  115: are preserved on all copies.
  116: 
  117: Permission is granted to copy and distribute modified versions of this
  118: manual under the conditions for verbatim copying, provided also that the
  119: entire resulting derived work is distributed under the terms of a
  120: permission notice identical to this one.
  121: 
  122: Permission is granted to copy and distribute translations of this manual
  123: into another language, under the above conditions for modified versions,
  124: except that this permission notice may be stated in a translation
  125: approved by the Free Software Foundation.
  126: @end titlepage
  127: 
  128: @comment ================================================================
  129: @comment                   The real text starts here
  130: @comment ================================================================
  131: 
  132: @ifinfo
  133: @c ---------------------------------------------------------------------
  134: @node    Top
  135: @top CVS 1.10.8 Japanese Manual
  136: @c Note: there is a space after that @top command.
  137: @c The texinfo-format-buffer Emacs function and
  138: @c the makeinfo shell command disagree on what arguments
  139: @c @top takes; @top followed by a single space is
  140: @c something they can both cope with.
  141: 
  142: この info manual は、
  143: @sc{cvs} version @value{CVSVN}
  144: の使用方法と管理方法について記述します。
  145: @end ifinfo
  146: 
  147: @c This menu is pretty long.  Not sure how easily that
  148: @c can be fixed (no brilliant ideas right away)...
  149: @menu
  150: * Overview::                    CVS への導入
  151: * Repository::                  全てのソースが保存される場所
  152: * Starting a new project::      CVS でプロジェクトを始める
  153: * Revisions::                   リビジョンの数値とシンボルの名前
  154: * Branching and merging::       開発の枝の多様化/再一本化
  155: * Recursive behavior::          CVS はディレクトリを降りていく
  156: * Adding and removing::         ファイル/ディレクトリを加える/取り除
  157:                                 く/名前を変える
  158: * History browsing::            ファイルの履歴をいろいろな方法で閲覧する
  159: 
  160: CVS と現実の世界
  161: -----------------------
  162: * Binary files::                CVS はバイナリ・ファイルを扱うことができる
  163: * Multiple developers::         CVS の開発者グループの援助の仕方
  164: * Revision management::         リビジョン管理のポリシーへの質問
  165: * Keyword substitution::        CVS はファイルの中にリビジョンを含むこ
  166:                                 とができる
  167: * Tracking sources::            サード・パーティーソースの追っかけ
  168: * Builds::                      CVS とコンパイルに関する問題
  169: * Special Files::		デバイス、リンクと他の普通でないファイ
  170:   171: 
  172: リファレンス
  173: -----------
  174: * CVS commands::                CVS の命令は同じものを使う
  175: * Invoking CVS::                CVS の命令の quick reference
  176: * Administrative files::        管理ファイルへのリファレンスマニュアル
  177: * Environment variables::       CVS に影響する全ての環境変数
  178: * Compatibility::               CVS のバージョンを上げる
  179: * Troubleshooting::             動作しないときのいくらかのこつ
  180: * Credits::                     このマニュアルへの貢献者達
  181: * BUGS::                        CVS かこのマニュアルのバグの対処
  182: * 翻訳者より:Translation.       日本語訳について
  183: * Index::                       索引
  184: @end menu
  185: 
  186: @c ---------------------------------------------------------------------
  187: @node Overview
  188: @chapter 概観
  189: @cindex Overview
  190: 
  191: この章は @sc{cvs} を一度も使ったことが無く、おそらく以前にバージョン管
  192: 理ソフトを使ったことの無い人のためのものです。
  193: 
  194: 既に @sc{cvs} に親しんでいて、特定の機能を学んだり、特定の命令を覚えよ
  195: うとしているときは、ここは全て飛ばしてください。
  196: 
  197: @menu
  198: * What is CVS?::                @sc{cvs} で何が出きるか
  199: * What is CVS not?::            @sc{cvs} が解決しようとしない問題
  200: * A sample session::            基本的な @sc{cvs} の利用のツアー
  201: @end menu
  202: 
  203: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  204: @node What is CVS?
  205: @section CVS とは?
  206: @cindex What is CVS?
  207: @cindex Introduction to CVS
  208: @cindex CVS, introduction to
  209: 
  210: @sc{cvs} はバージョン管理システムであり、
  211: あなたのソース・ファイルの変遷を記録するのに使用します。
  212: 
  213: @c -- ///
  214: @c -- ///Those who cannot remember the past are condemned to repeat it.
  215: @c -- ///               -- George Santayana
  216: @c -- //////
  217: 
  218: @c -- Insert history  quote here!
  219: 例えば、ソフトウェアの修正に伴なってバグが入り込み、
  220: 発見されるまでに長い時間がかかったとします。
  221: @sc{cvs} を使っていれば、古いバージョンを簡単に復元し、
  222: バグの原因となった変更点を正確に調べることができます。
  223: この特徴に救われる時が必ずあります。
  224: 
  225: 全てのバージョンの全てのファイルを保存しておくこともできますが、
  226: ディスク容量の無駄使いでしかありません。
  227: @sc{cvs} は、バージョン間の差分のみを保存する方法により、
  228: 各ファイルの全バージョンを一つのファイルに記録します。
  229: 
  230: @sc{cvs} は、複数の開発者が同じソフトウェアに
  231: 取り組む場合に、真価を発揮します。
  232: このような場合にはよほど気を付けていないと、
  233: 他の人が変更したファイルを上書きしてしまいます。
  234: @sc{gnu} Emacs のようなエディタを使えば、
  235: 複数の人が同時に同じファイルを編集することはありません。
  236: しかし不幸なことに、全員が同じエディタを使うとは限りません。
  237: @sc{cvs} は開発者を互いに隔離することにより、この問題を解決しました。
  238: 全ての開発者は自分のディレクトリで作業し、
  239: その仕事を @sc{cvs} が組み合わせます。
  240: 
  241: @cindex History of CVS
  242: @cindex CVS, history of
  243: @cindex Credits (CVS program)
  244: @cindex Contributors (CVS program)
  245: @sc{cvs} は Dick Grune が作成し、
  246: 1986年 12 月に @code{comp.sources.unix} の volume 6 に投稿した、
  247: シェル・スクリプトから始まりました。
  248: 現在の @sc{cvs} は、
  249: これらのシェル・スクリプトのコードを全く含みませんが、
  250: 衝突解決のアルゴリズムの大部分を受け継いでいます。
  251: 
  252: 1989年 4 月に Brian Berliner が @sc{cvs} を設計し、コーディングしました。
  253: その後、Jeff Polk が @sc{cvs} の ベンダー枝とモジュールの設計を助けました。
  254: 
  255: @cindex Source, getting CVS source
  256: @sc{cvs} をインターネットからの自由なダウンロードなど、いろいろな方法
  257: で取得することができます。 @sc{cvs} のダウンロードや、他の @sc{cvs} の
  258: 話題の情報は、以下のところを参照してください。
  259: 
  260: @example
  261: http://www.cyclic.com/
  262: http://www.loria.fr/~molli/cvs-index.html
  263: @end example
  264: 
  265: @cindex Mailing list
  266: @cindex List, mailing list
  267: @cindex Newsgroups
  268: @w{@code{info-cvs}} という @sc{cvs} 専門のメーリング・リストがあります。
  269: @c このメーリング・リストに
  270: 参加、又は脱退したい場合には、
  271: @w{@code{info-cvs-request@@gnu.org}} にメールを出して下さい。
  272: Usenet グループの方を好むのであれば、正しいグループは
  273: @code{comp.software.config-mgmt} で、@sc{cvs} の議論を
  274: するために適した場所です (他の構成管理システムと一緒で
  275: すが)。 将来は @code{comp.software.config-mgmt.cvs} を
  276: 作ることも可能かもしれませんが、おそらく
  277: @code{comp.software.config-mgmt} に十分な流量があるよう
  278: になったときだけでしょう。
  279: @c Other random data is that past attempts to create a
  280: @c gnu.* group have failed (the relevant authorities
  281: @c say they'll do it, but don't), and that tale was very
  282: @c skeptical of comp.software.config-mgmt.cvs when the
  283: @c subject came up around 1995 or so (for one
  284: @c thing, because creating it would be a "reorg" which
  285: @c would need to take a more comprehensive look at the
  286: @c whole comp.software.config-mgmt.* hierarchy).
  287: 
  288: @ref{BUGS} でより詳細に説明されている bug-cvs メーリン
  289: グリストを講読するともできます。講読するためには、
  290: bug-cvs-request@@gnu.org にメールを送ってください。
  291: 
  292: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  293: @node What is CVS not?
  294: @section CVS は何ではない?
  295: @cindex What is CVS not?
  296: 
  297: @sc{cvs} は多くのことができますが、全ての人に全てのことを
  298: するようにはなっていません。
  299: 
  300: @table @asis
  301: @item @sc{cvs} は構築システムではありません。
  302: 
  303: リポジトリと modules ファイルの構造と構築システム (例. 
  304: @file{Makefile}) とは相互作用するかもしれませんが、本質的
  305: に独立したものです。
  306: 
  307: @sc{cvs} は、何かの作り方を指示したりはしません。
  308: @sc{cvs} はあなたの意思に従って、
  309: ツリー構造から望むファイルを取り出すだけです。
  310: 
  311: @sc{cvs} は、@code{checkout} 先の作業ディレクトリのディスク容量の使用
  312: 法について指示したりはしません。あなたが @file{Makefile} やスクリプトを
  313: 全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
  314: るとすると、リポジトリ全てを取り出す必要が生じます。
  315: 
  316: あなたが仕事をモジュール化し、(@file{Makefile} に link,
  317: mount, @code{VPATH}等を使用して、)ファイルを共有するよ
  318: うな構築システムを構成すれば、好きな様にディスクの利用
  319: 法を決めることが出来ます。
  320: 
  321: しかしこれら@emph{全ての}システムは、
  322: 構築と維持に多大な労力が必要なことに、
  323: 気を付けなければいけません。
  324: @sc{cvs} は、このような問題に関して考慮しません。
  325: 
  326: もちろん、これらの構築システムを支援するための道具
  327: (スクリプト, @file{Makefile} 等) は、
  328: @sc{cvs} の管理下に置くと良いでしょう。
  329: 
  330: 何らかの変更があった際に、再構築が必要なファイルを調べるのは、
  331: やはり @sc{cvs} の守備外です。
  332: 伝統的な手法の一例をあげると、
  333: 構築には @code{make} を用い、
  334: @code{make} に必要な依存関係は自動化されたツールを用いて生成します。
  335: 
  336: @sc{cvs} と結合して構築を行うための情報は @ref{Builds}
  337: を参照してください。
  338: 
  339: @item @sc{cvs} は管理者代理ではありません。
  340: 
  341: あなたの管理者や上司は、期日に従っているかどうかや、 
  342: マージ点、枝の名前、リリースの日時等について、
  343: あなたと度々話しあうことを求められています。
  344: 彼等がそうしないなら、@sc{cvs} は役に立ちません。
  345: 
  346: @sc{cvs} は、あなたの調律に従ってソースを踊らせる楽器の
  347: ようなものです。あなたは楽器奏者もしくは作曲者のような
  348: ものです。どんな楽器も勝手に演奏をしたりしないし、音楽
  349: が勝手に書かれたりもしません。
  350: 
  351: @item @sc{cvs} は開発者同士の意志疎通の代用にはなりません。
  352: 
  353: あるファイルに衝突が起きた場合に、
  354: ほとんどの開発者はそれほど苦労せずに解決します。
  355: しかし、@dfn{衝突} (@dfn{conflict})のより一般的な定義には、
  356: 開発者同士の意志疎通なしには解決できない
  357: 困難な問題も含まれます。
  358: 
  359: 同じファイル (もしくはファイルの集合) に、
  360: 同時に加えられた変更に論理的な衝突があっても、
  361: @sc{cvs} には分りません。
  362: @dfn{衝突}という概念は単に文字列の比較によるもので、
  363: 同じファイルを基に加えられた二つの変更が、
  364: @code{merge} コマンド (つまり @code{diff3}) を驚かせるのに
  365: 十分なほど近接している場合にのみ生じます。
  366: 
  367: @sc{cvs} は、
  368: プログラムの論理に、文字列でない衝突や、散らばった衝突
  369: があったとしても、警告を表示しません。
  370: 
  371: 例: 
  372: あなたは @file{A} で定義された関数 @code{X} の引数を変更したとします。
  373: 同じ時に、誰かが @file{B} を編集して、
  374: 古い引数を使って @code{X} を呼び出したとします。
  375: これは @sc{cvs} の能力の範囲外です。
  376: 
  377: 仕様書を読み、同僚と話し合う習慣を付けましょう。
  378: 
  379: 
  380: @item @sc{cvs} は変更管理をしません。
  381: 
  382: 変更管理という言葉は様々な意味を持ちます。
  383: まず@dfn{バグ追跡}と解釈すれば、バグ報告と各バグの状態
  384: (修正されたか? どのリリースか? 報告者は修正を確認したか? )
  385: についてのデータベース管理を意味します。
  386: @sc{cvs} とバグ追跡システムとの連携については、
  387: @file{rcsinfo} と @file{editinfo} ファイルを見て下さい 
  388: (@pxref{Administrative files})。
  389: 
  390: 論理的には一つと考えられる変更のため、
  391: 複数のファイルが同時に変更されたことを覚えておくことも、
  392: 変更管理と呼ばれます。
  393: 複数のファイルの変更を一つの @code{cvs commit} により格納した場合、
  394: @sc{cvs} はそれらのファイルが同時に格納されたことを忘れてしまいます。
  395: そして、それらのファイルを結ぶ事柄は、
  396: 同じログ・メッセージを持つことだけになるのです。
  397: @sc{gnu} 形式の @file{ChangeLog} を用いれば何らかの助けになるでしょう。
  398: @c FIXME: should have an xref to a section which talks
  399: @c more about keeping ChangeLog's with CVS, but that
  400: @c section hasn't been written yet.
  401: 
  402: 各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
  403: 開発者によって加えられた変更もあれば、
  404: 他の開発者によって追試中の変更もあるとか、そういったことです。
  405: 一般的に @sc{cvs} でこのようなことをするには、
  406: (@code{cvs diff} や @code{diff} を用いて) 差分を生成し、
  407: @code{patch} を当てる人物にメールとして送ります。
  408: これは非常に融通のきく方法ですが、
  409: @sc{cvs} 以外の機構に依存しているので、
  410: 問題が無いことを保証できません。
  411: 
  412: @item @sc{cvs} は自動検査プログラムではありません。
  413: 
  414: @code{commitinfo} ファイルを使えば、
  415: 強制的に必須の項目を検査することは可能だと思います。
  416: しかし、
  417: そんなことをしようとしたプロジェクトのことは聞いたことがありません。
  418: 
  419: @item @sc{cvs} は手順規範を備えていません。
  420: 
  421: 変更やリリースに必要とされる色々な手順や多くの承認を、
  422: 確実に行なう方法を備えたシステムもあります。
  423: @sc{cvs} を用いてこれを達成することも可能ですが、
  424: ちょっと面倒だと思います。
  425: 場合によっては、
  426: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{verifymsg} 
  427: 等のファイルを用いて、変更点を格納する前に、
  428: 必要な手順を確実に踏むように設定できるでしょう。
  429: また枝やタグといった機構を用いて、
  430: 開発用の枝で仕事を実行し、
  431: 安定性が証明された確実な変更だけを
  432: 安定化指向の枝に統合することも考えられます。
  433: @end table
  434: 
  435: @c ---------------------------------------------------------------------
  436: @node A sample session
  437: @section 作業例
  438: @cindex Example of a work-session
  439: @cindex Getting started
  440: @cindex Work-session, example of
  441: @cindex tc, Trivial Compiler (example)
  442: @cindex Trivial Compiler (example)
  443: 
  444: @c I think an example is a pretty good way to start.  But
  445: @c somewhere in here, maybe after the sample session,
  446: @c we need something which is kind of
  447: @c a "roadmap" which is more directed at sketching out
  448: @c the functionality of CVS and pointing people to
  449: @c various other parts of the manual.  As it stands now
  450: @c people who read in order get dumped right into all
  451: @c manner of hair regarding remote repositories,
  452: @c creating a repository, etc.
  453: @c
  454: @c The following was in the old Basic concepts node.  I don't
  455: @c know how good a job it does at introducing modules,
  456: @c or whether they need to be introduced so soon, but
  457: @c something of this sort might go into some
  458: @c introductory material somewhere.
  459: @ignore
  460: @cindex Modules (intro)
  461: リポジトリはディレクトリやファイルを含み、
  462: 任意の場所に設定できます。
  463: 複数のディレクトリやファイルから成る単位を、
  464: @dfn{モジュール} (@dfn{modules}) として一括して管理できます 
  465: (@pxref{modules})。
  466: 各モジュールは、
  467: プロジェクト毎に定義するのが普通です。
  468: @end ignore
  469: 
  470: @sc{cvs} を紹介する方法として、@sc{cvs} を使って典型的な仕事をしてみま
  471: す。最初に理解すべきことは @sc{cvs} は全てのファイルを中央に集められた 
  472: @dfn{リポジトリ} (@dfn{repository}) (@pxref{Repository}) に保存すると
  473: いうことです。この節ではリポジトリは準備されていると仮定します。
  474: @c I'm not sure that the sentence concerning the
  475: @c repository quite tells the user what they need to
  476: @c know at this point.  Might need to expand on "centralized"
  477: @c slightly (maybe not here, maybe further down in the example?)
  478: 
  479: あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語
  480: で書かれたファイルでできていて、@file{Makefile} を含んでいるとします。
  481: このコンパイラを @samp{tc} (Trivial Compiler) と呼ぶことにします。そし
  482: て @samp{tc} というモジュール名でリポジトリに登録されています。
  483: 
  484: @menu
  485: * Getting the source::          作業場所の作成
  486: * Committing your changes::     あなたの仕事を他の人が利用可能にする
  487: * Cleaning up::                 お掃除
  488: * Viewing differences::         差分を見る
  489: @end menu
  490: 
  491: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  492: @node Getting the source
  493: @subsection ソースの取得
  494: @cindex Getting the source
  495: @cindex Checking out source
  496: @cindex Fetching source
  497: @cindex Source, getting from CVS
  498: @cindex Checkout, example
  499: 
  500: まず、@samp{tc} のソースの作業コピーを取ってくることから始めましょう。
  501: これには @code{checkout} コマンドを使用します:
  502: 
  503: @example
  504: $ cvs checkout tc
  505: @end example
  506: 
  507: @noindent
  508: とすると @file{tc} という新しい作業ディレクトリが作られ、
  509: その中にソース・ファイルがコピーされます。
  510: 
  511: @example
  512: $ cd tc
  513: $ ls
  514: CVS         Makefile    backend.c   driver.c    frontend.c  parser.c
  515: @end example
  516: 
  517: @file{CVS} というディレクトリは @sc{cvs} が内部的に使用
  518: します。普通はその中にあるどんなファイルでも修正したり
  519: 削除してはいけません。
  520: 
  521: で、あなたの好きなエディタを用いて @file{backend.c} をハックして、
  522: 数時間後にコンパイラの最適化経路を加えたとします。
  523: @sc{rcs} と @sc{sccs} の利用者への注意: 編集したいファ
  524: イルをロックする必要はありません。その説明は、 @xref{Multiple
  525: developers}.
  526: 
  527: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  528: @node Committing your changes
  529: @subsection 変更の格納
  530: @cindex Committing changes
  531: @cindex Log message entry
  532: @cindex CVSEDITOR, environment variable
  533: @cindex EDITOR, environment variable
  534: 
  535: あなたはコンパイラが相変わらずコンパイル可能であることを確認し、
  536: @file{backend.c} の新しいバージョンとすることに決めました。これは新し
  537: い @file{backend.c} をリポジトリに格納し、同じリポジトリを使っている他
  538: の人が使用できるようにします。
  539: 
  540: @example
  541: $ cvs commit backend.c
  542: @end example
  543: 
  544: @noindent
  545: @sc{cvs} はログ・メッセージを記すためにエディタを開きます。
  546: そこで ``Added an optimization pass.'' などと入力し、
  547: 一時ファイルに保存し、エディタを終了します。
  548: 
  549: どのエディタが開かれるかは環境変数 @code{$CVSEDITOR} により決定されま
  550: す。@code{$CVSEDITOR} が設定されておらず、環境変数 @code{$EDITOR} が設
  551: 定されていれば、これを使用します。@code{$CVSEDITOR} と @code{$EDITOR} 
  552: の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
  553: フォルトが使われます。例えば、unix では @code{vi}で、Windows NT/95 で
  554: は @code{notepad} です。
  555: 
  556: @cindex VISUAL, environment variable
  557: 加えて、@sc{cvs} は @code{$VISUAL} 環境変数も調べます。この動作が望ま
  558: しいか、また @sc{cvs} の将来のリリースが @code{$VISUAL} を調べるべきか
  559: どうか、という意見は人によって異なります。@code{$VISUAL} が設定されて
  560: いないか、@code{$EDITOR} に設定されていることを確実にすることで、どち
  561: らになっても対処することができます。
  562: @c This probably should go into some new node
  563: @c containing detailed info on the editor, rather than
  564: @c the intro.  In fact, perhaps some of the stuff with
  565: @c CVSEDITOR and -m and so on should too.
  566: @sc{cvs} がエディタを開始したときは、修正されたファイルのリストを含ん
  567: でいます。@sc{cvs} のクライアントでは、このリストはファイルの修正時刻
  568: を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
  569: ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
  570: いないというときも、修正されたものとして表示されます。これに対する最も
  571: 簡単な対処法は単純に気にしないことです---それを commitすると、@sc{cvs} 
  572: は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
  573: す。次の @code{update}はファイルが無修正であるという事実に基づき、将来
  574: のセッションでファイルが表示されないように、タイムスタンプを保存されて
  575: いるものに設定し直します。
  576: @c FIXCVS: Might be nice if "commit" and other commands
  577: @c would reset that timestamp too, but currently commit
  578: @c doesn't.
  579: @c FIXME: Need to talk more about the process of
  580: @c prompting for the log message.  Like show an example
  581: @c of what it pops up in the editor, for example.  Also
  582: @c a discussion of how to get the "a)bort, c)ontinue,
  583: @c e)dit" prompt and what to do with it.  Might also
  584: @c work in the suggestion that if you want a diff, you
  585: @c should make it before running commit (someone
  586: @c suggested that the diff pop up in the editor.  I'm
  587: @c not sure that is better than telling people to run
  588: @c "cvs diff" first if that is what they want, but if
  589: @c we want to tell people that, the manual possibly
  590: @c should say it).
  591: 
  592: わざわざエディタを開くのが嫌ならば、代わりにコマンド行の @samp{-m} フ
  593: ラグを使うことでログメッセージを以下のように指定することができます:
  594: 
  595: @example
  596: $ cvs commit -m "Added an optimization pass" backend.c
  597: @end example
  598: 
  599: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  600: @node Cleaning up
  601: @subsection お掃除
  602: @cindex Cleaning up
  603: @cindex Working copy, removing
  604: @cindex Removing your working copy
  605: @cindex Releasing your working copy
  606: 
  607: 他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も
  608: ちろん、次のようにしても可能です
  609: 
  610: @example
  611: $ cd ..
  612: $ rm -r tc
  613: @end example
  614: 
  615: @noindent
  616: しかし、@code{release} コマンドを使用するほうが良いでしょう 
  617: (@pxref{release}):
  618: 
  619: @example
  620: $ cd ..
  621: $ cvs release -d tc
  622: M driver.c
  623: ? tc
  624: You have [1] altered files in this repository.
  625: Are you sure you want to release (and delete) directory `tc': n
  626: ** `release' aborted by user choice.
  627: @end example
  628: 
  629: @code{release} コマンドは、あなたの修正が格納されているかどうか確認し
  630: ます。ログを記録する設定ならば、ファイル @file{history} にメモします。 
  631: @xref{history file}.
  632: 
  633: @code{release} コマンドに @samp{-d} フラグを使用すると、
  634: 確認と同時に作業コピーを削除します。
  635: 
  636: 上の例では、@code{release} コマンドが何行か出力しています。
  637: @samp{? tc} は @sc{cvs} が @file{tc} というファイルを知らないという意味です。
  638: モジュール @samp{tc} のことではなく、
  639: 生成したコンパイラ @file{tc} を指しており、
  640: これはリポジトリに格納しなくて良いので無視して構いません。
  641: この警告を消すための情報は @ref{cvsignore} 参照。
  642: @code{release} の出力の詳細な説明は @ref{release output} 参照。
  643: 
  644: @samp{M driver.c} の方は重要です。
  645: これは、@file{driver.c} というファイルに加えた修正が、
  646: 格納されていないことを指摘しています。
  647: 
  648: @code{release} コマンドは、常に作業コピーの
  649: 修正が加えられたファイルの数を報告した後、
  650: ファイルを削除したり履歴ファイルにメモする前に、
  651: その確認を求めてきます。
  652: 
  653: ここでは大事を取って、最後に @code{release} が確認を求めたときに 
  654: @kbd{n @key{RET}} を入力しました。
  655: 
  656: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  657: @node Viewing differences
  658: @subsection 差分を見る
  659: @cindex Viewing differences
  660: @cindex Diff
  661: 
  662: あなたは @file{driver.c} に加えた修正を覚えていなかったので、
  663: 何をしたのか調べる必要があります。
  664: 
  665: @example
  666: $ cd tc
  667: $ cvs diff driver.c
  668: @end example
  669: 
  670: このコマンドは @code{diff} を実行して、取り出した時と、あなたの作業コ
  671: ピーの @file{driver.c} のバージョンを比較します。その出力を見て、最適
  672: 化経路を有効にするオプションを、コマンド行で指定できるようにしたことを
  673: 思い出しました。その変更を格納して、このモジュールに対する作業を終了し
  674: ます。
  675: @c FIXME: we haven't yet defined the term "check in".
  676: 
  677: @example
  678: $ cvs commit -m "Added an optimization pass" driver.c
  679: Checking in driver.c;
  680: /usr/local/cvsroot/tc/driver.c,v  <--  driver.c
  681: new revision: 1.2; previous revision: 1.1
  682: done
  683: $ cd ..
  684: $ cvs release -d tc
  685: ? tc
  686: You have [0] altered files in this repository.
  687: Are you sure you want to release (and delete) directory `tc': y
  688: @end example
  689: 
  690: @c ---------------------------------------------------------------------
  691: @node Repository
  692: @chapter リポジトリ
  693: @cindex Repository (intro)
  694: @cindex Repository, example
  695: @cindex Layout of repository
  696: @cindex Typical repository
  697: @cindex /usr/local/cvsroot, as example repository
  698: @cindex cvsroot
  699: 
  700: @sc{cvs} の@dfn{リポジトリ} (@dfn{repository}) は、
  701: バージョン管理の対象となる全てのファイルとディレクトリの、
  702: 完全なコピーを保管します。
  703: 
  704: 通常、リポジトリ中のファイルを直接利用することはありません。
  705: その代わりに @sc{cvs} コマンドを使用して、
  706: 作業者自身のファイルのコピーを @dfn{作業ディレクトリ}
  707: に取り出し、そのコピーを用いて作業します。
  708: 
  709: そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も
  710: しくは @dfn{格納} します (@dfn{commit}))。リポジトリは、変更を加えたも
  711: のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され
  712: ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ
  713: とに注意してください。別の位置にあるべきです。
  714: @c Need some example, e.g. repository
  715: @c /usr/local/cvsroot; working directory
  716: @c /home/joe/sources.  But this node is too long
  717: @c as it is; need a little reorganization...
  718: 
  719: @cindex :local:, setting up
  720: @sc{cvs} は様々な方法でリポジトリを利用することができます。
  721: リポジトリは、使用中のコンピュータ内であってもいいし、
  722: 別の部屋のコンピュータや、別の国のコンピュータであっても構いません。
  723: リポジトリに接続する方法を区別するために、
  724: リポジトリの名前の最初に@dfn{接続経路} (@dfn{access
  725: method}) を加えることがあります。例えば @code{:local:} は、リポジトリ
  726: であるディレクトリを利用することを意味します。つまり 
  727: @code{:local:/usr/local/cvsroot} で表されるリポジトリは、@sc{cvs} を実
  728: 行したコンピュータの @file{/usr/local/cvsroot} というリポジトリを意味
  729: します。他の接続経路については @ref{Remote repositories} 参照。
  730: 
  731: @c Can se say this more concisely?  Like by passing
  732: @c more of the buck to the Remote repositories node?
  733: 接続経路の指定が省略され、リポジトリに @samp{:} が含まれない場合には、
  734: @code{:local:} が仮定されます。
  735: @samp{:} が含まれていた場合には、
  736: @code{:ext:} か @code{:server:} が仮定されます。
  737: 例えばリポジトリ @file{/usr/local/cvsroot} が同じコンピュータ内にある場合、
  738: @code{:local:/usr/local/cvsroot} を省略して
  739: @code{/usr/local/cvsroot} と記述しても構いません。
  740: しかし(Windows NT などで)、
  741: リポジトリが @file{c:\src\cvsroot} にある場合、 
  742: @code{:local:c:\src\cvsroot} として、
  743: 接続経路を明示する必要があります。
  744: 
  745: @c This might appear to go in Repository storage, but
  746: @c actually it is describing something which is quite
  747: @c user-visible, when you do a "cvs co CVSROOT".  This
  748: @c isn't necessary the perfect place for that, though.
  749: リポジトリは二つの要素から構成されます。
  750: @file{$CVSROOT/CVSROOT} には @sc{cvs} の管理用ファイルが置かれます。
  751: その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。
  752: 
  753: @menu
  754: * Specifying a repository::     どのリポジトリを使うか CVS に教える
  755: * Repository storage::          リポジトリの構造
  756: * Working directory storage::   作業ディレクトリの構造
  757: * Intro administrative files::  モジュールの定義
  758: * Multiple repositories::       複数のリポジトリ
  759: * Creating a repository::       リポジトリの作成
  760: * Backing up::                  リポジトリのバックアップ
  761: * Moving a repository::         リポジトリの移動
  762: * Remote repositories::         別のマシンのリポジトリを利用する
  763: * Read-only access::            リポジトリの読み込みのみの利用を許可する
  764: * Server temporary directory::  サーバは一時ディレクトリを作成する
  765: @end menu
  766: 
  767: @node Specifying a repository
  768: @section CVS にリポジトリの場所を教える
  769: 
  770: @sc{cvs} にリポジトリの場所を教えるには、
  771: いくつか方法があります。
  772: 一つ目はコマンド行で、
  773: @code{-d} ("directory" を示します) オプションを用いて
  774: 指定する方法です:
  775: 
  776: @example
  777: cvs -d /usr/local/cvsroot checkout yoyodyne/tc
  778: @end example
  779: 
  780: @cindex .profile, setting CVSROOT in
  781: @cindex .cshrc, setting CVSROOT in
  782: @cindex .tcshrc, setting CVSROOT in
  783: @cindex .bashrc, setting CVSROOT in
  784: @cindex CVSROOT, environment variable
  785: 二つ目は、環境変数 @code{$CVSROOT} に、
  786: 絶対パスでリポジトリを指定する方法です。
  787: 例では @file{/usr/local/cvsroot}です。
  788: @code{csh} や @code{tcsh} のユーザは各々
  789: @file{.cshrc} や @file{.tcshrc} に次の行を加えて下さい:
  790: 
  791: @example
  792: setenv CVSROOT /usr/local/cvsroot
  793: @end example
  794: 
  795: @noindent
  796: @code{sh} や @code{bash} のユーザは各々 
  797: @file{.profile} や @file{.bashrc} に次の行を加えて下さい:
  798: 
  799: @example
  800: CVSROOT=/usr/local/cvsroot
  801: export CVSROOT
  802: @end example
  803: 
  804: @cindex Root file, in CVS directory
  805: @cindex CVS/Root file
  806: @code{-d} によるリポジトリの指定は、
  807: 環境変数 @code{$CVSROOT} よりも優先されます。
  808: 一旦リポジトリから作業コピーを取得すれば、
  809: リポジトリの場所が記憶されます
  810: (この情報は、作業ディレクトリ内の 
  811: @file{CVS/Root} に記録されます)。
  812: 
  813: オプション @code{-d} とファイル @file{CVS/Root} は、
  814: どちらも環境変数 @code{$CVSROOT} よりも優先されます。
  815: また、@file{-d} と @file{CVS/Root} が一致しない場合は、
  816: 前者が使用されます。
  817: もちろん、
  818: 二つともが同じリポジトリを参照するのが、まともなやり方です。
  819: 
  820: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  821: @node Repository storage
  822: @section リポジトリでのデータの保存方法
  823: @cindex Repository, how data is stored
  824: 
  825: @sc{cvs} がリポジトリに情報を保存する@emph{方法}を知っていても、
  826: たいてい何の役にも立ちません。
  827: 実際、過去に書式が変更されましたし、
  828: 将来変更されることもあるでしょう。
  829: ほとんど全ての場合、
  830: @sc{cvs} コマンドを通してリポジトリを利用しますから、
  831: 書式を変更しても混乱は起きません。
  832: 
  833: しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え
  834: ば @sc{cvs} のロック解除が必要な場合 (@pxref{Concurrency}) や、リポジ
  835: トリのファイルの許可属性を適切に設定する必要がある場合などです。
  836: 
  837: @menu
  838: * Repository files::            リポジトリに保管されるファイル
  839: * File permissions::            ファイル使用許可
  840: * Windows permissions::         Windows 特有の問題
  841: * Attic::                       Attic に保存されるファイルもある
  842: * CVS in repository::           CVS ディレクトリの追加情報
  843: * Locks::                       CVS ロックは並列接続を制御する
  844: * CVSROOT storage::             CVSROOT の少しの違い
  845: @end menu
  846: 
  847: @node Repository files
  848: @subsection リポジトリのどこにファイルを保存するか
  849: 
  850: @c @cindex Filenames, legal
  851: @c @cindex Legal filenames
  852: @c Somewhere we need to say something about legitimate
  853: @c characters in filenames in working directory and
  854: @c repository.  Not "/" (not even on non-unix).  And
  855: @c here is a specific set of issues:
  856: @c 	Files starting with a - are handled inconsistently. They can not
  857: @c   be added to a repository with an add command, because it they are
  858: @c   interpreted as a switch. They can appear in a repository if they are
  859: @c   part of a tree that is imported. They can not be removed from the tree
  860: @c   once they are there.
  861: @c Note that "--" *is* supported (as a
  862: @c consequence of using GNU getopt).  Should document
  863: @c this somewhere ("Common options"?).  The other usual technique,
  864: @c "./-foo", isn't as effective, at least for "cvs add"
  865: @c which doesn't support pathnames containing "/".
  866: 
  867: リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい
  868: ます。例えば、リポジトリが
  869: 
  870: @example
  871: /usr/local/cvsroot
  872: @end example
  873: 
  874: @noindent
  875: にあれば、次のようなディレクトリの木構造になります (ディレクトリだけを
  876: 表示しています):
  877: 
  878: @example
  879: @t{/usr}
  880:  |
  881:  +--@t{local}
  882:  |   |
  883:  |   +--@t{cvsroot}
  884:  |   |    | 
  885:  |   |    +--@t{CVSROOT}
  886:           |      (管理用ファイル)
  887:           | 
  888:           +--@t{gnu}
  889:           |   | 
  890:           |   +--@t{diff}
  891:           |   |   (@sc{gnu} diff のソース)
  892:           |   | 
  893:           |   +--@t{rcs}
  894:           |   |   (@sc{rcs} のソース)
  895:           |   | 
  896:           |   +--@t{cvs}
  897:           |       (@sc{cvs} のソース)
  898:           | 
  899:           +--@t{yoyodyne}
  900:               | 
  901:               +--@t{tc}
  902:               |    |
  903:               |    +--@t{man}
  904:               |    |
  905:               |    +--@t{testing}
  906:               | 
  907:               +--(その他の Yoyodyne のソフトウェア)
  908: @end example                              
  909: 
  910: ディレクトリの中身は、管理下にあるファイルの@dfn{履歴ファイル} 
  911: (@dfn{history files}) です。
  912: 履歴ファイルの名前は、各ファイル名の最後に @samp{,v} を付加したものです。
  913: 次に、ディレクトリ @file{yoyodyne/tc} のリポジトリ構造を示します:
  914: @c FIXME: Should also mention CVS (CVSREP)
  915: @c FIXME? Should we introduce Attic with an xref to
  916: @c Attic?  Not sure whether that is a good idea or not.
  917: @example
  918:   @code{$CVSROOT}
  919:     |
  920:     +--@t{yoyodyne}
  921:     |   |
  922:     |   +--@t{tc}
  923:     |   |   |
  924:             +--@t{Makefile,v}
  925:             +--@t{backend.c,v}
  926:             +--@t{driver.c,v}
  927:             +--@t{frontend.c,v}
  928:             +--@t{parser.c,v}
  929:             +--@t{man}
  930:             |    |
  931:             |    +--@t{tc.1,v}
  932:             |
  933:             +--@t{testing}
  934:                  |
  935:                  +--@t{testpgm.t,v}
  936:                  +--@t{test2.t,v}
  937: @end example
  938: 
  939: @cindex History files
  940: @cindex RCS history files
  941: @c The first sentence, about what history files
  942: @c contain, is kind of redundant with our intro to what the
  943: @c repository does in node Repository....
  944: 履歴ファイルは、
  945: どのリビジョンのファイルでも再構築できる情報を持ち、
  946: また変更内容が格納された時のログ・メッセージと、
  947: その時のユーザの名前も記録しています。
  948: ファイルをこのような書式で保管した最初のプログラムが、
  949: @sc{rcs} というバージョン管理システムであったために、
  950: 履歴ファイルは @dfn{RCS ファイル} と呼ばれます。
  951: ファイル書式の完全な記述は、@sc{rcs} の配布セットにある
  952: @cite{rcsfile(5)} の @code{man} ページか、@sc{cvs} のソー
  953: ス配布のファイル @file{doc/RCSFILES} を参照してください。
  954: このファイル書式は非常に一般的なので、
  955: @sc{cvs} や @sc{rcs} 以外のシステムでも、
  956: 少くとも理解をすることができます。
  957: @c FIXME: Think about including documentation for this
  958: @c rather than citing it?  In the long run, getting
  959: @c this to be a standard (not sure if we can cope with
  960: @c a standards process as formal as IEEE/ANSI/ISO/etc,
  961: @c though...) is the way to go, so maybe citing is
  962: @c better.
  963: 
  964: @sc{cvs} で使用されている @sc{rcs} ファイルは標準の書式と少し違います。
  965: 最大の違いは魔法の枝です。詳細は @ref{Magic branch numbers} を参照して
  966: ください。@sc{cvs} では、有効なタグ名は @sc{rcs} で使用できるもののサ
  967: ブセットになっています。@sc{cvs} の規則は @ref{Tags} を参照してくださ
  968: い。
  969: 
  970: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  971: @node File permissions
  972: @subsection ファイル使用許可
  973: @c -- Move this to @node Creating a repository or similar
  974: @cindex Security
  975: @cindex File permissions, general
  976: @cindex Permissions, general
  977: @c FIXME: we need to somehow reflect "permissions in
  978: @c repository" versus "permissions in working
  979: @c directory" in the index entries.
  980: @cindex Group
  981: @cindex Read-only files, in repository
  982: 全ての @samp{,v} ファイルは読み込み専用であり、
  983: この使用許可を変えるべきではありません。
  984: これに対し、リポジトリ中のディレクトリは、
  985: ファイルの修正を行なう人物に対して、
  986: 書き込みを許可しなくてはいけません。
  987: これはつまり、
  988: ファイルの修正を行なう人物からなるグループを作って 
  989: (@cite{group(5)}参照)、
  990: そのディレクトリの所有グループとすることを意味しています。
  991: @c See also comment in commitinfo node regarding cases
  992: @c which are really awkward with unix groups.
  993: 
  994: 従って、
  995: ディレクトリ単位でしかファイルのアクセス権を
  996: 管理することができません。
  997: 
  998: @sc{cvs} はロック・ファイルを作成する必要があるため 
  999: (@pxref{Concurrency})、ファイルを取り出す使用者にも、書き込み許可が必
 1000: 要であることに注意して下さい。
 1001: 
 1002: @c CVS seems to use CVSUMASK in picking permissions for
 1003: @c val-tags, but maybe we should say more about this.
 1004: @c Like val-tags gets created by someone who doesn't
 1005: @c have CVSUMASK set right?
 1006: 利用者は @file{CVSROOT/val-tags} ファイルに書き込み許可が必要なことも
 1007: 注意してください。@sc{cvs} はそれをどのタグが有効かを記録するために使
 1008: います (作成時と、ときどきタグが使用されたときに更新されます)。
 1009: 
 1010: それぞれの @sc{rcs} ファイルは最後に書き込んだ利用者に所有されます。こ
 1011: れはあまり重要ではありません。重要なのは誰がディレクトリを所有している
 1012: かです。
 1013: 
 1014: @cindex CVSUMASK, environment variable
 1015: @cindex Umask, for repository files
 1016: 木の中に新しいディレクトリを加える場合、
 1017: @sc{cvs} はできるだけ適当な使用許可を与える努力をします。
 1018: しかし新しいディレクトリの使用許可が、
 1019: 親ディレクトリのものと異なる必要がある場合には、
 1020: 手動で変更する必要があります。
 1021: 環境変数 @code{CVSUMASK} を設定すれば、
 1022: リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。
 1023: @code{CVSUMASK} は、作業ディレクトリのファイル使用許可には影響しません。
 1024: 作業コピーの使用許可は、
 1025: 新たに作成したファイルに通常与えられるものと同じです。
 1026: 但し、@sc{cvs} が読み込みだけを許可することがあります
 1027: (監視時 @ref{Setting a watch}, -r 使用時 @ref{Global options},
 1028: @code{CVSREAD} 設定時 @ref{Environment variables} を各々参照)。
 1029: @c FIXME: Need more discussion of which
 1030: @c group should own the file in the repository.
 1031: @c Include a somewhat detailed example of the usual
 1032: @c case where CVSUMASK is 007, the developers are all
 1033: @c in a group, and that group owns stuff in the
 1034: @c repository.  Need to talk about group ownership of
 1035: @c newly-created directories/files (on some unices,
 1036: @c such as SunOS4, setting the setgid bit on the
 1037: @c directories will make files inherit the directory's
 1038: @c group.  On other unices, your mileage may vary.  I
 1039: @c can't remember what POSIX says about this, if
 1040: @c anything).
 1041: 
 1042: クライアント/サーバ @sc{cvs} を使用すると (@pxref{Remote
 1043: repositories})、@code{CVSUMASK} を設定する良い方法はありません。クライ
 1044: アントマシンでの設定は効果がありません。@code{rsh} で接続しているなら、
 1045: オペーレーティングシステムの説明に書いてあるように、@file{.bashrc} や
 1046: @file{.cshrc} で @code{CVSUMASK} を設定することができます。この振る舞
 1047: いは将来のバージョンの @sc{cvs} では変更されるかもしれません。クライア
 1048: ントの @code{CVSUMASK} の設定には頼らず、それは無効になるでしょう。
 1049: @c FIXME: need to explain what a umask is or cite
 1050: @c someplace which does.
 1051: @c
 1052: @c There is also a larger (largely separate) issue
 1053: @c about the meaning of CVSUMASK in a non-unix context.
 1054: @c For example, whether there is
 1055: @c an equivalent which fits better into other
 1056: @c protection schemes like POSIX.6, VMS, &c.
 1057: @c
 1058: @c FIXME: Need one place which discusses this
 1059: @c read-only files thing.  Why would one use -r or
 1060: @c CVSREAD?  Why would one use watches?  How do they
 1061: @c interact?
 1062: @c
 1063: @c FIXME: We need to state
 1064: @c whether using CVSUMASK removes the need for manually
 1065: @c fixing permissions (in fact, if we are going to mention
 1066: @c manually fixing permission, we better document a lot
 1067: @c better just what we mean by "fix").
 1068: 
 1069: pserver を使う場合は、一般的に、 @sc{cvsroot} ディレクトリと木構造でそ
 1070: れより上のディレクトリには厳しい使用許可が必要です。@ref{Password
 1071: authentication security} を参照してください。
 1072: 
 1073: @cindex Setuid
 1074: @cindex Setgid
 1075: @cindex Security, setuid
 1076: @cindex Installed images (VMS)
 1077: オペレーティングシステムには特定のプログラムが、プログラムの呼び手には
 1078: できないような動作をする能力とともに実行される機能があるものがあります。
 1079: 例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や
 1080: VMS の installed image 機能です。CVS はそのような機能を使用するように
 1081: 書かれていませんので、そのような方法で CVS をインストールすると事故の
 1082: 過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして
 1083: いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使
 1084: 用許可を得るかもしれません。代わりに pserver を使用することを考えるか
 1085: もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ
 1086: キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供
 1087: する可能性がありますので、このオプションを考えているなら、pserver の説
 1088: 明文書を注意深く読んでください。(@ref{Password authentication
 1089: security})。
 1090: 
 1091: @node Windows permissions
 1092: @subsection Windows に特有なファイルの使用許可問題
 1093: @cindex Windows, and permissions
 1094: @cindex File permissions, Windows-specific
 1095: @cindex Permissions, Windows-specific
 1096: 
 1097: ファイルの使用許可には Windows オペレーティングシステムに特有の問題も
 1098: あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ
 1099: ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、
 1100: 確かではありません)。
 1101: 
 1102: ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ
 1103: トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる
 1104: ことがあることが報告されています。Samba の設定で WRITE=YES にすると修
 1105: 正される/何とかなると言われています。
 1106: 責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調
 1107: 査をしていません。加えて、問題を避けるために CVS が違ったようにするこ
 1108: とができるかどうかも調べていません。何か発見したなら、@ref{BUGS} に書
 1109: かれているように我々に報せてください。
 1110: 
 1111: @node Attic
 1112: @subsection The attic
 1113: @cindex Attic
 1114: 
 1115: ときどき @sc{cvs} は @sc{rcs} ファイルを @code{Attic} に保存することが
 1116: あることに気付くでしょう。例えば、@sc{cvsroot} が 
 1117: @file{/usr/local/cvsroot} でディレクトリ @file{yoyodyne/tc} のファイル
 1118: @file{backend.c} について話をしているとき、普通はファイルは以下のとこ
 1119: ろにあります
 1120: 
 1121: @example
 1122: /usr/local/cvsroot/yoyodyne/tc/backend.c,v
 1123: @end example
 1124: 
 1125: しかし、attic に行けば、代わりに
 1126: 
 1127: @example
 1128: /usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
 1129: @end example
 1130: 
 1131: @cindex Dead state
 1132: になります。利用者にとってはファイルが attic にあるかどうかは関係あり
 1133: ません。@sc{cvs} はこれを記録し、必要なときは attic を調べます。詳細を
 1134: 知りたい人のために書くと、幹の先頭リビジョンが @code{dead} の状態であ
 1135: るまさにそのときだけ、ファイルは attic に保存されます。@code{dead} の
 1136: 状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが
 1137: ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは
 1138: @code{dead} の状態になり枝のリビジョンは @code{dead} ではない状態にな
 1139: ります。
 1140: @c Probably should have some more concrete examples
 1141: @c here, or somewhere (not sure exactly how we should
 1142: @c arrange the discussion of the dead state, versus
 1143: @c discussion of the attic).
 1144: 
 1145: @node CVS in repository
 1146: 
 1147: @subsection リポジトリの CVS ディレクトリ
 1148: @cindex CVS directory, in repository
 1149: 
 1150: それぞれのリポジトリのディレクトリの @file{CVS} ディレクトリはファイル
 1151: 属性などの情報が収められています (@file{CVS/fileattr} というファイルで
 1152: す。)。将来はこのディレクトリには他のファイルが加えられる可能性があり
 1153: ますから、実装は追加のファイルを静かに無視するのが良いでしょう。
 1154: 
 1155: この動作は @sc{cvs} 1.7 とその後のものだけで実装されています。詳細は
 1156: @ref{Watches Compatibility} を参照してください。
 1157: 
 1158: fileattr ファイルの書式は以下の形式の登録の連続したものです (@samp{@{}
 1159: と @samp{@}} は括弧の中のテキストを0回以上繰り返すことができるというこ
 1160: とです):
 1161: 
 1162: @var{ent-type} @var{filename} <tab> @var{attrname} = @var{attrval}
 1163:   @{; @var{attrname} = @var{attrval}@} <linefeed>
 1164: 
 1165: @var{ent-type} はファイルでは @samp{F} で、その場合は登録はそのファイ
 1166: ルの属性を指定します。
 1167: 
 1168: @var{ent-type} が @samp{D} で、@var{filename} が空であると、新しく追加
 1169: されたファイルへの既定属性を指定します。
 1170: 
 1171: 他の @var{ent-type} は将来の拡張のために予約されています。CVS 1.9 とそ
 1172: れ以前のものはファイル属性を書き込むときにいつでもそれらを消すでしょう。
 1173: CVS 1.10 とそれ以降はそれらを保存します。
 1174: 
 1175: 行の順番は関係無いことに注意してください。
 1176: fileattr ファイルを書き込むプログラムは便利な様に再編成するかもしれま
 1177: せん。
 1178: 
 1179: ファイル名でのタブとラインフィード、@var{attrname} での @samp{=},
 1180: @var{attrval} での @samp{;}、などを引用する方法は今はありません。
 1181: 
 1182: 習慣では、@var{attrname} は CVS により特別な意味を持っている属性は 
 1183: @samp{_} で始まります。他の @var{attrname} は使用者定義の属性のために
 1184: あります (もしくは、実装が使用者定義の属性のサポートを始めたときにそう
 1185: なるでしょう)。
 1186: 
 1187: 作りつけの属性です:
 1188: 
 1189: @table @code
 1190: @item _watched
 1191: 存在すると、ファイルが監視下にあり、読み込み専用で取り出すべきであるこ
 1192: とを意味します。
 1193: 
 1194: @item _watchers
 1195: このファイルを監視している使用者です。値は
 1196: @var{watcher} > @var{type} @{ , @var{watcher} > @var{type} @}
 1197: で、@var{editor} は使用者名、@var{val} は 
 1198: @var{time}+@var{hostname}+@var{pathname} で、@var{time} は @code{cvs
 1199: edit} コマンド (もしくはそれと等価なもの) が発生したときで、
 1200: @var{hostname} と @var{pathname} は作業ディレクトリのためです。
 1201: @end table
 1202: 
 1203: 例:
 1204: 
 1205: @c FIXME: sanity.sh should contain a similar test case
 1206: @c so we can compare this example from something from
 1207: @c Real Life(TM).  See cvsclient.texi (under Notify) for more
 1208: @c discussion of the date format of _editors.
 1209: @example
 1210: Ffile1 _watched=;_watchers=joe>edit,mary>commit
 1211: Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs
 1212: D _watched=
 1213: @end example
 1214: 
 1215: は @file{file1} は読み込み専用で取り出されるべきだということです。加え
 1216: て、joe は edit を監視しており、mary は commit を監視しています。ファ
 1217: イル @file{file2} は読み込み専用で取り出されるべきです。sue は 1975年1
 1218: 月8日にマシン @code{workstn1} のディレクトリ @file{/home/sue/cs}編集を
 1219: 始めました。この例を表現するために、@samp{D}, @samp{Ffile1},
 1220: @samp{Ffile2} の後に空白を表示していますが、実際は単独のタブ文字がそこ
 1221: にあり、空白があってはいけません。
 1222: 
 1223: @node Locks
 1224: @subsection リポジトリの CVS ロック
 1225: 
 1226: @cindex #cvs.rfl, technical details
 1227: @cindex #cvs.wfl, technical details
 1228: @cindex #cvs.lock, technical details
 1229: @cindex Locks, cvs, technical details
 1230: 利用者から見える部分の CVS のロックに焦点をあてた紹介は 
 1231: @ref{Concurrency} を参照してください。次の部分は同じリポジトリをアクセ
 1232: スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう
 1233: なツールを書きたい人を対象にしています。@dfn{読み込みロック}
 1234: (@dfn{read lock}), @dfn{書き込みロック} (@dfn{write lock}), @dfn{デッ
 1235: ドロック} (@dfn{deadlock}) のような概念がよくわからなかったら、オペレー
 1236: ティングシステムやデータベースの文献を参照すると良いかもしれません。
 1237: 
 1238: @cindex #cvs.tfl
 1239: リポジトリ中の @file{#cvs.rfl.} で始まる全てのファイルは読み込みロック
 1240: です。リポジトリ中の @file{#cvs.wfl} で始まる全てのファイルは書き込み
 1241: ロックです。古いバージョンの CVS (CVS 1.5 以前) は @file{#cvs.tfl} で
 1242: 始まる名前のファイルも作成していましたが、ここではそれらは議論しません。
 1243: ディレクトリ @file{#cvs.lock} はマスターロックとして働きます。すなわち、
 1244: 他のロックを取得する前に、まずこのロックを取得しなければならない、とい
 1245: うことです。
 1246: 
 1247: 書き込みロックを取得するためには、まず @file{#cvs.lock} ディレクトリを
 1248: 作成します。この操作は原子的操作でなければなりません (これはたいていの
 1249: オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた
 1250: めに失敗すれば、しばらく待ってもう一度試します。@file{#cvs.lock} ロッ
 1251: クを取得した後、@file{#cvs.rfl.} の後に選択した情報 (例えば、ホスト名
 1252: とプロセス番号) が続いた名前のファイルを作成します。それからマスターロッ
 1253: クを解放するために @file{#cvs.lock} ディレクトリを消去します。それから
 1254: リポジトリを読んで続行します。終った後、読み込みロックを解放するために
 1255: @file{#cvs.rfl} ファイルを消去します。
 1256: 
 1257: 書き込みロックを取得するためには、読み込みロックと同様にまず 
 1258: @file{#cvs.lock} ディレクトリを作成します。それから @file{#cvs.rfl.} 
 1259: で始まるファイルが無いかどうかを調べます。もしあれば、@file{#cvs.lock} 
 1260: を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、
 1261: @file{#cvs.wfl} の後に選択した情報を続けた名前のファイルを作成します 
 1262: (例えば、ホスト名とプロセス番号)。ロック @file{#cvs.lock} を続けます。
 1263: リポジトリへの書き込みを実行します。それが終わると、まず 
 1264: @file{#cvs.wfl} ファイルを消去し、それから @file{#cvs.lock} ディレクト
 1265: リを消去します。@file{#cvs.rfl} ファイルと違って、@file{#cvs.wfl} ファ
 1266: イルは情報提供のためだけにあることに注意してください。@file{#cvs.lock} 
 1267: そのもののロックを続ける以上のロック操作の効果はありません。
 1268: 
 1269: それぞれのロック (書き込みロック及び読み込みロック) は @file{Attic} と
 1270: @file{CVS} を含んだリポジトリの単独のディレクトリのみをロックしますが、
 1271: バージョン管理下の他のディレクトリは含まないことに注意してください。木
 1272: 全体をロックするためには、それぞれのディレクトリをロックする必要があり
 1273: ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため
 1274: に再挑戦の前に木全体を解放しなければならないことに注意してください)。
 1275: 
 1276: @sc{cvs} は個々の @file{foo,v} ファイルへのアクセス制御のために書き込
 1277: みロックを期待するということにも注意してください。@sc{rcs} には 
 1278: @file{,foo,} ファイルがロックとして働く機構がありますが、@sc{cvs} はそ
 1279: れを実装しておらず、@sc{cvs} の書き込みロックを取り出すことが推奨され
 1280: ています。さらなる議論/合理性は @sc{cvs} のソースコードの 
 1281: rcs_internal_lockfile のところのコメントを読んでください。
 1282: 
 1283: @node CVSROOT storage
 1284: @subsection CVSROOT ディレクトリでファイルが保管される方法
 1285: @cindex CVSROOT, storage of files
 1286: 
 1287: @file{$CVSROOT/CVSROOT} ディレクトリにはいろいろな管理ファイルがありま
 1288: す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て
 1289: います。そこにはファイル名が @samp{,v} で終わる多くの @sc{rcs} ファイ
 1290: ルがあり、多くの @sc{cvs} コマンドは同じ方法でそれを操作します。しかし、
 1291: 少しの違いはあります。
 1292: 
 1293: それぞれの管理ファイルには、@sc{rcs} ファイルに加えて、ファイルの取り
 1294: 出された版のコピーがあります。例えば、@sc{rcs} ファイル 
 1295: @file{loginfo,v} とそれの最新リビジョンであるファイル @file{loginfo}
 1296: があります。管理ファイルを格納したときは、@sc{cvs} は
 1297: 
 1298: @example
 1299: cvs commit: Rebuilding administrative file database
 1300: @end example
 1301: 
 1302: @noindent
 1303: を印字し、@file{$CVSROOT/CVSROOT} の取り出された版のコピーを更新するよ
 1304: うになっています。もしそうならなければ、何かがおかしくなっています 
 1305: (@pxref{BUGS})。自分自身のファイルをこのように更新されるファイル群に追
 1306: 加するために、それらを管理ファイル @file{checkoutlist} に追加できます 
 1307: (@pxref{checkoutlist})。
 1308: 
 1309: @cindex modules.db
 1310: @cindex modules.pag
 1311: @cindex modules.dir
 1312: 初期設定では @file{modules} ファイルは上で説明されているように振舞いま
 1313: す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし
 1314: て保存しているとモジュールの探索が遅くなるかもしれません (@sc{cvs} が
 1315: 最初にこの機能を追加したときほど関心があるかどうかは定かではありません。
 1316: ベンチマークは見ていませんので)。ですから、@sc{cvs} ソースコードに適切
 1317: な修正を加えるとおで、modules ファイルを Berkeley db や GDBM のような 
 1318: @code{ndbm} インターフェースを実装したデータベースで保存することができ
 1319: ます。このオプションが使用されると、modules データベースは
 1320: @file{module.db}, @file{modules} と/もしくは @file{modules.dir} に保存
 1321: されます。
 1322: @c I think fileattr also will use the database stuff.
 1323: @c Anything else?
 1324: 
 1325: いろいろな管理ファイルの意味に関する情報は @ref{Administrative files}
 1326: を参照してください。
 1327: 
 1328: @node Working directory storage
 1329: @section リポジトリでのデータの保存方法
 1330: 
 1331: @c FIXME: Somewhere we should discuss timestamps (test
 1332: @c case "stamps" in sanity.sh).  But not here.  Maybe
 1333: @c in some kind of "working directory" chapter which
 1334: @c would encompass the "Builds" one?  But I'm not sure
 1335: @c whether that is a good organization (is it based on
 1336: @c what the user wants to do?).
 1337: 
 1338: @cindex CVS directory, in working directory
 1339: しばしば表面に現れてくるかもしれない @sc{cvs} の内部についての話をして
 1340: いる間に、@sc{cvs} が作業ディレクトリの @file{CVS} ディレクトリに何を
 1341: 入れるかも話した方が良いでしょう。リポジトリと同様に、@sc{cvs} がこの
 1342: 情報を扱い、普通は @sc{cvs} のコマンドを通してだけそれを使用します。で
 1343: も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター
 1344: フェース の @code{jCVS} や emacs のための @code{VC} パッケージなどの他
 1345: のプログラムがそれを見る必要があるかもしれません。そのようなプログラム
 1346: は、上で書いたプログラムやコマンド行 @sc{cvs} クライアントの将来のバー
 1347: ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望
 1348: むなら、この節の推奨規格に従う必要があります。
 1349: 
 1350: @file{CVS} ディレクトリには複数のファイルがあります。このディレクトリ
 1351: を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在
 1352: するけれどここで説明されていないファイルは静かに無視するのが望ましいで
 1353: す。
 1354: 
 1355: ファイルは使用しているシステムのテキストファイルの習慣に従って保存され
 1356: ます。これはテキストファイルの補完の習慣が違うシステム間では作業ディレ
 1357: クトリは可搬性が無いということです。これは意図的になされていて、おそら
 1358: く CVS で管理されているファイル自体がそのようなシステム間では可搬性が
 1359: ないであろう、という理由に基づいています。
 1360: 
 1361: @table @file
 1362: @item Root
 1363: このファイルは @ref{Specifying a repository} で説明されているように、
 1364: 現在の @sc{cvs} のルートを保持しています。
 1365: 
 1366: @cindex Repository file, in CVS directory
 1367: @cindex CVS/Repository file
 1368: @item Repository
 1369: このファイルは現在のディレクトリが対応するリポジトリでのディレクトリを
 1370: 保持しています。指定は絶対パス名と相対パス名のどちらでも可能です。
 1371: @sc{cvs} は少なくともバージョン 1.3 くらいから両方の形式を読み込む能力
 1372: を備えています。相対パスはルートからの相対位置で、より賢い方法ですが、
 1373: 絶対パス名は非常によく使われており、実装は両方を受け付けることが望まれ
 1374: ます。例えば、以下のコマンドの後で
 1375: 
 1376: @example
 1377: cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
 1378: @end example
 1379: 
 1380: @file{Root} は以下のようになり
 1381: 
 1382: @example
 1383: :local:/usr/local/cvsroot
 1384: @end example
 1385: 
 1386: @file{Repository} は
 1387: 
 1388: @example
 1389: /usr/local/cvsroot/yoyodyne/tc
 1390: @end example
 1391: 
 1392: @noindent
 1393:  1394: 
 1395: @example
 1396: yoyodyne/tc
 1397: @end example
 1398: 
 1399: @noindent
 1400: のどちらかになります。
 1401: 
 1402: 特定の作業ディレクトリがリポジトリのディレクトリに対応しなければ、
 1403: @file{Repository} は @file{CVSROOT/Emptydir} になっているはずです。
 1404: 
 1405: @cindex Entries file, in CVS directory
 1406: @cindex CVS/Entries file
 1407: @item Entries
 1408: このファイルは作業ディレクトリ中のファイルとディレクトリの一覧を挙げて
 1409: います。
 1410: 各行の最初の文字はそれがどんな行かを示します。将来の拡張ができるように、
 1411: 文字を認識できない場合は、ファイルを読み込んでいるファイルは暗黙にその
 1412: 行を飛ばすことが望まれます。
 1413: 
 1414: 最初の文字が @samp{/} であれば、様式は:
 1415: 
 1416: @example
 1417: /@var{name}/@var{revision}/@var{timestamp}[+@var{conflict}]/@var{options}/@var{tagdate}
 1418: @end example
 1419: 
 1420: で、@samp{[} と @samp{]} は登録の一部ではありませんが、その代わりに 
 1421: @samp{+} と衝突の印は省略任意であることを示しています。@var{name} はディ
 1422: レクトリ中のファイルの名前です。@var{revision} は作業中のファイルの元
 1423: のリビジョンで、@samp{0} の場合は追加されたファイル、@samp{-} の後にリ
 1424: ビジョンは削除されたファイルです。@var{timestamp} は @sc{cvs} がファイ
 1425: ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の
 1426: 修正時刻と違えば、ファイルは修正されたということです。それは ISO C
 1427: astime() 関数で使われる様式で保存されます (例えば、@samp{Sun Apr 7
 1428: 01:29:26 1996})。ファイルが常に修正されていると見なされるように、例え
 1429: ば、@samp{Result of merge} のようにその様式とは違う文字列を書くかもし
 1430: れません。これは特別な場合ではありません。ファイルが修正されたかどうか
 1431: を調べるために、プログラムはファイルのタイムスタンプを単純に 
 1432: @var{timestamp} と文字列比較をするべきです。衝突があれば、
 1433: @var{conflict} は、ファイルが衝突の印とともに書き込まれた後でファイル
 1434: の修正時刻に設定することができます (@pxref{Conflicts example})。 もし 
 1435: @var{conflict} がその後も実際の修正時刻と同じであるなら、ユーザは明か
 1436: に衝突を解消していません。@var{options} は貼り付けられたオプションを保
 1437: 持しています (例えば、バイナリ・ファイルのための @samp{-kbd})。
 1438: @var{tagdate} は @samp{T} の後にタグ名が続いているか、日付 (date) の 
 1439: @samp{D} で、貼り付けられたタグか日付がつづいているかのどちらかを保持
 1440: しています。@var{timestamp} が単独のタイムスタンプではなく、スペースで
 1441: 分離されたタイムスタンプの対であるなら、@sc{cvs} 1.5 より前のバージョ
 1442: ンの @sc{cvs} を扱っているということに注意してください (ここでは説明さ
 1443: れていません)。
 1444: 
 1445: CVS/Entries のタイムスタンプの標準時 (ローカルもしくは共通時) はオペレー
 1446: ティングシステムがファイル自身のタイムスタンプとして保存するものと同じ
 1447: である必要があります。例えば、Unix ではファイルのタイムスタンプは共通
 1448: 時刻 (UT) ですので、CVS/Entries のタイムスタンプもそうなっているべきで
 1449: す。@sc{vms} ではファイルのタイムスタンプはローカル時刻なので、
 1450: @sc{vms} 上の @sc{cvs} はローカル時刻を使うべきです。この規則は、標準
 1451: 時が変わったためだけでファイルが修正されたようにならないためです (例え
 1452: ば、サマータイムになったり、それが終わったときなどです)。
 1453: @c See comments and calls to gmtime() and friends in
 1454: @c src/vers_ts.c (function time_stamp).
 1455: 
 1456: @file{Entries} の行の最初の文字が @samp{D} であると、それはサブディレ
 1457: クトリを現しています。行が @samp{D} だけのときは、 @file{Entries} ファ
 1458: イルを書いたプログラムはサブディレクトリを記録したということを現します 
 1459: (ですから、そのような行があって、他に @samp{D} で始まる行がなければ、
 1460: サブディレクトリがないことがわかります)。そうでなければ、行は次のよう
 1461: になっています:
 1462: 
 1463: @example
 1464: D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
 1465: @end example
 1466: 
 1467: ここで @var{name} はサブディレクトリの名前であり、将来の拡張のために、
 1468: 全ての @var{filler} 部分は暗黙の内に無視されるべきです。@code{Entries} 
 1469: を修正するプログラムはこれらの部分を保存するのが望まれています。
 1470: 
 1471: ファイル @file{Entries} 中の行はどんな順番でも構いません。
 1472: 
 1473: @cindex Entries.Log file, in CVS directory
 1474: @cindex CVS/Entries.Log file
 1475: @item Entries.Log
 1476: このファイルは @file{Entries} に無いさらなる情報を記録することはありま
 1477: せんが、@file{Entries} ファイル全体を再書き込みすることなく、情報を更
 1478: 新するための方法をもたらし、その中には @file{Entries} と 
 1479: @file{Entries.Log} を書いているプログラムが不意に異常終了しても情報を
 1480: 保護する機能もあります。@file{Entries} ファイルを読み込むプログラムは
 1481: @file{Entries.Log} も調べるべきです。後者が存在すれば、@file{Entries} 
 1482: を読み込んで、@file{Entries.Log} にある変更を適用すべきです。変更を適
 1483: 用した後で、@file{Entries} を再度書き込んで、@file{Entries} を消去する
 1484: 習慣が推奨されています。@file{Entries.Log} の行の様式は、単独文字コマ
 1485: ンドがあり、その後にスペースが続き、その後は @file{Entries} の行に指定
 1486: された様式になります。単独文字コマンドは登録が追加されたことを示す
 1487: @samp{A} と登録が消去されたことを示す @samp{R} か、@file{Entries} の登
 1488: 録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2
 1489: 番目の文字が @file{Entries.Log} の行の2番目の文字がスペースでないと、
 1490: それは @sc{cvs} の古いバージョンで書かれています (ここでは説明されてい
 1491: ません)。
 1492: 
 1493: 読み込みではなく、書き込みをしているプログラムは、もし望むならば
 1494: @file{Entries.Log} ファイルを安全に無視することもできます。
 1495: 
 1496: @cindex Entries.Backup file, in CVS directory
 1497: @cindex CVS/Entries.Backup file
 1498: @item Entries.Backup
 1499: これは一時ファイルです。推奨された使用法は、新しい Entriy ファイルを 
 1500: @file{Entries.Backup} に書き、それから @file{Entries} に改名する (もし
 1501: 可能なら原子的操作で) ことです。
 1502: 
 1503: @cindex Entries.Static file, in CVS directory
 1504: @cindex CVS/Entries.Static file
 1505: @item Entries.Static
 1506: このファイルが関連する唯一のことはそれが存在するか否か、ということです。
 1507: もし存在すると、ディレクトリの一部分だけが取得されていて、@sc{cvs} は
 1508: そのディレクトリに追加のファイルを作成しないということです。それを消去
 1509: するためには、@code{update} コマンドを @samp{-d} オプションとともに使っ
 1510: てください。そうすれば、追加のファイルを取得して、
 1511: @file{Entries.Static} を消去します。
 1512: @c FIXME: This needs to be better documented, in places
 1513: @c other than Working Directory Storage.
 1514: @c FIXCVS: The fact that this setting exists needs to
 1515: @c be more visible to the user.  For example "cvs
 1516: @c status foo", in the case where the file would be
 1517: @c gotten except for Entries.Static, might say
 1518: @c something to distinguish this from other cases.
 1519: @c One thing that periodically gets suggested is to
 1520: @c have "cvs update" print something when it skips
 1521: @c files due to Entries.Static, but IMHO that kind of
 1522: @c noise pretty much makes the Entries.Static feature
 1523: @c useless.
 1524: 
 1525: @cindex Tag file, in CVS directory
 1526: @cindex CVS/Tag file
 1527: @cindex Sticky tags/dates, per-directory
 1528: @cindex Per-directory sticky tags/dates
 1529: @item Tag
 1530: このファイルはディレクトリごとの貼り付いたタグを保持します。最初の文字
 1531: は枝のタグには @samp{T}、枝でないタグは @samp{N}、日付は @samp{D} にな
 1532: り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ
 1533: の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付
 1534: は新規に追加されたファイルに適用されること等に使用されることに注意して
 1535: ください。貼り付きタグと日付に関する一般的な情報は @ref{Sticky tags} 
 1536: を参照してください。
 1537: @c FIXME: This needs to be much better documented,
 1538: @c preferably not in the context of "working directory
 1539: @c storage".
 1540: @c FIXME: The Sticky tags node needs to discuss, or xref to
 1541: @c someplace which discusses, per-directory sticky
 1542: @c tags and the distinction with per-file sticky tags.
 1543: 
 1544: @cindex Checkin.prog file, in CVS directory
 1545: @cindex CVS/Checkin.prog file
 1546: @cindex Update.prog file, in CVS directory
 1547: @cindex CVS/Update.prog file
 1548: @item Checkin.prog
 1549: @itemx Update.prog
 1550: これらのファイルはそれぞれ modules ファイルの @samp{-i} と @samp{-u}
 1551: オプションで指定されたプログラムを保存します。
 1552: 
 1553: @cindex Notify file, in CVS directory
 1554: @cindex CVS/Notify file
 1555: @item Notify
 1556: このファイルはまだサーバに送信されていない通知 (例えば、@code{edit} や 
 1557: @code{unedit} のため) を保存します。書式はまだここでは説明されていませ
 1558: ん。
 1559: 
 1560: @cindex Notify.tmp file, in CVS directory
 1561: @cindex CVS/Notify.tmp file
 1562: @item Notify.tmp
 1563: このファイルと @file{Notify} の関係は @file{Entries.Backup} と 
 1564: @file{Entries} の関係と同じです。即ち、@file{Notify} を書くためにはま
 1565: ず新しい内容を @file{Notify.tmp} に書き、それから (可能であれば自動的
 1566: に) それを @file{Notify} に改名します。
 1567: 
 1568: @cindex Base directory, in CVS directory
 1569: @cindex CVS/Base directory
 1570: @item Base
 1571: 監視を使用していると、@code{edit} コマンドはファイルの元のコピーを 
 1572: @file{Base} ディレクトリに保存します。これで、サーバと通信できないとき
 1573: でさえ @code{unedit} コマンドが実行できるようになります。
 1574: 
 1575: @cindex Baserev file, in CVS directory
 1576: @cindex CVS/Baserev file
 1577: @item Baserev
 1578: このファイルは @file{Base} ディレクトリのそれぞれのファイルのリビジョ
 1579: ンを一覧にします。書式は:
 1580: 
 1581: @example
 1582: B@var{name}/@var{rev}/@var{expansion}
 1583: @end example
 1584: 
 1585: で、@var{expansion} は将来の拡張のために、無視されるべきものです。
 1586: 
 1587: @cindex Baserev.tmp file, in CVS directory
 1588: @cindex CVS/Baserev.tmp file
 1589: @item Baserev.tmp
 1590: このファイルと @file{Baserev} の関係は @file{Entries.Backup} と
 1591: @file{Entries} との関係と同じです。即ち、@file{Baserev} に書くために、
 1592: まず新しい内容を @file{Baserev.tmp} に書き、それから (もし可能なら自動
 1593: 的に) それを @file{Baserev} に改名します。
 1594: 
 1595: @cindex Template file, in CVS directory
 1596: @cindex CVS/Template file
 1597: @item Template
 1598: このファイルには @file{rcsinfo} ファイルで指定された雛型が入っています
 1599: (@pxref{rcsinfo})。それはクライアントだけに使われます。非クライアント/
 1600: サーバ型 @sc{cvs} は直接 @file{rcsinfo} ファイルを調べます。
 1601: @end table
 1602: 
 1603: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1604: @node Intro administrative files
 1605: @section 管理用ファイルの紹介
 1606: @cindex Administrative files (intro)
 1607: @cindex Modules file
 1608: @cindex CVSROOT, module name
 1609: @cindex Defining modules (intro)
 1610: 
 1611: @c FIXME: this node should be reorganized into "general
 1612: @c information about admin files" and put the "editing
 1613: @c admin files" stuff up front rather than jumping into
 1614: @c the details of modules right away.  Then the
 1615: @c Administrative files node can go away, the information
 1616: @c on each admin file distributed to a place appropriate
 1617: @c to its function, and this node can contain a table
 1618: @c listing each file and a @ref to its detailed description.
 1619: 
 1620: @file{$CVSROOT/CVSROOT} には、いくつか @dfn{管理用ファイル} 
 1621: (@dfn{administrative files}) があります。完全な説明は 
 1622: @xref{Administrative files}. これらのファイルが無く
 1623: ても @sc{cvs} を使用することができます。しかし、少なくとも 
 1624: @file{modules} というファイルが適切に設定してあれば @sc{cvs} のコマン
 1625: ドはうまく働きます。
 1626: 
 1627: 管理用ファイルの中で、
 1628: 最も重要なファイルは @file{modules} です。
 1629: これはリポジトリの中の全てのモジュールを定義しています。
 1630: @file{modules} ファイルの例を次に示します。
 1631: 
 1632: @c FIXME: The CVSROOT line is a goofy example now that
 1633: @c mkmodules doesn't exist.
 1634: @example
 1635: CVSROOT         CVSROOT
 1636: modules         CVSROOT modules
 1637: cvs             gnu/cvs
 1638: rcs             gnu/rcs
 1639: diff            gnu/diff
 1640: tc              yoyodyne/tc
 1641: @end example
 1642: 
 1643: @file{modules} ファイルは行ごとに意味を持つファイルです。
 1644: @file{modules} ファイルの各行はそれぞれ、
 1645: モジュール名, 空白, モジュールのあるディレクトリ名
 1646: という書式で記述されます。
 1647: モジュールのあるディレクトリ名は、
 1648: @code{$CVSROOT} からの相対パスです。
 1649: @file{modules} ファイルの各行はそれぞれ、
 1650: モジュール名, 空白, モジュールのあるディレクトリ名
 1651: という書式で記述されます。
 1652: モジュールのあるディレクトリ名は、
 1653: @code{$CVSROOT} からの相対パスです。
 1654: 上の例の最後の4行はそのような行の例です。
 1655: 
 1656: @c FIXME: might want to introduce the concept of options in modules file
 1657: @c (the old example which was here, -i mkmodules, is obsolete).
 1658: 
 1659: モジュール @samp{modules} を定義する行については、
 1660: ここでは説明しません。
 1661: より詳しい説明は @ref{modules} 参照。
 1662: 
 1663: @c FIXME: subsection without node is bogus
 1664: @subsection 管理用ファイルの編集
 1665: @cindex Editing administrative files
 1666: @cindex Administrative files, editing them
 1667: 
 1668: 管理用ファイルは、
 1669: 他のモジュールと同じ方法で編集します。
 1670: @samp{cvs checkout CVSROOT} を用いて作業コピーを取り出して、
 1671: 編集し、通常通り変更内容を格納します。
 1672: 
 1673: 間違いのある管理用ファイルを格納することも可能です。
 1674: このような場合には、間違いを正して新たなリビジョンを登録します。
 1675: しかし管理用ファイルに深刻な間違いがあれば、
 1676: 新たなリビジョンの登録さえも不可能になります。
 1677: @c @xref{Bad administrative files} for a hint
 1678: @c about how to solve such situations.
 1679: @c -- administrative file checking--
 1680: 
 1681: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1682: @node Multiple repositories
 1683: @section 複数のリポジトリ
 1684: @cindex Multiple repositories
 1685: @cindex Repositories, multiple
 1686: @cindex Many repositories
 1687: @cindex Parallel repositories
 1688: @cindex Disjoint repositories
 1689: @cindex CVSROOT, multiple repositories
 1690: 
 1691: 特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ
 1692: のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ
 1693: ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変
 1694: 数 @code{$CVSROOT} で設定するか、@sc{cvs} のオプション @samp{-d} に指
 1695: 定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に @sc{cvs} 
 1696: に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ
 1697: けです。
 1698: 
 1699: 複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。
 1700: @sc{cvs} バージョン 1.10 では、単独のコマンドは違うリポジトリのディレ
 1701: クトリを再帰的に辿ることはできません。開発バージョンの @sc{cvs} では、
 1702: 複数のサーバから作業ディレクトリに取り出すことがでます。@sc{cvs} は要
 1703: 求されたコマンドを実行するために必要であれば、再帰的に動作し、対応する
 1704: 数のサーバ・マシンに接続するという細い作業全部を扱います。
 1705: 以下は作業ディレクトリを設定する例です:
 1706: 
 1707: @example
 1708: cvs -d server1:/cvs co dir1
 1709: cd dir1
 1710: cvs -d server2:/root co sdir
 1711: cvs update
 1712: @end example
 1713: 
 1714: @code{cvs co} コマンドは作業ディレクトリを設定し、それから @code{cvs
 1715: update} コマンドは server2 に接続し、dir1/sdir サブディレクトリを更新
 1716: し、その他のものを更新するために server1 に接続します。
 1717: @c FIXME: Does the FAQ have more about this?  I have a
 1718: @c dim recollection, but I'm too lazy to check right now.
 1719: 
 1720: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1721: @node Creating a repository
 1722: @section リポジトリの作成
 1723: 
 1724: @cindex Repository, setting up
 1725: @cindex Creating a repository
 1726: @cindex Setting up a repository
 1727: 
 1728: @sc{cvs} リポジトリを設定するために、まずソースファイルのリビジョン履
 1729: 歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも
 1730: のですので、たいていのマシンは十分なはずです。詳細は @ref{Server
 1731: requirements} を参照してください。
 1732: @c Possible that we should be providing a quick rule of
 1733: @c thumb, like the 32M memory for the server.  That
 1734: @c might increase the number of people who are happy
 1735: @c with the answer, without following the xref.
 1736: 
 1737: ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを
 1738: 移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、
 1739: バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ
 1740: ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに
 1741: なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは
 1742: ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同
 1743: じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、
 1744: 全体の木かそれの一部分のどちらかになります)。
 1745: 
 1746: リポジトリはサーバ経由からか直接 @sc{cvs} を使う全てのマシンからか、
 1747: (直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に
 1748: する必要があります。クライアントのマシンは @sc{cvs} プロトコル経由以外
 1749: でそれにアクセス可能である必要はありません。@sc{cvs} は、リポジトリに
 1750: ロック・ファイルを作成する必要があるため (@pxref{Concurrency})、利用者
 1751: が読み込み許可しか持たないリポジトリを、@sc{cvs} から使うことはできま
 1752: せん。
 1753: 
 1754: @cindex init (subcommand)
 1755: リポジトリを作成するときには、@code{cvs init} コマンドを実行して下さい。
 1756: 通常の方法で指定された @sc{cvs} のルート (@pxref{Repository}) 以下の、
 1757: 空のリポジトリを利用できるように整えます。例えば次のようにします。
 1758: 
 1759: @example
 1760: cvs -d /usr/local/cvsroot init
 1761: @end example
 1762: 
 1763: @code{cvs init} は注意深いので、リポジトリに存在するファイルを上書きし
 1764: ません。従って既に利用できる状態のリポジトリに対して @code{cvs init} 
 1765: を実行しても、何の不都合もありません。
 1766: 
 1767: @code{cvs init} は、操作履歴を記録するように設定します。
 1768: もしこれを望まないのであれば、@code{cvs init} を実行した後に、
 1769: @file{history} ファイルを削除して下さい。@xref{history file}.
 1770: 
 1771: @node Backing up
 1772: @section リポジトリのバックアップ
 1773: @cindex Repository, backing up
 1774: @cindex Backing up, repository
 1775: 
 1776: リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん
 1777: どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき
 1778: 点も幾つかあります。
 1779: 
 1780: @cindex Locks, cvs, and backups
 1781: @cindex #cvs.rfl, and backups
 1782: 最初の点は偏執的で、バックアップ中には @sc{cvs} を使用しないか、バック
 1783: アップ中はバックアッププログラムに @sc{cvs} をロックさせる必要がありま
 1784: す。@sc{cvs} を使わないために、リポジトリを操作できるマシンへのログイ
 1785: ンを禁止したり、@sc{cvs} サーバを停止したり、同様な機構を利用するかも
 1786: しれません。詳細はあなたのオペレーティングシステムと、@sc{cvs} を設定
 1787: した方法に依存します。@sc{cvs} をロックするためには、@file{#cvs.rfl} 
 1788: ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう
 1789: に言ってきましたが、これらの事前注意をせずにただバックアップを行なって
 1790: も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元
 1791: すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること
 1792: が非常に難しいということは無いでしょう。
 1793: 
 1794: リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時
 1795: から変更されていると仮定すると、失敗に影響を受けあかったディレクトリは
 1796: 今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし
 1797: れません。そのようなディレクトリで @sc{cvs} を実行しようとすると、普通
 1798: はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す
 1799: 方法の一つに以下のようなものがあります:
 1800: 
 1801: @itemize @bullet
 1802: @item
 1803: 新しい作業ディレクトリを取得します。
 1804: 
 1805: @item
 1806: 失敗前に作業ディレクトリからファイルをコピーします (もちろん、
 1807: @file{CVS} ディレクトリの内容をコピーしないでください)。
 1808: 
 1809: @item
 1810: 新しい作業ディレクトリで作業をし、@code{cvs update} や @code{cvs diff} 
 1811: のようなコマンドを使って何が変更されたかを見つけ、準備がでいたなら、変
 1812: 更をリポジトリに格納します。
 1813: @end itemize
 1814: 
 1815: @node Moving a repository
 1816: @section リポジトリの移動
 1817: @cindex Repository, moving
 1818: @cindex Moving a repository
 1819: @cindex Copying a repository
 1820: 
 1821: リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く
 1822: 似ているように、リポジトリを別の場所に移動する必要があるときも、それは
 1823: 他のファイルの集合を移動するのと非常に良く似ています。
 1824: 
 1825: 主に考慮することは、作業ディレクトリがリポジトリを指しているか、という
 1826: ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し
 1827: い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ
 1828: クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような
 1829: 何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作
 1830: 業ディレクトリを再利用したいなら、@file{CVS/Repository} ファイルを手で
 1831: 手術することで可能です。@file{CVS/Repository}  と @file{CVS/Root} ファ
 1832: イルの情報は @ref{Working  directory storage} で参照することができます
 1833: が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。
 1834: @c FIXME: Surgery on CVS/Repository should be avoided
 1835: @c by making RELATIVE_REPOS the default.
 1836: @c FIXME-maybe: might want some documented way to
 1837: @c change the CVS/Root files in some particular tree.
 1838: @c But then again, I don't know, maybe just having
 1839: @c people do this in perl/shell/&c isn't so bad...
 1840: 
 1841: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1842: @node Remote repositories
 1843: @section 別のマシンのリポジトリ
 1844: @cindex Repositories, remote
 1845: @cindex Remote repositories
 1846: @cindex Client/Server Operation
 1847: @cindex Server, CVS
 1848: 
 1849: ソースの作業コピーはリポジトリと別のマシンに存在することができます。
 1850: @sc{cvs} をこの方法で使うことは @dfn{クライアント/サーバ}
 1851: (@dfn{client/server}) 操作として知られています。@dfn{クライアント} と
 1852: して、@sc{cvs} を作業ディレクトリを mount できるマシンで @sc{cvs} を実
 1853: 行し、@dfn{サーバ} となる、リポジトリを mount できるマシンと通信するよ
 1854: うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式
 1855: が以下のようになることを除き、ローカルのものを使うのと同じです:
 1856: 
 1857: @example
 1858: :@var{method}:@var{user}@@@var{hostname}:/path/to/repository
 1859: @end example
 1860: 
 1861: どれが本当に設定する必要があるかは、サーバに接続している方法に依って変
 1862: わります。
 1863: 
 1864: @var{method} が指定されず、リポジトリ名に @samp{:} が含まれる場合には、
 1865: 使用するオペレーティングシステムに依って @code{ext} か @code{server} 
 1866: が既定値とされます。詳しくは @ref{Connecting via rsh} 参照。
 1867: @c Should we try to explain which platforms are which?
 1868: @c Platforms like unix and VMS, which only allow
 1869: @c privileged programs to bind to sockets <1024 lose on
 1870: @c :server:
 1871: @c Platforms like Mac and VMS, whose rsh program is
 1872: @c unusable or nonexistent, lose on :ext:
 1873: @c Platforms like OS/2 and NT probably could plausibly
 1874: @c default either way (modulo -b troubles).
 1875: 
 1876: @c FIXME: We need to have a better way of explaining
 1877: @c what method to use.  This presentation totally
 1878: @c obscures the fact that :ext: and CVS_RSH is the way to
 1879: @c use SSH, for example.  Plus it incorrectly implies
 1880: @c that you need an @code{rsh} binary on the client to use
 1881: @c :server:.
 1882: @c Also note that rsh not pserver is the right choice if you want
 1883: @c users to be able to create their own repositories
 1884: @c (because of the --allow-root related issues).
 1885: @menu
 1886: * Server requirements::         サーバのためのメモリと他の資源
 1887: * Connecting via rsh::          接続に @code{rsh} プログラムを利用する
 1888: * Password authenticated::      パスワードを利用して直接接続する
 1889: * GSSAPI authenticated::        GSSAPI を利用して直接接続する
 1890: * Kerberos authenticated::      ケルベロスを利用して直接接続する
 1891: * Connecting via fork::         接続に fork された @code{cvs server}を使う
 1892: @end menu
 1893: 
 1894: @node Server requirements
 1895: @subsection サーバの要求
 1896: 
 1897: サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は
 1898: こじんまりとしたものであるということです---32M のメモリやそれ以下のサー
 1899: バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。
 1900: @c Say something about CPU speed too?  I'm even less sure
 1901: @c what to say on that subject...
 1902: 
 1903: もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の
 1904: 見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分
 1905: が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで
 1906: ないものがあれば、この説明文書を更新できるように、@ref{BUGS} に書かれ
 1907: ているように、我々に知らせてください)。
 1908: 
 1909: 大量のメモリ消費をする最初の部分は、@sc{cvs} サーバを使っているときの
 1910: 大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための
 1911: 2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ
 1912: ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー
 1913: ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな
 1914: るか、2メガバイトほどかどちらか大きいものになることが予想されています。
 1915: @c "two megabytes" of course is SERVER_HI_WATER.  But
 1916: @c we don't mention that here because we are
 1917: @c documenting the default configuration of CVS.  If it
 1918: @c is a "standard" thing to change that value, it
 1919: @c should be some kind of run-time configuration.
 1920: @c
 1921: @c See cvsclient.texi for more on the design decision
 1922: @c to not have locks in place while waiting for the
 1923: @c client, which is what results in memory consumption
 1924: @c as high as this.
 1925: 
 1926: それぞれの @sc{cvs} サーバの大きさを予想上の一度に活動するサーバ数で掛
 1927: けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい
 1928: ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ
 1929: リでしょう。
 1930: @c Has anyone verified that notion about swap space?
 1931: @c I say it based pretty much on guessing that the
 1932: @c ->text of the struct buffer_data only gets accessed
 1933: @c in a first in, first out fashion, but I haven't
 1934: @c looked very closely.
 1935: 
 1936: @c What about disk usage in /tmp on the server?  I think that
 1937: @c it can be substantial, but I haven't looked at this
 1938: @c again and tried to figure it out ("cvs import" is
 1939: @c probably the worst case...).
 1940: 
 1941: 大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの
 1942: @code{diff} です。これはバイナリ・ファイルでさえも必要です。大体の目安
 1943: は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が
 1944: 適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を
 1945: するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ 
 1946: でなければ、@sc{cvs} を実行しているマシン) に100メガバイトのメモリがあ
 1947: るのが良いです。これは物理メモリでなく、スワップであるかもしれません。
 1948: メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ
 1949: れるときのためのメモリを準備する必要は特にありません。
 1950: @c The 5-10 times rule of thumb is from Paul Eggert for
 1951: @c GNU diff.  I don't think it is in the GNU diff
 1952: @c manual or anyplace like that.
 1953: @c
 1954: @c Probably we could be saying more about
 1955: @c non-client/server CVS.
 1956: @c I would guess for non-client/server CVS in an NFS
 1957: @c environment the biggest issues are the network and
 1958: @c the NFS server.
 1959: 
 1960: クライアントの資源消費はさらに少ないです---オペレーティングシステムを
 1961: 動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。
 1962: @c Is that true?  I think the client still wants to
 1963: @c (bogusly) store entire files in memory at times.
 1964: 
 1965: ディスク容量に対する要求の情報は、@ref{Creating a repository} を参照し
 1966: てください。
 1967: 
 1968: @node Connecting via rsh
 1969: @subsection rsh で接続する
 1970: 
 1971: @cindex rsh
 1972: CVS はこれらの操作を実行するために @file{rsh} プロトコルを用いますので、
 1973: 遠隔側の使用者のホストはローカルの使用者の接続を許可する
 1974: @file{.rhosts} を持つ必要があります。
 1975: 
 1976: 例えば、あなたがローカルマシン @file{toe.example.com} の利用者
 1977: @file{mozart} であり、サーバマシンは @file{faun.example.org} であると
 1978: しましょう。faun では、以下の行を @file{bach} のホームディレクトリ
 1979: の @file{.rhosts} ファイルに書いてください:
 1980: 
 1981: @example
 1982: toe.example.com  mozart
 1983: @end example
 1984: 
 1985: そして、@code{rsh} の動作を次の行で確認します。
 1986: 
 1987: @example
 1988: rsh -l bach faun.example.org 'echo $PATH'
 1989: @end example
 1990: 
 1991: @cindex CVS_SERVER, environment variable
 1992: 次に @code{rsh} が、
 1993: サーバを発見できるかどうか確認する必要があります。
 1994: 上記の例で @code{rsh} が表示したパスの中に、
 1995: サーバである @code{cvs} のあるディレクトリが
 1996: 含まれているかどうか確認して下さい。
 1997: @file{.login} や @file{.profile} でなく、
 1998: @file{.bashrc}, @file{.cshrc} 等に
 1999: パスを設定する必要があります。
 2000: 代わりに、クライアント側で環境変数 @code{CVS_SERVER} に、
 2001: @file{/usr/local/bin/cvs-1.6} などと、
 2002: 使用したいサーバ名を設定できます。
 2003: @c FIXME: there should be a way to specify the
 2004: @c program in CVSROOT, not CVS_SERVER, so that one can use
 2005: @c different ones for different roots.  e.g. ":server;cvs=cvs-1.6:"
 2006: @c instead of ":server:".
 2007: 
 2008: @file{inetd.conf} を編集したり、
 2009: @sc{cvs} のサーバ・デーモンを走らせる必要はありません。
 2010: 
 2011: @cindex :server:, setting up
 2012: @cindex :ext:, setting up
 2013: @cindex Kerberos, using kerberized rsh
 2014: @cindex SSH (rsh replacement)
 2015: @cindex rsh replacements (Kerberized, SSH, &c)
 2016: @code{rsh} 経由で @code{CVSROOT} を利用するときに
 2017: 指定できる接続経路は二つあります。
 2018: @code{:server:} を指定した場合、
 2019: @sc{cvs} が内部実装した @code{rsh} のクライアントが用いられますが、
 2020: 移植版では利用できないものもあります。
 2021: @code{:ext:} を指定した場合、外部の @code{rsh} プログラムが用いられます。
 2022: @code{rsh} が既定となっていますが、
 2023: サーバを利用できる他のプログラムを呼び出す場合は、
 2024: 環境変数 @code{CVS_RSH} に設定して下さい 
 2025: (例えば HP-UX 9 では、
 2026: @code{rsh} は何か別のものなので @code{remsh} を用いて下さい)。
 2027: 指定するプログラムは、データを変更しないで送受信できなくてはいけません。
 2028: 例えば Windows NT の @code{rsh} は、
 2029: 既定では @t{CRLF} を @t{LF} に換えるので不適当です。
 2030: @sc{cvs} の OS/2 版はこれを回避するため、
 2031: @code{rsh} に @samp{-b} を渡して切り抜けていますが、
 2032: 標準的な @code{rsh} でないプログラムを黙認する形になるので、
 2033: 将来は別のやり方になるでしょう。
 2034: @code{CVS_RSH} に @code{SSH} 等の @code{rsh} の代替物を設定した場合、
 2035: この節の残りの @file{.rhosts} の使用説明などは、
 2036: おそらく不適当でしょうから、
 2037: 各 @code{rsh} の代替物の文書資料を参照して下さい。
 2038: @c FIXME: there should be a way to specify the
 2039: @c program in CVSROOT, not CVS_RSH, so that one can use
 2040: @c different ones for different roots.  e.g. ":ext;rsh=remsh:"
 2041: @c instead of ":ext:".
 2042: @c See also the comment in src/client.c for rationale
 2043: @c concerning "rsh" being the default and never
 2044: @c "remsh".
 2045: 
 2046: 例を続けます。仮に @file{faun.example.org} の
 2047: リポジトリ @file{/usr/local/cvsroot/} 中の
 2048: モジュール @file{foo} を利用したい場合には、
 2049: もう準備はできています:
 2050: 
 2051: @example
 2052: cvs -d :ext:bach@@faun.example.org:/usr/local/cvsroot checkout foo
 2053: @end example
 2054: 
 2055: (クライアント側とサーバ側で、使用者名が同じ場合には、
 2056: @file{bach@@} を省略することが出来ます。)
 2057: 
 2058: @c Should we mention "rsh host echo hi" and "rsh host
 2059: @c cat" (the latter followed by typing text and ^D)
 2060: @c as troubleshooting techniques?  Probably yes
 2061: @c (people tend to have trouble setting this up),
 2062: @c but this kind of thing can be hard to spell out.
 2063: 
 2064: @node Password authenticated
 2065: @subsection パスワード認証による直接接続
 2066: 
 2067: @sc{cvs} のクライアントは、
 2068: パスワード・プロトコルを用いて、
 2069: サーバと接続することもできます。
 2070: この方法は、
 2071: @code{rsh} の使用が可能でなく 
 2072: (例えばサーバが防火壁の向こうにある場合)、
 2073: またケルベロスも利用できない場合に特に有効です。
 2074: 
 2075: この方法を使用するために、
 2076: サーバとクライアント双方での調整が必要になります。
 2077: 
 2078: @menu
 2079: * Password authentication server::     サーバ側の設定
 2080: * Password authentication client::     クライアントの使用
 2081: * Password authentication security::   この方法が何をして何をしないか
 2082: @end menu
 2083: 
 2084: @node Password authentication server
 2085: @subsubsection パスワード認証のためのサーバの設定
 2086: 
 2087: まず最初に、@file{$CVSROOT} と @file{$CVSROOT/CVSROOT} ディレクトリの
 2088: 使用許可をきつくすることを考えるでしょう。詳細は @ref{Password
 2089: authentication security} を参照してください。
 2090: 
 2091: @cindex pserver (subcommand)
 2092: @cindex Password server, setting up
 2093: @cindex Authenticating server, setting up
 2094: @c FIXME: this isn't quite right regarding port
 2095: @c numbers; CVS looks up "cvspserver" in
 2096: @c /etc/services (on unix, but what about non-unix?).
 2097: サーバ側では @file{/etc/inetd.conf} を編集する必要があります。
 2098: 正しいポートに接続を受けた時、
 2099: @code{inetd} がコマンド @code{cvs pserver} を実行する様に変更します。
 2100: ポート番号の既定値は 2401 ですが、
 2101: クライアントをコンパイルした時に、
 2102: @code{CVS_AUTH_PORT} に他の値を定義した場合には異なります。
 2103: 
 2104: あなたの使用する @code{inetd} が、
 2105: ポート番号を素のまま @file{/etc/inetd.conf} に書いて良いならば、
 2106: 次の記述で十分でしょう 
 2107: (@file{inetd.conf} には一行で記述して下さい):
 2108: 
 2109: @example
 2110: 2401  stream  tcp  nowait  root  /usr/local/bin/cvs
 2111: cvs -f --allow-root=/usr/cvsroot pserver
 2112: @end example
 2113: 
 2114: @samp{-T} オプションで一時ファイルを作成するディレクトリも指定できます。
 2115: 
 2116: @samp{--allow-root} オプションは使用可能な @sc{cvsroot} ディレクトリを
 2117: 指定します。違う @sc{cvsroot} ディレクトリの使用を試みるクライアントは
 2118: 接続できません。許可したい @sc{cvsroot} ディレクトリが2つ以上あるなら、
 2119: オプションを繰り返してください。(不幸なことに、@code{inetd} の多くのバー
 2120: ジョンはコマンドと引数の両方、もしくはどちらかの長さ全体に対して非常に
 2121: 小さくなるように制限を課しています。この問題に対する普通の解決は、
 2122: @code{inetd} に @sc{cvs} を必要な引数と共に起動するシェルスクリプトを
 2123: 実行させることです。)
 2124: 
 2125: あなたの使用する @code{inetd} が、
 2126: 素のポート番号ではなく、サービス名を要求するならば、
 2127: @file{/etc/services} に次の行を追加して下さい:
 2128: 
 2129: @example
 2130: cvspserver      2401/tcp
 2131: @end example
 2132: 
 2133: そして @file{inetd.conf} には、
 2134: @code{2401} ではなく @code{cvspserver} と記述して下さい。
 2135: 
 2136: 以上を注意して行なった後、
 2137: @code{inetd} を再起動するか、
 2138: 初期設定ファイルを再読させるのに必要な処置を取って下さい。
 2139: 
 2140: これの設定に問題があるときは、@ref{Connection} を参照してください。
 2141: 
 2142: @cindex CVS passwd file
 2143: @cindex passwd (admin file)
 2144: クライアントはパスワードを平文のまま保存または伝送します 
 2145: (ほぼそのように---詳細は @ref{Password authentication security})。
 2146: 従って、リポジトリを利用する時に、
 2147: 正規のパスワードを危険に曝さないために、
 2148: @sc{cvs} では普通は別のパスワードファイルを使用します。
 2149: このファイルは @file{$CVSROOT/CVSROOT/passwd} です。
 2150: 欄が少ないことを除けば、Unix システムでの @file{/etc/passwd} と同様に
 2151: コロンで分割した書式を使います:
 2152: @sc{cvs} 使用者名、省略可能なパスワード、認証が成功したかのように
 2153: 実行するためにサーバが使用する任意に省略可能な使用者名です。
 2154: 次に5つの登録がある @file{passwd} ファイルを例示します:
 2155: 
 2156: @example
 2157: anonymous:
 2158: bach:ULtgRLXo7NRxs
 2159: spwang:1sOp854gDF3DY
 2160: melissa:tGX1fS8sun6rY:pubcvs
 2161: qproj:XR4EZcEs0szik:pubcvs
 2162: @end example
 2163: 
 2164: パスワードは、標準 Unix の関数 @code{crypt()} によって暗号化されます。
 2165: 従って、標準 Unix の @file{/etc/passwd} から直接コピーすることも可能です。
 2166: 
 2167: 例の最初の行は使用者 @code{anonymous} として認証しようとする全ての 
 2168: @sc{cvs} クライアントに空パスワードなど、パスワードに関わらず、使用を
 2169: 許可します。(これは匿名読み込み専用アクセスを許可するサイトでよく
 2170: することです。"読み込み専用" の方法は @ref{Read-only access} を参照し
 2171: てください。)
 2172: 
 2173: 2行目と3行目は @code{bach} と @code{spwang} がそれぞれ平文のパスワード
 2174: を提供した場合にアクセスを許可します。
 2175: 
 2176: @cindex User aliases
 2177: 4行目は @code{mellisa} が正しいパスワードを使用したときにアクセスを許
 2178: 可しますが、彼女の @sc{cvs} での操作はサーバではシステムユーザ 
 2179: @code{pubcvs} として行われます。ですから、@code{melissa} という名前の
 2180: システム使用者は必要ではありませんが、@code{pubcvs} という名前の使用者
 2181: は存在している必要が@emph{あります}。
 2182: 
 2183: 5行目はシスステムユーザは共有できることを示しています。@code{qproj} と
 2184: して認証を成功した全てのクライアントは @code{melissa} と同様に、実際は
 2185: @code{pubcvs} でして実行します。そのようにすることで、リポジトリ中にそ
 2186: れぞれのプロジェクトごとに単独の共有ユーザを作成することができ、それぞ
 2187: れの開発者に @file{$CVSROOT/CVSROOT/passwd} ファイルで専用の行を与える
 2188: ことができます。それぞれの行の @sc{cvs} 使用者名は違うかもしれませんが、
 2189: システムの使用者名は同じです。別の @sc{cvs} 使用者名を使う理由は、CVS
 2190: は操作をそれらの名前で記録するからです: @code{melissa} が変更をプロジェ
 2191: クトに書き込むと、その格納はプロジェクトの履歴に @code{pubcvs} ではな
 2192: く、@code{melissa} の名前で記録されます。システムのユーザ名を共有する
 2193: 理由は、リポジトリの該当する部分の使用許可を、そのアカウントのみが書き
 2194: 込み許可を持つように設定することができるからです。
 2195: 
 2196: CVS はシステム認証を行なうこともできます。
 2197: パスワード認証では、まずサーバが、@file{$CVSROOT/CVSROOT/passwd} 
 2198: ファイル中の、使用者のエントリを確認します。
 2199: 使用者のエントリがあれば、そのエントリを上で説明された様に
 2200: 認証に使用します。
 2201: ユーザを発見できないか、@sc{cvs} の @file{passwd} ファイルが
 2202: 存在しない場合には、オペレーティングシステムの使用者の調査機構を
 2203: 使って使用者名とパスワードとの認証を試すことができます。
 2204: (この失敗時の動作は @file{config} ファイルで @code{SystemAuth=no} を
 2205: 設定することで、使用不能にすることができます)。
 2206: しかしながら、システムの認証に立ち戻ることは安全性の面で
 2207: 危険を冒すことになるかもしれないことには注意してください:
 2208: @sc{cvs} の操作はそのユーザの普通のログインパスワードで認証され、
 2209: パスワードはネットワークを平文で流れます。詳しくは @ref{Password
 2210: authentication security} を参照してください。
 2211: 
 2212: 現在、
 2213: @sc{cvs} の @file{passwd} ファイルにパスワードを加えるには、
 2214: 他のどこかからコピーするしか方法がありません。
 2215: いつの日か @code{cvs passwd} コマンドができることでしょう。
 2216: 
 2217: @file{$CVSROOT/CVSROOT} の多くのファイルと違って、@file{passwd} ファイ
 2218: ルは @sc{cvs} 経由ではなく、直接編集するのが普通です。
 2219: これは@file{passwd} ファイルが作業コピーに含まれているセキュリティの
 2220: 危険性のためです。@file{passwd} ファイルを @file{$CVSROOT/CVSROOT} を
 2221: チェックアウトに含めたい場合は @ref{checkoutlist} を参照してください。
 2222: @c We might also suggest using the @code{htpasswd} command
 2223: @c from freely available web servers as well, but that
 2224: @c would open up a can of worms in that the users next
 2225: @c questions are likely to be "where do I get it?" and
 2226: @c "how do I use it?"
 2227: @c Also note that htpasswd, at least the version I had,
 2228: @c likes to clobber the third field.
 2229: 
 2230: @node Password authentication client
 2231: @subsubsection パスワード認証によるクライアントの使用
 2232: @cindex Login (subcommand)
 2233: @cindex Password client, using
 2234: @cindex Authenticated client, using
 2235: @cindex :pserver:, setting up
 2236: @sc{cvs} コマンドをパスワード認証サーバを通じて遠隔リポジトリで実行
 2237: するためには、@code{pserver} プロトコル、使用者名、リポジトリのホスト、
 2238: リポジトリへのパスを指定します。例えば:
 2239: 
 2240: @example
 2241: cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot checkout someproj
 2242: @end example
 2243: 
 2244: もしくは、
 2245: 
 2246: @example
 2247: CVSROOT=:pserver:bach@@faun.example.org:/usr/local/cvsroot
 2248: cvs checkout someproj
 2249: @end example
 2250: 
 2251: しかし、全員に使用可能なリポジトリ (すなわち、使用者名がパスワードを要
 2252: 求しないもの) でない限り、最初に @dfn{ログイン} しなければなりません。
 2253: ログインはリポジトリのパスワードを認証します。これは @code{login} コマ
 2254: ンドで行われ、対話的にパスワード認証を促します。
 2255: 
 2256: @example
 2257: cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot login
 2258: CVS password:
 2259: @end example
 2260: 
 2261: パスワードを入力し終わると、@sc{cvs} がサーバで認証します。認証が成功
 2262: すれば、その使用者名、ホスト、リポジトリ、パスワードが永久に記録されま
 2263: す。ですから、将来のリポジトリでの通信は @code{cvs login} の実行を要求
 2264: しません。(認証が失敗すれば、@sc{cvs} はパスワードが正しくないことを言っ
 2265: た後終了し、何も記録されません。)
 2266: 
 2267: 既定では、登録はファイル @file{$HOME/.cvspass} に保存されます。ファ
 2268: イルの形式は人間が読めるもので、ある程度人間が編集可能でもありますが、
 2269: パスワードは平文で保存されているのではないことは注意してください---そ
 2270: れらは "純真な" 侵入 (つまり、システム管理者や他の悪意のない人間が不
 2271: 注意に見るといった事) を防ぐため、簡単な符号化がされています。
 2272: 
 2273: @cindex CVS_PASSFILE, environment variable
 2274: このファイルの既定の場所を @code{CVS_PASSFILE} 環境変数を設定すること
 2275: で変更することができます。
 2276: この変数を使用するのであれば、
 2277: @code{cvs login} を実行する@emph{前に}設定しなければいけません。
 2278: @code{cvs login} を実行した後に設定した場合、
 2279: その後の @sc{cvs} コマンドは、
 2280: サーバに送るパスワードを見付けられません。
 2281: 
 2282: 一度ログインをすると、その遠隔リポジトリを使う全ての @sc{cvs} のコマン
 2283: ドは保存されたパスワードで認証します。ですから、例えば
 2284: 
 2285: @example
 2286: cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot checkout foo
 2287: @end example
 2288: 
 2289: はそのまま動作します (サーバ側でパスワードが変更されない限り。その場合
 2290: は @code{cvs login} をもう一度実行する必要があります)。
 2291: 
 2292: リポジトリ指定中に @samp{:pserver} が存在していなければ、@sc{cvs} は変
 2293: わりに @code{rsh} で接続すると仮定することに気を付けてください
 2294: (@pxref{Connecting via rsh})。
 2295: 
 2296: もちろん、一度作業コピーを取り出してそこから @sc{cvs} のコマンドを実行
 2297: していれば、明示的にリポジトリを指定する必要は無くなります。というのは、
 2298: @sc{cvs} は作業コピーの @file{CVS} サブディレクトリから導き出すことが
 2299: できるからです。
 2300: 
 2301: @c FIXME: seems to me this needs somewhat more
 2302: @c explanation.
 2303: @cindex Logout (subcommand)
 2304: 任意の遠隔リポジトリのパスワードは @code{cvs logout} コマン
 2305: ドを使用すると @code{CVS_PASSFILE} から消去できます。
 2306: 
 2307: @node Password authentication security
 2308: @subsubsection パスワード認証における安全性の考察
 2309: 
 2310: @cindex Security, of pserver
 2311: パスワードは、
 2312: 平文を簡単に符号化してクライアント側に保存されており、
 2313: 送信の際も同じ符号化が用いられます。
 2314: この符号化は、パスワードが偶然見られること (すなわちシステム管理者が
 2315: 不注意に見てしまう事) を防ぐためのもので、
 2316: 素人の攻撃からパスワードの取得を防ぐことさえ出来ません。
 2317: 
 2318: @c FIXME: The bit about "access to the repository
 2319: @c implies general access to the system is *not* specific
 2320: @c to pserver; it applies to kerberos and SSH and
 2321: @c everything else too.  Should reorganize the
 2322: @c documentation to make this clear.
 2323: @sc{cvs} 独自のパスワードファイルにより 
 2324: (@pxref{Password authentication server})、
 2325: リポジトリを利用する時には、
 2326: システムにログインする時とは別のパスワードが使用できます。
 2327: しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、
 2328: 多様な方法により、サーバ上でプログラムが実行可能になります。
 2329: つまりリポジトリの利用は、
 2330: かなり広範囲にシステムが利用できる事を暗示しています。
 2331: これを防止するように @sc{cvs} を修正する事は可能でしょうが、
 2332: これを書いている時点までには誰もやっていません。
 2333: @c OpenBSD uses chroot() and copies the repository to
 2334: @c provide anonymous read-only access (for details see
 2335: @c http://www.openbsd.org/anoncvs.shar).  While this
 2336: @c closes the most obvious holes, I'm not sure it
 2337: @c closes enough holes to recommend it (plus it is
 2338: @c *very* easy to accidentally screw up a setup of this
 2339: @c type).
 2340: 
 2341: @file{$CVSROOT/CVSROOT} ディレクトリには @file{passwd} と他のセキュリ
 2342: ティを調べるために使われるファイルがあるので、このディレクトリの使用許
 2343: 可をを @file{/etc} と同じくらいきつくしなければならないことに注意して
 2344: ください。同じことが @file{$CVSROOT} ディレクトリそのものと、木のそれ
 2345: より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ
 2346: クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが
 2347: できます。これらの使用許可は普通は pserver を使っていないときに使用す
 2348: るものよりもきついものであることに注意してください。
 2349: @c TODO: Would be really nice to document/implement a
 2350: @c scheme where the CVS server can run as some non-root
 2351: @c user, e.g. "cvs".  CVSROOT/passwd would contain a
 2352: @c bunch of entries of the form foo:xxx:cvs (or the "cvs"
 2353: @c would be implicit).  This would greatly reduce
 2354: @c security risks such as those hinted at in the
 2355: @c previous paragraph.  I think minor changes to CVS
 2356: @c might be required but mostly this would just need
 2357: @c someone who wants to play with it, document it, &c.
 2358: 
 2359: 要約すると、
 2360: パスワードを得た人物は誰でもリポジトリを利用できます
 2361: (これはまたある程度通常のシステム利用も可能になるということを含むかも
 2362: しれません。)
 2363: ネットワークのパケットを漁ったり、
 2364: 保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、
 2365: 全ての人物がパスワードを入手可能です。
 2366: あなたが本物の安全を望むのならば、ケルベロスにしましょう。
 2367: 
 2368: @node GSSAPI authenticated
 2369: @subsection GSSAPI による直接接続
 2370: 
 2371: @cindex GSSAPI
 2372: @cindex Security, GSSAPI
 2373: @cindex :gserver:, setting up
 2374: @cindex Kerberos, using :gserver:
 2375: GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般
 2376: 的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、
 2377: @sc{cvs} を GSSAPI で認証して、直接 @sc{tcp} 接続を通して接続すること
 2378: ができます。
 2379: 
 2380: これをするためには、@sc{cvs} が GSSAPI サポート付きでコンパイルされて
 2381: いる必要があります。@sc{cvs} を configure しているときに、ケルベロス 
 2382: version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま
 2383: す。構築するために @file{--with-gssapi} も使用できます。
 2384: 
 2385: 接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認
 2386: 証@emph{されません}。ストリームの認証を要求するためには、広域オプショ
 2387: ン @code{-a} を使用する必要があります。
 2388: 
 2389: 既定状態では、データ転送は暗号化@emph{されません}。
 2390: クライアントとサーバ双方を、
 2391: 暗号化を有効にしてコンパイルしておく必要があります。
 2392: 構築時に @file{--enable-encryption} オプションを付加して、
 2393: 暗号化機能を有効にして下さい。
 2394: また暗号化を要求するために、
 2395: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2396: 
 2397: GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ
 2398: れます。@ref{Password authentication server} 参照。ケルベロスのような
 2399: 強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ
 2400: る認証を使用不能にしたいと思うかもしれません。そのためには、空の 
 2401: @file{CVSROOT/passwd} パスワードファイルを作成して、config ファイルで 
 2402: @code{SystemAuth=no} を設定します (@pxref{config})。
 2403: 
 2404: GSSAPI サーバは cvs/@var{hostname} の主な名前を使い、@var{hostname} は
 2405: サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ
 2406: うにこれを設定しなければなりません。
 2407: 
 2408: GSSAPI を使用して接続するには、@samp{:gserver:} を使用します。例えば、
 2409: 以下のようになります。
 2410: 
 2411: @example
 2412: cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
 2413: @end example
 2414: 
 2415: @node Kerberos authenticated
 2416: @subsection ケルベロスによる直接接続
 2417: 
 2418: @cindex Kerberos, using :kserver:
 2419: @cindex Security, kerberos
 2420: @cindex :kserver:, setting up
 2421: ケルベロスを使う一番簡単な方法は @ref{Connecting via rsh} で説明されて
 2422: いるようにケルベロスの @code{rsh} を使用することです。
 2423: rsh を利用する際の主な欠点は、
 2424: 全てのデータが他のプログラムを経由する必要があるため、
 2425: 時間がかかるかもしれない事です。
 2426: もしケルベロスが導入されているならば、
 2427: ケルベロスの認証により、直接 @sc{tcp} 接続する事が可能です
 2428: 
 2429: この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関
 2430: するものです。ケルベロス バージョン5は前節で説明されているように、
 2431: GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ
 2432: うになっています。
 2433: 
 2434: このためには、
 2435: ケルベロスの支援を受けるように @sc{cvs} をコンパイルする必要があります。
 2436: @sc{cvs} は configre 時に
 2437: ケルベロスが利用できるかどうかを検出しようとしますが、
 2438: 駄目ならフラグ @file{--with-krb4} を用いて強制させることも可能です。
 2439: 
 2440: 既定状態では、データ転送は暗号化され@emph{ません}。
 2441: クライアントとサーバ双方を、
 2442: 暗号化を有効にしてコンパイルしておく必要があります。
 2443: 構築時に @file{--enable-encryption} オプションを付加して、
 2444: 暗号化機能を有効にして下さい。
 2445: また暗号化を要求するために、
 2446: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2447: 
 2448: @cindex CVS_CLIENT_PORT
 2449: サーバの @file{inetd.conf} を編集する必要があります。
 2450: クライアントが使用する既定のポート番号は 1999 です。
 2451: 他のポートを使用したい場合には、
 2452: クライアントの環境変数 @code{CVS_CLIENT_PORT} で指定して下さい。
 2453: 
 2454: @cindex kinit
 2455: @sc{cvs} を利用する前に、
 2456: 通常の方法で切符を取得して下さい (一般的には @code{kinit} です)。
 2457: この切符でサーバへのログインが許可されるはずです。
 2458: これで準備ができました:
 2459: 
 2460: @example
 2461: cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
 2462: @end example
 2463: 
 2464: ここで接続に失敗した場合、
 2465: 以前のバージョンの @sc{cvs} は rsh で再接続を試みましたが、
 2466: このバージョンでは再試行されません。
 2467: 
 2468: @node Connecting via fork
 2469: @subsection fork を通じての接続
 2470: 
 2471: @cindex fork, access method
 2472: @cindex :fork:, setting up
 2473: この接続方法で、ローカル・ディスクのリポジトリに遠隔プロトコルを使って
 2474: 接続することができます。言い換えると、それは @code{:local:} とほとんど
 2475: 同じことをしますが、変な振舞いや、バグやその他のものはローカルの
 2476: @sc{cvs} のものではなく、遠隔 @sc{cvs} のものです。
 2477: 
 2478: 毎日の作業では、@code{:local:} か @code{:fork:} を好むかは個人の好みに
 2479: 依ります。もちろん @code{:fork:} は @code{cvs} と遠隔プロトコルをデバッ
 2480: グしているときは特に役立ちます。特に、我々は他の遠隔アクセス方法のネッ
 2481: トワーク関連の設定、変更、時間切れ設定、認証全てを避けることができ、そ
 2482: の上で遠隔プロトコルを使う接続を作成することができるのです。
 2483: 
 2484: @code{fork} 方法を用いて接続するためには、@samp{:fork:} とローカルのリ
 2485: ポジトリへのパス名を使用します。例えば、:
 2486: 
 2487: @example
 2488: cvs -d :fork:/usr/local/cvsroot checkout foo
 2489: @end example
 2490: 
 2491: @cindex CVS_SERVER, and :fork:
 2492: @code{:ext:} と同様に、サーバは既定値の @samp{cvs} と呼ばれるか、
 2493: @code{CVS_SERVER} 環境変数の値になります。
 2494: 
 2495: @c ---------------------------------------------------------------------
 2496: @node Read-only access
 2497: @section 読み込み専用リポジトリ接続
 2498: @cindex Read-only repository access
 2499: @cindex readers (admin file)
 2500: @cindex writers (admin file)
 2501: 
 2502: パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める
 2503: ことができます (@pxref{Password authenticated})。 (他の接続方法は全て
 2504: リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用
 2505: 許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助
 2506: はありません。)
 2507: 
 2508: 読み込み専用接続の使用者は、特定の ``管理'' ファイル (ロックファイルや
 2509: 履歴ファイル) を除いて、リポジトリを変更しない @sc{cvs} の操作のみを実
 2510: 行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ
 2511: う (@pxref{Password authentication server})。
 2512: 
 2513: 以前のバージョンの @sc{cvs} と違って、読み込み専用使用者はリポジトリを
 2514: 読むことができるだけで、サーバのプログラムを実行できないようになってい
 2515: るはずです。そうしないと、予期しないレベルの接続を得ることができてしま
 2516: います。もしくは、より正確に言うと、@emph{既知の}穴は塞がれました。こ
 2517: の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ
 2518: リティへの関心に従って、どのような程度の注意も払うべきというのは正当の
 2519: ようです。
 2520: 
 2521: 使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除
 2522: です。
 2523: 
 2524: "包含" は、使用者を特別に @file{$CVSROOT/CVSROOT/readers} ファイルに一
 2525: 覧表示するということで、それは単純な改行で分離された利用者の一覧です。
 2526: これは @file{readers} ファイルの例です:
 2527: 
 2528: @example
 2529: melissa
 2530: splotnik
 2531: jrandom
 2532: @end example
 2533: 
 2534: (最後の使用者の後の改行を忘れないでください。)
 2535: 
 2536: "排除" は @emph{書き込み} 接続のできる人を全て明示的に一覧表示するとい
 2537: うことです---もしファイル
 2538: 
 2539: @example
 2540: $CVSROOT/CVSROOT/writers
 2541: @end example
 2542: 
 2543: @noindent
 2544: が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その
 2545: 他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相
 2546: 変らず @sc{cvs} @file{passwd} ファイルに挙げられている必要があります。)
 2547: @file{writers} ファイル は @file{readers} ファイルと同じ書式です。
 2548: 
 2549: 注意: @sc{cvs} @file{passwd} ファイルが cvs の使用者をシステムの使用者
 2550: にマップしているときは、@emph{cvs} の使用者名を使って書き込み専用接続
 2551: を拒否したり認めたりしていて、システムの使用者名を使っていないことを確
 2552: 認してください。すなわち、@file{readers} と @file{writers} ファイルに
 2553: cvs の使用者名があるということで、それはシステムの使用者名と同じかもし
 2554: れませんし、違うかもしれません。
 2555: 
 2556: これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ
 2557: の振舞いの完全な説明です。
 2558: 
 2559: @file{readers} が存在して、この使用者がそこに挙げられていれば、読み込
 2560: み専用接続になります。もしくは、@file{writers} が存在していて、使用者
 2561: がそこに挙げられていなければ読み込み専用接続になります (@file{readers}
 2562: が存在するけれど、そこには挙げられていないというときにもそのようになり
 2563: ます)。その他の場合では、完全な読み込み書き込み接続になります。
 2564: 
 2565: もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。
 2566: これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより
 2567: 多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな
 2568: ります。
 2569: 
 2570: @node Server temporary directory
 2571: @section サーバの一時ディレクトリ
 2572: @cindex Temporary directories, and server
 2573: @cindex Server, temporary directories
 2574: 
 2575: @sc{cvs} サーバは実行中に一時ディレクトリを作成します。それは
 2576: 
 2577: @example
 2578: cvs-serv@var{pid}
 2579: @end example
 2580: 
 2581: @noindent
 2582: のような名前で、@var{pid} はサーバのプロセス番号です。それらは環境変数
 2583: @code{TMPDIR} (@pxref{Environment variables})、@samp{-T} 広域オプショ
 2584: ン (@pxref{Global options})、で指定されるディレクトリもしくは、それら
 2585: がないと @file{/tmp} に置かれます。
 2586: 
 2587: ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時
 2588: ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな
 2589: い場合がいくつかあります。例えば:
 2590: 
 2591: @itemize @bullet
 2592: @item
 2593: サーバがサーバの内部エラーで異常終了すると、デバッグを助けるためにディ
 2594: レクトリを保存するかもしれません。
 2595: 
 2596: @item
 2597: サーバが後始末をできない方法で kill されたとき (主にほとんど unix での 
 2598: @samp{kill -KILL})。
 2599: 
 2600: @item
 2601: システムが、サーバに後始末をするように告げる通常のシャットダウンをする
 2602: ことなくシャットダウンしたとき。
 2603: @end itemize
 2604: 
 2605: このような場合は、手で @file{cvs-serv@var{pid}} ディレクトリを消去する
 2606: 必要があります。プロセス番号 @var{pid} で動いているサーバが無ければ、
 2607: その行為は安全です。
 2608: 
 2609: @c ---------------------------------------------------------------------
 2610: @node Starting a new project
 2611: @chapter CVS でプロジェクトを始める
 2612: @cindex Starting a project with CVS
 2613: @cindex Creating a project
 2614: 
 2615: @comment --moduledb--
 2616: ファイルの改名とディレクトリ間の移動はうまくできないので、
 2617: 新しいプロジェクトを始めるときには、
 2618: 最初にファイルの構成をよく考えておく必要があります。
 2619: ファイルの改名や移動は、
 2620: 不可能ではありませんが非常にやっかいです。
 2621: 特にディレクトリの改名に関して、
 2622: @sc{cvs} は癖のある動作をします 
 2623: (@pxref{Moving files})。
 2624: 
 2625: 次に何をするかは、始める状況に依ります。
 2626: 
 2627: @menu
 2628: * Setting up the files::        ファイルをリポジトリに加える
 2629: * Defining the module::         ファイルからモジュールを作る
 2630: @end menu
 2631: @c -- File permissions!
 2632: 
 2633: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2634: @node Setting up the files
 2635: @section ファイルの準備
 2636: 
 2637: 始めの一歩は、リポジトリ中にファイルを生成することです。
 2638: これには幾つか異なる方法があります。
 2639: 
 2640: @c -- The contributed scripts
 2641: @menu
 2642: * From files::                  既存のプロジェクトに便利な方法
 2643:                                 (既にファイルが存在する場合)
 2644: * From other version control systems::  古いプロジェクトの、他の
 2645:                                         システムでの履歴を保存する
 2646: * From scratch::                ゼロからディレクトリを作成する
 2647: @end menu
 2648: 
 2649: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2650: @node From files
 2651: @subsection 存在するファイルからディレクトリを生成する
 2652: @cindex Importing files
 2653: 
 2654: @sc{cvs} を使い始める場合に、
 2655: おそらく @sc{cvs} を使用できるプロジェクトが
 2656: 既に幾つかあるでしょう。
 2657: この場合 @code{import} コマンドを使用するのが最も簡単です。
 2658: 例を挙げて説明します。
 2659: @sc{cvs} に組み込みたいファイルが @file{@var{wdir}} にあり、
 2660: それを @file{$CVSROOT/yoyodyne/@var{rdir}} に置きたい時、
 2661: 次のようにします。
 2662: 
 2663: @example
 2664: $ cd @var{wdir}
 2665: $ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
 2666: @end example
 2667: 
 2668: @samp{-m} フラグでログ・メッセージを与えなかった場合、@sc{cvs} により
 2669: エディタが開かれ、メッセージの入力が促されます。文字列 @samp{yoyo} は 
 2670: @dfn{ベンダー・タグ}と呼ばれるものであり、
 2671: @samp{start} は@dfn{リリース・タグ}と呼ばれるもの
 2672: です。この文脈では意味をなさないかもしれませんが、@sc{cvs} はそれらの
 2673: 存在を要求します。詳しくは @xref{Tracking sources}.
 2674: 
 2675: では実際に動作したことを確かめた後、元のソースディレクトリを削除します。
 2676: @c FIXME: Need to say more about "verify that it
 2677: @c worked".  What should the user look for in the output
 2678: @c from "diff -r"?
 2679: 
 2680: @example
 2681: $ cd ..
 2682: $ mv @var{dir} @var{dir}.orig
 2683: $ cvs checkout yoyodyne/@var{dir}       # @r{下で説明}
 2684: $ diff -r @var{dir}.orig yoyodyne/@var{dir}
 2685: $ rm -r @var{dir}.orig
 2686: @end example
 2687: 
 2688: @noindent
 2689: 誤って @sc{cvs} を通さないで編集してしまわないように、下のソースを削除
 2690: すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るの
 2691: が賢明です。
 2692: 
 2693: @code{checkout} コマンドはモジュールの名前 (以前の全ての例のように)、
 2694: または @code{$CVSROOT} からの相対パス (上の例のように) を引数に取りま
 2695: す。
 2696: 
 2697: @sc{cvs} が @code{$CVSROOT} 中のディレクトリに設定した
 2698: 使用許可とグループ属性が、
 2699: 適切かどうか調べると良いでしょう。@xref{File permissions}.
 2700: 
 2701: 取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、
 2702: wrapper 機能を用いて、どのファイルがバイナリなのか
 2703: 明示するとよいでしょう。@xref{Wrappers}.
 2704: 
 2705: @c The node name is too long, but I am having trouble
 2706: @c thinking of something more concise.
 2707: @node From other version control systems
 2708: @subsection 他のバージョン管理システムからファイルを作成する
 2709: @cindex Importing files, from other version control systems
 2710: 
 2711: @sc{rcs} 等の、
 2712: 他のバージョン管理システムで保守されてきたプロジェクトがあり、
 2713: そのプロジェクトのファイルを @sc{cvs} に移管する場合、
 2714: 各ファイルの修正履歴の維持を望むでしょう。
 2715: 
 2716: @table @asis
 2717: @cindex RCS, importing files from
 2718: @item RCS から
 2719: @sc{rcs} を使用してきた場合、@sc{rcs} ファイルを見付けて下さい---
 2720: 通常 @file{foo.c} という名前のファイルには、
 2721: @file{RCS/foo.c,v} という @sc{rcs} ファイルが対応します 
 2722: (他の場所にあるかもしれませんので、
 2723: 詳細は @sc{rcs} の文書を調べて下さい)。
 2724: 次に、@sc{cvs} リポジトリに適当なディレクトリを作成して下さい。
 2725: そして @sc{cvs} リポジトリの当該ディレクトリに、
 2726: ファイルをコピーして下さい 
 2727: (リポジトリ中のファイル名は、
 2728: ソース・ファイルに @samp{,v} が付加されたものでなくてはならず、
 2729: またファイルは @file{RCS} サブディレクトリではなく、
 2730: 当該ディレクトリに直接置いて下さい)。
 2731: この例のように、@sc{cvs} コマンドを利用せず、
 2732: @sc{cvs} リポジトリを直接利用するほうが適当な場合が稀にあります。
 2733: 以上で作業コピーを新たに取り出す準備ができました。
 2734: @c Someday there probably should be a "cvs import -t
 2735: @c rcs" or some such.  It could even create magic
 2736: @c branches.  It could also do something about the case
 2737: @c where the RCS file had a (non-magic) "0" branch.
 2738: 
 2739: @sc{rcs} ファイルを @sc{cvs} に移動するときに、
 2740: ロックされていてはいけません。
 2741: ロックされている場合には、@sc{cvs} での操作に支障を来します。
 2742: @c What is the easiest way to unlock your files if you
 2743: @c have them locked?  Especially if you have a lot of them?
 2744: @c This is a CVS bug/misfeature; importing RCS files
 2745: @c should ignore whether they are locked and leave them in
 2746: @c an unlocked state.  Yet another reason for a separate
 2747: @c "import RCS file" command.
 2748: 
 2749: @c How many is "many"? Or do they just import RCS files?
 2750: @item 他のバージョン管理システムから
 2751: 多くのバージョン管理システムは、
 2752: 標準形式の @sc{rcs} ファイルを出力する機能を持っています。
 2753: これが可能ならば、@sc{rcs} ファイルを出力して、
 2754: 前項の説明に従って下さい。
 2755: 
 2756: それが駄目なら、おそらく一番良いのは他のシステムのコマンド行のインター
 2757: フェースを使って一回に一つのリビジョンを取り出し、それを @sc{cvs} に格
 2758: 納するスクリプトを書くことでしょう。下の @file{sccs2rs} スクリプトはそ
 2759: のために役に立つ例でしょう。
 2760: 
 2761: @cindex SCCS, importing files from
 2762: @item From SCCS
 2763: @item SCCS から
 2764: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2765: @file{sccs2rcs} という名前のスクリプトがあります。
 2766: これを用いて @sc{sccs} ファイルを @sc{rcs} ファイルに変換できます。
 2767: 注意: @sc{sccs} と @sc{rcs} の両方を持つマシンで実行する必要があり、
 2768: また @file{contrib} 内の他の全てと同様に動作保証はされません 
 2769: (使用者によって評価は異なるでしょう)。
 2770: 
 2771: @cindex PVCS, importing files from
 2772: @item From PVCS
 2773: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2774: @file{pvcs_to_rcs} という名前のスクリプトがあります。
 2775: これを用いて @sc{pvcs} アーカイブを @sc{rcs} ファイルに変換できます。
 2776: @sc{pvcs} と @sc{rcs} のあるマシンで実行する必要があり、
 2777: また @file{contrib} 内の他の全てと同様に動作保証はされません
 2778: (使用者によって評価は異なるでしょう)。
 2779: 詳細はスクリプト中のコメントを読んでください。
 2780: @end table
 2781: @c CMZ and/or PATCHY were systems that were used in the
 2782: @c high energy physics community (especially for
 2783: @c CERNLIB).  CERN has replaced them with CVS, but the
 2784: @c CAR format seems to live on as a way to submit
 2785: @c changes.  There is a program car2cvs which converts
 2786: @c but I'm not sure where one gets a copy.
 2787: @c Not sure it is worth mentioning here, since it would
 2788: @c appear to affect only one particular community.
 2789: @c Best page for more information is:
 2790: @c http://wwwcn1.cern.ch/asd/cvs/index.html
 2791: @c See also:
 2792: @c http://ecponion.cern.ch/ecpsa/cernlib.html
 2793: 
 2794: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2795: @node From scratch
 2796: @subsection ゼロからディレクトリを作る
 2797: 
 2798: @c Also/instead should be documenting
 2799: @c $ cvs co -l .
 2800: @c $ mkdir tc
 2801: @c $ cvs add tc
 2802: @c $ cd tc
 2803: @c $ mkdir man
 2804: @c $ cvs add man
 2805: @c etc.
 2806: @c Using import to create the directories only is
 2807: @c probably a somewhat confusing concept.
 2808: 新しいプロジェクトを始める場合、
 2809: まず次のように空のディレクトリを作ります。
 2810: 
 2811: @example
 2812: $ mkdir tc
 2813: $ mkdir tc/man
 2814: $ mkdir tc/testing
 2815: @end example
 2816: 
 2817: その後 @code{import} コマンドを使って、
 2818: リポジトリに各々の (空の) ディレクトリを登録(作成)します:
 2819: 
 2820: @example
 2821: $ cd tc
 2822: $ cvs import -m "Created directory structure" yoyodyne/@var{dir} yoyo start
 2823: @end example
 2824: 
 2825: そして @code{add} コマンドで、
 2826: ファイル (と新しいディレクトリ) を加えていきます。
 2827: 
 2828: その時、 @code{$CVSROOT} の中のファイルの使用許可が、
 2829: 正しいものかどうかを確認すると良いでしょう。
 2830: 
 2831: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2832: @node Defining the module
 2833: @section モジュールの定義
 2834: @cindex Defining a module
 2835: @cindex Editing the modules file
 2836: @cindex Module, defining
 2837: @cindex Modules file, changing
 2838: 
 2839: 二歩目は @file{modules} ファイルにモジュールの定義をする事です。
 2840: 必ずしも必要ではありませんが、
 2841: 関連するファイルやディレクトリをグループ化するのに便利です。
 2842: 
 2843: モジュールを定義する簡単な手順を示します。
 2844: 
 2845: @enumerate
 2846: @item
 2847: ファイル modules の作業コピーを取ってきます。
 2848: 
 2849: @example
 2850: $ cvs checkout CVSROOT/modules
 2851: $ cd CVSROOT
 2852: @end example
 2853: 
 2854: @item
 2855: ファイルを編集し、モジュールの定義を加えます。
 2856: 導入は @xref{Intro administrative files}.
 2857: 詳細な記述は @ref{modules} 参照。
 2858: モジュール @samp{tc} を定義するには次の行を加えます:
 2859: 
 2860: @example
 2861: tc   yoyodyne/tc
 2862: @end example
 2863: 
 2864: @item
 2865: modules ファイルに変更を格納します。
 2866: 
 2867: @example
 2868: $ cvs commit -m "Added the tc module." modules
 2869: @end example
 2870: 
 2871: @item
 2872: モジュール modules をリリースします。
 2873: 
 2874: @example
 2875: $ cd ..
 2876: $ cvs release -d CVSROOT
 2877: @end example
 2878: @end enumerate
 2879: 
 2880: @c ---------------------------------------------------------------------
 2881: @node Revisions
 2882: @chapter リビジョン
 2883: 
 2884: @sc{cvs} の多くの利用ではあまりリビジョン番号について心配する必要はあ
 2885: りません。@sc{cvs} は @code{1.1}, @code{1.2} などのような番号を割当て、
 2886: それだけが皆が知る必要のあることです。しかし、@sc{cvs} がリビジョン番
 2887: 号を割当てる方法に関してより知識を持ち、より制御したい人もいます。
 2888: 
 2889: どのリビジョンが特定のリリースになったか、などの 1 つより多くのファイ
 2890: ルを含むリビジョンの組を追いかけたいときは、@dfn{タグ} を使います。そ
 2891: れはそれぞれのファイルの数字リビジョンに割当てることのできるリビジョン
 2892: 名です。
 2893: 
 2894: @menu
 2895: * Revision numbers::            リビジョン番号の意味
 2896: * Versions revisions releases::  このマニュアルでの用語
 2897: * Assigning revisions::         リビジョンの割当て
 2898: * Tags::                        タグ--文字によるリビジョン
 2899: * Sticky tags::                 貼り付いたタグ
 2900: * Tagging the working directory::  cvs tag コマンド
 2901: * Tagging by date/tag::         cvs rtag コマンド
 2902: * Modifying tags::              タグの追加、改名、削除
 2903: * Tagging add/remove::          ファイルの追加と削除を伴うタグ
 2904: @end menu
 2905: 
 2906: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2907: @node Revision numbers
 2908: @section リビジョン番号
 2909: @cindex Revision numbers
 2910: @cindex Revision tree
 2911: @cindex Linear development
 2912: @cindex Number, revision-
 2913: @cindex Decimal revision number
 2914: @cindex Branch number
 2915: @cindex Number, branch
 2916: 
 2917: 各バージョンのファイルはそれぞれ一意な@dfn{リビジョン番号} 
 2918: (@dfn{revision number}) を持ちます。
 2919: @samp{1.1}, @samp{1.2} とか @samp{1.3.2.2} とか 
 2920: @samp{1.3.2.2.4.5} なんてのもあります。
 2921: リビジョン番号はピリオドで分けられた偶数個の十進整数です。
 2922: 初期設定ではファイルの最初のリビジョンは 1.1 で、
 2923: リビジョンが新しくなると一番右の番号が1つ増えます。
 2924: 次の絵は、新しいリビジョンを右にして少しリビジョンを図示しています。
 2925: 
 2926: @example
 2927:        +-----+    +-----+    +-----+    +-----+    +-----+
 2928:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 2929:        +-----+    +-----+    +-----+    +-----+    +-----+
 2930: @end example
 2931: 
 2932: 2 つ以上のピリオドを含む番号になることもあります。例えば、
 2933: @samp{1.3.2.2} です。そのようなリビジョンは枝のリビジョンを表します 
 2934: (@pxref{Branching and merging})。そのようなリビジョン番号は 
 2935: @ref{Branching and merging} で詳しく説明されています。
 2936: 
 2937: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2938: @node Versions revisions releases
 2939: @section バージョン、リビジョン、リリース
 2940: @cindex Revisions, versions and releases
 2941: @cindex Versions, revisions and releases
 2942: @cindex Releases, revisions and versions
 2943: 
 2944: 上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト
 2945: ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ
 2946: く @samp{4.1.1} のようなバージョン番号を付けられます。
 2947: 
 2948: バージョンには二つの意味があり、
 2949: 最初のものはこの文書で@dfn{リビジョン}と呼ばれるものです。
 2950: 二番目は@dfn{リリース}と呼ばれるものです。
 2951: 混乱を避けるために、
 2952: この文書ではなるべく@dfn{バージョン}という単語は使わないようにします。
 2953: 
 2954: @node Assigning revisions
 2955: @section リビジョンの割当て
 2956: 
 2957: @c We avoid the "major revision" terminology.  It seems
 2958: @c like jargon.  Hopefully "first number" is clear enough.
 2959: 初期設定では、@sc{cvs} は最初の番号を同じにして 2番目の番号を増加させ
 2960: ることにより数字リビジョンを割当てます。例えば、@code{1.1},
 2961: @code{1.2}, @code{1.3} のように。
 2962: 
 2963: 新しいファイルを加えるときは、2番目の番号は常に 1 で、最初の番号はその
 2964: ディレクトリの中のファイルの最初の番号の一番大きいものと等しくなります。
 2965: 例えば、現在のディレクトリの一番大きい番号が @code{1.7}, @code{3.1},
 2966: @code{4.12} であると、追加されたファイルの数字リビジョンは @code{4.1}
 2967: になります。
 2968: 
 2969: @c This is sort of redundant with something we said a
 2970: @c while ago.  Somewhere we need a better way of
 2971: @c introducing how the first number can be anything
 2972: @c except "1", perhaps.  Also I don't think this
 2973: @c presentation is clear on why we are discussing releases
 2974: @c and first numbers of numeric revisions in the same
 2975: @c breath.
 2976: 普通はリビジョン番号を気にかける必要はありません---それを @sc{cvs} が
 2977: 維持している内部番号のように扱う方が簡単で、タグは製品リリース 1 とリ
 2978: リース 2 のような間を区別するより良い手段です (@pxref{Tags})。 しかし、
 2979: 数字リビジョンを設定したいのであれば、@code{cvs commit} の @samp{-r}
 2980: オプションですることができます。@samp{-r} オプションは @samp{-f} オプ
 2981: ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
 2982: ということになります。
 2983: 
 2984: 例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな
 2985: いものも含めて)、次のように実行するかもしれません:
 2986: 
 2987: @example
 2988: $ cvs commit -r 3.0
 2989: @end example
 2990: 
 2991: @samp{-r} で指定する番号は存在するリビジョン番号より大きくなければなら
 2992: ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、
 2993: @samp{cvs commit -r 1.3} とはできないということです。複数のリリースを
 2994: 並行して維持したいときは、枝を使う必要があります (@pxref{Branching and
 2995: merging}).
 2996: 
 2997: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2998: @node Tags
 2999: @section タグ--文字によるリビジョン
 3000: @cindex Tags
 3001: 
 3002: リビジョン番号は開発に従って徐々に増えていきますが、
 3003: ソフトウェア製品のリリース番号とは全く何の関係もありません。
 3004: @sc{cvs} の使い方にもよりますが、
 3005: 異なる二つのリリースにおけるリビジョン番号は異なっているでしょう。
 3006: 例えば @sc{rcs} 5.6 を作るソース・ファイルは、
 3007: 次のようなリビジョン番号を持ちます:
 3008: @cindex RCS revision numbers
 3009: 
 3010: @example
 3011: ci.c            5.21
 3012: co.c            5.9
 3013: ident.c         5.3
 3014: rcs.c           5.12
 3015: rcsbase.h       5.11
 3016: rcsdiff.c       5.10
 3017: rcsedit.c       5.11
 3018: rcsfcmp.c       5.9
 3019: rcsgen.c        5.10
 3020: rcslex.c        5.11
 3021: rcsmap.c        5.2
 3022: rcsutil.c       5.10
 3023: @end example
 3024: 
 3025: @cindex tag, command, introduction
 3026: @cindex Tag, symbolic name
 3027: @cindex Symbolic name (tag)
 3028: @cindex Name, symbolic (tag)
 3029: @cindex HEAD, as reserved tag name
 3030: @cindex BASE, as reserved tag name
 3031: @code{tag} コマンドを使えば、
 3032: 特定のリビジョンに名前 (タグ名) を付けることができます。
 3033: 各ファイルに付けられた全てのタグと
 3034: 対応するリビジョン番号を調べたい場合は、
 3035: @code{status} コマンドに @samp{-v} フラグを付けて下さい。
 3036: タグには、大文字と小文字で始まる必要があり、大文字, 小文字, 数字,
 3037: @samp{-}, @samp{_} が使用可能です。
 3038: @code{BASE} と @code{HEAD} の二つのタグ名は、
 3039: @sc{cvs} が使用するために予約されています。
 3040: 将来使われる @sc{cvs} にとって特別な名前は、実際のタグ名との衝突を避け
 3041: るために @code{BASE} や @code{HEAD} などのような名前ではなく、例えば 
 3042: @samp{.} で始まるような特別な方法で命名されることが望まれています。
 3043: @c Including a character such as % or = has also been
 3044: @c suggested as the naming convention for future
 3045: @c special tag names.  Starting with . is nice because
 3046: @c that is not a legal tag name as far as RCS is concerned.
 3047: @c FIXME: CVS actually accepts quite a few characters
 3048: @c in tag names, not just the ones documented above
 3049: @c (see RCS_check_tag).  RCS
 3050: @c defines legitimate tag names by listing illegal
 3051: @c characters rather than legal ones.  CVS is said to lose its
 3052: @c mind if you try to use "/" (try making such a tag sticky
 3053: @c and using "cvs status" client/server--see remote
 3054: @c protocol format for entries line for probable cause).
 3055: @c TODO: The testsuite
 3056: @c should test for whatever are documented above as
 3057: @c officially-OK tag names, and CVS should at least reject
 3058: @c characters that won't work, like "/".
 3059: 
 3060: タグの命名にプログラムの名前とリリースのバージョン番号のような情報に基
 3061: いた何らかの習慣を選びたいでしょう。例えば、CVS 1.9 が @code{cvs1-9} 
 3062: という名前でタグ付けされるように、まずプログラムの名前を使い、その直後
 3063: にバージョン番号の @samp{.} を @samp{-} に変更したものを続けるかもしれ
 3064: ません。同じ習慣を続ければ、常にタグが @code{cvs-1-9} や @code{cvs1_9}
 3065: や他のものであったかを推測する必要はなくなります。taginfo ファイルでそ
 3066: の習慣を強制することさえ考えるかもしれません (@pxref{user-defined
 3067: logging}).
 3068: @c Might be nice to say more about using taginfo this
 3069: @c way, like giving an example, or pointing out any particular
 3070: @c issues which arise.
 3071: 
 3072: @cindex Adding a tag
 3073: @cindex Tag, example
 3074: 次の例は、ファイルにタグを付ける方法を示したものです。
 3075: コマンドはあなたの作業ディレクトリで実行して下さい。
 3076: すなわち、@file{backend.c} があるディレクトリでコマンドを実行すべきで
 3077: ある、ということです。
 3078: 
 3079: @example
 3080: $ cvs tag rel-0-4 backend.c
 3081: T backend.c
 3082: $ cvs status -v backend.c
 3083: ===================================================================
 3084: File: backend.c         Status: Up-to-date
 3085: 
 3086:     Version:            1.4     Tue Dec  1 14:39:01 1992
 3087:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 3088:     Sticky Tag:         (none)
 3089:     Sticky Date:        (none)
 3090:     Sticky Options:     (none)
 3091: 
 3092:     Existing Tags:
 3093:         rel-0-4                     (revision: 1.4)
 3094: 
 3095: @end example
 3096: 
 3097: @code{cvs tag} の構文の完全なまとめと、いろいろなオプションの説明は
 3098: @ref{Invoking CVS} を参照してください。
 3099: 
 3100: 単独のファイルにタグを付けるべき理由はほとんどありません。
 3101: タグの主な使い途は、
 3102: モジュールを構成する全てのファイルに同じタグを付け、
 3103: 開発の流れの重要点 (リリース時等) を示すことです。
 3104: 
 3105: @example
 3106: $ cvs tag rel-1-0 .
 3107: cvs tag: Tagging .
 3108: T Makefile
 3109: T backend.c
 3110: T driver.c
 3111: T frontend.c
 3112: T parser.c
 3113: @end example
 3114: 
 3115: (@sc{cvs} に対する引数にディレクトリを指定した場合は、
 3116: そのディレクトリに含まれる全てのファイルにタグが付けられます。
 3117: そのディレクトリ以下の全てのサブディレクトリに対しても
 3118: (再帰的に) 動作します。@xref{Recursive behavior}.)
 3119: 
 3120: @cindex Retrieving an old revision using tags
 3121: @cindex Tag, retrieving old revisions
 3122: @code{checkout} コマンドの @samp{-r} フラグに、
 3123: モジュールから取り出すリビジョンを指定します。
 3124: このフラグを用いて、
 3125: モジュール @samp{ tc} のリリース 1.0 を作るソースを、
 3126: 将来のいつでも簡単に復元することができます:
 3127: 
 3128: @example
 3129: $ cvs checkout -r rel-1-0 tc
 3130: @end example
 3131: 
 3132: @noindent
 3133: リリース時にタグを付けるようにしておけば、
 3134: 過去のリリースにバグが発見されたが最新版には無い、
 3135: という場合などに非常に便利です。
 3136: 
 3137: 任意の時間を指定してモジュールを復元することもできます。 
 3138: @xref{checkout options}. @samp{-r} をこれらのコマンドのどれかに指定す
 3139: るときは、貼り付きタグに注意する必要があります。@ref{Sticky tags} 参照。
 3140: 
 3141: 複数のファイルに同じタグを付けるという事を、
 3142: 「ファイル名とリビジョン番号の行列の中に線を引く」
 3143: と考えると良いでしょう。
 3144: 以下のリビジョンの五つのファイルがあるとしましょう:
 3145: 
 3146: @example
 3147: @group
 3148:         file1   file2   file3   file4   file5
 3149: 
 3150:         1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
 3151:         1.2*-   1.2     1.2    -1.2*-
 3152:         1.3  \- 1.3*-   1.3   / 1.3
 3153:         1.4          \  1.4  /  1.4
 3154:                       \-1.5*-   1.5
 3155:                         1.6
 3156: @end group
 3157: @end example
 3158: 
 3159: 過去の何らかの時点で、
 3160: @code{*} の付けられたバージョンにタグが付けられています。
 3161: 上図では @samp{*} の付いたリビジョンにタグが付けられています。
 3162: 仮にタグ名を「タグ付きリビジョンを結んだ紐」と考えると、
 3163: @code{checkout} の @samp{-r} は
 3164: 「紐を引くとタグ付きリビジョン全てが釣れる」などと解釈できるでしょう。
 3165: あるいはタグ付きリビジョンを水平に並べた方が、分り易いかも知れません:
 3166: 
 3167: @example
 3168: @group
 3169:         file1   file2   file3   file4   file5
 3170: 
 3171:                         1.1
 3172:                         1.2
 3173:                 1.1     1.3                       _
 3174:         1.1     1.2     1.4     1.1              /
 3175:         1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- ここを見る
 3176:         1.3             1.6     1.3              \_
 3177:         1.4                     1.4
 3178:                                 1.5
 3179: @end group
 3180: @end example
 3181: 
 3182: @node Tagging the working directory
 3183: @section 作業ディレクトリからどれをタグ付けするかを指定する
 3184: 
 3185: @cindex tag (subcommand)
 3186: 前の節の例は、どのリビジョンにタグを付けるかを選ぶ一番普通の方法を表し
 3187: ています。つまり、引数無しの @code{cvs tag} コマンドでは、@sc{cvs} は
 3188: 現在の作業ディレクトリに取り出されたリビジョンを選択します。例えば、作
 3189: 業ディレクトリの @file{backend.c} がリビジョン1.4から取り出されたので
 3190: あれば、@sc{cvs} はリビジョン1.4にタグを付けます。タグはリポジトリのリ
 3191: ビジョン1.4にすぐに適用されることに注意してくさい。タグ付けはファイル
 3192: の修正とは違いますし、まず作業ディレクトリを修正してそれから @code{cvs
 3193: commit} を実行して修正をリポジトリに送信するような他の操作とも違います。
 3194: 
 3195: @code{cvs tag} がリポジトリに作用するという事実による、もしかすると驚
 3196: くかもしれない側面に、格納されたリビジョンにタグを付けていて、それは作
 3197: 業ディレクトリにあるローカルで修正されているファイルと違うかもしれない、
 3198: というものがあります。間違ってそうしてしまわないようにするには、
 3199: @code{cvs tag} に @samp{-c} オプションを指定します。もしローカルで修正
 3200: されたファイルがあれば、@sc{cvs} はファイルをタグ付けする前にエラーを
 3201: 出し、異常終了します:
 3202: 
 3203: @example
 3204: $ cvs tag -c rel-0-4
 3205: cvs tag: backend.c is locally modified
 3206: cvs [tag aborted]: correct the above errors first!
 3207: @end example
 3208: 
 3209: @node Tagging by date/tag
 3210: @section どれにタグを付けるかを日付やリビジョンで指定する
 3211: @cindex rtag (subcommand)
 3212: 
 3213: @code{cvs rtag} コマンドは特定の日付や時間のリポジトリにタグを付けます
 3214: (もしくは最新のリビジョンにタグを付けることに使うことができます)。
 3215: @code{rtag} はリポジトリの内容に直接作用します (コマンドの前に取り出す
 3216: ことを要求しませんし、作業ディレクトリを見に行きません)。
 3217: 
 3218: 以下のオプションはタグを付ける日付やリビジョンを指定します。完全な説明
 3219: は @ref{Common options} 参照。
 3220: 
 3221: @table @code
 3222: @item -D @var{date}
 3223: @var{date} 以前の一番新しいリビジョンにタグを付けます。
 3224: 
 3225: @item -f
 3226: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒のときにだけ役に立ち
 3227: ます。合致するリビジョンが見つからなければ、(ファイルを無視する代わり
 3228: に) 一番新しいリビジョンを使います。
 3229: 
 3230: @item -r @var{tag}
 3231: 存在するタグ @var{tag} を含むファイルにのみタグを付けます。
 3232: @end table
 3233: 
 3234: @code{cvs tag} コマンドは同じ @samp{-r}, @samp{-D}, @samp{-f} オプショ
 3235: ンを使って、ファイルをリビジョンや日付により指定することもできるように
 3236: なっています。しかし、この機能はおそらくあなたが望むものではないでしょ
 3237: う。その理由は、@code{cvs tag} は与えられたタグ/日付ではなく、存在する
 3238: 作業ディレクトリに基づいてタグを付けるファイルを選ぶからです。ですから、
 3239: 普通は @code{cvs rtag} を使う方がうまくいくでしょう。例外はこのような
 3240: 場合です:
 3241: 
 3242: @example
 3243: cvs tag -r 1.4 backend.c
 3244: @end example
 3245: 
 3246: @node Modifying tags
 3247: @section タグの削除、移動、改名
 3248: 
 3249: @c Also see:
 3250: @c  "How do I move or rename a magic branch tag?"
 3251: @c in the FAQ (I think the issues it talks about still
 3252: @c apply, but this could use some sanity.sh work).
 3253: 
 3254: 普通はタグを修正しません。それはリポジトリの履歴を記録するために存在し
 3255: ており、削除したり意味を変えたりすることは、普通は望むことではないでしょ
 3256: う。
 3257: 
 3258: しかし、一時的にタグを使用したり、偶然に間違った場所に付けてしまったり
 3259: する場合もあるでしょう。ですから、タグを削除、移動、改名するかもしれま
 3260: せん。警告: この節のコマンドは危険です。それは履歴情報を永遠に捨て去り、
 3261: エラーからの復帰が難しくなるか、不可能になります。あなたが @sc{cvs} の
 3262: 管理者なら、これらのコマンドを taginfo で制限することを考えるかもしれ
 3263: ません (@pxref{user-defined logging})。
 3264: 
 3265: @cindex Deleting tags
 3266: @cindex Removing tags
 3267: @cindex Tags, deleting
 3268: タグを削除するには、@samp{-d} オプションを @code{cvs tag} か
 3269: @code{rtag} に指定します。例えば:
 3270: 
 3271: @example
 3272: cvs rtag -d rel-0-4 tc
 3273: @end example
 3274: 
 3275: はモジュール @code{tc} からタグ @code{rel-0-4} を削除します。
 3276: 
 3277: @cindex Moving tags
 3278: @cindex Tags, moving
 3279: @dfn{移動} とは、同じ名前を違うリビジョンを指すようにすることです。例
 3280: えば、@code{stable} タグは現時点で @file{backend.c} のリビジョン1.4を
 3281: 指しており、おそらくそれをリビジョン1.6を指すようにしたいと思っている
 3282: かもしれません。タグを移動するには、@samp{-F} オプションを @code{cvs
 3283: tag} か@code{cvs rtag} に指定します。例えば、今書いた作業は以下のもの
 3284: で達成できます:
 3285: 
 3286: @example
 3287: cvs tag -r 1.6 -F stable backend.c
 3288: @end example
 3289: 
 3290: @cindex Renaming tags
 3291: @cindex Tags, renaming
 3292: タグの @dfn{改名} とは、違った名前を古いタグと同じリビジョンを指すよう
 3293: にすることです。例えば、タグ名の綴りを間違えて、修正したいと思っている
 3294: かもしれません (できれば他の人が古い綴りに頼る前に)。タグを改名するた
 3295: めには、まず @samp{-r} オプションを @code{cvs rtag} に与えて新しいタグ
 3296: を作り、それから古い名前を削除します。これは新しいタグを古いタグと全く
 3297: 同じファイルにつけることになります。例えば:
 3298: 
 3299: @example
 3300: cvs rtag -r old-name-0-4 rel-0-4 tc
 3301: cvs rtag -d old-name-0-4 tc
 3302: @end example
 3303: 
 3304: @node Tagging add/remove
 3305: @section タグ付けとファイルの追加、削除
 3306: 
 3307: タグ付けがどのようにファイルの追加と削除と関連して動作するかの正確な議
 3308: 題は少し複雑です。たいていの場合、@sc{cvs} はファイルが存在したかどう
 3309: かをたいして苦労することなく追い掛けることができます。既定では、タグは
 3310: タグ付けされたリビジョンに対応するファイルだけに適用されます。ファイル
 3311: がまだ存在していないか、既に削除されていると、単にタグを省略し、
 3312: @sc{cvs} はタグが無いものは、そのタグではファイルが存在しないという意
 3313: 味に扱うことを知っています。
 3314: 
 3315: ところが、これは少し情報を失います。例えば、ファイルが追加されて、それ
 3316: から削除されたとしましょう。そして、タグがそのファイルになければ、その
 3317: タグがファイルの追加前のときか、削除の後かどちらを参照するかを知る方法
 3318: はありません。@samp{-r} オプションを @code{cvs rtag} に指定すれば、
 3319: @sc{cvs} は削除されたファイルにタグを付け、この問題を回避することがで
 3320: きます。例えば、先頭のリビジョンにタグを付けるために @code{-r HEAD} を
 3321: 指定するかもしれません。
 3322: 
 3323: ファイルの追加と削除という題に関して、@code{cvs rtag} コマンドには他の
 3324: 方法ではタグ付けされない、削除されたファイルのタグを消去する @samp{-a} 
 3325: オプションがあります。例えば、タグを移動しているときに @samp{-F} と共
 3326: に指定するでしょう。@samp{-a} 無しでタグを移動すれば、削除されたファイ
 3327: ルはファイルが削除されたという事実を反映せずに、まだ古いリビジョンを参
 3328: 照しているでしょう。私は上に書いてあるように @samp{-r} が指定されてい
 3329: るときはこれは必要ではないと思います。
 3330: 
 3331: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3332: @node Sticky tags
 3333: @section 貼り付いたタグ
 3334: @cindex Sticky tags
 3335: @cindex Tags, sticky
 3336: 
 3337: @c A somewhat related issue is per-directory sticky
 3338: @c tags (see comment at CVS/Tag in node Working
 3339: @c directory storage); we probably want to say
 3340: @c something like "you can set a sticky tag for only
 3341: @c some files, but you don't want to" or some such.
 3342: 
 3343: 作業コピーのリビジョンには関連した追加のデータがあることがあります。例
 3344: えば、枝であったり (@pxref{Branching and merging})、@samp{checkout -D}
 3345: か @samp{update -D} によって特定の日時より前のバージョンに制限されてい
 3346: るかもしれません。このデータは永続しますので -- すなわち、作業コピーの
 3347: 残りのコマンドに適用されます -- 我々はそれを @dfn{貼り付けられた} と表
 3348: 現しました。
 3349: 
 3350: たいていの場合、貼り付きは考える必要のない @sc{cvs} の隠れた側面です。
 3351: しかし、この機能を使いたくないとしても、貼り付けられたタグに関して 
 3352: @emph{何か} 知る必要があるかもしれません (例えば、それを避ける方法!).
 3353: 
 3354: @dfn{貼り付いたタグ} (@dfn{sticky tag}) や日付を調べるには、
 3355: @code{status} コマンドを使用します:
 3356: 
 3357: @example
 3358: $ cvs status driver.c
 3359: ===================================================================
 3360: File: driver.c          Status: Up-to-date
 3361: 
 3362:     Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
 3363:     RCS Version:        1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
 3364:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3365:     Sticky Date:        (none)
 3366:     Sticky Options:     (none)
 3367: 
 3368: @end example
 3369: 
 3370: @cindex Resetting sticky tags
 3371: @cindex Sticky tags, resetting
 3372: @cindex Deleting sticky tags
 3373: 作業ファイルに貼り付いたタグは、
 3374: @samp{cvs update -A} を使って削除するまで残ります。
 3375: オプション @samp{-A} は、ファイルを幹の先頭のバージョンに戻し、
 3376: 貼り付いたタグ, 日付, オプションを全て剥します。
 3377: 
 3378: @cindex Sticky date
 3379: 貼り付けられたタグの一番普通の使用法は、@ref{Accessing branches} で説
 3380: 明されているようにどの枝で作業しているかを確認することです。しかし、枝
 3381: でない貼り付きタグにも利用法はあります。
 3382: ここでは、他人の変更が安定しているかどうか分らないので、
 3383: 作業ディレクトリを更新したくない場合を例に挙げて考えます。
 3384: もちろんこの場合、@code{cvs update} の実行を控えれば済みます。
 3385: しかし、更新したくないのが大きなツリー構造の一部分だけならば、
 3386: そこにリビジョンを貼り付ければ良いのです。
 3387: ソースを取り出す際に (1.4 などと) リビジョンを指定すれば、
 3388: そのリビジョンを貼り付けることができます。
 3389: 以後、@samp{cvs update -A} によってタグを剥がすまで、
 3390: @code{cvs update} を実行しても
 3391: 最新リビジョンに更新されることはありません。
 3392: 同様にオプション @samp{-D} を @code{update} や @code{checkout} に使うと、
 3393: @dfn{貼り付いた日付} (@dfn{sticky date}) が設定され、
 3394: これ以降のコマンドにその日付が与えられます。
 3395: 
 3396: 古いバージョンのファイルを取り出す際に、
 3397: タグを貼り付けたくない場合も多いと思います。
 3398: @code{checkout} や @code{update} にオプション @samp{-p} を付けると、
 3399: ファイルの内容が標準出力に送られるので、これを利用します。
 3400: 例えば:
 3401: 
 3402: @example
 3403: $ cvs update -p -r 1.1 file1 >file1
 3404: ===================================================================
 3405: Checking out file1
 3406: RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
 3407: VERS: 1.1
 3408: ***************
 3409: $
 3410: @end example
 3411: 
 3412: しかし、あなたの尋ねていることが前の格納に戻す (この例では、
 3413: @file{file1} をリビジョン1.1であったときに戻す) 方法なら、これが一番簡
 3414: 単な方法ではありません。その場合は @code{update -j} オプションを
 3415: @code{update} に付けるのが良いでしょう。さらなる議論は、@ref{Merging
 3416: two revisions} 参照。
 3417: 
 3418: @c ---------------------------------------------------------------------
 3419: @node Branching and merging
 3420: @chapter 枝とマージ
 3421: @cindex Branching
 3422: @cindex Merging
 3423: @cindex Copying changes
 3424: @cindex Main trunk and branches
 3425: @cindex Revision tree, making branches
 3426: @cindex Branches, copying changes between
 3427: @cindex Changes, copying between branches
 3428: @cindex Modifications, copying between branches
 3429: 
 3430: CVS では変更を @dfn{枝} (@dfn{branch}) として知られる別の開発ラインに
 3431: 分けることができます。枝のファイルを変更しても、その変更は幹や他の枝に
 3432: は現れません。
 3433: 
 3434: 後程、@dfn{マージ} (@dfn{merging}) によって変更をある枝から別の枝 (も
 3435: しくは幹) に移動することができます。マージはまず @code{cvs update -j}
 3436: を実行して、変更を作業ディレクトリに混ぜることから始まります。それから
 3437: そのリビジョンを格納することができ、こうして効果的に変更を別の枝にコピー
 3438: することができます。
 3439: 
 3440: @menu
 3441: * Branches motivation::         枝は何の役に立つか
 3442: * Creating a branch::           枝の作成
 3443: * Accessing branches::          枝の更新と取り出し
 3444: * Branches and revisions::      枝はリビジョン番号に反映される
 3445: * Magic branch numbers::        魔法の枝番号
 3446: * Merging a branch::            枝全体をマージする
 3447: * Merging more than once::      枝から何度もマージする
 3448: * Merging two revisions::       二つのリビジョン間の差分をマージする
 3449: * Merging adds and removals::   ファイルが追加/削除された場合はどうか?
 3450: * Merging and keywords::        キーワード置換による衝突を回避する
 3451: @end menu
 3452: 
 3453: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3454: @node Branches motivation
 3455: @section 枝は何の役に立つか
 3456: @cindex Branches motivation
 3457: @cindex What branches are good for
 3458: @cindex Motivation for branches
 3459: 
 3460: @c FIXME: this node mentions one way to use branches,
 3461: @c but it is by no means the only way.  For example,
 3462: @c the technique of committing a new feature on a branch,
 3463: @c until it is ready for the main trunk.  The whole
 3464: @c thing is generally speaking more akin to the
 3465: @c "Revision management" node although it isn't clear to
 3466: @c me whether policy matters should be centralized or
 3467: @c distributed throughout the relevant sections.
 3468: tc のリリース 1.0 ができたとしましょう。tc の開発を継続していて、数ヶ
 3469: 月の間にリリース 1.1 を作成する計画を立てています。しばらくして、顧客
 3470: が致命的なバグについて文句を言ってくるようになりました。リリース 1.0を
 3471: 取り出し (@pxref{Tags})、バグを見つけました (結局些細な修正に終わりま
 3472: した)。しかし、ソースの現在のリビジョンは流動的で、少くとも1ヶ月は安定
 3473: しない状態です。最新のソースに基づくバグ修正リリースはとても作成できま
 3474: せん。
 3475: 
 3476: この様な状況でするべきことは tc のリリース 1.0 の全てのファイルのリビ
 3477: ジョンツリーに基づく @dfn{枝} (@dfn{branch}) を作成することです。そう
 3478: すれば幹の邪魔をすることなく枝に修正を加えることができます。修正が終わっ
 3479: たときに、幹に取り込むか、枝に残しておくかを選択することができます。
 3480: 
 3481: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3482: @node Creating a branch
 3483: @section 枝の作成
 3484: @cindex Creating a branch
 3485: @cindex Branch, creating a
 3486: @cindex tag, creating a branch using
 3487: @cindex rtag, creating a branch using
 3488: 
 3489: @code{tag -b} で枝を作成することができます。例えば、作業コピーのところ
 3490: にいるとしましょう:
 3491: 
 3492: @example
 3493: $ cvs tag -b rel-1-0-patches
 3494: @end example
 3495: 
 3496: @c FIXME: we should be more explicit about the value of
 3497: @c having a tag on the branchpoint.  For example
 3498: @c "cvs tag rel-1-0-patches-branchpoint" before
 3499: @c the "cvs tag -b".  This points out that
 3500: @c rel-1-0-patches is a pretty awkward name for
 3501: @c this example (more so than for the rtag example
 3502: @c below).
 3503: 
 3504: これは作業コピーの現在のリビジョンに基づいた枝を別に作成し、その枝に名
 3505: 前 @samp{rel-1-0-patches} を割当てます。
 3506: 
 3507: 枝はリポジトリに作成されているのであって、作業コピーに作成されているの
 3508: ではないということを理解することは重要です。上記の例の様に、現在のリビ
 3509: ジョンに基づいた枝を作成することは、自動的に作業コピーを新しい枝に切り
 3510: 換えることは @emph{しません}。それをする方法に関する情報は 
 3511: @ref{Accessing branches} を参照してください。
 3512: 
 3513: @code{rtag} を使って、作業コピーへの参照無しに枝を作ることもできます:
 3514: 
 3515: @example
 3516: $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
 3517: @end example
 3518: 
 3519: @samp{-r rel-1-0} はこの枝がタグ @samp{rel-1-0} に対応するリビジョンを
 3520: 根とするということを指定します。最新のリビジョンである必要はありません 
 3521: -- 古いリビジョンから枝を生やすことが役に立つことがしばしばあります
 3522: (例えば、他の部分は安定していることが知られている過去のリリースのバグ
 3523: を修正するとき)。
 3524: 
 3525: @samp{tag} と同様に @samp{-b} フラグは @code{rtag} に枝を作成するよう
 3526: に指示します (単なるリビジョン名ではなく)。@samp{rel-1-0} に対応する数
 3527: 字リビジョン番号はファイル毎に違うことを注意してください。
 3528: 
 3529: ですから、命令の完全な効果は新しい枝を作成することです -- モジュール 
 3530: @samp{tc} で、@samp{rel-1-0} でタグ付けされたリビジョンツリーを根元と
 3531: する -- @samp{rel-1-0-patches} という名前のものを。
 3532: 
 3533: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3534: @node Accessing branches
 3535: @section 枝のアクセス
 3536: @cindex Check out a branch
 3537: @cindex Retrieve a branch
 3538: @cindex Access a branch
 3539: @cindex Identifying a branch
 3540: @cindex Branch, check out
 3541: @cindex Branch, retrieving
 3542: @cindex Branch, accessing
 3543: @cindex Branch, identifying
 3544: 
 3545: 2 つの方法のどちらかで枝を取得することができます: リポジトリから新しく
 3546: 取り出すか、存在する作業コピーをその枝に切り換える方法です。
 3547: 
 3548: リポジトリから枝を取り出すには @samp{checkout} をフラグ @samp{-r} と、
 3549: その後に枝のタグ名を続けて起動します (@pxref{Creating a branch})。
 3550: 
 3551: @example
 3552: $ cvs checkout -r rel-1-0-patches tc
 3553: @end example
 3554: 
 3555: もしくは、既に作業コピーを持っていれば、@samp{update -r} で任意の枝に
 3556: 切り換えることができます:
 3557: 
 3558: @example
 3559: $ cvs update -r rel-1-0-patches tc
 3560: @end example
 3561: 
 3562: もしくは、それと等価な:
 3563: 
 3564: @example
 3565: $ cd tc
 3566: $ cvs update -r rel-1-0-patches
 3567: @end example
 3568: 
 3569: 作業コピーが元々幹にあったか他の枝にあったかは関係ありません -- 上のコ
 3570: マンドはそれを指定された名前の枝に切り換えます。普通の @samp{update}
 3571: コマンドと同様に、@samp{update -r} は全ての変更をマージし、衝突がどこ
 3572: で起こったかを知らせます。
 3573: 
 3574: 一度特定の枝に結び付けられた作業コピーを手に入れると、指示しない限りそ
 3575: こに残り続けます。これは、作業コピーから格納された変更はその枝に新しい
 3576: リビジョンを加えますが、幹と他の枝には影響を及ぼさないということです。
 3577: 
 3578: @cindex Branches, sticky
 3579: 作業コピーがどの枝であるかを知るために、コマンド @samp{status} を使う
 3580: ことができます。その出力で、@samp{Sticky tag} という名前の場所を探して
 3581: ください (@pxref{Sticky tags}) -- それは現在の作業ファイルに、もし枝が
 3582: あれば、それを教える @sc{cvs} の方法です:
 3583: 
 3584: @example
 3585: $ cvs status -v driver.c backend.c
 3586: ===================================================================
 3587: File: driver.c          Status: Up-to-date
 3588: 
 3589:     Version:            1.7     Sat Dec  5 18:25:54 1992
 3590:     RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
 3591:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3592:     Sticky Date:        (none)
 3593:     Sticky Options:     (none)
 3594: 
 3595:     Existing Tags:
 3596:         rel-1-0-patches             (branch: 1.7.2)
 3597:         rel-1-0                     (revision: 1.7)
 3598: 
 3599: ===================================================================
 3600: File: backend.c         Status: Up-to-date
 3601: 
 3602:     Version:            1.4     Tue Dec  1 14:39:01 1992
 3603:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 3604:     Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
 3605:     Sticky Date:        (none)
 3606:     Sticky Options:     (none)
 3607: 
 3608:     Existing Tags:
 3609:         rel-1-0-patches             (branch: 1.4.2)
 3610:         rel-1-0                     (revision: 1.4)
 3611:         rel-0-4                     (revision: 1.4)
 3612: 
 3613: @end example
 3614: 
 3615: それぞれのファイルの枝番号が違うという事実に混乱しないでください 
 3616: (それぞれ @samp{1.7.1} と @samp{1.4.2} です)。枝タグは同じ 
 3617: @samp{rel-1-0-patches} で、ファイルは実際に同じ枝にあります。番号は単
 3618: に枝が作られたときのそれぞれのファイルのリビジョン履歴を反映しています。
 3619: 上の例では、この枝が作成される前に、@samp{driver.c} が 
 3620: @samp{backend.c} よりも多くの変更が成されたということを導き出すことが
 3621: できます。
 3622: 
 3623: 枝番号が作成される方法の詳細は @ref{Branches and revisions} を参照して
 3624: ください。
 3625: 
 3626: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3627: @node Branches and revisions
 3628: @section 枝とリビジョン
 3629: @cindex Branch number
 3630: @cindex Number, branch
 3631: @cindex Revision numbers (branches)
 3632: 
 3633: 普通はファイルのリビジョン履歴は線形増加です (@pxref{Revision
 3634: numbers}):
 3635: 
 3636: @example
 3637:        +-----+    +-----+    +-----+    +-----+    +-----+
 3638:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 3639:        +-----+    +-----+    +-----+    +-----+    +-----+
 3640: @end example
 3641: 
 3642: しかし、@sc{cvs} は線形の開発に限られているわけではありません。@dfn{リ
 3643: ビジョン・ツリー} は @dfn{枝} に分割することができ、それぞれの枝は別に
 3644: 維持された開発ラインです。枝になされた変更は簡単に幹に戻すことができま
 3645: す。
 3646: 
 3647: それぞれの枝には @dfn{枝番号} があり、ピリオドで分けられた奇数個の10進
 3648: 整数から成ります。枝番号は枝が分岐した元の枝に対応するリビジョン番号に
 3649: 整数を追加することによって作成されます。枝番号により、特定のリビジョン
 3650: から 1 つ以上の枝を枝分かれすることができます。
 3651: 
 3652: @need 3500
 3653: 枝の全てのリビジョンは枝番号に普通の数字を追加することで形成されます。
 3654: 下図に、前述の例から枝が発展した例を示します。
 3655: 
 3656: @example
 3657: @c This example used to have a 1.2.2.4 revision, which
 3658: @c might help clarify that development can continue on
 3659: @c 1.2.2.  Might be worth reinstating if it can be done
 3660: @c without overfull hboxes.
 3661: @group
 3662:                                                       +-------------+
 3663:                            Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
 3664:                                                     / +-------------+
 3665:                                                    /
 3666:                                                   /
 3667:                  +---------+    +---------+    +---------+
 3668: Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3669:                / +---------+    +---------+    +---------+
 3670:               /
 3671:              /
 3672: +-----+    +-----+    +-----+    +-----+    +-----+
 3673: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
 3674: +-----+    +-----+    +-----+    +-----+    +-----+
 3675:                 !
 3676:                 !
 3677:                 !   +---------+    +---------+    +---------+
 3678: Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
 3679:                     +---------+    +---------+    +---------+
 3680: 
 3681: @end group
 3682: @end example
 3683: 
 3684: @c --   However, at least for me the figure is not enough.  I suggest more
 3685: @c --   text to accompany it.  "A picture is worth a thousand words", so you
 3686: @c --   have to make sure the reader notices the couple of hundred words
 3687: @c --   *you* had in mind more than the others!
 3688: 
 3689: @c --   Why an even number of segments?  This section implies that this is
 3690: @c --   how the main trunk is distinguished from branch roots, but you never
 3691: @c --   explicitly say that this is the purpose of the [by itself rather
 3692: @c --   surprising] restriction to an even number of segments.
 3693: 
 3694: 枝番号が作成される厳密な詳細は普通は気にしなくて良いのですが、以下が動
 3695: 作の方法です: @sc{cvs} が枝番号を作成するときは、2 から始まる最初の未
 3696: 使用の偶数を選びます。ですから、リビジョン 6.4 から枝を作成したいとき
 3697: は、それは 6.4.2 という番号になるでしょう。零で終わる全ての枝番号 
 3698: (6.4.0 のように) は @sc{cvs} の内部で使用されます (@pxref{Magic branch
 3699: numbers})。枝 1.1.1 は特別な意味を持ちます。@xref{Tracking sources}.
 3700: 
 3701: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3702: @node Magic branch numbers
 3703: @section 魔法の枝番号
 3704: 
 3705: @c Want xref to here from "log"?
 3706: 
 3707: この部分は @dfn{魔法の枝} (@dfn{magic brandh}) と呼ばれる @sc{cvs} の
 3708: 機能を説明します。たいていの目的のためには魔法の枝を心配する必要はあり
 3709: ません。@sc{cvs} が代わりに扱ってくれます。しかし、特定の状況ではそれ
 3710: が見えていることもありますので、いくらか動作の仕方を知っていると役に立
 3711: つかもしれません。
 3712: 
 3713: 表面的には、枝番号はドットで分けられた奇数個の10進の整数です。 
 3714: @xref{Revision numbers}.  しかし、これは真実の姿ではありません。
 3715: @sc{cvs} は能率のために、余分な 0 を右から2番目の位置に挿入することが
 3716: あります(1.2.3 は 1.2.0.3 となり、8.9.10.11.12 は 8.9.10.11.0.12 にな
 3717: ります)。
 3718: 
 3719: この魔法の枝と呼ばれるものを、@sc{cvs} はうまく隠しています。しかし、
 3720: 完璧に隠し切れていないところも数ヶ所あります。
 3721: 
 3722: @itemize @bullet
 3723: @ignore
 3724: @c This is in ignore as I'm taking their word for it,
 3725: @c that this was fixed
 3726: @c a long time ago.  But before deleting this
 3727: @c entirely, I'd rather verify it (and add a test
 3728: @c case to the testsuite).
 3729: @item
 3730: @sc{cvs} 1.3 で、
 3731: 魔法の枝番号が @code{cvs status} の出力に現われてしまう。
 3732: これは @sc{cvs} 1.3-s2 では修復されました。
 3733: 
 3734: @end ignore
 3735: @item
 3736: 魔法の枝番号が @code{cvs log} の出力に現われてしまう。
 3737: @c What output should appear instead?
 3738: 
 3739: @item
 3740: @code{cvs admin} で枝のタグ名が指定できない。
 3741: 
 3742: @end itemize
 3743: 
 3744: @c Can CVS do this automatically the first time
 3745: @c you check something in to that branch?  Should
 3746: @c it?
 3747: @code{admin} コマンドを使用して、
 3748: @sc{rcs} が枝のタグ名を理解できるように再設定する方法があります。
 3749: @code{R4patches} というタグ名が、
 3750: ファイル @file{number.c} の枝 1.4.2 に付けられている場合
 3751: (魔法の枝番号は 1.4.0.2 です)、
 3752: 次のようにします:
 3753: 
 3754: @example
 3755: $ cvs admin -NR4patches:1.4.2 numbers.c
 3756: @end example
 3757: 
 3758: この方法を用いる場合は、1つ以上のリビジョンが、
 3759: 既に枝に格納されている必要があります。
 3760: タグに間違った番号を設定しないように、注意しなくてはいけません。
 3761: (実行以前にタグがどう設定されていたかを調べる方法はありません)。
 3762: 
 3763: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3764: @node Merging a branch
 3765: @section 枝全体をマージする
 3766: @cindex Merging a branch
 3767: @cindex -j (merging branches)
 3768: 
 3769: @code{update} コマンドに @samp{-j @var{branch}} フラグを付けると、
 3770: 枝に加えられた変更を作業コピーに反映することができます。
 3771: @samp{-j @var{branch}} オプションが1つだけだと、
 3772: 枝の分岐点と枝の最新リビジョン間の違いを 
 3773: (あなたの作業コピーに) マージします。
 3774: 
 3775: @cindex Join
 3776: @samp{-j} は、``join'' の略です。
 3777: 
 3778: @cindex Branch merge example
 3779: @cindex Example, branch merge
 3780: @cindex Merge, branch example
 3781: 次のリビジョン・ツリーを考えます。
 3782: 
 3783: @example
 3784: +-----+    +-----+    +-----+    +-----+
 3785: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
 3786: +-----+    +-----+    +-----+    +-----+
 3787:                 !
 3788:                 !
 3789:                 !   +---------+    +---------+
 3790: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3791:                     +---------+    +---------+
 3792: @end example
 3793: 
 3794: @noindent
 3795: 枝 1.2.2 には @samp{R1fix} というタグ (文字列) が付けられています。次
 3796: は @file{m.c} というファイル1つを含むモジュール @samp{mod} の例です。
 3797: 
 3798: @example
 3799: $ cvs checkout mod               # @r{最新のリビジョン 1.4 を取り出す}
 3800: 
 3801: $ cvs update -j R1fix m.c        # @r{枝で行なわれた変更(リビジョン 1.2}
 3802:                                  # @r{と 1.2.2.2 の差分)を作業コピーに追加}
 3803: 
 3804: $ cvs commit -m "Included R1fix" # @r{リビジョン 1.5 を作成}
 3805: @end example
 3806: 
 3807: マージ作業で衝突が起きることもありますが、衝突が起きた場合は、それを解
 3808: 決してから新しいリビジョンを格納して下さい。 @xref{Conflicts example}.
 3809: 
 3810: もしソースファイルにキーワードがあれば (@pxref{Keyword substitution}),
 3811: 本当に必要なものよりも余分に衝突を得るかもしれません。これを回避する方
 3812: 法は @ref{Merging and keywords} を参照してください。
 3813: 
 3814: @code{checkout} コマンドでもフラグ @samp{-j @var{branch}} を使用できます。
 3815: 以下の様にして上記と同じ効果を得ることができます:
 3816: 
 3817: @example
 3818: $ cvs checkout -j R1fix mod
 3819: $ cvs commit -m "Included R1fix"
 3820: @end example
 3821: 
 3822: @node Merging more than once
 3823: @section 枝から何度もマージする
 3824: 
 3825: 前節の例を続けると、
 3826: 現在のリビジョン・ツリーは次の様になっています:
 3827: 
 3828: @example
 3829: +-----+    +-----+    +-----+    +-----+    +-----+
 3830: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3831: +-----+    +-----+    +-----+    +-----+    +-----+
 3832:                 !                           *
 3833:                 !                          *
 3834:                 !   +---------+    +---------+
 3835: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3836:                     +---------+    +---------+
 3837: @end example
 3838: 
 3839: 前節で枝 @samp{R1fix} を幹にマージした事を、ここでは星線で表します。
 3840: 
 3841: 次に、枝 @samp{R1fix} で開発が続けられたと仮定します:
 3842: 
 3843: @example
 3844: +-----+    +-----+    +-----+    +-----+    +-----+
 3845: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3846: +-----+    +-----+    +-----+    +-----+    +-----+
 3847:                 !                           *
 3848:                 !                          *
 3849:                 !   +---------+    +---------+    +---------+
 3850: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3851:                     +---------+    +---------+    +---------+
 3852: @end example
 3853: 
 3854: そしてこの新しい変更を幹にマージしたくなりました。
 3855: ここで再び @code{cvs update -j R1fix m.c} コマンドを用いた場合、
 3856: @sc{cvs} は既にマージされた変更点を重ねてマージしようとして、
 3857: 望ましくない結果をもたらします。
 3858: 
 3859: そこで、
 3860: 未だ幹にマージされてない変更点だけマージしたい旨を、
 3861: 明示する必要があります。
 3862: これには、@samp{-j} オプションで二つのリビジョンを指定します。
 3863: @sc{cvs} は、
 3864: 最初のリビジョンから次のリビジョンまでの変更をマージします。
 3865: 例えば、この場合、最も簡単な方法は次の様になります。
 3866: 
 3867: @example
 3868: cvs update -j 1.2.2.2 -j R1fix m.c    # @r{1.2.2.2 から、枝 R1fix の}
 3869:                                       # @r{先頭までの変更をマージする}
 3870: @end example
 3871: 
 3872: この方法の問題点は、リビジョン 1.2.2.2 を自分で指定する必要がある事です。
 3873: 最後にマージが行われた日時を使用する方が、少しましでしょう:
 3874: 
 3875: @example
 3876: cvs update -j R1fix:yesterday -j R1fix m.c
 3877: @end example
 3878: 
 3879: さらに良いのは、
 3880: 変更点を幹にマージする度に、
 3881: 枝 @samp{R1fix} にタグを振っておき、
 3882: 後でマージする時にそのタグを用いる方法です:
 3883: 
 3884: @example
 3885: cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
 3886: @end example
 3887: 
 3888: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3889: @node Merging two revisions
 3890: @section 二つのリビジョン間の差分をマージする
 3891: @cindex Merging two revisions
 3892: @cindex Revisions, merging differences between
 3893: @cindex Differences, merging
 3894: 
 3895: @code{update} (と @code{checkout}) コマンドに @samp{-j @var{revision}} 
 3896: フラグを二つ付けることで、任意の二つのリビジョン間の違いをあなたの作業
 3897: コピーに加えることができます。
 3898: 
 3899: @cindex Undoing a change
 3900: @cindex Removing a change
 3901: @example
 3902: $ cvs update -j 1.5 -j 1.3 backend.c
 3903: @end example
 3904: 
 3905: @noindent
 3906: このようにするとリビジョン 1.3 と 1.5 間の変更を
 3907: 全て@emph{元に戻す}ことになります。
 3908: リビジョンを指定する順序に十分注意して下さい!
 3909: 
 3910: 複数のファイルに対してこのオプションを指定する場合は、
 3911: ファイルごとにリビジョン番号が全く異なるであろうことを思い出して下さい。
 3912: 複数のファイルを操作する場合には、
 3913: リビジョン番号ではなく、
 3914: 必ずタグ名を用いるようにして下さい。
 3915: 
 3916: @cindex Restoring old version of removed file
 3917: @cindex Resurrecting old version of dead file
 3918: 2つ @samp{-j} オプションを指定すると、追加や削除を元に戻すこともできま
 3919: す。例えば、リビジョン1.1として存在していた @file{file1} という名前の
 3920: ファイルがあり、それを消去した (つまり、死んだリビジョン1.2を追加しま
 3921: した) としましょう。今、またそれを以前と同じ内容で追加したいと思ったと
 3922: しましょう。これがそれをする方法です:
 3923: 
 3924: @example
 3925: $ cvs update -j 1.2 -j 1.1 file1
 3926: U file1
 3927: $ cvs commit -m test
 3928: Checking in file1;
 3929: /tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
 3930: new revision: 1.3; previous revision: 1.2
 3931: done
 3932: $
 3933: @end example
 3934: 
 3935: @node Merging adds and removals
 3936: @section ファイルの追加や削除もマージできる
 3937: 
 3938: マージする変更点に、ファイルの削除や追加が伴なう場合でも、
 3939: @code{update -j} は削除や追加を反映します。
 3940: 
 3941: @c FIXME: This example needs a lot more explanation.
 3942: @c We also need other examples for some of the other
 3943: @c cases (not all--there are too many--as long as we present a
 3944: @c coherent general principle).
 3945: 実行例:
 3946: @example
 3947: cvs update -A
 3948: touch a b c
 3949: cvs add a b c ; cvs ci -m "added" a b c
 3950: cvs tag -b branchtag
 3951: cvs update -r branchtag
 3952: touch d ; cvs add d
 3953: rm a ; cvs rm a
 3954: cvs ci -m "added d, removed a"
 3955: cvs update -A
 3956: cvs update -jbranchtag
 3957: @end example
 3958: 
 3959: これらのコマンドが実行され、@samp{cvs commit} がなされた後、幹ではファ
 3960: イル @file{a} は削除され、ファイル@file{d} は追加されます
 3961: @c (which was determined by trying it)
 3962: 
 3963: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3964: @node Merging and keywords
 3965: @section マージとキーワード
 3966: @cindex Merging, and keyword substitution
 3967: @cindex Keyword substitution, and merging
 3968: @cindex -j (merging branches), and keyword substitution
 3969: @cindex -kk, to avoid conflicts during a merge
 3970: 
 3971: キーワードを含むファイルをマージすると (@pxref{Keyword substitution}、
 3972: 通常マージの間に数多くの衝突が起こります。なぜなら、キーワードはマージ
 3973: 中のリビジョンで違う様に展開されているからです。
 3974: 
 3975: ですから、しばしばマージのコマンド行で @samp{-kk} (@pxref{Substitution
 3976: modes}) スイッチを指定したいと思うでしょう。キーワードの展開された値を
 3977: 展開するのでは無く、キーワードの名前だけを置換することによって、このオ
 3978: プションはマージしているリビジョンがそれぞれ同じことを確実にして、見せ
 3979: かけの衝突を回避します。
 3980: 
 3981: 例えば、このようなファイルがあるとしましょう:
 3982: 
 3983: @example
 3984:        +---------+
 3985:       _! 1.1.2.1 !   <-  br1
 3986:      / +---------+
 3987:     /
 3988:    /
 3989: +-----+    +-----+
 3990: ! 1.1 !----! 1.2 !
 3991: +-----+    +-----+
 3992: @end example
 3993: 
 3994: そして、作業ディレクトリは現在幹 (revision 1.2) にあります。そうすると、
 3995: 以下の結果をマージから得るでしょう:
 3996: 
 3997: @example
 3998: $ cat file1
 3999: key $@asis{}Revision: 1.2 $
 4000: . . .
 4001: $ cvs update -j br1
 4002: U file1
 4003: RCS file: /cvsroot/first-dir/file1,v
 4004: retrieving revision 1.1
 4005: retrieving revision 1.1.2.1
 4006: Merging differences between 1.1 and 1.1.2.1 into file1
 4007: rcsmerge: warning: conflicts during merge
 4008: $ cat file1
 4009: @asis{}<<<<<<< file1
 4010: key $@asis{}Revision: 1.2 $
 4011: @asis{}=======
 4012: key $@asis{}Revision: 1.1.2.1 $
 4013: @asis{}>>>>>>> 1.1.2.1
 4014: . . .
 4015: @end example
 4016: 
 4017: これで起こったことは、merge が 1.1 と 1.1.2.1 間の差分を作業ディレクト
 4018: リにマージしようとした、ということです。キーワードは@code{Revision:
 4019: 1.1} から @code{Revision: 1.1.2.1} へと変わっているので、@sc{cvs} はそ
 4020: の変更を作業ディレクトリにマージしようとして、それは作業ディレクトリが 
 4021: @code{Revision: 1.2} を含んでいた、という事実と衝突をしました。
 4022: 
 4023: これは @samp{-kk} を使用したときにに起こることです:
 4024: 
 4025: @example
 4026: $ cat file1
 4027: key $@asis{}Revision: 1.2 $
 4028: . . .
 4029: $ cvs update -kk -j br1
 4030: U file1
 4031: RCS file: /cvsroot/first-dir/file1,v
 4032: retrieving revision 1.1
 4033: retrieving revision 1.1.2.1
 4034: Merging differences between 1.1 and 1.1.2.1 into file1
 4035: $ cat file1
 4036: key $@asis{}Revision$
 4037: . . .
 4038: @end example
 4039: 
 4040: ここでは、リビジョン 1.1 とリビジョン 1.1.2.1 の両方ともが 
 4041: @code{Revision} に展開され、それらの変更を作業コピーにマージすることは
 4042: 何も変更しません。ですから、衝突は起こりません。
 4043: 
 4044: しかしながら、マージで @samp{-kk} を使うことには一つ大きな注意がありま
 4045: す。つまり、それは普通は @sc{cvs} が使っていたであろうキーワード展開の
 4046: 様式を上書きします。特に、これは、バイナリファイルのために様式が 
 4047: @samp{-kb} であったときに問題になります。ですので、リポジトリにバイナ
 4048: リファイルがあるときは、@samp{-kk} を使用するよりは、衝突に対処する必
 4049: 要があるでしょう。
 4050: 
 4051: @ignore
 4052: The following seems rather confusing, possibly buggy,
 4053: and in general, in need of much more thought before it
 4054: is a recommended technique.  For one thing, does it
 4055: apply on Windows as well as on Unix?
 4056: 
 4057: Unchanged binary files will undergo the same keyword substitution
 4058: but will not be checked in on a subsequent
 4059: @code{cvs commit}.  Be aware that binary files containing keyword
 4060: strings which are present in or below the working directory
 4061: will most likely remain corrupt until repaired, however.  A simple 
 4062: @code{cvs update -A} is sufficient to fix these otherwise unaltered binary files
 4063: if the merge is being done to the main branch but
 4064: this must be done after the merge has been committed or the merge itself
 4065: will be lost.
 4066: 
 4067: For Example:
 4068: @example
 4069: cvs update -Akk -jbranchtag
 4070: cvs commit
 4071: cvs update -A
 4072: @end example
 4073: 
 4074: @noindent
 4075: will update the current directory from the main trunk of the
 4076: repository, substituting the base keyword strings for keywords,
 4077: and merge changes made on the branch @samp{branchtag} into the new
 4078: work files, performing the same keyword substitution on that file set before
 4079: comparing the two sets.  The final @code{cvs update -A} will restore any
 4080: corrupted binary files as well as resetting the sticky @samp{-kk} tags which
 4081: were present on the files in and below the working directory.
 4082: Unfortunately, this doesn't work as well with an arbitrary branch tag, as the
 4083: @samp{-r @var{branchtag}} switch does not reset the sticky @samp{-kk}
 4084: switches attached to the working files as @samp{-A} does.  The workaround
 4085: for this is to release the working directory after the merge has been
 4086: committed and check it out again.
 4087: @end ignore
 4088: 
 4089: @c ---------------------------------------------------------------------
 4090: @node Recursive behavior
 4091: @chapter 再帰的動作
 4092: @cindex Recursive (directory descending)
 4093: @cindex Directory, descending
 4094: @cindex Descending directories
 4095: @cindex Subdirectories
 4096: 
 4097: ほとんど全ての @sc{cvs} のコマンドは、
 4098: ディレクトリを引数に取ったときに再帰的に動作します。
 4099: 例えば、次のディレクトリ構造を考えます。
 4100: 
 4101: @example
 4102:       @code{$HOME}
 4103:         |
 4104:         +--@t{tc}
 4105:         |   |
 4106:             +--@t{CVS}
 4107:             |      (内部 @sc{cvs} ファイル)
 4108:             +--@t{Makefile}
 4109:             +--@t{backend.c}
 4110:             +--@t{driver.c}
 4111:             +--@t{frontend.c}
 4112:             +--@t{parser.c}
 4113:             +--@t{man}
 4114:             |    |
 4115:             |    +--@t{CVS}
 4116:             |    |  (内部 @sc{cvs} ファイル)
 4117:             |    +--@t{tc.1}
 4118:             |
 4119:             +--@t{testing}
 4120:                  |
 4121:                  +--@t{CVS}
 4122:                  |  (内部 @sc{cvs} ファイル)
 4123:                  +--@t{testpgm.t}
 4124:                  +--@t{test2.t}
 4125: @end example
 4126: 
 4127: @noindent
 4128: 現在のディレクトリが @samp{tc} であれば、
 4129: 以下が成立します:
 4130: 
 4131: @itemize @bullet
 4132: @item
 4133: @samp{cvs update testing} は
 4134: 
 4135: @example
 4136: cvs update testing/testpgm.t testing/test2.t
 4137: @end example
 4138: と等価です。
 4139: 
 4140: @item
 4141: @samp{cvs update testing man} は
 4142: サブディレクトリ中の全てのファイルを更新します。
 4143: 
 4144: @item
 4145: @samp{cvs update .} 又は @samp{cvs update} は、
 4146: ディレクトリ @code{tc} 中の全てのファイルを更新します。
 4147: @end itemize
 4148: 
 4149: 引数を付けない @code{update} コマンドは現在の作業ディレクトリと全ての
 4150: サブディレクトリを更新します。言い替えると、@file{.} は @code{update} 
 4151: の既定引数です。これは @code{update} コマンドだけではなく、たいていの 
 4152: @sc{cvs} のコマンドにも当てはまります。
 4153: 
 4154: @samp{-l} オプションを付けることによって、
 4155: @sc{cvs} の再帰的な動作を抑止することができます。
 4156: 逆に、@samp{-R} オプションは @file{~/.cvsrc} で @samp{-l} が指定されて
 4157: いるときに再帰的動作を強制するために使うことができます
 4158: (@pxref{~/.cvsrc})。
 4159: 
 4160: @example
 4161: $ cvs update -l         # @r{サブディレクトリのファイルは更新しない。}
 4162: @end example
 4163: 
 4164: @c ---------------------------------------------------------------------
 4165: @node Adding and removing
 4166: @chapter ファイルとディレクトリの追加、削除、改名
 4167: 
 4168: プロジェクトの最中では、よく新しいファイルを追加します。削除や改名、も
 4169: しくはディレクトリも同様です。心に留めておく総合的な概念は、元に戻せな
 4170: い変更をする代わりに、存在するファイルの修正のように、@sc{cvs} に変更
 4171: が発生したという事実を記録させたい、ということです。@sc{cvs} でこれを
 4172: する厳密な機構は状況に依り異ります。
 4173: 
 4174: @menu
 4175: * Adding files::                ファイルの追加
 4176: * Removing files::              ファイルの削除
 4177: * Removing directories::        ディレクトリの削除
 4178: * Moving files::                ファイルの移動と改名
 4179: * Moving directories::          ディレクトリの移動と改名
 4180: @end menu
 4181: 
 4182: @node Adding files
 4183: @section ディレクトリにファイルを加える
 4184: @cindex Adding files
 4185: 
 4186: ディレクトリにファイルを加える手順を説明します。
 4187: 
 4188: @itemize @bullet
 4189: @item
 4190: ディレクトリの作業コピーが必要です。@xref{Getting the source}.
 4191: 
 4192: @item
 4193: ディレクトリの作業コピーの中に、
 4194: 新しいファイルを作ります。
 4195: 
 4196: @item
 4197: @samp{cvs add @var{filename}} を用いて、
 4198: バージョン管理に加えたいファイルを @sc{cvs} に伝えます。
 4199: ファイルがバイナリ・データを含んでいる場合には、
 4200: @samp{-kb} を指定して下さい (@pxref{Binary files})。
 4201: 
 4202: @item
 4203: @samp{cvs commit @var{filename}} を用いて、
 4204: 実際にリポジトリにファイルを格納します。
 4205: この手順を行なうまでは、他の開発者はファイルを見ることができません。
 4206: @end itemize
 4207: 
 4208: @code{add} コマンドは、
 4209: 新しいディレクトリを加える場合にも使用します。
 4210: @c FIXCVS and/or FIXME: Adding a directory doesn't
 4211: @c require the commit step.  This probably can be
 4212: @c considered a CVS bug, but it is possible we should
 4213: @c warn people since this behavior probably won't be
 4214: @c changing right away.
 4215: 
 4216: 他のほとんどのコマンドと異なり、
 4217: @code{add} コマンドは再帰的に動作しません。
 4218: @samp{cvs add foo/bar} とタイプすることさえできません。
 4219: 代りに、
 4220: 次のようにする必要があります。
 4221: @c FIXCVS: This is, of course, not a feature.  It is
 4222: @c just that no one has gotten around to fixing "cvs add
 4223: @c foo/bar".
 4224: 
 4225: @example
 4226: $ cd foo
 4227: $ cvs add bar
 4228: @end example
 4229: 
 4230: @cindex add (subcommand)
 4231: @deffn コマンド {cvs add} [@code{-k} kflag] [@code{-m} message] files @dots{}
 4232: 
 4233: @var{files} が加えられた事をリポジトリに伝えます。
 4234: @code{add} で指定するファイルやディレクトリは、
 4235: 現在のディレクトリに存在している必要があります。
 4236: 新しいディレクトリ階層の全てをリポジトリに加える場合は 
 4237: (例えばサード・パーティーからのファイル等)、
 4238: 代りに @code{import} コマンドを使用した方が良いでしょう。@xref{import}.
 4239: 
 4240: 内容を @code{commit} で格納するまで、
 4241: ここで加えたファイルは実際にはリポジトリに置かれません。
 4242: @code{remove} コマンドで削除されたファイルに対して、
 4243: @code{commit} を発行する前に @code{add} を実行した場合、
 4244: @code{remove} が無効になります。
 4245: 例は @xref{Removing files}.
 4246: 
 4247: オプション @samp{-k} には、
 4248: このファイルを取り出すときの置換モードを指定します。
 4249: 詳細は @ref{Substitution modes} 参照。
 4250: 
 4251: @c As noted in BUGS, -m is broken client/server (Nov
 4252: @c 96).  Also see testsuite log2-* tests.
 4253: @samp{-m} オプションには、ファイルの説明文を記述します。
 4254: (ログ情報を記録する設定ならば)この説明文が
 4255: ファイル @file{history} に記録されます (@pxref{history file})。
 4256: またファイルを格納する際、リポジトリの履歴ファイルにも記録されます。
 4257: この説明文は @code{log} コマンドの出力で確認できます。
 4258: 変更するには @samp{admin -t} を用います。@xref{admin}.
 4259: フラグ @samp{-m @var{description}} を省略した場合、
 4260: 空の文字列が使用され、説明を記述するように促されることはありません。
 4261: @end deffn
 4262: 
 4263: 例えば、以下のコマンドでファイル @file{backend.c} が
 4264: リポジトリに加えられます:
 4265: 
 4266: @c This example used to specify
 4267: @c     -m "Optimizer and code generation passes."
 4268: @c to the cvs add command, but that doesn't work
 4269: @c client/server (see log2 in sanity.sh).  Should fix CVS,
 4270: @c but also seems strange to document things which
 4271: @c don't work...
 4272: @example
 4273: $ cvs add backend.c
 4274: $ cvs commit -m "Early version. Not yet compilable." backend.c
 4275: @end example
 4276: 
 4277: 加えたファイルは、作業中の枝だけに加えられます 
 4278: (@pxref{Branching and merging})。
 4279: 他の枝にも加えたい場合は、後でマージすることができます 
 4280: (@pxref{Merging adds and removals})。
 4281: @c Should we mention that earlier versions of CVS
 4282: @c lacked this feature (1.3) or implemented it in a buggy
 4283: @c way (well, 1.8 had many bugs in cvs update -j)?
 4284: @c Should we mention the bug/limitation regarding a
 4285: @c file being a regular file on one branch and a directory
 4286: @c on another?
 4287: @c FIXME: This needs an example, or several, here or
 4288: @c elsewhere, for it to make much sense.
 4289: @c Somewhere we need to discuss the aspects of death
 4290: @c support which don't involve branching, I guess.
 4291: @c Like the ability to re-create a release from a tag.
 4292: 
 4293: @c ---------------------------------------------------------------------
 4294: @node Removing files
 4295: @section ファイルを削除する
 4296: @cindex Removing files
 4297: @cindex Deleting files
 4298: 
 4299: @c FIXME: this node wants to be split into several
 4300: @c smaller nodes.  Could make these children of
 4301: @c "Adding and removing", probably (death support could
 4302: @c be its own section, for example, as could the
 4303: @c various bits about undoing mistakes in adding and
 4304: @c removing).
 4305: ディレクトリは変わります。
 4306: 新しいファイルが加えられ、古いファイルが削除されます。
 4307: しかし、モジュールの古いバージョンの、
 4308: 正確なコピーを復元できるようにしておきたいと思うでしょう。
 4309: 
 4310: ここでは、モジュールからファイルを削除した後も、
 4311: 古いバージョンの復元を可能にする手順を説明します:
 4312: 
 4313: @itemize @bullet
 4314: @c FIXME: should probably be saying something about
 4315: @c having a working directory in the first place.
 4316: @item
 4317: 未格納の修正がファイルに残ってないことを確認する必要があります。
 4318: 確認方法は @xref{Viewing differences}.
 4319: また @code{status} や @code{update} といった
 4320: コマンドを使用しても確認できます。
 4321: 修正を格納せずにファイルを消した場合、
 4322: 当然ですが以前の状態に復元することはできません。
 4323: 
 4324: @item
 4325: モジュールの作業コピーからファイルを削除します。
 4326: 例えば、@code{rm} などを使っても良いでしょう。
 4327: 
 4328: @item
 4329: ファイルを本当に削除するという意思を @sc{cvs} に伝えるために、
 4330: @samp{cvs remove @var{filename}} を使います。
 4331: 
 4332: @item
 4333: リポジトリからファイルを実際に削除するために、
 4334: @samp{cvs commit @var{filename}} を使います。
 4335: @end itemize
 4336: 
 4337: @c FIXME: Somehow this should be linked in with a more
 4338: @c general discussion of death support.  I don't know
 4339: @c whether we want to use the term "death support" or
 4340: @c not (we can perhaps get by without it), but we do
 4341: @c need to discuss the "dead" state in "cvs log" and
 4342: @c related subjects.  The current discussion is
 4343: @c scattered around, and not xref'd to each other.
 4344: @c FIXME: I think this paragraph wants to be moved
 4345: @c later down, at least after the first example.
 4346: ファイルの削除を格納する場合、@sc{cvs} は、
 4347: ファイルがもう無いという事実を記録します。
 4348: ファイルが他の枝に存在していても良いし、
 4349: 後で別のファイルを同じ名前で加えても構いません。
 4350: @code{checkout} や @code{update} に指定する
 4351: オプション @samp{-r} や @samp{-D} に応じて、
 4352: @sc{cvs} が正しくファイルを作成したり、しなかったりします。
 4353: 
 4354: @c FIXME: This style seems to clash with how we
 4355: @c document things in general.
 4356: @cindex Remove (subcommand)
 4357: @deffn コマンド {cvs remove} [options] files @dots{}
 4358: 
 4359: ファイルが削除された事実をリポジトリに伝えます 
 4360: (作業ディレクトリから未削除のファイルは処理されません)。
 4361: このコマンドを実行しても、リポジトリのファイルは、
 4362: 削除が格納されるまで実際には削除されません。
 4363: オプションの完全な一覧は @ref{Invoking CVS} を参照してください。
 4364: @end deffn
 4365: 
 4366: 以下に、幾つかファイルを削除する例を挙げます:
 4367: 
 4368: @example
 4369: $ cd test
 4370: $ rm *.c
 4371: $ cvs remove
 4372: cvs remove: Removing .
 4373: cvs remove: scheduling a.c for removal
 4374: cvs remove: scheduling b.c for removal
 4375: cvs remove: use 'cvs commit' to remove these files permanently
 4376: $ cvs ci -m "Removed unneeded files"
 4377: cvs commit: Examining .
 4378: cvs commit: Committing .
 4379: @end example
 4380: 
 4381: 利便性のために、@samp{-f} オプションを指定することでファイルの削除と 
 4382: @code{cvs remove} を一度に行うことができます。例えば、上の例はこのよう
 4383: にすることもできます:
 4384: 
 4385: @example
 4386: $ cd test
 4387: $ cvs remove -f *.c
 4388: cvs remove: scheduling a.c for removal
 4389: cvs remove: scheduling b.c for removal
 4390: cvs remove: use 'cvs commit' to remove these files permanently
 4391: $ cvs ci -m "Removed unneeded files"
 4392: cvs commit: Examining .
 4393: cvs commit: Committing .
 4394: @end example
 4395: 
 4396: ファイルに @code{remove} を実行したけれど、
 4397: 格納前に気が変わったのなら、@code{add} コマンドを用いて、
 4398: 簡単にファイルを復活させることができます。
 4399: @ignore
 4400: @c is this worth saying or not?  Somehow it seems
 4401: @c confusing to me.
 4402: もちろん、作業ディレクトリからファイルのコピーを削除しましたので、
 4403: @sc{cvs} は必ずしも @code{remove} を実行する前のファイルの内容に戻すわ
 4404: けではありません。代わりにリポジトリからもう一度ファイルを取得します。
 4405: @end ignore
 4406: 
 4407: @c FIXME: what if you change your mind after you commit
 4408: @c it?  (answer is also "cvs add" but we don't say that...).
 4409: @c We need some index entries for thinks like "undoing
 4410: @c removal" too.
 4411: 
 4412: @example
 4413: $ ls
 4414: CVS   ja.h  oj.c
 4415: $ rm oj.c
 4416: $ cvs remove oj.c
 4417: cvs remove: scheduling oj.c for removal
 4418: cvs remove: use 'cvs commit' to remove this file permanently
 4419: $ cvs add oj.c
 4420: U oj.c
 4421: cvs add: oj.c, version 1.1.1.1, resurrected
 4422: @end example
 4423: 
 4424: @code{remove} コマンドを実行する前に失敗に気付いた場合、
 4425: @code{update} コマンドを用いてファイルを復活できます:
 4426: 
 4427: @example
 4428: $ rm oj.c
 4429: $ cvs update oj.c
 4430: cvs update: warning: oj.c was lost
 4431: U oj.c
 4432: @end example
 4433: 
 4434: 削除したファイルは、作業中の枝だけから削除されます 
 4435: (@pxref{Branching and merging})。
 4436: 他の枝からも削除したい場合は、後でマージすることができます 
 4437: (@pxref{Merging adds and removals})。
 4438: 
 4439: @node Removing directories
 4440: @section ディレクトリを削除する
 4441: @cindex Removing directories
 4442: @cindex Directories, removing
 4443: 
 4444: 概念上では、ディレクトリの削除はファイルの削除と似ています---現在の作
 4445: 業ディレクトリからそのディレクトリを消したいけれど、ディレクトリが存在
 4446: した古いリリースも取得できるようにしたい、と思うでしょう。
 4447: 
 4448: ディレクトリを削除する方法は、その中の全てのファイルを削除することです。
 4449: ディレクトリ自身は削除しません。そうする方法はありません。代わりに、
 4450: @code{cvs update}, @code{cvs checkout}, @code{cvs export} に @samp{-P} 
 4451: オプションを指定して、作業ディレクトリから空のディレクトリを削除するよ
 4452: うにします。おそらく最良の方法は常に @samp{-P} を指定することです。空
 4453: のディレクトリが欲しければ、削除されないように、ダミーファイルを作って
 4454: ください (例えば、 @file{.keepme})。
 4455: 
 4456: @c I'd try to give a rationale for this, but I'm not
 4457: @c sure there is a particularly convincing one.  What
 4458: @c we would _like_ is for CVS to do a better job of version
 4459: @c controlling whether directories exist, to eliminate the
 4460: @c need for -P and so that a file can be a directory in
 4461: @c one revision and a regular file in another.
 4462: @code{checkout} と @code{export} の @samp{-r} と @samp{-D} のオプショ
 4463: ンでは @samp{-P} が暗黙に含まれていることに注意してください。この方法
 4464: により @sc{cvs} は正しくディレクトリを作ることができ、又、取り出した特
 4465: 定のバージョンのそのディレクトリにファイルがあるかどうかに左右されなく
 4466: なります。
 4467: 
 4468: @c ---------------------------------------------------------------------
 4469: @node Moving files
 4470: @section ファイルの改名と移動
 4471: @cindex Moving files
 4472: @cindex Renaming files
 4473: @cindex Files, moving
 4474: 
 4475: ファイルを他のディレクトリに移動したり、改名したりするのは、
 4476: 難しくはありません。
 4477: しかし、難解な方法でこれを実現するものがあります。
 4478: (ディレクトリの移動と改名は、
 4479: より困難です。@xref{Moving directories}.)。
 4480: 
 4481: 以降の例では、
 4482: @var{old} というファイルを @var{new} に改名します。
 4483: 
 4484: @menu
 4485: * Outside::                     通常の改名方法
 4486: * Inside::                      小技を使った別の方法
 4487: * Rename by copying::           別の小技を使った方法
 4488: @end menu
 4489: 
 4490: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4491: @node Outside
 4492: @subsection 通常の改名方法
 4493: 
 4494: @c More rename issues.  Not sure whether these are
 4495: @c worth documenting; I'm putting them here because
 4496: @c it seems to be as good a place as any to try to
 4497: @c set down the issues.
 4498: @c * "cvs annotate" will annotate either the new
 4499: @c file or the old file; it cannot annotate _each
 4500: @c line_ based on whether it was last changed in the
 4501: @c new or old file.  Unlike "cvs log", where the
 4502: @c consequences of having to select either the new
 4503: @c or old name seem fairly benign, this may be a
 4504: @c real advantage to having CVS know about renames
 4505: @c other than as a deletion and an addition.
 4506: 
 4507: ファイルを移動する通常の方法は、
 4508: @var{old} を @var{new} にコピーして、
 4509: 普通の @sc{cvs} コマンドで @var{old} をリポジトリから削除し、
 4510: @var{new} を加えることです。
 4511: @c The following sentence is not true: one must cd into
 4512: @c the directory to run "cvs add".
 4513: @c  (Both @var{old} and @var{new} could
 4514: @c contain relative paths, for example @file{foo/bar.c}).
 4515: 
 4516: @example
 4517: $ mv @var{old} @var{new}
 4518: $ cvs remove @var{old}
 4519: $ cvs add @var{new}
 4520: $ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new}
 4521: @end example
 4522: 
 4523: これがファイルを移動する最も単純な方法であり、
 4524: 間違いがなく、この操作の履歴も記録されます。
 4525: このファイルの履歴を利用する際、
 4526: 古い名前か、新しい名前のどちらかを指定して、
 4527: 履歴のどの部分が欲しいのか知らせなくてはいけません。
 4528: 例えば、@code{cvs log @var{old}} を実行しても、
 4529: 改名が行なわれた時までのログ情報しか得られません。
 4530: 
 4531: @var{new} が格納される場合には、
 4532: リビジョン番号は普通は 1.1 から再び始まります。
 4533: それが嫌ならば、格納時にオプション @samp{-r rev}
 4534: を用いると良いでしょう。詳しい情報は @ref{Assigning revisions} を参照
 4535: してください。
 4536: 
 4537: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4538: @node Inside
 4539: @subsection 履歴ファイルを移動する
 4540: 
 4541: この方法は、リポジトリ中のファイルの移動を含むため、
 4542: さらに危険です。
 4543: この節を全部読んでから実行して下さい。
 4544: 
 4545: @example
 4546: $ cd $CVSROOT/@var{dir}
 4547: $ mv @var{old},v @var{new},v
 4548: @end example
 4549: 
 4550: @noindent
 4551: 利点:
 4552: 
 4553: @itemize @bullet
 4554: @item
 4555: 変更の記録が完全に保たれる。
 4556: 
 4557: @item
 4558: リビジョン番号に影響がない。
 4559: @end itemize
 4560: 
 4561: @noindent
 4562: 欠点:
 4563: 
 4564: @itemize @bullet
 4565: @item
 4566: リポジトリから、古いリリースを簡単に復元できない。
 4567: (改名される以前のリビジョンでもファイルの名前が @var{new} になる。)
 4568: 
 4569: @item
 4570: ファイルがいつ改名されたかの記録がない。
 4571: 
 4572: @item
 4573: ファイルの移動の最中に、
 4574: 誰かが履歴ファイルにアクセスした場合、酷いことが起きる。
 4575: あなたがファイルを移動させている間は、
 4576: 誰にも @sc{cvs} コマンドを発行させてはいけません。
 4577: @end itemize
 4578: 
 4579: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4580: @node Rename by copying
 4581: @subsection 履歴ファイルをコピーする
 4582: 
 4583: この方法も、リポジトリ中のファイルの移動を含みます。
 4584: 欠点が無い訳ではありませんが、安全です。
 4585: 
 4586: @example
 4587: # @r{リポジトリ中の @sc{rcs} ファイルをコピーする}
 4588: $ cd $CVSROOT/@var{dir}
 4589: $ cp @var{old},v @var{new},v
 4590: # @r{以前のファイルを削除する}
 4591: $ cd ~/@var{dir}
 4592: $ rm @var{old}
 4593: $ cvs remove @var{old}
 4594: $ cvs commit @var{old}
 4595: # @r{@var{new} の全てのタグを削除する}
 4596: $ cvs update @var{new}
 4597: $ cvs log @var{new}             # @r{枝でないタグ名を思い出す}
 4598: $ cvs tag -d @var{tag1} @var{new}
 4599: $ cvs tag -d @var{tag2} @var{new}
 4600: @dots{}
 4601: @end example
 4602: 
 4603: タグを削除することで、
 4604: 以前のリビジョンを復元することができます。
 4605: 
 4606: @noindent
 4607: 利点:
 4608: 
 4609: @itemize @bullet
 4610: @item
 4611: @c FIXME: Is this true about -D now that we have death
 4612: @c support?  See 5B.3 in the FAQ.
 4613: リビジョンの取得に @samp{-D@var{date}} を使わないで、
 4614: @samp{-r@var{tag}} を使う限り、以前のリビジョンのファイルを正しく復元
 4615: できる。
 4616: 
 4617: @item
 4618: 変更の記録を完全に維持できる。
 4619: 
 4620: @item
 4621: リビジョン番号に影響しない。
 4622: @end itemize
 4623: 
 4624: @noindent
 4625: 欠点:
 4626: 
 4627: @itemize @bullet
 4628: @item
 4629: 改名の前後で履歴を辿ることが困難である。
 4630: 
 4631: @ignore
 4632: @c Is this true?  I don't see how the revision numbers
 4633: @c _could_ start over, when new,v is just old,v with
 4634: @c the tags deleted.
 4635: @c If there is some need to reinstate this text,
 4636: @c it is "usually 1.1", not "1.0" and it needs an
 4637: @c xref to Assigning revisions
 4638: @item
 4639: @samp{-r rev} フラグを付けて @code{commit} しないと、
 4640: @var{new} のリビジョン番号はまた 1.0 から始まる
 4641: (@pxref{commit options})。
 4642: @end ignore
 4643: @end itemize
 4644: 
 4645: @c ---------------------------------------------------------------------
 4646: @node Moving directories
 4647: @section ディレクトリの改名と移動
 4648: @cindex Moving directories
 4649: @cindex Renaming directories
 4650: @cindex Directories, moving
 4651: 
 4652: ディレクトリの改名と移動の普通の方法は @ref{Outside} で説明されている
 4653: ようにその中のそれぞれのファイルを改名もしくは移動することです。それか
 4654: ら @ref{Removing directories} に説明されているように @samp{-P} オプショ
 4655: ンを付けて取り出します。
 4656: 
 4657: 本当にリポジトリの中身を変更してディレクトリを改名したり削除したければ、
 4658: 次のようにしてください:
 4659: 
 4660: @enumerate
 4661: @item
 4662: ディレクトリを改名する前に、
 4663: ディレクトリの作業コピーを取り出している全ての人に、
 4664: その旨を知らせます。
 4665: 次のステップに進む前に、彼等全員が変更内容を格納し、
 4666: 作業コピーを削除しなければなりません。
 4667: 
 4668: @item
 4669: リポジトリ中のディレクトリを改名します。
 4670: 
 4671: @example
 4672: $ cd $CVSROOT/@var{parent-dir}
 4673: $ mv @var{old-dir} @var{new-dir}
 4674: @end example
 4675: 
 4676: @item
 4677: @sc{cvs} の管理用ファイルを修正します。
 4678: (例えばモジュール名を改名する場合等)。
 4679: 
 4680: @item
 4681: 再び取り出して作業を続けられることを、
 4682: 全員に知らせます。
 4683: 
 4684: @end enumerate
 4685: 
 4686: 誰かが作業コピーを消さずに持っていた場合、
 4687: 彼がリポジトリから消されたディレクトリを削除するまで、
 4688: 彼の発行する @sc{cvs} コマンドは無視されます。
 4689: 
 4690: ディレクトリを移動させるよりは、
 4691: ディレクトリ中のファイルを移動させる方を推奨します。
 4692: ディレクトリを移動させれば、
 4693: ディレクトリ名に依存している古いリリースを正確に復元する事は、
 4694: ほとんど不可能になります。
 4695: 
 4696: @c ---------------------------------------------------------------------
 4697: @node History browsing
 4698: @chapter 履歴の閲覧
 4699: @cindex History browsing
 4700: @cindex Traceability
 4701: @cindex Isolation
 4702: 
 4703: @ignore
 4704: @c This is too long for an introduction (goal is
 4705: @c one 20x80 character screen), and also mixes up a
 4706: @c variety of issues (parallel development, history,
 4707: @c maybe even touches on process control).
 4708: 
 4709: @c -- @quote{To lose ones history is to lose ones soul.}
 4710: @c -- ///
 4711: @c -- ///Those who cannot remember the past are condemned to repeat it.
 4712: @c -- ///               -- George Santayana
 4713: @c -- ///
 4714: 
 4715: @sc{cvs} tries to make it easy for a group of people to work
 4716: together.  This is done in two ways:
 4717: 
 4718: @itemize @bullet
 4719: @item
 4720: Isolation---You have your own working copy of the
 4721: source.  You are not affected by modifications made by
 4722: others until you decide to incorporate those changes
 4723: (via the @code{update} command---@pxref{update}).
 4724: 
 4725: @item 
 4726: Traceability---When something has changed, you can
 4727: always see @emph{exactly} what changed.
 4728: @end itemize
 4729: 
 4730: There are several features of @sc{cvs} that together lead
 4731: to traceability:
 4732: 
 4733: @itemize @bullet
 4734: @item
 4735: Each revision of a file has an accompanying log
 4736: message.
 4737: 
 4738: @item
 4739: All commits are optionally logged to a central history
 4740: database.
 4741: 
 4742: @item
 4743: Logging information can be sent to a user-defined
 4744: program (@pxref{loginfo}).
 4745: @end itemize
 4746: 
 4747: @c -- More text here.
 4748: 
 4749: This chapter should talk about the history file, the
 4750: @code{log} command, the usefulness of ChangeLogs
 4751: even when you run @sc{cvs}, and things like that.
 4752: 
 4753: @end ignore
 4754: 
 4755: @c kind of lame, in a lot of ways the above text inside
 4756: @c the @ignore motivates this chapter better
 4757: 何時、誰が、どのように、どのファイルを変更したか、
 4758: といったバージョン管理の履歴を @sc{cvs} を使って保存してきたならば、
 4759: 様々な機構を用いてこの履歴を調べることができます。
 4760: 
 4761: @c FIXME: should also be talking about how you look at
 4762: @c old revisions (e.g. "cvs update -p -r 1.2 foo.c").
 4763: @menu
 4764: * log messages::                ログ・メッセージ
 4765: * history database::            履歴データベース
 4766: * user-defined logging::        ログ方法を使用者自身が設定する
 4767: * annotate::                    各行がどのリビジョンで変更されたか?
 4768: @end menu
 4769: 
 4770: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4771: @node log messages
 4772: @section ログ・メッセージ
 4773: 
 4774: @c FIXME: @xref to place where we talk about how to
 4775: @c specify message to commit.
 4776: ファイルを格納する時には、必ずログ・メッセージを記述します。
 4777: 
 4778: @c FIXME: bring the information here, and get rid of or
 4779: @c greatly shrink the "log" node.
 4780: 各リビジョンの格納時に記述されたログ・メッセージを調べる場合、
 4781: @code{cvs log} コマンドを使用します (@pxref{log})。
 4782: 
 4783: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4784: @node history database
 4785: @section 履歴データベース
 4786: 
 4787: @c FIXME: bring the information from the history file
 4788: @c and history nodes here.  Rewrite it to be motivated
 4789: @c better (start out by clearly explaining what gets
 4790: @c logged in history, for example).
 4791: 様々な @sc{cvs} の実行履歴を記録するために、
 4792: ファイル @file{history} が使用できます (@pxref{history file})。
 4793: ファイル @file{history} の情報を検索するには、
 4794: @code{cvs history} コマンドを使用して下さい (@pxref{history})。
 4795: @c
 4796: @c The history database has many problems:
 4797: @c * It is very unclear what field means what.  This
 4798: @c could be improved greatly by better documentation,
 4799: @c but there are still non-orthogonalities (for
 4800: @c example, tag does not record the "repository"
 4801: @c field but most records do).
 4802: @c * Confusion about files, directories, and modules.
 4803: @c Some commands record one, some record others.
 4804: @c * File removal is not logged.  There is an 'R'
 4805: @c record type documented, but CVS never uses it.
 4806: @c * Tags are only logged for the "cvs rtag" command,
 4807: @c not "cvs tag".  The fix for this is not completely
 4808: @c clear (see above about modules vs. files).
 4809: @c * Are there other cases of operations that are not
 4810: @c logged?  One would hope for all changes to the
 4811: @c repository to be logged somehow (particularly
 4812: @c operations like tagging, "cvs admin -k", and other
 4813: @c operations which do not record a history that one
 4814: @c can get with "cvs log").  Operations on the working
 4815: @c directory, like export, get, and release, are a
 4816: @c second category also covered by the current "cvs
 4817: @c history".
 4818: @c * The history file does not record the options given
 4819: @c to a command.  The most serious manifestation of
 4820: @c this is perhaps that it doesn't record whether a command
 4821: @c was recursive.  It is not clear to me whether one
 4822: @c wants to log at a level very close to the command
 4823: @c line, as a sort of way of logging each command
 4824: @c (more or less), or whether one wants
 4825: @c to log more at the level of what was changed (or
 4826: @c something in between), but either way the current
 4827: @c information has pretty big gaps.
 4828: @c * Further details about a tag--like whether it is a
 4829: @c branch tag or, if a non-branch tag, which branch it
 4830: @c is on.  One can find out this information about the
 4831: @c tag as it exists _now_, but if the tag has been
 4832: @c moved, one doesn't know what it was like at the time
 4833: @c the history record was written.
 4834: @c * Whether operating on a particular tag, date, or
 4835: @c options was implicit (sticky) or explicit.
 4836: @c
 4837: @c Another item, only somewhat related to the above, is a
 4838: @c way to control what is logged in the history file.
 4839: @c This is probably the only good way to handle
 4840: @c different people having different ideas about
 4841: @c information/space tradeoffs.
 4842: @c
 4843: @c It isn't really clear that it makes sense to try to
 4844: @c patch up the history file format as it exists now to
 4845: @c include all that stuff.  It might be better to
 4846: @c design a whole new CVSROOT/nhistory file and "cvs
 4847: @c nhistory" command, or some such, or in some other
 4848: @c way trying to come up with a clean break from the
 4849: @c past, which can address the above concerns.  Another
 4850: @c open question is how/whether this relates to
 4851: @c taginfo/loginfo/etc.
 4852: 
 4853: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4854: @node user-defined logging
 4855: @section ログ方法を使用者自身が設定する
 4856: 
 4857: @c FIXME: should probably also mention the fact the -l
 4858: @c global option can disable most of the mechanisms
 4859: @c discussed here (why?  What is the -l global option for?).
 4860: @c
 4861: @c FIXME: probably should centralize this information
 4862: @c here, at least to some extent.  Maybe by moving the
 4863: @c loginfo, etc., nodes here and replacing
 4864: @c the "user-defined logging" node with one node for
 4865: @c each method.
 4866: @sc{cvs} を用いた様々な作業の履歴は、
 4867: 利用者自身が選択する方法で記録されます。
 4868: @sc{cvs} は、様々な場面でスクリプトを実行し、
 4869: この機構を実現します。
 4870: これらのスクリプトには、
 4871: ログ・ファイルに情報を追記したり、
 4872: 開発者グループにメールを送ったり、
 4873: 特定のニュース・グループに記事を投稿したりするものがあります。
 4874: 格納時のログ方法は @file{loginfo} で設定します(@pxref{loginfo})。
 4875: @c FIXME: What is difference between doing it in the
 4876: @c modules file and using loginfo/taginfo?  Why should
 4877: @c user use one or the other?
 4878: commit, checkout, export, tag
 4879: 等を実行した時のログ方法は、
 4880: 各々オプション @samp{-i}, @samp{-o}, @samp{-e}, @samp{-t} を用いて、
 4881: modules ファイルに設定できます。
 4882: これらのスクリプトほどのものは必要としない使用者にも、
 4883: @code{cvs watch add} コマンドを使用して、
 4884: 様々な告知をする弾力的な方法を提供します(@pxref{Getting Notified})。
 4885: この方法は @code{cvs watch on} を使用していない場合でも利用できます。
 4886: 
 4887: @cindex taginfo
 4888: @cindex Exit status, of taginfo
 4889: 誰かが @code{tag} か @code{rtag} コマンドを実行した時に
 4890: 実行されるプログラムを、@file{taginfo} ファイルに設定します。
 4891: 管理用ファイルの標準書式に従い(@pxref{Administrative files})、
 4892: @file{taginfo} の各行には、
 4893: 正規表現に続いて実行されるコマンドが記述されます。
 4894: コマンドに渡される引数を順に挙げると、
 4895: @var{タグ名}, @var{操作}(@code{tag} なら @code{add},
 4896: @code{tag -F} なら @code{mov}, @code{tag -d} なら @code{del}),
 4897: @var{リポジトリ}, 残りは全て @var{ファイル名} と @var{リビジョン} の組
 4898: です。
 4899: フィルタ・プログラムが非零で終了した場合は、
 4900: タグ処理が中止されます。
 4901: 
 4902: これは taginfo を使って tag と rtag コマンドのログを取る例です。
 4903: taginfo ファイルには以下のものを入れます:
 4904: 
 4905: @example
 4906: ALL /usr/local/cvsroot/CVSROOT/loggit
 4907: @end example
 4908: 
 4909: @file{/usr/local/cvsroot/CVSROOT/loggit} は以下のスクリプトになってい
 4910: ます:
 4911: 
 4912: @example
 4913: #!/bin/sh
 4914: echo "$@@" >>/home/kingdon/cvsroot/CVSROOT/taglog
 4915: @end example
 4916: 
 4917: @node annotate
 4918: @section コマンド annotate
 4919: @cindex annotate (subcommand)
 4920: 
 4921: @deffn コマンド {cvs annotate} [@code{-flR}] [@code{-r rev}|@code{-D date}] files @dots{}
 4922: 
 4923: @var{files} で指定された各ファイルについて、
 4924: 幹の先頭リビジョンの内容と、各行が最後に修正された時の情報を、
 4925: 併せて表示します。
 4926: 以下に例示します:
 4927: 
 4928: @example
 4929: $ cvs annotate ssfile
 4930: Annotations for ssfile
 4931: ***************
 4932: 1.1          (mary     27-Mar-96): ssfile line 1
 4933: 1.2          (joe      28-Mar-96): ssfile line 2
 4934: @end example
 4935: 
 4936: ファイル @file{ssfile} は現在 2行から成り、
 4937: @code{ssfile line 1} という行は 3月 27日に @code{mary} が格納しました。
 4938: そして 3月 28日に @code{joe} が、
 4939: @code{ssfile line 1} という行を修正せずに、
 4940: @code{ssfile line 2} という行を格納しました。
 4941: この報告では、削除されたり修正された行については何も分らないので、
 4942: @code{cvs diff} を用いる必要があるでしょう(@pxref{diff})。
 4943: 
 4944: @end deffn
 4945: 
 4946: @code{cvs annotate} へのオプションは @ref{Invoking CVS} で一覧にされて
 4947: ていて、annotate するファイルとリビジョンを選択するために使うことがで
 4948: きます。オプションは @ref{Common options} でより詳しく説明されています。
 4949: 
 4950: @c FIXME: maybe an example using the options?  Just
 4951: @c what it means to select a revision might be worth a
 4952: @c few words of explanation ("you want to see who
 4953: @c changed this line *before* 1.4"...).
 4954: 
 4955: @c ---------------------------------------------------------------------
 4956: @node Binary files
 4957: @chapter バイナリ・ファイルの扱い
 4958: @cindex Binary files
 4959: 
 4960: 最も普通の @sc{cvs} の使用はテキスト・ファイルの保管です。テキスト・ファ
 4961: イルでは、@sc{cvs} はリビジョンをマージしたり、リビジョン間の違いを人
 4962: 間が読める形式で表示したり、他の似たような操作をすることができます。し
 4963: かし、これらの中のいくつかの機能を諦めることで、@sc{cvs} はバイナリ・
 4964: ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ
 4965: 画像の両方からなるウェブサイトを @sc{cvs} で保管するかもしれません。
 4966: 
 4967: @menu
 4968: * Binary why::     バイナリ・ファイルの問題の詳細
 4969: * Binary howto::   保管方法
 4970: @end menu
 4971: 
 4972: @node Binary why
 4973: @section バイナリ・ファイルの問題
 4974: 
 4975: 普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必
 4976: 要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ
 4977: せます。
 4978: 
 4979: バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。
 4980: 例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して
 4981: いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ
 4982: イルには、@sc{cvs} は @code{cvs diff} コマンドでこの機能を提供します。
 4983: バイナリ・ファイルには、2つのリビジョンを取り出して、@sc{cvs} の外部に
 4984: あるプログラムで比較することができるでしょう (例えば、ワープロにはよく
 4985: そのような機能があります)。もしそのようなツールがなければ、人に良いロ
 4986: グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実
 4987: 際にした変更が本当にそうしたいと思っている変更そのものであることを期待
 4988: しなければなりません。
 4989: 
 4990: バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。
 4991: @sc{cvs} ではこれは2つの文脈で発生します。1つめは使用者が分離された作
 4992: 業ディレクトリで変更をしたときです (@pxref{Multiple developers})。2つ
 4993: 目は @samp{update -j} コマンドで明示的にマージしたときです 
 4994: (@pxref{Branching and merging})。
 4995: 
 4996: テキスト・ファイルの場合は、@sc{cvs} は独立になされた変更をマージでき、
 4997: 変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、
 4998: @sc{cvs} にできることは、せいぜい2つの違ったファイルのコピーを出して、
 4999: 使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー
 5000: を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール
 5001: があればそれを実行するかもしれません。使用者にマージをさせることは、主
 5002: に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して
 5003: おり、エラーが発生する可能性が高いということに注意してください。
 5004: 
 5005: この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別
 5006: の作業ディレクトリによるマージを避けるためには、@ref{Multiple
 5007: developers} の独占取得 (ファイル占有) の議論を参照してください。枝によ
 5008: るマージを避けるためには、枝の使用を制限してください。
 5009: 
 5010: @node Binary howto
 5011: @section バイナリ・ファイルを保管する方法
 5012: 
 5013: @sc{cvs} でバイナリ・ファイルを保管する際の問題点が二つあります。
 5014: 一つ目は、@sc{cvs} がファイルを取り出す際に、
 5015: リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、
 5016: クライアント側のオペレーティングシステムに適した形式に変換する事です 
 5017: (例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり
 5018: ます)。
 5019: 
 5020: 二つ目の問題点は、キーワードと同じデータが
 5021: 偶然バイナリ・ファイルに含まれる可能性がある事です 
 5022: (@pxref{Keyword substitution})。
 5023: そのためキーワード展開を無効にする必要があります。
 5024: 
 5025: @c FIXME: the third is that one can't do merges with
 5026: @c binary files.  xref to Multiple Developers and the
 5027: @c reserved checkout issues.
 5028: 
 5029: 幾つかの @sc{cvs} コマンドで @samp{-kb} オプションを用いれば、
 5030: 確実に行末変換とキーワード展開を止めることができます。
 5031: 
 5032: @samp{-kb} フラグを用いて新しいファイルを登録する方法を、
 5033: 以下に例示します:
 5034: 
 5035: @example
 5036: $ echo '$@asis{}Id$' > kotest
 5037: $ cvs add -kb -m"A test file" kotest
 5038: $ cvs ci -m"First checkin; contains a keyword" kotest
 5039: @end example
 5040: 
 5041: ふと油断して @samp{-kb} 無しでファイルを加えてしまった場合、
 5042: @code{cvs admin} コマンドを使用して正常な状態に戻す必要があります。
 5043: 以下に例示します:
 5044: 
 5045: @example
 5046: $ echo '$@asis{}Id$' > kotest
 5047: $ cvs add -m"A test file" kotest
 5048: $ cvs ci -m"First checkin; contains a keyword" kotest
 5049: $ cvs admin -kb kotest
 5050: $ cvs update -A kotest
 5051: # @r{For non-unix systems:}
 5052: # @r{Copy in a good copy of the file from outside CVS}
 5053: $ cvs commit -m "make it binary" kotest
 5054: @end example
 5055: 
 5056: @c Trying to describe this for both unix and non-unix
 5057: @c in the same description is very confusing.  Might
 5058: @c want to split the two, or just ditch the unix "shortcut"
 5059: @c (unixheads don't do much with binary files, anyway).
 5060: @c This used to say "(Try the above example, and do a
 5061: @c @code{cat kotest} after every command)".  But that
 5062: @c only really makes sense for the unix case.
 5063: ファイル @file{kotest} を格納した時はファイルはバイナリ・ファイルとし
 5064: ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ
 5065: たからです。
 5066: @samp{cvs admin -kb} コマンドでファイルの置換モードを設定しますが、
 5067: 既にある作業コピーは変更してくれません。
 5068: 行末を適切に処理する必要がある場合 (@sc{cvs} のクライアントとして 
 5069: unix 以外のシステムを使用している場合) は、
 5070: 上記の例に示した @code{cvs commit} コマンドのように、
 5071: 新たにファイルのコピーを格納する必要があります。
 5072: Unix では、@samp{cvs update -A} で十分です。
 5073: @c FIXME: should also describe what the *other users*
 5074: @c need to do, if they have checked out copies which
 5075: @c have been corrupted by lack of -kb.  I think maybe
 5076: @c "cvs update -kb" or "cvs
 5077: @c update -A" would suffice, although the user who
 5078: @c reported this suggested removing the file, manually
 5079: @c removing it from CVS/Entries, and then "cvs update"
 5080: 
 5081: ここで、@samp{cvs admin -k} を用いて置換モードを変更しても、
 5082: この置換モードはバージョン管理されないことを認識しておいて下さい。
 5083: これは例えば古いリリースにテキスト・ファイルがあり、
 5084: 新しいリリースに同じ名前のバイナリ・ファイルがあった場合、
 5085: バージョンによってテキストとバイナリを区別して取り出す方法を、
 5086: @sc{cvs} が備えていないことを意味しています。
 5087: この問題を解決する方法は今のところありません。
 5088: 
 5089: @code{cvs add} や @code{cvs import} を実行する際、
 5090: 既定でバイナリとして扱うかどうかを、
 5091: ファイルの名前によって判断するように設定もできます。
 5092: 例えば、ファイル名が @samp{.exe} で終わるファイルを
 5093: バイナリと判断するように設定できます。@xref{Wrappers}.
 5094: 現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ
 5095: ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの
 5096: 区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに
 5097: 応じてかなり異なるであろうということです。
 5098: @c For example, it would be good on MS-DOS-family OSes
 5099: @c for anything containing ^Z to be binary.  Having
 5100: @c characters with the 8th bit set imply binary is almost
 5101: @c surely a bad idea in the context of ISO-8859-* and
 5102: @c other such character sets.  On VMS or the Mac, we
 5103: @c could use the OS's file typing.  This is a
 5104: @c commonly-desired feature, and something of this sort
 5105: @c may make sense.  But there are a lot of pitfalls here.
 5106: @c
 5107: @c Another, probably better, way to tell is to read the
 5108: @c file in text mode, write it to a temp file in text
 5109: @c mode, and then do a binary mode compare of the two
 5110: @c files.  If they differ, it is a binary file.  This
 5111: @c might have problems on VMS (or some other system
 5112: @c with several different text modes), but in general
 5113: @c should be relatively portable.  The only other
 5114: @c downside I can think of is that it would be fairly
 5115: @c slow, but that is perhaps a small price to pay for
 5116: @c not having your files corrupted.  Another issue is
 5117: @c what happens if you import a text file with bare
 5118: @c linefeeds on Windows.  Such files will show up on
 5119: @c Windows sometimes (I think some native windows
 5120: @c programs even write them, on occasion).  Perhaps it
 5121: @c is reasonable to treat such files as binary; after
 5122: @c all it is something of a presumption to assume that
 5123: @c the user would want the linefeeds converted to CRLF.
 5124: 
 5125: @c ---------------------------------------------------------------------
 5126: @node Multiple developers
 5127: @chapter 複数の開発者
 5128: @cindex Multiple developers
 5129: @cindex Team of developers
 5130: @cindex File locking
 5131: @cindex Locking files
 5132: @cindex Working copy
 5133: @cindex Reserved checkouts
 5134: @cindex Unreserved checkouts
 5135: @cindex RCS-style locking
 5136: 
 5137: 複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。
 5138: 例えば二人の人物が、
 5139: 同じファイルを同時に編集しようとすることがよくあります。
 5140: 解決策の一つは、
 5141: @dfn{ファイル占有} (@dfn{file locking}) または @dfn{独占取得} 
 5142: (@dfn{reserved checkouts}) と呼ばれるもので、
 5143: 同時にファイルを編集できる人数を一人に制限するものです。
 5144: @sc{rcs} や @sc{sccs} 等の履歴管理システムでは、
 5145: これが唯一の方法です。
 5146: 現時点では @sc{cvs} で独占取得をする普通の方法は @code{cvs admin -l}
 5147: コマンドです (@pxref{admin options})。これは後述する監視機能のように 
 5148: @sc{cvs} によく実装されてはいませんが、独占取得を必要なほとんどの人は
 5149: 十分だと思うでしょう。
 5150: @c Or "find it better than worrying about implementing
 5151: @c nicely integrated reserved checkouts" or ...?
 5152: また後述する監視機構を適切な手順を踏んで用いることでも (ソフトウェアか
 5153: らは強制されません)、同時編集を避けることが可能でしょう。
 5154: 
 5155: @c Our unreserved checkout model might not
 5156: @c be quite the same as others.  For example, I
 5157: @c think that some systems will tend to create a branch
 5158: @c in the case where CVS prints "up-to-date check failed".
 5159: @c It isn't clear to me whether we should try to
 5160: @c explore these subtleties; it could easily just
 5161: @c confuse people.
 5162: @sc{cvs} の既定モデルは@dfn{無条件取得} 
 5163: (@dfn{unreserved checkouts}) と呼ばれるものです。
 5164: このモデルでは、
 5165: 開発者がそれぞれ自分の @dfn{作業コピー} 
 5166: (@dfn{working copy}) のファイルを同時に編集できます。
 5167: 最初に変更を格納した人物は、
 5168: 他の人物が編集を始めたことが自動的には分りません。
 5169: 二番目の人物が格納する時にはエラー表示を受けますから、
 5170: @sc{cvs} コマンドを用いて、
 5171: 自分の作業コピーをリポジトリのリビジョンの最新のものにする
 5172: 必要があります。
 5173: この手順はほぼ自動化されています。
 5174: 
 5175: @c FIXME? should probably use the word "watch" here, to
 5176: @c tie this into the text below and above.
 5177: @sc{cvs} は、独占取得がするような規則を強制することなく、
 5178: 種々の意志疎通を容易にする仕組みを用意しています。
 5179: 
 5180: この章の残りでは、色々なモデルの動作方法と、
 5181: 各モデルの選択に伴なう問題点について述べます。
 5182: 
 5183: @ignore
 5184: Here is a draft reserved checkout design or discussion
 5185: of the issues.  This seems like as good a place as any
 5186: for this.
 5187: 
 5188: Might want a cvs lock/cvs unlock--in which the names
 5189: differ from edit/unedit because the network must be up
 5190: for these to work.  unedit gives an error if there is a
 5191: reserved checkout in place (so that people don't
 5192: accidentally leave locks around); unlock gives an error
 5193: if one is not in place (this is more arguable; perhaps
 5194: it should act like unedit in that case).
 5195: 
 5196: On the other hand, might want it so that emacs,
 5197: scripts, etc., can get ready to edit a file without
 5198: having to know which model is in use.  In that case we
 5199: would have a "cvs watch lock" (or .cvsrc?) (that is,
 5200: three settings, "on", "off", and "lock").  Having cvs
 5201: watch lock set would cause a get to record in the CVS
 5202: directory which model is in use, and cause "cvs edit"
 5203: to change behaviors.  We'd want a way to query which
 5204: setting is in effect (this would be handy even if it is
 5205: only "on" or "off" as presently).  If lock is in
 5206: effect, then commit would require a lock before
 5207: allowing a checkin; chmod wouldn't suffice (might be
 5208: debatable--see chmod comment below, in watches--but it
 5209: is the way people expect RCS to work and I can't think
 5210: of any significant downside.  On the other hand, maybe
 5211: it isn't worth bothering, because people who are used
 5212: to RCS wouldn't think to use chmod anyway).
 5213: 
 5214: Implementation: use file attributes or use RCS
 5215: locking.  The former avoids more dependence on RCS
 5216: behaviors we will need to reimplement as we librarify
 5217: RCS, and makes it easier to import/export RCS files (in
 5218: that context, want to ignore the locker field).  But
 5219: note that RCS locks are per-branch, which is the
 5220: correct behavior (this is also an issue for the "watch
 5221: on" features; they should be per-branch too).
 5222: 
 5223: Here are a few more random notes about implementation
 5224: details, assuming "cvs watch lock" and
 5225: 
 5226: CVS/Watched file?  Or try to fit this into CVS/Entries somehow?
 5227: Cases: (1) file is checked out (unreserved or with watch on) by old
 5228: version of CVS, now we do something with new one, (2) file is checked
 5229: out by new version, now we do something with old one.
 5230: 
 5231: Remote protocol would have a "Watched" analogous to "Mode".  Of course
 5232: it would apply to all Updated-like requests.  How do we keep this
 5233: setting up to date?  I guess that there wants to be a Watched request,
 5234: and the server would send a new one if it isn't up to date? (Ugh--hard
 5235: to implement and slows down "cvs -q update"--is there an easier way?)
 5236: 
 5237: "cvs edit"--checks CVS/Watched, and if watch lock, then sends
 5238: "edit-lock" request.  Which comes back with a Checked-in with
 5239: appropriate Watched (off, on, lock, locked, or some such?), or error
 5240: message if already locked.
 5241: 
 5242: "cvs commit"--only will commit if off/on/locked.  lock is not OK.
 5243: 
 5244: Doc:
 5245: note that "cvs edit" must be connected to network if watch lock is in
 5246: effect.
 5247: 
 5248: Talk about what to do if someone has locked a file and you want to
 5249: edit that file.  (breaking locks, or lack thereof).
 5250: 
 5251: 
 5252: One other idea (which could work along with the
 5253: existing "cvs admin -l" reserved checkouts, as well as
 5254: the above):
 5255: 
 5256: "cvs editors" could show who has the file locked, if
 5257: someone does.
 5258: 
 5259: @end ignore
 5260: 
 5261: @menu
 5262: * File status::                 ファイルは幾つかの状態を取る
 5263: * Updating a file::             ファイルを最新にする
 5264: * Conflicts example::           有益な実行例
 5265: * Informing others::            協力のために他の人にお知らせする
 5266: * Concurrency::                 リポジトリの同時利用
 5267: * Watches::                     ファイル編集者の追跡機構
 5268: * Choosing a model::            独占取得か無条件取得か?
 5269: @end menu
 5270: 
 5271: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5272: @node File status
 5273: @section ファイル状態
 5274: @cindex File status
 5275: @cindex Status of a file
 5276: 
 5277: @c Shouldn't this start with an example or something,
 5278: @c introducing the unreserved checkout model?  Before we
 5279: @c dive into listing states?
 5280: 取り出した後にあなたが加えた操作や、
 5281: 他の人物がリポジトリに加えた操作によって、
 5282: ファイルを幾つかの状態に分類します。
 5283: @code{status} コマンドによって報告される状態を以下に挙げます:
 5284: 
 5285: @c The order of items is chosen to group logically
 5286: @c similar outputs together.
 5287: @c People who want alphabetical can use the index...
 5288: @table @asis
 5289: @cindex Up-to-date
 5290: @item Up-to-date
 5291: このファイルが、
 5292: 使用している枝の最新リビジョンと同じであることを示します。
 5293: @c FIXME: should we clarify "in use"?  The answer is
 5294: @c sticky tags, and trying to distinguish branch sticky
 5295: @c tags from non-branch sticky tags seems rather awkward
 5296: @c here.
 5297: @c FIXME: What happens with non-branch sticky tags?  Is
 5298: @c a stuck file "Up-to-date" or "Needs checkout" or what?
 5299: 
 5300: @item Locally Modified
 5301: @cindex Locally Modified
 5302: このファイルを修正したが、まだ変更内容を格納してないことを示します。
 5303: 
 5304: @item Locally Added
 5305: @cindex Locally Added
 5306: @code{add} コマンドによりファイルを加えたが、
 5307: まだその内容を格納してないことを示します。
 5308: @c There are many cases involving the file being
 5309: @c added/removed/modified in the working directory, and
 5310: @c added/removed/modified in the repository, which we
 5311: @c don't try to describe here.  I'm not sure that "cvs
 5312: @c status" produces a non-confusing output in most of
 5313: @c those cases.
 5314: 
 5315: @item Locally Removed
 5316: @cindex Locally Removed
 5317: @code{remove} コマンドによりファイルを削除したが、
 5318: まだその変更を格納してないことを示します。
 5319: 
 5320: @item Needs Checkout
 5321: @cindex Needs Checkout
 5322: 他の人物が新しいリビジョンをリポジトリに格納したことを示します。
 5323: この表示は少し紛らわしいのですが、
 5324: 新しいリビジョンを取り出す際には、@code{checkout} ではなく、
 5325: @code{update} を使用するのが普通です。
 5326: 
 5327: @item Needs Patch
 5328: @cindex Needs Patch
 5329: @c See also newb-123j0 in sanity.sh (although that case
 5330: @c should probably be changed rather than documented).
 5331: Needs Checkout と似たようなものですが、
 5332: @sc{cvs} のサーバは、ファイル全てではなく差分を送ります。
 5333: 差分を送る場合も、ファイル全てを送る場合と結果は同じです。
 5334: 
 5335: @item Needs Merge
 5336: @cindex Needs Merge
 5337: 他の人物が新しいリビジョンをリポジトリに格納したが、
 5338: 作業ファイルも修正されていたため、マージする必要があることを示します。
 5339: 
 5340: @item File had conflicts on merge
 5341: @cindex File had conflicts on merge
 5342: @c is it worth saying that this message was "Unresolved
 5343: @c Conflict" in CVS 1.9 and earlier?  I'm inclined to
 5344: @c think that is unnecessarily confusing to new users.
 5345: Locally Modified と似ていますが、先の @code{update} コマンドの結果、
 5346: 変更点の衝突が発見されたことを示します。
 5347: 衝突を解消する方法は @ref{Conflicts example} 参照。
 5348: 
 5349: @item Unknown
 5350: @cindex Unknown
 5351: このファイルについて @sc{cvs} が何も知らないことを示します。
 5352: 例えば新たなファイルを作成したが、@code{add} を実行していない場合などです。
 5353: @c
 5354: @c "Entry Invalid" and "Classify Error" are also in the
 5355: @c status.c.  The latter definitely indicates a CVS bug
 5356: @c (should it be worded more like "internal error" so
 5357: @c people submit bug reports if they see it?).  The former
 5358: @c I'm not as sure; I haven't tracked down whether/when it
 5359: @c appears in "cvs status" output.
 5360: 
 5361: @end table
 5362: 
 5363: @code{status} は、ファイル状態を分類する際の補助として、
 5364: 作業中のファイルの由来となるリビジョン
 5365: を示す @samp{Working revision} と、
 5366: 使用中の枝のリポジトリにおける最新リビジョン
 5367: を示す @samp{Repository revision} とも報告します。
 5368: @c FIXME: should we clarify "in use"?  The answer is
 5369: @c sticky tags, and trying to distinguish branch sticky
 5370: @c tags from non-branch sticky tags seems rather awkward
 5371: @c here.
 5372: @c FIXME: What happens with non-branch sticky tags?
 5373: @c What is the Repository Revision there?  See the
 5374: @c comment at vn_rcs in cvs.h, which is kind of
 5375: @c confused--we really need to document better what this
 5376: @c field contains.
 5377: @c Q: Should we document "New file!" and other such
 5378: @c outputs or are they self-explanatory?
 5379: @c FIXME: what about the date to the right of "Working
 5380: @c revision"?  It doesn't appear with client/server and
 5381: @c seems unnecessary (redundant with "ls -l") so
 5382: @c perhaps it should be removed for non-client/server too?
 5383: @c FIXME: Need some examples.
 5384: @c FIXME: Working revision can also be something like
 5385: @c "-1.3" for a locally removed file.  Not at all
 5386: @c self-explanatory (and it is possible that CVS should
 5387: @c be changed rather than documenting this).
 5388: 
 5389: @c Would be nice to have an @example showing output
 5390: @c from cvs status, with comments showing the xref
 5391: @c where each part of the output is described.  This
 5392: @c might fit in nicely if it is desirable to split this
 5393: @c node in two; one to introduce "cvs status" and one
 5394: @c to list each of the states.
 5395: @code{status} コマンドのオプションについての情報は、@ref{Invoking CVS}
 5396: 参照。
 5397: @samp{Sticky tag} と @samp{Sticky date} についての
 5398: 情報は、@ref{Sticky tags} 参照。
 5399: @samp{Sticky options} の情報は、@ref{update options} 
 5400: の @samp{-k} オプションを参照して下さい。
 5401: 
 5402: @code{status} と @code{update} コマンドは補完するようなものとして考え
 5403: ることができます。ファイルを最新にするためには @code{update} を使い、
 5404: @code{status} で @code{update} が何をするかをある程度知ることができま
 5405: す (もちろん、リポジトリの状態は実際に @code{update} を実行するまでに
 5406: 変化するかもしれません)。実際は、@code{status} コマンドで表示されるよ
 5407: り短い形式でコマンドに表示させたければ、次を実行することができます
 5408: 
 5409: @cindex update, to display file status
 5410: @example
 5411: $ cvs -n -q update
 5412: @end example
 5413: 
 5414: @samp{-n} オプションは実際に update をしないが、状態を表示するだけであ
 5415: る、ということです。@samp{-q} オプションはそれぞれのディレクトリ名の印
 5416: 字を避けます。@code{update} コマンドとこれらのオプションの情報は、
 5417: @ref{Invoking CVS} を参照してください。
 5418: 
 5419: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5420: @node Updating a file
 5421: @section ファイルを最新にする
 5422: @cindex Bringing a file up to date
 5423: @cindex Updating a file
 5424: @cindex Merging a file
 5425: @cindex Update, introduction
 5426: 
 5427: ファイルを更新もしくはマージしたい場合には、
 5428: @code{update} コマンドを使用します。
 5429: これは最新でないファイルに対しては @code{checkout} コマンドとほとんど
 5430: 等価です。
 5431: つまり、ファイルの最新リビジョンをリポジトリから取り出して、
 5432: 作業ディレクトリに置きます。
 5433: 
 5434: @code{update} コマンドを使用しても、
 5435: あなたの修正が失なわれることはありません。
 5436: より新しいバージョンが無い場合には、@code{update} は何もしません。
 5437: 新しいバージョンが存在し、かつ作業ファイルが修正されている場合、
 5438: @sc{cvs} は全ての変更を作業コピーにマージします。
 5439: 
 5440: 例えばリビジョン 1.4 を取り出して、編集を始めたとします。
 5441: その合間に他の人物がバージョン 1.5 を格納し、
 5442: またすぐに 1.6 になったとします。
 5443: ここで @code{update} コマンドを使用した場合、
 5444: @sc{cvs} は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。
 5445: 
 5446: @cindex Overlap
 5447: 1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、
 5448: @dfn{重複} (@dfn{overlap}) が起きます。
 5449: そして警告が表示され、ファイルには重複した行が両方並記されて、
 5450: 特別なマークで囲まれます。
 5451: @code{update} コマンドの詳細は @xref{update}.
 5452: 
 5453: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5454: @node Conflicts example
 5455: @section 衝突の例
 5456: @cindex Merge, an example
 5457: @cindex Example of merge
 5458: @cindex driver.c (merge example)
 5459: 
 5460: リビジョン 1.4 の @file{drive.c} は次のような内容とします:
 5461: 
 5462: @example
 5463: #include <stdio.h>
 5464: 
 5465: void main()
 5466: @{
 5467:     parse();
 5468:     if (nerr == 0)
 5469:         gencode();
 5470:     else
 5471:         fprintf(stderr, "No code generated.\n");
 5472:     exit(nerr == 0 ? 0 : 1);
 5473: @}
 5474: @end example
 5475: 
 5476: @noindent
 5477: リビジョン 1.6 では @file{drive.c} は次のようになっています:
 5478: 
 5479: @example
 5480: #include <stdio.h>
 5481: 
 5482: int main(int argc,
 5483:          char **argv)
 5484: @{
 5485:     parse();
 5486:     if (argc != 1)
 5487:     @{
 5488:         fprintf(stderr, "tc: No args expected.\n");
 5489:         exit(1);
 5490:     @}
 5491:     if (nerr == 0)
 5492:         gencode();
 5493:     else
 5494:         fprintf(stderr, "No code generated.\n");
 5495:     exit(!!nerr);
 5496: @}
 5497: @end example
 5498: 
 5499: @noindent
 5500: リビジョン 1.4 を元にしたあなたの @file{driver.c} の作業コピーは、
 5501: @samp{cvs update} の前に次ようになっています:
 5502: @c -- Really include "cvs"?
 5503: 
 5504: @example
 5505: #include <stdlib.h>
 5506: #include <stdio.h>
 5507: 
 5508: void main()
 5509: @{
 5510:     init_scanner();
 5511:     parse();
 5512:     if (nerr == 0)
 5513:         gencode();
 5514:     else
 5515:         fprintf(stderr, "No code generated.\n");
 5516:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5517: @}
 5518: @end example
 5519: 
 5520: @noindent
 5521: この時 @samp{cvs update} を実行してみます:
 5522: @c -- Really include "cvs"?
 5523: 
 5524: @example
 5525: $ cvs update driver.c
 5526: RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
 5527: retrieving revision 1.4
 5528: retrieving revision 1.6
 5529: Merging differences between 1.4 and 1.6 into driver.c
 5530: rcsmerge warning: overlaps during merge
 5531: cvs update: conflicts found in driver.c
 5532: C driver.c
 5533: @end example
 5534: 
 5535: @noindent
 5536: @cindex Conflicts (merge example)
 5537: @sc{cvs} は上記のように、衝突が起きたことが報告します。
 5538: あなたが編集したオリジナルのファイルは、
 5539: 無修正で @file{.#driver.c.1.4} という名前で保存されます。
 5540: @file{driver.c} の新しいバージョンは次のようになります:
 5541: 
 5542: @example
 5543: #include <stdlib.h>
 5544: #include <stdio.h>
 5545: 
 5546: int main(int argc,
 5547:          char **argv)
 5548: @{
 5549:     init_scanner();
 5550:     parse();
 5551:     if (argc != 1)
 5552:     @{
 5553:         fprintf(stderr, "tc: No args expected.\n");
 5554:         exit(1);
 5555:     @}
 5556:     if (nerr == 0)
 5557:         gencode();
 5558:     else
 5559:         fprintf(stderr, "No code generated.\n");
 5560: @asis{}<<<<<<< driver.c
 5561:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5562: @asis{}=======
 5563:     exit(!!nerr);
 5564: @asis{}>>>>>>> 1.6
 5565: @}
 5566: @end example
 5567: 
 5568: @noindent
 5569: @cindex Markers, conflict
 5570: @cindex Conflict markers
 5571: @cindex <<<<<<<
 5572: @cindex >>>>>>>
 5573: @cindex =======
 5574: 
 5575: 重複しなかった修正がどの様に作業コピーに組み込まれているか注意して下さ
 5576: い。
 5577: 重複した部分は
 5578: @samp{<<<<<<<}, @samp{=======} 及び @samp{>>>>>>>} 
 5579: ではっきりと囲まれています。
 5580: 
 5581: @cindex Resolving a conflict
 5582: @cindex Conflict resolution
 5583: ファイルを編集して衝突が起きた部分を解決し、
 5584: マークと間違った行を消します。
 5585: 最終的に次のようになったとします:
 5586: @c -- Add xref to the pcl-cvs manual when it talks
 5587: @c -- about this.
 5588: @example
 5589: #include <stdlib.h>
 5590: #include <stdio.h>
 5591: 
 5592: int main(int argc,
 5593:          char **argv)
 5594: @{
 5595:     init_scanner();
 5596:     parse();
 5597:     if (argc != 1)
 5598:     @{
 5599:         fprintf(stderr, "tc: No args expected.\n");
 5600:         exit(1);
 5601:     @}
 5602:     if (nerr == 0)
 5603:         gencode();
 5604:     else
 5605:         fprintf(stderr, "No code generated.\n");
 5606:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5607: @}
 5608: @end example
 5609: 
 5610: @noindent
 5611: 今やこのファイルを格納してリビジョン 1.7 とすることができます。
 5612: 
 5613: @example
 5614: $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
 5615: Checking in driver.c;
 5616: /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
 5617: new revision: 1.7; previous revision: 1.6
 5618: done
 5619: @end example
 5620: 
 5621: 衝突が起きたが未解決であるファイルは、安全を考慮して、
 5622: @sc{cvs} が格納することを拒否します。
 5623: 衝突を解決するとき、ファイルの編集時間を変更する必要があります。
 5624: 前のバージョンの @sc{cvs} では、ファイルに衝突マークがないことを確認す
 5625: る必要もありました。ファイルには正しく衝突マークがあるかもしれませんの
 5626: で (すなわち、行頭にある @samp{>>>>>>> } は衝突の印ではありません)、現
 5627: 在のバージョンの @sc{cvs} は警告を印字してファイルの格納を実行します。
 5628: @c The old behavior was really icky; the only way out
 5629: @c was to start hacking on
 5630: @c the @code{CVS/Entries} file or other such workarounds.
 5631: @c
 5632: @c If the timestamp thing isn't considered nice enough,
 5633: @c maybe there should be a "cvs resolved" command
 5634: @c which clears the conflict indication.  For a nice user
 5635: @c interface, this should be invoked by an interactive
 5636: @c merge tool like emerge rather than by the user
 5637: @c directly--such a tool can verify that the user has
 5638: @c really dealt with each conflict.
 5639: 
 5640: @cindex emerge
 5641: もしあなたが pcl-cvs (@sc{gnu} Emacs 用 @sc{cvs} フロントエンド) の、
 5642: 1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに 
 5643: emerge という Emacs パッケージが利用できます。
 5644: pcl-cvs の文書を見て下さい。
 5645: 
 5646: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5647: @node Informing others
 5648: @section 格納したことを他の人に知らせる
 5649: @cindex Informing others
 5650: @cindex Spreading information
 5651: @cindex Mail, automatic mail on commit
 5652: 
 5653: 新しいリビジョンが格納されたときに、
 5654: それを開発者全員に通知するようにしておくと便利でしょう。
 5655: @file{moduels} か @file{loginfo} ファイルの 
 5656: @samp{-i} オプションにより、この手順を自動化することができます 
 5657: @xref{modules}. @xref{loginfo}.
 5658: この機構により、例えば全ての開発者にメールを出したり、
 5659: ニュースに記事を投稿したりすることができます。
 5660: @c -- More text would be nice here.
 5661: 
 5662: @node Concurrency
 5663: @section 同時に CVS の実行を試みる複数の開発者
 5664: 
 5665: @cindex Locks, cvs, introduction
 5666: @c For a discussion of *why* CVS creates locks, see
 5667: @c the comment at the start of src/lock.c
 5668: 複数の開発者が同時に @sc{cvs} を実行しようとした場合、
 5669: 次のようなメッセージが表示されます:
 5670: 
 5671: @example
 5672: [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
 5673: @end example
 5674: 
 5675: @cindex #cvs.rfl, removing
 5676: @cindex #cvs.wfl, removing
 5677: @cindex #cvs.lock, removing
 5678: @sc{cvs} は 30秒毎に実行を試み、
 5679: まだ待つ必要があれば再度メッセージを表示し、
 5680: そうでなければ処理を続けます。
 5681: 不適当な程長く待ち続けているようならば、
 5682: ロックさせている人物を見付けて、
 5683: 実行中の cvs コマンドを訊いてみて下さい。
 5684: cvs コマンドが実行されてないのならば、メッセージで書かれているリポジト
 5685: リディレクトリを見て、彼等が所有している 
 5686: @file{#cvs.tfl}, @file{#cvs.rfl}, @file{#cvs.wfl} 
 5687: という名前で始まるファイルを捜して、削除して下さい。
 5688: 
 5689: このロックは @sc{cvs} の内部データ構造を保護するもので、
 5690: @sc{rcs} で使用される@dfn{ロック} (@dfn{lock}) 
 5691: という言葉とは全く何の関係もないことに注意してください。
 5692: @sc{rcs} のロックについては、
 5693: 独占取得についての記述を参照して下さい (@pxref{Multiple developers})。
 5694: 
 5695: 任意のリポジトリから何人でも、
 5696: 同時に読み出すことが可能です。
 5697: 誰かが書き込み中の場合にだけ、
 5698: 他の人の読み出しや書き込みが禁止されます。
 5699: 
 5700: @cindex Atomic transactions, lack of
 5701: @cindex Transactions, atomic, lack of
 5702: @c the following talks about what one might call commit/update
 5703: @c atomicity.
 5704: @c Probably also should say something about
 5705: @c commit/commit atomicity, that is, "An update will
 5706: @c not get partial versions of more than one commit".
 5707: @c CVS currently has this property and I guess we can
 5708: @c make it a documented feature.
 5709: @c For example one person commits
 5710: @c a/one.c and b/four.c and another commits a/two.c and
 5711: @c b/three.c.  Then an update cannot get the new a/one.c
 5712: @c and a/two.c and the old b/four.c and b/three.c.
 5713: 次に示すような動作を望む人がいるでしょう
 5714: 
 5715: @example
 5716: ある人物が一つの cvs コマンドで複数のファイルに対する変更点を
 5717: 格納した時、他の誰かが同時に update を実行すると、全てのファイルが
 5718: 更新されるか、全く更新されないかのどちらかである。
 5719: @end example
 5720: 
 5721: が、@sc{cvs} はこのように動作@emph{しません}。
 5722: 例えば以下のファイルがあるとして、
 5723: 
 5724: @example
 5725: a/one.c
 5726: a/two.c
 5727: b/three.c
 5728: b/four.c
 5729: @end example
 5730: 
 5731: ある人物が次のコマンドを実行した時、
 5732: 
 5733: @example
 5734: cvs ci a/two.c b/three.c
 5735: @end example
 5736: 
 5737: 同時に他の誰かが @code{cvs update} を実行した場合、
 5738: @code{update} を実行している人は @file{b/three.c} の変更点のみが更新さ
 5739: れ、
 5740: @file{a/two.c} の変更点は更新されないでしょう。
 5741: 
 5742: @node Watches
 5743: @section ファイル編集者の追跡機構
 5744: @cindex Watches
 5745: 
 5746: 多くのグループが @sc{cvs} を既定状態で使用していますが、
 5747: ほぼ完全に満足しているようです。
 5748: しかし時には、自分と他人の修正点が重複する事があり、
 5749: この重複を処理して再び格納しなくてはいけません。
 5750: あるグループでは、
 5751: 誰がどのファイルを編集中か分るようにしています。
 5752: 従って、二人で同じファイルを編集する場合、
 5753: 誰が何時何をするのか相談できるため、
 5754: 格納時に驚かされずに済みます。
 5755: この節では、
 5756: このような調整作業を行なう機能について説明しますが、
 5757: 二人の開発者が同時に同じファイルを編集する能力は維持されます。
 5758: 
 5759: @c Some people might ask why CVS does not enforce the
 5760: @c rule on chmod, by requiring a cvs edit before a cvs
 5761: @c commit.  The main reason is that it could always be
 5762: @c circumvented--one could edit the file, and
 5763: @c then when ready to check it in, do the cvs edit and put
 5764: @c in the new contents and do the cvs commit.  One
 5765: @c implementation note: if we _do_ want to have cvs commit
 5766: @c require a cvs edit, we should store the state on
 5767: @c whether the cvs edit has occurred in the working
 5768: @c directory, rather than having the server try to keep
 5769: @c track of what working directories exist.
 5770: @c FIXME: should the above discussion be part of the
 5771: @c manual proper, somewhere, not just in a comment?
 5772: 開発者は、
 5773: 編集するファイルを読み書き可能にする時に、
 5774: (@code{chmod} でなく) @code{cvs edit} を使用し、
 5775: もう使用しない作業ディレクトリを処分する時に、
 5776: (@code{rm} でなく) @code{cvs release} を使用することが推奨されます。
 5777: しかし、@sc{cvs} はこれらの手順を強制する事は出来ません。
 5778: 
 5779: @c I'm a little dissatisfied with this presentation,
 5780: @c because "watch on"/"edit"/"editors" are one set of
 5781: @c functionality, and "watch add"/"watchers" is another
 5782: @c which is somewhat orthogonal even though they interact in
 5783: @c various ways.  But I think it might be
 5784: @c confusing to describe them separately (e.g. "watch
 5785: @c add" with loginfo).  I don't know.
 5786: 
 5787: @menu
 5788: * Setting a watch::             監視するファイルを CVS に教える
 5789: * Getting Notified::            誰に通知するか CVS に教える
 5790: * Editing files::               監視下にあるファイルの編集方法
 5791: * Watch information::           誰が監視や編集をしているか
 5792: * Watches Compatibility::       監視は CVS 1.6 以前と上手く協調しない
 5793: @end menu
 5794: 
 5795: @node Setting a watch
 5796: @subsection 監視するファイルを CVS に教える
 5797: 
 5798: 監視機能を有効にするには、
 5799: まずそのファイルを監視するように指示する必要があります。
 5800: 
 5801: @cindex watch on (subcommand)
 5802: @deffn コマンド {cvs watch on} [@code{-lR}] files @dots{}
 5803: 
 5804: @cindex Read-only files, and watches
 5805: この指定以降、@var{files} を編集しようとする開発者は 
 5806: @code{cvs edit} を実行する必要があります。
 5807: 開発者が編集前に @code{cvs edit} の実行を忘れない様に、
 5808: @sc{cvs} は @var{files} の読み込みだけを許可します。
 5809: 
 5810: @var{files} がディレクトリを含む場合、
 5811: リポジトリの対応するディレクトリ内の全てのファイルに加えて、
 5812: 将来ディレクトリに追加されるファイル全てが 
 5813: @sc{cvs} の監視対象になります。
 5814: この動作を利用して、ディレクトリ毎に通知方針を設定することができます。
 5815: またオプション @samp{-l} を指定しない場合、
 5816: ディレクトリ以下が再帰的に処理されます。
 5817: @code{-l} オプションが @file{~/.cvsrc} で設定されている場合は 
 5818: @code{-R} オプションを使って再帰を強制することができます 
 5819: (@pxref{~/.cvsrc})。
 5820: 
 5821: @var{files} を省略した場合、
 5822: 現在のディレクトリが指定されたと解釈します。
 5823: 
 5824: @cindex watch off (subcommand)
 5825: @end deffn
 5826: 
 5827: @deffn コマンド {cvs watch off} [@code{-lR}] files @dots{}
 5828: 
 5829: 取り出し時に @var{files} を読み込み専用にはしません。ですから、開発者
 5830: は @code{cvs edit} と @code{cvs undit} の使用に注意することはありませ
 5831: ん。CVS は @file{config} 管理ファイルで @code{PreservePermissions} オ
 5832: プションを使用すうことになっいるための他の使用許可の条件が無いかぎり、
 5833: @var{files} を 普通に読み書き両用で取り出します。(@pxref{Special
 5834: Files}, @pxref{config}).
 5835: 
 5836: @var{files} や引数指定時の振舞いは、
 5837: @code{cvs watch on} の場合と同じです。
 5838: 
 5839: @end deffn
 5840: 
 5841: @node Getting Notified
 5842: @subsection 誰に通知するか CVS に教える
 5843: 
 5844: あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、
 5845: その旨を @sc{cvs} に知らせます。
 5846: そのファイルに対して @code{cvs watch on} を用いなくても、
 5847: 通知の要求は可能です。
 5848: しかし、開発者がコマンド @code{cvs edit} を用いるとは限らないため、
 5849: 通常は @code{cvs watch on} を用いた方が良いでしょう。
 5850: 
 5851: @cindex watch add (subcommand)
 5852: @deffn コマンド {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{}
 5853: 
 5854: 現在の使用者を、 @var{files} に対して操作が行なわれた時に
 5855: 通知を受けとる人の一覧に追加します。
 5856: 
 5857: オプション @samp{-a} には、
 5858: 通知して欲しい操作の種類を指定します。
 5859: @var{action} は次のうちのどれかです:
 5860: 
 5861: @table @code
 5862: 
 5863: @item edit
 5864: あなた以外の人物が、
 5865: ファイルに対してコマンド @code{cvs edit} (後述) を適用した場合。
 5866: 
 5867: @item unedit
 5868: あなた以外の人物が、
 5869: ファイルに対してコマンド @code{cvs unedit} (後述) または 
 5870: @code{cvs release} を適用した場合。
 5871: また、ファイルが消されて @code{cvs update} により再度生成された場合。
 5872: 
 5873: @item commit
 5874: あなた以外の人物が、ファイルに対する変更を格納した場合。
 5875: 
 5876: @item all
 5877: 上記全て。
 5878: 
 5879: @item none
 5880: 上記以外。
 5881: (これは後述の @code{cvs edit} で使用すると便利です。)
 5882: 
 5883: @end table
 5884: 
 5885: オプション @samp{-a} は何度指定しても良いし、
 5886: 全く指定しなくても構いません。
 5887: 省略した場合には、@code{all} が指定されたと解釈します。
 5888: 
 5889: @var{files} や引数指定時の振舞いは、
 5890: @code{cvs watch on} の場合と同じです。
 5891: 
 5892: @end deffn
 5893: 
 5894: 
 5895: @cindex watch remove (subcommand)
 5896: @deffn コマンド {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{}
 5897: 
 5898: @code{cvs watch add} で設定した通知要求を取り下げます。
 5899: 引数は同じです。
 5900: オプション @samp{-a} を用いた場合、
 5901: 指定された事項に対する通知のみを停止します。
 5902: 
 5903: @end deffn
 5904: 
 5905: @cindex notify (admin file)
 5906: 通知すべき状態が発生した時、
 5907: @sc{cvs} は管理用ファイル @file{notify} を見ます。
 5908: @file{notify} は他の管理用ファイルと同じように編集して下さい。
 5909: (@pxref{Intro administrative files})。
 5910: 管理用ファイルの慣例に従って (@pxref{syntax})、このファイルの各行には、
 5911: 正規表現に続けて実行したいコマンドを記述します。
 5912: コマンドの引数には、(通知すべき使用者に置換される) 
 5913: @samp{%s} という文字列を一つだけ指定する必要があり、
 5914: 通知内容はコマンドの標準入力に与えられます。
 5915: ファイル @code{notify} に書く標準のものは次の一行です:
 5916: 
 5917: @example
 5918: ALL mail %s -s \"CVS notification\"
 5919: @end example
 5920: 
 5921: この記述により、使用者に電子メールで通知が行なわれます。
 5922: @c FIXME: should it be this hard to set up this
 5923: @c behavior (and the result when one fails to do so,
 5924: @c silent failure to notify, so non-obvious)?  Should
 5925: @c CVS give a warning if no line in notify matches (and
 5926: @c document the use of "DEFAULT :" for the case where
 5927: @c skipping the notification is indeed desired)?
 5928: 
 5929: @cindex users (admin file)
 5930: 上記の行をそのまま記述した場合、
 5931: 使用者はサーバ上で通知を受ける事に注意して下さい。
 5932: 他の場所に通知したい場合には、
 5933: もちろん @file{notify} に記述しても良いのですが、
 5934: @sc{cvs} ではもっと簡単に各使用者の通知先を設定できます。
 5935: @file{CVSROOT} に @file{users} というファイルを作成し、
 5936: @var{user}:@var{value} という書式で、
 5937: 各使用者について一行ずつ記述して下さい。
 5938: @sc{cvs} は、@file{notify} に記述された @var{user} の代りに、
 5939: @var{value} (通常は別のマシンのメールアドレス) に通知します。
 5940: 
 5941: @sc{cvs} はあなた自身の変更は通知しません。現時点では、この照合は通知
 5942: を発生させる動作をしている人の使用者名が通知を受ける人の使用者名と合う
 5943: かどうかに基づいてなされています。実際のところ、一般的に、監視機構はそ
 5944: れぞれの使用者の一つの編集だけを追跡します。おそらく、監視がそれぞれの
 5945: 作業ディレクトリを別に追跡するとより便利なので、この振舞いは変更する
 5946: 価値があるでしょう。
 5947: @c "behavior might be worth changing" is an effort to
 5948: @c point to future directions while also not promising
 5949: @c that "they" (as in "why don't they fix CVS to....")
 5950: @c will do this.
 5951: @c one implementation issue is identifying whether a
 5952: @c working directory is same or different.  Comparing
 5953: @c pathnames/hostnames is hopeless, but having the server
 5954: @c supply a serial number which the client stores in the
 5955: @c CVS directory as a magic cookie should work.
 5956: 
 5957: @node Editing files
 5958: @subsection 監視下にあるファイルの編集方法
 5959: 
 5960: @cindex Checkout, as term for getting ready to edit
 5961: 監視下にあるファイルを取り出した場合、
 5962: 読み込みだけが許可されるため、単純に編集はできません。
 5963: 読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、
 5964: @code{cvs edit} コマンドを使用して下さい。
 5965: 上記の作業を @dfn{checkout} と呼ぶシステムもありますが、
 5966: @sc{cvs} ではこの用語をソースのコピーを得る (@dfn{取り出す}) 
 5967: という意味で用います (@pxref{Getting the source})。
 5968: 他のシステムでは、この操作は @dfn{get} とか @dfn{fetch} と呼ばれます。
 5969: @c Issue to think about: should we transition CVS
 5970: @c towards the "get" terminology?  "cvs get" is already a
 5971: @c synonym for "cvs checkout" and that section of the
 5972: @c manual refers to "Getting the source".  If this is
 5973: @c done, needs to be done gingerly (for example, we should
 5974: @c still accept "checkout" in .cvsrc files indefinitely
 5975: @c even if the CVS's messages are changed from "cvs checkout: "
 5976: @c to "cvs get: ").
 5977: @c There is a concern about whether "get" is not as
 5978: @c good for novices because it is a more general term
 5979: @c than "checkout" (and thus arguably harder to assign
 5980: @c a technical meaning for).
 5981: 
 5982: @cindex edit (subcommand)
 5983: @deffn コマンド {cvs edit} [options] files @dots{}
 5984: 
 5985: 作業ファイル @var{files} を編集する準備をします。
 5986: @sc{cvs} は @var{files} の読み書きを許可し、
 5987: @var{files} に対する @code{edit} 通知を求める使用者に通知します。
 5988: 
 5989: @code{cvs edit} コマンドに、
 5990: @code{cvs watch add} コマンドと同じ @var{options} を使用すれば、
 5991: 一時的に @var{files} を監視することができます。
 5992: @sc{cvs} は、
 5993: @var{files} が @code{unedit} もしくは @code{commit} されたときに、
 5994: 監視を止めます。
 5995: 通知を受けたくない場合には、@samp{-a none} を指定して下さい。
 5996: 
 5997: @var{files} や引数指定時の振舞いは、
 5998: @code{cvs watch} の場合と同じです。
 5999: 
 6000: @strong{注意:} @code{PreservePermissions} オプションがリポジトリで使用
 6001: 可になっていると (@pxref{config})、CVS はどの @var{files} の使用許可も
 6002: 変更しません。この変更の理由は @samp{cvs edit} の使用が CVS リポジトリ
 6003: のファイル使用許可を保管する機能と干渉しないようにするということです。
 6004: 
 6005: @end deffn
 6006: 
 6007: 変更を全て終了したら、通常は @code{cvs commit} を用いて、
 6008: 監視下にあるファイルの変更点を格納し、
 6009: 読み込みだけが許可された状態に戻します。
 6010: しかし、途中で変更を止めたり、何も変更しないと決めた場合には、
 6011: @code{cvs unedit} コマンドを使用します。
 6012: 
 6013: @cindex unedit (subcommand)
 6014: @cindex Abandoning work
 6015: @cindex Reverting to repository version
 6016: @deffn コマンド {cvs unedit} [@code{-lR}] files @dots{}
 6017: 
 6018: 作業ファイル @var{files} に加えた変更を捨て、
 6019: 変更前のリポジトリのバージョンに戻します。
 6020: @var{files} に対して、@code{cvs watch on} による通知要求がある場合、
 6021: @sc{cvs} は @var{files} の読み込みだけを許可します。
 6022: また @var{files} に対する @code{unedit} 通知を求める使用者に通知します。
 6023: 
 6024: @var{files} や引数指定時の振舞いは、
 6025: @code{cvs watch} の場合と同じです。
 6026: 
 6027: ファイルが監視されてないときにはおそらく 
 6028: @code{unedit} コマンドが動作しないため、
 6029: リポジトリのバージョンに戻したい場合は、ファイルを削除してから 
 6030: @code{cvs update} で新たにコピーを取得して下さい。
 6031: これは厳密には同じ意味ではなく、削除して更新した場合には、
 6032: あなたが最後に更新した後にリポジトリに加えられた変更も付随します。
 6033: @c It would be a useful enhancement to CVS to make
 6034: @c unedit work in the non-watch case as well.
 6035: @end deffn
 6036: 
 6037: @sc{cvs} のクライアント/サーバを使用していて、
 6038: サーバとうまく接続できなかった場合でも、
 6039: @code{cvs edit} や @code{cvs unedit} コマンドが使用できます。
 6040: 次に @sc{cvs} コマンドが成功した時に、
 6041: 一緒に通知が行なわれます。
 6042: 
 6043: @node Watch information
 6044: @subsection 誰が監視や編集をしているか
 6045: 
 6046: @cindex watchers (subcommand)
 6047: @deffn コマンド {cvs watchers} [@code{-lR}] files @dots{}
 6048: 
 6049: 現在、@var{files} の変更を監視している人物の一覧を表示します。
 6050: 監視されているファイルと、各監視者のメールアドレスを報告します。
 6051: 
 6052: @var{files} や引数指定時の振舞いは、
 6053: @code{cvs watch} の場合と同じです。
 6054: 
 6055: @end deffn
 6056: 
 6057: 
 6058: @cindex editors (subcommand)
 6059: @deffn コマンド {cvs editors} [@code{-lR}] files @dots{}
 6060: 
 6061: 現在、@var{files} を編集している人物の一覧を表示します。
 6062: 各編集者のメールアドレス、編集作業を開始した時間、
 6063: ファイルが置かれた作業ディレクトリのパス名とホスト名を報告します。
 6064: 
 6065: @var{files} や引数指定時の振舞いは、
 6066: @code{cvs watch} の場合と同じです。
 6067: 
 6068: @end deffn
 6069: 
 6070: @node Watches Compatibility
 6071: @subsection 古いバージョンの CVS と監視機能
 6072: 
 6073: @cindex CVS 1.6, and watches
 6074: 監視機能を使用している場合、
 6075: リポジトリに @file{CVS} というディレクトリが作成され、
 6076: このディレクトリに監視情報が格納されます。
 6077: このリポジトリに対して @sc{cvs} 1.6 以前のものを使用した場合には、
 6078: 以下のエラー・メッセージが出力されます (全て一行にでます):
 6079: 
 6080: @example
 6081: cvs update: cannot open CVS/Entries for reading:
 6082: No such file or directory
 6083: @end example
 6084: 
 6085: そして、操作が途中で終了します。
 6086: 監視機能を使用するためには、
 6087: このリポジトリを利用するクライアント/サーバ両方で、
 6088: @sc{cvs} を新しいものと交換する必要があります。
 6089: もし新しいものと交換できない場合には、
 6090: @code{watch off} と @code{watch remove} コマンドを用いて
 6091: 監視を全て停止すれば、
 6092: リポジトリを @sc{cvs} 1.6 が利用できる状態に再構築できます。
 6093: 
 6094: @node Choosing a model
 6095: @section 独占取得と無条件取得の選択
 6096: @cindex Choosing, reserved or unreserved checkouts
 6097: 
 6098: 独占取得、無条件取得それぞれに一長一短があります。
 6099: ここでは、この問題を簡単に説明しますが、
 6100: 残りの多くは個人的な見解の相違や、
 6101: 各グループの作業スタイルの相違だと思います。
 6102: 開発者チームを構成するには様々な方法があります。
 6103: @sc{cvs} は特定の構成を強制せず、
 6104: 各々を実現する機能を提供するだけです。
 6105: 
 6106: 独占取得には、非常に非生産的な部分があります。
 6107: 二人が同じファイルを編集する場合でも、編集部分が異なる場合には、
 6108: どちらか一方の編集を禁止する必要は全くありません。
 6109: また、ファイルを編集するためにロックした後、
 6110: ロック解除を忘れてしまうことが、普通に起こり得ます。
 6111: 
 6112: @c "many groups"?  specifics?  cites to papers on this?
 6113: @c some way to weasel-word it a bit more so we don't
 6114: @c need facts :-)?
 6115: 独占取得に特別な安心感を持つ人々は、
 6116: 無条件取得を用いた場合の衝突の多さや、
 6117: それを解決する困難さをよく訴えます。
 6118: しかし多くのグループの経験から言うと、
 6119: 衝突は稀であり、解決も普通は比較的簡単なものです。
 6120: 
 6121: 衝突は2人の開発者がコードの与えられた部分の適切な設計について
 6122: 意見が食い違っているときにのみ起こることを理解するまで、
 6123: 深刻な衝突の発生の少なさは驚きでしょう。
 6124: このような衝突は、そもそもチーム内での意思疎通が上手く行っていないこと
 6125: を示しています。
 6126: @emph{どのような}ソース管理方法を採るにしても、
 6127: 開発者が共同で作業する際には、
 6128: システム全体の設計方針に従わなければいけません。
 6129: きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。
 6130: 
 6131: 無条件取得が、全く不適当な場合があります。
 6132: 管理下にあるファイルの形式をマージする道具が無く 
 6133: (例えばワード・プロセッサによるファイルや、
 6134: CAD プログラムで編集されたファイル等)、
 6135: マージ可能なデータ書式を使用するようにプログラムを変更できない場合、
 6136: 悪夢のような衝突解決をするよりは、
 6137: 普通は独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。
 6138: 
 6139: 上の @ref{Watches} で記述された監視機構は、
 6140: 独占取得と無条件取得の中間的なものと考えられます。
 6141: ファイルを編集する前に、
 6142: 他の誰がファイルを編集中なのか調べることができます。
 6143: これは単純に双方の同時編集を禁止するのではなく、
 6144: 現況を報告し、それが問題かどうかは自分で判断してもらいます。
 6145: これを適切に使用すれば、
 6146: 独占取得と無条件取得の中でも最善の選択となるでしょう。
 6147: 
 6148: @c ---------------------------------------------------------------------
 6149: @node Revision management
 6150: @chapter リビジョン管理
 6151: @cindex Revision management
 6152: 
 6153: @c -- This chapter could be expanded a lot.
 6154: @c -- Experiences are very welcome!
 6155: 
 6156: ここまで読んだあなたは、
 6157: @sc{cvs} を使って何ができるかを、もう随分理解しているでしょう。
 6158: ここでは、あなたが決めるべき事柄について少し説明します。
 6159: 
 6160: あなたが一人で @sc{cvs} を使用して開発しているならば、
 6161: ここは読み飛ばして結構です。
 6162: 複数の人物が同じリポジトリを使って作業する場合に、
 6163: ここで説明する問題が重要になってきます。
 6164: 
 6165: @menu
 6166: * When to commit::              この問題の論議
 6167: @end menu
 6168: 
 6169: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6170: @node When to commit
 6171: @section いつ格納すべきか?
 6172: @cindex When to commit
 6173: @cindex Commit, when to
 6174: @cindex Policy
 6175: 
 6176: あなたのグループは、格納の時期に関して、
 6177: どのような方針を採るか決めておく必要があります。
 6178: 幾つかの方針が可能であり、@sc{cvs} での経験を重ねることによって、
 6179: 独自の方法を見付けることができるでしょう。
 6180: 
 6181: とにかく早く格納することにして、
 6182: コンパイルもせずに格納してしまったとします。
 6183: あなたの同僚が、作業ソースを更新して
 6184: あなたのバギーなファイルを取り込んだ場合、
 6185: 彼はコンパイルができません。
 6186: 逆にめったに格納しない場合、
 6187: 同僚はあなたがコードに加えた改良の利益を得ることができず、
 6188: 衝突がより多くなるでしょう。
 6189: 
 6190: コンパイルできるかどうか確認したファイルだけを
 6191: 格納する方法がよく採られます。
 6192: あるサイトでは、ファイルが検査に合格することを要求します。
 6193: @file{commitinfo} ファイルを使用して (@pxref{commitinfo})、
 6194: このような方針を強制できますが、その前によく考えなくてはいけません。
 6195: 十分過ぎる程管理された開発環境を作ると、
 6196: 厳格になり過ぎて、非生産的になり、
 6197: ソフトウェアを書くという目的が果たせなくなります。
 6198: 
 6199: @c ---------------------------------------------------------------------
 6200: @node Keyword substitution
 6201: @chapter キーワード置換
 6202: @cindex Keyword substitution
 6203: @cindex Keyword expansion
 6204: @cindex Identifying files
 6205: 
 6206: @comment   この章を編集する場合には十分注意して下さい。
 6207: @comment   このファイルはバージョン管理されており、
 6208: @comment   有効なキーワードが、文中に含まれないように
 6209: @comment   注意しなくてはいけません。
 6210: 
 6211: 作業ファイルを編集している間は、
 6212: いつでも @samp{cvs status} や @samp{cvs log} を使って
 6213: そのファイルの状態を調べることができます。
 6214: しかし開発環境から取り出した場合は、
 6215: 各ファイルのリビジョンを識別するのが難しくなります。
 6216: 
 6217: CVSは、@dfn{キーワード置換} (@dfn{keyword substitution}) 
 6218: (もしくは@dfn{キーワード展開} (@dfn{keyword expansion}))
 6219: と呼ばれる機構により、ファイルの識別を補助します。
 6220: ファイル中に @code{$@var{keyword}$}, 
 6221: @code{$@var{keyword}:@dots{}$} といった書式で
 6222: 埋め込まれた文字列を、ファイルを取り出すときに 
 6223: @code{$@var{keyword}:@var{value}$} といった書式の文字列に置き換えます。
 6224: 
 6225: @menu
 6226: * Keyword list::                キーワード
 6227: * Using keywords::              キーワードの使用
 6228: * Avoiding substitution::       置換を止めるには
 6229: * Substitution modes::          置換モード
 6230: * Log keyword::                 キーワード $@asis{}Log$ の問題点
 6231: @end menu
 6232: 
 6233: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6234: @node Keyword list
 6235: @section キーワード一覧
 6236: @cindex Keyword List
 6237: 
 6238: @c FIXME: need some kind of example here I think,
 6239: @c perhaps in a
 6240: @c "Keyword intro" node.  The intro in the "Keyword
 6241: @c substitution" node itself seems OK, but to launch
 6242: @c into a list of the keywords somehow seems too abrupt.
 6243: 
 6244: これはキーワードの利用の一覧です:
 6245: 
 6246: @table @code
 6247: @cindex Author keyword
 6248: @item $@asis{Author}$
 6249: そのリビジョンを格納したユーザのログイン名。
 6250: 
 6251: @cindex Date keyword
 6252: @item $@asis{Date}$
 6253: そのリビジョンを格納した日付と時間 (UTC)。
 6254: 
 6255: @cindex Header keyword
 6256: @item $@asis{Header}$
 6257: 標準のヘッダは、@sc{rcs} ファイルのフルパス名, 
 6258: リビジョン番号, 日付 (UTC), 最終変更者, ファイル状態, 
 6259: (ロックされているならば) ロックしている人物という情報で
 6260: 構成されます。
 6261: @sc{cvs} を使用する場合、普通ファイルはロックされません。
 6262: 
 6263: @cindex Id keyword
 6264: @item $@asis{Id}$
 6265: @sc{rcs} ファイル名がフルパスでないことを除けば、
 6266: @code{$@asis{Header}$} と同じです。
 6267: 
 6268: @cindex Name keyword
 6269: @item $@asis{Name}$
 6270: このファイルを取り出すときに使用したタグ名。キーワードは明示的なタグ名
 6271: で取り出したときにのみ展開されます。例えば、コマンド @code{cvs co -r
 6272: first} を実行すると、キーワードを @samp{Name: first} に展開します。
 6273: 
 6274: @cindex Locker keyword
 6275: @item $@asis{Locker}$
 6276: そのリビジョンをロックしている人物のログイン名。
 6277: (ロックされていなければ空で、@code{cvs admin -l} が使われていなければ
 6278: それが普通です。)
 6279: 
 6280: @cindex Log keyword
 6281: @item $@asis{Log}$
 6282: @sc{rcs} ファイル名, リビジョン番号, 最終変更者, 
 6283: 日付 (UTC) から構成されるヘッダ行に続けて、
 6284: 格納時のログ・メッセージを挿入します。
 6285: 以前に挿入されたログ・メッセージを置き換えるのでは@emph{なく}、
 6286: 新しいメッセージを @code{$@asis{Log:@dots{}}$} の次の行に挿入します。
 6287: それぞれの新しい行には @code{$Log} キーワードの前にあるものと
 6288: 同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。
 6289: 
 6290: @example
 6291:   /* Here is what people have been up to:
 6292:    *
 6293:    * $@asis{}Log: frob.c,v $
 6294:    * Revision 1.1  1997/01/03 14:23:51  joe
 6295:    * Add the superfrobnicate option
 6296:    *
 6297:    */
 6298: @end example
 6299: 
 6300: @noindent
 6301: そうすると、@code{$Log} を展開するときに追加される行はその前に 
 6302: @samp{  * } が付きます。以前のバージョンの @sc{cvs}、@sc{rcs} と違って、
 6303: @sc{rcs} ファイル の @dfn{註釈符} (@dfn{comment leader}) は使用されま
 6304: せん。
 6305: @code{$Log} キーワードは、
 6306: ソース・ファイルに全てのログを残したい場合には便利ですが、
 6307: 問題点も幾つかあります (@pxref{Log keyword})。
 6308: 
 6309: @cindex RCSfile keyword
 6310: @item $@asis{RCSfile}$
 6311: パスを含まない @sc{rcs} ファイル名。
 6312: 
 6313: @cindex Revision keyword
 6314: @item $@asis{Revision}$
 6315: そのリビジョンを表わすリビジョン番号。
 6316: 
 6317: @cindex Source keyword
 6318: @item $@asis{Source}$
 6319: RCS ファイルのフルパス名。
 6320: 
 6321: @cindex State keyword
 6322: @item $@asis{State}$
 6323: そのリビジョンの状態。
 6324: 各リビジョンの状態は、@samp{cvs admin -s} で割り当てることができます---
 6325: @ref{admin options} 参照。
 6326: 
 6327: @end table
 6328: 
 6329: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6330: @node Using keywords
 6331: @section キーワードの使用
 6332: 
 6333: キーワードを使いたい場合は、@code{$@asis{Id}$} などの適当な文字列を
 6334: ファイルに記述してから格納するだけです。
 6335: @sc{cvs} は格納操作の一環として自動的に文字列を展開します。
 6336: 
 6337: @code{$@asis{}Id$} 文字列をソースファイルに入れて、生成されるファイル
 6338: にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
 6339: ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
 6340: れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために 
 6341: @code{#pragma ident} 命令が使用できるコンパイラもあります。もしくは、
 6342: 文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
 6343: れません。
 6344: 
 6345: @c Would be nice to give an example, but doing this in
 6346: @c portable C is not possible and the problem with
 6347: @c picking any one language (VMS HELP files, Ada,
 6348: @c troff, whatever) is that people use CVS for all
 6349: @c kinds of files.
 6350: 
 6351: @cindex Ident (shell command)
 6352: @code{ident} コマンド (@sc{rcs} パッケージの一部) を使用して、
 6353: ファイルからキーワードとその値を抜き出すことができます。
 6354: もちろんテキスト・ファイルにも使えますが、
 6355: バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。
 6356: 
 6357: @example
 6358: $ ident samp.c
 6359: samp.c:
 6360:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 6361: $ gcc samp.c
 6362: $ ident a.out
 6363: a.out:
 6364:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 6365: @end example
 6366: 
 6367: @cindex What (shell command)
 6368: 別のリビジョン管理システムとして有名なものに @sc{sccs} があります。
 6369: @sc{sccs} には、@code{ident} と非常によく似た
 6370: 同じ用途のコマンド @code{what} が含まれます。
 6371: @sc{rcs} を持たないサイトの多くは @sc{sccs} を使っています。
 6372: @code{what} コマンドは @code{@@(#)} という文字列を探すため、
 6373: 両方のコマンドに対応するキーワードを含めるのは簡単です。
 6374: キーワードの前に、
 6375: 簡単な @sc{sccs} の魔法の呪文を唱えるだけで良いのです:
 6376: 
 6377: @example
 6378: static char *id="@@(#) $@asis{}Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
 6379: @end example
 6380: 
 6381: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6382: @node Avoiding substitution
 6383: @section 置換を止めるには
 6384: 
 6385: キーワード置換にも欠点があります。
 6386: ファイル中に表われる文字列 @samp{$@asis{}Author$} は、
 6387: @sc{rcs} によってキーワードと見倣されます。
 6388: この文字列を @samp{$@asis{}Author: ceder $} などと解釈させずに、
 6389: そのまま使いたい事があるでしょう。
 6390: 
 6391: 不幸なことに、選択的にキーワード置換を止めることはできません。
 6392: @samp{-ko} によって完全にキーワード置換を止めることができます 
 6393: (@pxref{Substitution modes})。
 6394: 
 6395: @sc{rcs} キーワードが最終製品に現われるとしても、
 6396: ソース・ファイル中には使いたくない場合が多くあります。
 6397: 例えばこのマニュアルのソースには @samp{$@asis{}Author$} ではなく、
 6398: @samp{$@@asis@{@}Author$} と記述しています。
 6399: @code{nroff} や @code{troff} であれば、
 6400: ヌル文字である @code{\&} をキーワード中に埋め込めば
 6401: 同様の効果を発揮します。
 6402: 
 6403: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6404: @node Substitution modes
 6405: @section 置換モード
 6406: @cindex keyword substitution, changing modes
 6407: @cindex -k (keyword substitution)
 6408: @cindex Kflag
 6409: 
 6410: @c FIXME: This could be made more coherent, by expanding it
 6411: @c with more examples or something.
 6412: 各ファイルには既定の置換モードが設定されており、
 6413: 作業ディレクトリの各ファイルの置換モードも別々に設定できます。
 6414: 前者は @code{cvs add} や @code{cvs admin} に
 6415: オプション @samp{-k} を付けて設定します。
 6416: 後者は @code{cvs checkout} や @code{cvs update} に
 6417: オプション @samp{-k} や @samp{-A} を付けて設定します。
 6418: @code{cvs diff} にも @samp{-k} オプションがあります。
 6419: 例が幾つかありますので、@ref{Binary files} と @ref{Merging and
 6420: keywords} 参照。
 6421: @c The fact that -A is overloaded to mean both reset
 6422: @c sticky options and reset sticky tags/dates is
 6423: @c somewhat questionable.  Perhaps there should be
 6424: @c separate options to reset sticky options (e.g. -k
 6425: @c A") and tags/dates (someone suggested -r HEAD could
 6426: @c do this instead of setting a sticky tag of "HEAD"
 6427: @c as in the status quo but I haven't thought much
 6428: @c about that idea.  Of course -r .reset or something
 6429: @c could be coined if this needs to be a new option).
 6430: @c On the other hand, having -A mean "get things back
 6431: @c into the state after a fresh checkout" has a certain
 6432: @c appeal, and maybe there is no sufficient reason for
 6433: @c creeping featurism in this area.
 6434: 
 6435: 利用できるモードを以下に示します:
 6436: 
 6437: @table @samp
 6438: @item -kkv
 6439: 既定形式でキーワード文字列を生成します。
 6440: 例えば、キーワード @code{Revision} に対して 
 6441: @code{$@asis{}Revision: 5.7 $} が生成されます。
 6442: 
 6443: @item -kkvl
 6444: @samp{-kkv} とほぼ同様ですが、
 6445: 指定されたリビジョンがロックされていれば、
 6446: ロックしている人物の名前を挿入します。
 6447: ロックしている人物名は @code{cvs admin -l} が使用されているときだけ関
 6448: 係があります。
 6449: 
 6450: @item -kk
 6451: キーワード文字列からキーワードのみを生成し、その値は省略されます。
 6452: 例えば、キーワード @code{Revision} に対して、
 6453: @code{$@asis{}Revision: 5.7 $} ではなく、
 6454: @code{$@asis{}Revision$} が生成されます。
 6455: このオプションは、リビジョン間の違いを比較する時、
 6456: キーワードによる違いを無視するのに便利です (@pxref{Merging and
 6457: keywords})。
 6458: 
 6459: @item -ko
 6460: そのファイルが格納される前の、
 6461: 古いキーワード文字列を生成します。
 6462: 例えば、キーワード @code{Revision} に対して、
 6463: @code{$@asis{}Revision: 5.7 $} ではなく、
 6464: ファイルが格納された時の文字列である 
 6465: @code{$@asis{}Revision: 1.1 $} が生成されます。
 6466: 
 6467: @item -kb
 6468: @samp{-ko} と同様ですが、
 6469: リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、
 6470: クライアント側のオペレーティングシステムに適した形式へ変換しません。
 6471: 行端にラインフィードのみが使用されるシステム (unix 等) では、
 6472: このオプションは @samp{-ko} と同じです。
 6473: バイナリ・ファイルの詳細情報は @ref{Binary files} 参照。
 6474: 
 6475: @item -kv
 6476: キーワードの値のみを生成します。
 6477: 例えば、キーワード @code{Revision} に対して、
 6478: @code{$@asis{}Revision: 5.7 $} ではなく、
 6479: @code{5.7} が生成されます。
 6480: これは、@code{$@asis{}Revision: $} といった、
 6481: キーワード識別子を除くのが困難な
 6482: プログラミング言語のファイルを生成する時に便利です。
 6483: しかし、キーワード名が削除されてしまうために、
 6484: これ以後はキーワード置換を行うことができません。
 6485: 従って使用には注意が必要です。
 6486: 
 6487: オプション @samp{-kv} は、@code{cvs export} で使用される事が
 6488: 多くあります---@pxref{export}。
 6489: しかしモジュールがバイナリ・ファイルを含む場合は、
 6490: うまく処理できないので使用しない方が賢明です。
 6491: 
 6492: @end table
 6493: 
 6494: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6495: @node Log keyword
 6496: @section キーワード $@asis{}Log$ の問題点
 6497: 
 6498: キーワード @code{$@asis{}Log$} にはちょっと問題があります。
 6499: 開発環境で作業をしているならば、
 6500: キーワード @code{$@asis{}Log$} を使用しなくても、
 6501: @code{cvs log} を使えば同じ情報が簡単に手に入ります。
 6502: いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。
 6503: 
 6504: さらに重要な問題は、枝を幹にマージするときに、
 6505: @sc{rcs} が @code{$@asis{}Log$} の項目をうまく扱えないことです。
 6506: このマージ操作の結果、衝突が起きることがよくあります。
 6507: @c Might want to check whether the CVS implementation
 6508: @c of RCS_merge has this problem the same way rcsmerge
 6509: @c does.  I would assume so....
 6510: 
 6511: またファイル中のログ・メッセージは、@emph{修復}される傾向にあります。
 6512: (綴の間違いやほんとの間違い等)。
 6513: しかしこの結果、
 6514: @code{cvs log} の情報とファイルの中身が一致しないことになります。
 6515: これも問題といえば問題でしょう。
 6516: 
 6517: どうしてもキーワード @code{$@asis{}Log$} を使うのならば、
 6518: ファイルの先頭ではなく、
 6519: ファイルの @emph{最後} に挿入することを推奨します。
 6520: この方法ならば、
 6521: 長い変更メッセージを毎日眺めなくて済みます。
 6522: 
 6523: @c ---------------------------------------------------------------------
 6524: @node Tracking sources
 6525: @chapter サード・パーティーのソースの追っかけ
 6526: @cindex Third-party sources
 6527: @cindex Tracking sources
 6528: 
 6529: @c FIXME: Need discussion of added and removed files.
 6530: @c FIXME: This doesn't really adequately introduce the
 6531: @c concepts of "vendor" and "you".  They don't *have*
 6532: @c to be separate organizations or separate people.
 6533: @c We want a description which is somewhat more based on
 6534: @c the technical issues of which sources go where, but
 6535: @c also with enough examples of how this relates to
 6536: @c relationships like customer-supplier, developer-QA,
 6537: @c maintainer-contributor, or whatever, to make it
 6538: @c seem concrete.
 6539: あなたのサイトに合わせてプログラムを修正した場合、
 6540: そのプログラムの次のリリースにも同じ修正を加えたいでしょう。
 6541: @sc{cvs} を用いてこの作業を自動化することができます。
 6542: 
 6543: @cindex Vendor
 6544: @cindex Vendor branch
 6545: @cindex Branch, vendor-
 6546: @sc{cvs} の用語では、プログラムの開発元を@dfn{ベンダー} 
 6547: (@dfn{vendor}) と呼びます。
 6548: ベンダーの配布物は、
 6549: 修正を加えずに @dfn{ベンダー枝} (@dfn{vendor branch}) という枝に格納します。
 6550: @sc{cvs} はこの為に 1.1.1 という番号を予約しています。
 6551: 
 6552: あなたがソースを修正して格納した場合、
 6553: そのリビジョンは幹に入ります。
 6554: ベンダーから新しいリリースが届いたら、
 6555: それをベンダー枝に加えて、修正を幹にコピーします。
 6556: 
 6557: ベンダー枝を作り、更新するには、
 6558: @code{import} コマンドを使用します。
 6559: 新しいファイルを import すると、
 6560: ベンダー枝に `最初' のリビジョンが作られ、
 6561: @code{checkout} する人は誰でもそのリビジョンを取得します。
 6562: 格納されたローカルな修正は幹に置かれ、
 6563: `最初' のリビジョンが作られます。
 6564: 
 6565: @menu
 6566: * First import::                初めて持ち込む
 6567: * Update imports::              import コマンドで更新する
 6568: * Reverting local changes::     最新のベンダーリリースに戻す
 6569: * Binary files in imports::     バイナリ・ファイルには特別な操作が必要
 6570: * Keywords in imports::         キーワード置換は望ましくない
 6571: * Multiple vendor branches::    複数の場所からソースを取得すると?
 6572: @end menu
 6573: 
 6574: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6575: @node First import
 6576: @section 初めて持ち込む
 6577: @cindex Importing modules
 6578: 
 6579: @c Should mention naming conventions for vendor tags,
 6580: @c release tags, and perhaps directory names.
 6581: まず最初に、@code{import} コマンドを使ってソースを登録します。
 6582: @code{import} コマンドでサード・パーティーの追っかけをする場合には、
 6583: @dfn{ベンダー・タグ} (@dfn{vendor tag}) と
 6584: @dfn{リリース・タグ} (@dfn{release tag}) を用いると良いでしょう。
 6585: @dfn{ベンダー・タグ}は枝のタグ名です 
 6586: (@samp{-b @var{branch}} フラグを使用しなければ、
 6587: 枝のリビジョンは常に 1.1.1 です---@xref{Multiple vendor branches}.)。
 6588: @dfn{リリース・タグ}は特定のリリースを指すタグ名で、
 6589: ここでは @samp{FSF_0_04} とします。
 6590: 
 6591: @c I'm not completely sure this belongs here.  But
 6592: @c we need to say it _somewhere_ reasonably obvious; it
 6593: @c is a common misconception among people first learning CVS
 6594: @code{import} は起動されたディレクトリを変更 @emph{しない} ことに注意
 6595: してください。特に、そのディレクトリが @sc{cvs} の作業ディレクトリとし
 6596: て設定されることはありません。ソースに作業をしたいなら、まずそれを持ち
 6597: 込んで、それから違うディレクトリに取り出してください (@pxref{Getting
 6598: the source})。
 6599: 
 6600: @cindex Wdiff (import example)
 6601: ディレクトリ @file{wdiff-0.04} に @code{wdiff} というプログラムのソー
 6602: スがあるとします。将来に新しいリリースがなされたときでも適用したい個人
 6603: 的な修正を加えようとしています。まず、リポジトリに @code{wdiff} のソー
 6604: スを加えることから始めましょう:
 6605: 
 6606: @example
 6607: $ cd wdiff-0.04
 6608: $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
 6609: @end example
 6610: 
 6611: 上の例では、ベンダー・タグを @samp{FSF_DIST} とし、
 6612: 唯一のリリース・タグを @samp{WDIFF_0_04} としています。
 6613: @c FIXME: Need to say where fsf/wdiff comes from.
 6614: 
 6615: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6616: @node Update imports
 6617: @section import コマンドで更新する
 6618: 
 6619: 新しいリリースのソースが届いたら、
 6620: それを最初と同じく @code{import} コマンドでリポジトリに加えます。
 6621: 違いは、最初と異なるリリース・タグを用いることだけです。
 6622: 
 6623: @example
 6624: $ tar xfz wdiff-0.05.tar.gz
 6625: $ cd wdiff-0.05
 6626: $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
 6627: @end example
 6628: 
 6629: ファイルがローカルな修正を受けてなければ、
 6630: 今加えたものが最初のリビジョンになります。
 6631: ローカルな変更を加えていれば、
 6632: @code{import} コマンドは変更を幹にマージするように警告を出し、
 6633: @samp{checkout -j} を使うように促します。
 6634: 
 6635: @c FIXME: why "wdiff" here and "fsf/wdiff" in the
 6636: @c "import"?  I think the assumption is that one has
 6637: @c "wdiff fsf/wdiff" or some such in modules, but it
 6638: @c would be better to not use modules in this example.
 6639: @example
 6640: $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
 6641: @end example
 6642: 
 6643: @noindent
 6644: このコマンドで @samp{wdiff} の最新のリビジョンが取り出され、
 6645: @samp{yesterday} 以降にベンダー枝 @samp{FSF_DIST} に加えられた変更を、
 6646: 作業コピーにマージします。
 6647: マージの過程で衝突が起きれば、通常の方法で解決して下さい 
 6648: (@pxref{Conflicts example})。
 6649: その後、変更したファイルを格納します。
 6650: 
 6651: 上記の実行例のように日時を使用する場合、
 6652: 一日に一つ以上のリリースを @code{import} しないと仮定しています。
 6653: この仮定に反するならば、次のようにして下さい:
 6654: 
 6655: @example
 6656: $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
 6657: @end example
 6658: 
 6659: @noindent
 6660: 今の例では、上の二つのコマンドは等価です。
 6661: 
 6662: @node Reverting local changes
 6663: @section 最新のベンダーリリースに戻す
 6664: 
 6665: 全てのファイルで `先頭' のリビジョンを変更してベンダー枝に戻すことで
 6666: ローカルの変更を完全に復旧し、最新のベンダーリリースに戻ることができま
 6667: す。例えば、ソースの取り出したコピーを @file{~/work.d/wdiff} に置いて
 6668: いて、そのディレクトリの全てのファイルをベンダーのバージョンに戻したい
 6669: のなら、次のように入力します:
 6670: 
 6671: @example
 6672: $ cd ~/work.d/wdiff
 6673: $ cvs admin -bWDIFF .
 6674: @end example
 6675: 
 6676: @noindent
 6677: @samp{-bWDIFF} は @samp{-b} の後空白を入れないで指定しなければなりませ
 6678: ん。@xref{admin options}.
 6679: 
 6680: @node Binary files in imports
 6681: @section cvs import でバイナリ・ファイルを扱う方法
 6682: 
 6683: @samp{-k} wrapper 機能オプションを使って、どのファイルがバイナリである
 6684: かを教えます。@xref{Wrappers}.
 6685: 
 6686: @node Keywords in imports
 6687: @section cvs import でキーワード置換を扱う方法
 6688: 
 6689: 持ち込んでいるソースにキーワードがある場合があります (@pxref{Keyword
 6690: substitution})。例えば、ベンダーは @sc{cvs} や他の似たキーワード展開構
 6691: 文を使うシステムを使っているかもしれません。既定の方法でファイルを持ち
 6692: 込んだだけでは、ベンダーのキーワード展開があなた自身の @sc{cvs} コピー
 6693: でも行われます。この情報はベンダーから持ち込んだソースの情報であること
 6694: がありますから、ベンダーの展開を維持した方がより便利でしょう。
 6695: 
 6696: ベンダーのキーワード展開を維持するためには、最初にファイルを持ち込むと
 6697: きに @code{cvs import} に @samp{-ko} オプションを付けます。こうすると、
 6698: そのファイルのキーワード展開を完全に止めます。もっと選択的な方法を望む
 6699: 場合は、@code{cvs update} や @code{cvs admin} に適切に @samp{-k} オプ
 6700: ションを使用します。
 6701: @c Supplying -ko to import if the file already existed
 6702: @c has no effect.  Not clear to me whether it should
 6703: @c or not.
 6704: 
 6705: @node Multiple vendor branches
 6706: @section 複数のベンダー枝
 6707: 
 6708: 今までの例はソースを取得しているベンダーは一つだけだと仮定しています。
 6709: いろいろな場所からソースを得るような場合もあります。例えば、多くの違っ
 6710: た人やチームがソフトウェアを修正しているプロジェクトに関係しているとし
 6711: ます。これを扱う方法はいろいろありますが、たくさんのソースツリーが散ら
 6712: ばっていて、とりあえずやりたいことはそれら全てを CVS に放り込んで少な
 6713: くとも一箇所にまとめることだ、ということがあります。
 6714: 
 6715: 複数のベンダーがある状況を扱うために、@code{cvs import} に @samp{-b}
 6716: オプションを指定できます。その引数は持ち込むベンダー枝です。既定値は
 6717: @samp{-b 1.1.1} です。
 6718: 
 6719: 例えば、赤チームと青チームの2つのチームがあり、あなたにソースを送って
 6720: くるとします。赤チームが努力したものを枝 1.1.1 に持ち込んで、ベンダー
 6721: タグ RED を使いたいと思っています。青チームが努力したものは枝 1.1.3 に
 6722: 持ち込んで、ベンダータグ BLUE を使おうとしています。使用するコマンドは
 6723: 以下のようになります。
 6724: 
 6725: @example
 6726: $ cvs import dir RED RED_1-0
 6727: $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
 6728: @end example
 6729: 
 6730: ベンダータグ が @samp{-b} オプションと合わなくても、CVS は発見しないこ
 6731: とに注意してください。例えば、
 6732: 
 6733: @example
 6734: $ cvs import -b 1.1.3 dir RED RED_1-0
 6735: @end example
 6736: 
 6737: @noindent
 6738: 慎重に; この種類の不適当な組合せは混乱や、よりひどいことへの種になりま
 6739: す。不釣合いを指定することでの便利な使用をここでは考え付きません。もし
 6740: そのような使用を発見しても、使わないでください。CVS は将来のリリースで
 6741: はそれをエラーにするでしょう。
 6742: 
 6743: @c Probably should say more about the semantics of
 6744: @c multiple branches.  What about the default branch?
 6745: @c What about joining (perhaps not as useful with
 6746: @c multiple branches, or perhaps it is.  Either way
 6747: @c should be mentioned).
 6748: 
 6749: @c I'm not sure about the best location for this.  In
 6750: @c one sense, it might belong right after we've introduced
 6751: @c CVS's basic version control model, because people need
 6752: @c to figure out builds right away.  The current location
 6753: @c is based on the theory that it kind of akin to the
 6754: @c "Revision management" section.
 6755: @node Builds
 6756: @chapter 構築システムと CVS の関係方法
 6757: @cindex Builds
 6758: @cindex make
 6759: 
 6760: 紹介で書かれているように、@sc{cvs} にはソースコードからソフトウェアを
 6761: 構築するためのソフトウェアはありません。この部分は構築システムが
 6762: @sc{cvs} と協調するかもしれない種々の側面を説明します。
 6763: 
 6764: @c Is there a way to discuss this without reference to
 6765: @c tools other than CVS?  I'm not sure there is; I
 6766: @c wouldn't think that people who learn CVS first would
 6767: @c even have this concern.
 6768: @sc{rcs} に慣れている人からの特に多い、よくある質問は、どうすれば構築
 6769: 機構が最新のソースのコピーを手に入れることができるか、ということです。
 6770: @sc{cvs} では2重になります。まず最初に、@sc{cvs} はディレクトリを再帰
 6771: 的に辿ることができますので、各ファイルが最新であることを確認するために 
 6772: @file{Makefile} (もしくは、構築ツールが使う設定ファイルの名前) を修正
 6773: する必要はありません。その代わりに、まず @code{cvs -q update} として、
 6774: それから @code{make} や構築ツールを起動するコマンドを実行するという2つ
 6775: のコマンドだけを使います。2番目に、あなた自身の作業が終わるまで、誰か
 6776: の変更したコピーを取得@emph{したい} と思わないかもしれません。1つの方
 6777: 法はまずソースを更新して、それから実装、構築し、考えていた変更を試して
 6778: からソースを格納する (必要ならまず更新します) というものです。定期的に
 6779: (変更の合間に、さっき書いた方法で) 木全体を更新することで、ソースが十
 6780: 分に新しいことを保証できます。
 6781: 
 6782: @cindex Bill of materials
 6783: よくある要求は、どのソースファイルのどのリビジョンが特定の構築に相当す
 6784: るかを記録することです。このような種類の機能は @dfn{bill of materials} 
 6785: などと呼ばれることがあります。@sc{cvs} で実現する最良の方法は 
 6786: @code{tag}コマンドがどのバージョンが与えられた構築に相当するかを記録す
 6787: ることです (@pxref{Tags})。
 6788: 
 6789: @sc{cvs} を一番素直な方法で使うと、それぞれの開発者は特定の構築に使わ
 6790: れるソースツリー全体のコピーを持っています。ソースツリーが小さかったり、
 6791: 開発者が地理的に離れたところにいるのなら、これが好ましい解決方法です。
 6792: 実のところ、大きなプロジェクトを遂行する手段の一つはプロジェクトを小さ
 6793: な分割してコンパイルされるサブシステムに分け、開発者に必要なことは主に
 6794: 作業しているサブシステムだけを取り出すだけにするように、内部でリリース
 6795: する方法を作ることです。
 6796: @c I say subsystem instead of module because they may or
 6797: @c may not use the modules file.
 6798: 
 6799: 別の手段は、開発者にいくつかのファイルのコピーだけの所有をして、他のファ
 6800: イルには中央管理下のソースファイルを見に行くことができるようにする機構
 6801: を設定することです。多くの人は、大部分のオペレーティング・システムにあ
 6802: るシンボリックリンクや、@code{make} の多くのバージョンにある 
 6803: @code{VPATH} 機能を使う様な解決法に到達しました。
 6804: @c two such people are paul@sander.cupertino.ca.us (for
 6805: @c a previous employer)
 6806: @c and gtornblo@senet.abb.se (spicm and related tools),
 6807: @c but as far as I know
 6808: @c no one has nicely packaged or released such a system (or
 6809: @c instructions for constructing one).
 6810: このような種類のものを助けるために設計された構築ツールに Odin というも
 6811: のがあります (@code{ftp://ftp.cs.colorado.edu/pub/distribs/odin} 参照)。
 6812: @c Should we be saying more about Odin?  Or how you use
 6813: @c it with CVS?  Also, the Prime Time Freeware for Unix
 6814: @c disk (see http://www.ptf.com/) has Odin (with a nice
 6815: @c paragraph summarizing it on the web), so that might be a
 6816: @c semi-"official" place to point people.
 6817: @c
 6818: @c Of course, many non-CVS systems have this kind of
 6819: @c functionality, for example OSF's ODE
 6820: @c (http://www.osf.org/ode/) or mk
 6821: @c (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
 6822: @c He has changed providers in the past; a search engine search
 6823: @c for "Peter Ziobrzynski" probably won't get too many
 6824: @c spurious hits :-).  A more stable URL might be
 6825: @c ftp://ftp.uu.net/pub/cmvc/mk).  But I'm not sure
 6826: @c there is any point in mentioning them here unless they
 6827: @c can work with CVS.
 6828: 
 6829: @c ---------------------------------------------------------------------
 6830: @node Special Files
 6831: @chapter 特別なファイル
 6832: 
 6833: @cindex Special files
 6834: @cindex Device nodes
 6835: @cindex Ownership, saving in CVS
 6836: @cindex Permissions, saving in CVS
 6837: @cindex Hard links
 6838: @cindex Symbolic links
 6839: 
 6840: 普通の環境では、CVS は普通のファイルでのみ動作します。プロジェクトの全
 6841: てのファイルは永続すると仮定されています。開き、読み込み、閉じるという
 6842: 操作などが可能でなければなりません。また、CVS はファイルの使用許可と所
 6843: 有権を無視します。そのような問題はインストール時に開発者によって解決さ
 6844: れる必要があります。言い換えれば、デバイスを "格納" することは不可能で
 6845: す。デバイスファイルを開けなければ、CVS はそれを扱うことを拒否します。
 6846: ファイルはリポジトリの取り扱い中にも所有権や使用許可を失います。
 6847: 
 6848: リポジトリで設定変数 @code{PreservePermissions} (@pxref{config}) が設
 6849: 定されていると、CVS は以下のファイルの特性をリポジトリに記録します:
 6850: 
 6851: @itemize @bullet
 6852: @item 使用者とグループの所有権
 6853: @item 使用許可
 6854: @item 主・副デバイス番号
 6855: @item シンボリックリンク
 6856: @item ハードリンク機構
 6857: @end itemize
 6858: 
 6859: @code{PreservePermissions} オプションを使うと CVS の振舞いにいくつか影
 6860: 響します。まず、CVS で使用可能になった新しい操作の中に、全ての使用者に
 6861: は使用可能でないものができます。特に、ファイルの所有権と特別なファイル
 6862: の特性とはスーパーユーザにだけ変更できるものでしょう。ですから、
 6863: @code{PreservePermissions} 設定変数が設定されていると、使用者は CVS の
 6864: 操作をうるために `root' になる必要があるでしょう。
 6865: 
 6866: @code{PreservePermissions} が使用されていると、CVS の操作の中には 
 6867: (@samp{cvs status} のように) ファイルのハードリンク構造を認識せず、合っ
 6868: ていないハードリンクに関して見せかけの警告を出力します。これは CVS の
 6869: 内部構造がハードリンクに必要なデータ全てを集めるのを難しくしており、そ
 6870: のために不正確なデータでファイルの衝突を調べるからです。
 6871: 
 6872: CVS はファイルの内容が変更されたときのみ、それが変更されたと考えること
 6873: による、より微妙な違いがあります (特に、作業ファイルの修正時刻がリポジ
 6874: トリのそのファイルと合わないとき)。ですから、使用許可、所有権、ハード
 6875: リンクが変わったり、デバイスの主、副番号が変わったとしても、CVS は報告
 6876: しません。そのような変更をリポジトリに格納するためには、@samp{cvs
 6877: commit -f} で格納を強制する必要があります。これは、ファイルの使用許可
 6878: が変わっていて、リポジトリのファイルが作業コピーより新しいと、
 6879: @samp{cvs update} の実行は、知らない間に作業コピーの使用許可を変更して
 6880: いるということでもあります。
 6881: 
 6882: CVS リポジトリでのハードリンクの変更は特に慎重な扱いが必要です。
 6883: @file{foo} がファイル @file{old} にリンクされていたけれど、後でファイ
 6884: ル @file{new} にリンクされ直したとしましょう。@file{foo}, @file{old},
 6885: @file{new} は全て中のリンクパターンは変更されているけれど、@file{foo} 
 6886: と @file{new} だけが修正されていて、そのために @file{old} は格納の候補
 6887: としてみなされない、という変な状況になることがあります。このような方法
 6888: により整合しない結果は非常に簡単に作られます。ですから、ハードリンクを
 6889: リポジトリに保存するのが重要なときは、賢明な動作方法は最後の格納からリ
 6890: ンクや状態が変わったファイル全てに @code{touch} することです。実際、複
 6891: 雑なハードリンク構造のディレクトリを格納する前には @code{touch *} をす
 6892: るのが賢いかもしれません。
 6893: 
 6894: おそらく明らかである理由により、普通のファイルだけがマージできるという
 6895: ことを書いておくのも意味のあることでしょう。もし @samp{cvs update} や 
 6896: @samp{cvs checkout -j} がシンボリックリンクを普通のファイルとマージし
 6897: ようとしたり、2つのデバイスファイルが違った種類のデバイスのためのもの
 6898: であったりすると、CVS は衝突を報告して、マージの実行を拒否します。また、
 6899: テキストがないファイル上でのテキスト比較は無意味なので、@samp{cvs
 6900: diff} はこれらのファイル間の相違を報告しません。
 6901: 
 6902: @code{PreservePermissions} 機能はクライアント/サーバの @sc{cvs} では動
 6903: 作しません。別の制限に、ハードリンクは同じディレクトリの他のファイルへ
 6904: のリンクでなければならない、というものがあります。ディレクトリをまたい
 6905: だハードリンクは使用できません。
 6906: 
 6907: @c ---------------------------------------------------------------------
 6908: @node CVS commands
 6909: @appendix CVS のコマンド便覧
 6910: 
 6911: この付録は @sc{cvs} コマンドの全体構造の説明をし、いくつかのコマンドは
 6912: 詳しく説明します (他のものは別のところで説明されています。@sc{cvs} コ
 6913: マンドの簡単な便覧は、@pxref{Invoking CVS})。
 6914: @c The idea is that we want to move the commands which
 6915: @c are described here into the main body of the manual,
 6916: @c in the process reorganizing the manual to be
 6917: @c organized around what the user wants to do, not
 6918: @c organized around CVS commands.
 6919: @c
 6920: @c Note that many users do expect a manual which is
 6921: @c organized by command.  At least some users do.
 6922: @c One good addition to the "organized by command"
 6923: @c section (if any) would be "see also" links.
 6924: @c The awk manual might be a good example; it has a
 6925: @c reference manual which is more verbose than Invoking
 6926: @c CVS but probably somewhat less verbose than CVS
 6927: @c Commands.
 6928: 
 6929: @menu
 6930: * Structure::                   CVS コマンド構造の全て
 6931: * Exit status::                 CVS の成功か失敗を示す
 6932: * ~/.cvsrc::                    既定オプションと ~/.cvsrc ファイル
 6933: * Global options::              cvs_command の左側に付けるオプション
 6934: * Common options::              cvs_command の右側に付けるオプション
 6935: * admin::                       管理
 6936: * checkout::                    編集の為にソースを取り出す
 6937: * commit::                      ファイルをリポジトリに格納する
 6938: * diff::                        リビジョン間の差分を見る
 6939: * export::                      CVS からソースを取り出す, checkout に類似
 6940: * history::                     ファイルと使用者の状態を表示
 6941: * import::                      CVS にソースを取り込む, ベンダー枝を使用
 6942: * log::                         ファイルのログ情報を表示
 6943: * rdiff::                       リリース間の `patch' 形式の差分
 6944: * release::                     ディレクトリの放棄を表明する
 6945: * update::                      作業コピーをリポジトリと一致させる
 6946: @end menu
 6947: 
 6948: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6949: @node Structure
 6950: @appendixsec CVS コマンド構造の全て
 6951: @cindex Structure
 6952: @cindex CVS command structure
 6953: @cindex Command structure
 6954: @cindex Format of CVS commands
 6955: 
 6956: @sc{cvs} のコマンド全体の書式を示します:
 6957: 
 6958: @example
 6959: cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
 6960: @end example
 6961: 
 6962: @table @code
 6963: @item cvs
 6964: @sc{cvs} プログラムの名前です。
 6965: 
 6966: @item cvs_options
 6967: @sc{cvs} のサブコマンド全体に適用されるオプションです。以下で説明され
 6968: ています。
 6969: 
 6970: @item cvs_command
 6971: いくつかの違ったサブコマンドの一つです。
 6972: 幾つかのコマンドでは別名が使用できます。別名はそのコマンドの便覧マニュ
 6973: アルのところで書かれています。
 6974: 次の二つの場合にだけ @samp{cvs_command} を省略できます。
 6975: つまり @samp{cvs -H} として利用可能なコマンドのリストを得る場合か、
 6976: @samp{cvs -v} として @sc{cvs} 自身のバージョン情報を得る場合です。
 6977: 
 6978: @item command_options
 6979: コマンド固有のオプションです。
 6980: 
 6981: @item command_args
 6982: コマンドの引数です。
 6983: @end table
 6984: 
 6985: 不幸な事に、
 6986: @code{cvs_options} と @code{command_options} の間で幾つか混乱があります。
 6987: @samp{-l} は @code{cvs_option} として使われたときいくつかのコマンドに
 6988: 影響します。@code{command_option} として使されたときは、より多くのコマ
 6989: ンドで意味を持ちます。つまり、上の分類をあまり深刻に受けとめないでくだ
 6990: さい。代わりに文書を見るようにしましょう。
 6991: 
 6992: @node Exit status
 6993: @appendixsec CVS の終了状態
 6994: @cindex Exit status, of CVS
 6995: 
 6996: CVS はそれ呼んだ環境に @dfn{終了状態} (@dfn{exit status}) を設定するこ
 6997: とで、成功したか失敗したかを示すことができます。
 6998: 終了状態を調べる正確な方法はオペレーティング・システムごとに異なります。
 6999: 例えば、unix のシェルスクリプトでは、最後のコマンドが成功終了状態を返
 7000: せば変数 @samp{$?} は0で、終了状態が失敗を示していれば、0より大きくな
 7001: ります。
 7002: 
 7003: CVS が成功した場合は、成功状態を返します。エラーがあれば、エラーメッセー
 7004: ジを印字して、失敗状態を返します。@code{cvs diff} コマンドはこの例外で
 7005: す。違いが見つからなければ成功状態を返し、違いが見つかるか、エラーが発
 7006: 生したときに失敗状態を返します。この振舞いはエラーの検知には良くないの
 7007: で、将来では @code{cvs diff} が他の @sc{cvs} コマンドと同じように振舞
 7008: うように変更される可能性があります。
 7009: @c It might seem like checking whether cvs -q diff
 7010: @c produces empty or non-empty output can tell whether
 7011: @c there were differences or not.  But it seems like
 7012: @c there are cases with output but no differences
 7013: @c (testsuite basica-8b).  It is not clear to me how
 7014: @c useful it is for a script to be able to check
 7015: @c whether there were differences.
 7016: @c FIXCVS? In previous versions of CVS, cvs diff
 7017: @c returned 0 for no differences, 1 for differences, or
 7018: @c 2 for errors.  Is this behavior worth trying to
 7019: @c bring back (but what does it mean for VMS?)?
 7020: 
 7021: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7022: @node ~/.cvsrc
 7023: @appendixsec 既定オプションと ~/.cvsrc ファイル
 7024: @cindex .cvsrc file
 7025: @cindex Option defaults
 7026: 
 7027: よく使用する @code{command_option} が幾つかあり、
 7028: そのオプションを必ず指定するように設定したいことがあります。
 7029: 例えば (実際に .cvsrc を実装した要因の一つですが) 
 7030: 多くの人には @samp{diff} の既定出力は大変読みにくく、
 7031: context 形式か unidiff 形式のほうが遥かに分かりやすいでしょう。
 7032: 
 7033: シェル・スクリプトやエイリアスに頼らなくても、
 7034: @file{~/.cvsrc} ファイルを用いて @code{cvs_commands} 各々に
 7035: 既定のオプションを加えることができます。
 7036: 
 7037: @file{~/.cvsrc} の書式は簡単です。
 7038: 実行された @code{cvs_command} と同じ名前で始まる行が検索されます。
 7039: 一致した行を発見したら、行の残りの部分をオプションに分割し (空白のとこ
 7040: ろで)、
 7041: コマンド行からのオプションを与える@emph{前に}、
 7042: 得られたオプションをコマンドの引数として与えます。
 7043: コマンドが別名を持つ場合 (例えば、@code{checkout} と @code{co})、
 7044: コマンド行で使われるものとは限りませんが、公的な名前がファイルとの
 7045: 合致時に使用されます。
 7046: 例えば @file{~/.cvsrc} の内容が次の様であった場合:
 7047: 
 7048: @example
 7049: log -N
 7050: diff -u
 7051: update -P
 7052: checkout -P
 7053: @end example
 7054: 
 7055: @noindent
 7056: @samp{cvs co foo} も、コマンド @samp{cvs checkout foo} と同様に 
 7057: @samp{-P} が引数として与えられます。
 7058: 
 7059: 上記の例では @samp{cvs diff foobar} の出力は unidiff 形式になります。
 7060: @samp{cvs diff -c foobar} だと指定通り context 形式になります。
 7061: @samp{diff} には "古い" 形式で出力するためのオプションが無いため、
 7062: "古い" 形式を使いたい場合には少し面倒ですが 
 7063: @samp{cvs -f diff foobar} とする必要があります。
 7064: 
 7065: コマンド名の部分に @code{cvs} と記述すれば、
 7066: 広域オプションを指定することができます (@pxref{Global options})。
 7067: 例えば @file{.cvsrc} 中の以下の行は、
 7068: 
 7069: @example
 7070: cvs -z6
 7071: @end example
 7072: 
 7073: @sc{cvs} が圧縮レベル 6 を用いるように指定しています。
 7074: 
 7075: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7076: @node Global options
 7077: @appendixsec 広域オプション
 7078: @cindex Options, global
 7079: @cindex Global options
 7080: @cindex Left-hand options
 7081: 
 7082: @samp{cvs_options} (@samp{cvs_command} の左側に与えられる) 
 7083: として利用できるものを以下に示します:
 7084: 
 7085: @table @code
 7086: @item --allow-root=@var{rootdir}
 7087: 正しい @sc{cvsroot} ディレクトリを指定します。@ref{Password
 7088: authentication server} 参照。
 7089: 
 7090: @cindex Authentication, stream
 7091: @cindex Stream authentication
 7092: @item -a
 7093: クライアントとサーバの全ての通信を認証します。@sc{cvs} クライアントで
 7094: だけ意味をもちます。これを書いている時点では、GSSAPI 接続を行う場合だ
 7095: けに実装されています (@pxref{GSSAPI authenticated})。認証は流れている 
 7096: @sc{tcp} 接続のハイジャックというような攻撃から身を守ることができます。
 7097: 認証を使用しても暗号化は使用されません。
 7098: 
 7099: @cindex RCSBIN, overriding
 7100: @cindex Overriding RCSBIN
 7101: @item -b @var{bindir}
 7102: @sc{cvs} 1.9.18 以前では、これは @sc{rcs} プログラムが @var{bindir} ディ
 7103: レクトリにあることを指定していました。現在のバージョンの @sc{cvs} は 
 7104: @sc{rcs} プログラムを実行しません。互換性のためにこのオプションがあり
 7105: ますが、指定しても何もしません。
 7106: 
 7107: @cindex TMPDIR, overriding
 7108: @cindex Overriding TMPDIR
 7109: @item -T @var{tempdir}
 7110: 一時ファイルが置かれるディレクトリを @var{tempdir} とします。
 7111: 環境変数 @code{$TMPDIR} の設定や、
 7112: コンパイル時のディレクトリ設定よりも優先されます。
 7113: この値は絶対パス名で指定して下さい。
 7114: 
 7115: @cindex CVSROOT, overriding
 7116: @cindex Overriding CVSROOT
 7117: @item -d @var{cvs_root_directory}
 7118: リポジトリのルートディレクトリのパス名を @var{cvs_root_directory} とし
 7119: ます。
 7120: 環境変数 @code{$CVSROOT} よりも優先します。@xref{Repository}.
 7121: 
 7122: @cindex EDITOR, overriding
 7123: @cindex Overriding EDITOR
 7124: @item -e @var{editor}
 7125: リビジョンのログ情報の入力に @var{editor} を使用します。
 7126: 環境変数 @code{$CVSEDITOR} や @code{$EDITOR} よりも優先します。
 7127: 詳しい情報は @ref{Committing your changes} 参照。
 7128: 
 7129: @item -f
 7130: @file{~/.cvsrc} を読みません。
 7131: このオプションが最も良く使われるのは、
 7132: @sc{cvs} のオプション設定に直交性がない時です。
 7133: 例えば @samp{cvs log} のオプション @samp{-N} (タグの表示を抑制します)
 7134: に対応する表示を行なうオプションはありません。
 7135: 従って、@file{~/.cvsrc} の @samp{log} エントリに @samp{-N} があったとき、
 7136: タグを表示するには @samp{-f} を使用する他ありません。
 7137: 
 7138: @item -H
 7139: @itemx --help
 7140: 指定された @samp{cvs_command} の使用法を表示します 
 7141: (コマンドが実際に実行されることはありません)。
 7142: コマンド名を指定しない場合には、
 7143: @samp{cvs -H} は他のヘルプオプションの一覧などを含む、@sc{cvs} の全体
 7144: のヘルプを表示します。
 7145: @c It seems to me it is better to document it this way
 7146: @c rather than trying to update this documentation
 7147: @c every time that we add a --help-foo option.  But
 7148: @c perhaps that is confusing...
 7149: 
 7150: @item -l
 7151: @samp{cvs_command} をコマンド履歴に記録しません 
 7152: (しかしコマンドは実行されます)。
 7153: コマンド履歴の情報は @xref{history}.
 7154: 
 7155: @cindex Read-only mode
 7156: @item -n
 7157: ファイルを更新しません。
 7158: @samp{cvs_command} を実行した場合の表示だけが行なわれます。
 7159: 既存のファイルを削除, 更新, マージしたり、
 7160: 新しいファイルを作成することはありません。
 7161: 
 7162: @sc{cvs} は必ずしも @samp{-n} を付けなかったときと全く同じ出力をするわ
 7163: けではないことに注意してください。ときどき、出力が同じ場合がありますが、
 7164: 他の場合では、@sc{cvs} は正確に同じ出力をするために必要な実行を飛ばし
 7165: ます。
 7166: 
 7167: @item -Q
 7168: コマンドの出力が完全に抑止され、
 7169: 重大な問題が発生した場合にのみ出力が行なわれます。
 7170: 
 7171: @item -q
 7172: コマンドの出力を減らします。
 7173: 再帰的にサブディレクトリを辿る時の報告などの補助情報は抑止されます。
 7174: 
 7175: @cindex Read-only files, and -r
 7176: @item -r
 7177: 新たな作業ファイルを読み込み専用にします。
 7178: 環境変数 @code{$CVSREAD} を設定するのと同じ効果があります 
 7179: (@pxref{Environment variables})。
 7180: 既定では、そのファイルが監視されてない限り作業ファイルへの書き込みが許
 7181: 可されます (@pxref{Watches})。
 7182: 
 7183: @item -s @var{variable}=@var{value}
 7184: ユーザ変数を設定します (@pxref{Variables})。
 7185: 
 7186: @cindex Trace
 7187: @item -t
 7188: プログラムの実行状態をトレースします。
 7189: @sc{cvs} が実行する各ステップの情報を表示します。
 7190: @samp{-n} オプションと共に使用し、
 7191: 不慣れなコマンドの潜在的な影響を調べるのに便利です。
 7192: 
 7193: @item -v
 7194: @item --version
 7195: @sc{cvs} のバージョンと著作権情報を表示します。
 7196: 
 7197: @cindex CVSREAD, overriding
 7198: @cindex Overriding CVSREAD
 7199: @item -w
 7200: 新しい作業ファイルを読み書き可能にします。
 7201: 環境変数 @code{$CVSREAD} の設定を無効にします。
 7202: @code{$CVSREAD} が設定されておらず、
 7203: @samp{-r} オプションも無い場合には、
 7204: 作成されるファイルは読み書き可能とされます。
 7205: @c Note that -w only overrides -r and CVSREAD; it has
 7206: @c no effect on files which are readonly because of
 7207: @c "cvs watch on".  My guess is that is the way it
 7208: @c should be (or should "cvs -w get" on a watched file
 7209: @c be the same as a get and a cvs edit?), but I'm not
 7210: @c completely sure whether to document it this way.
 7211: 
 7212: @item -x
 7213: @cindex encryption
 7214: クライアントとサーバ間の全ての通信を暗号化します。これは @sc{cvs} クラ
 7215: イアントでだけ意味を持ち、また現時点では GSSAPI 接続を用いる場合 
 7216: (@pxref{GSSAPI authenticated}) かケルベロス接続 (@pxref{Kerberos
 7217: authenticated}) を用いる場合にしか実装されていません。暗号化を使用する
 7218: ということは送信されるメッセージも認証されるということです。既定状態で
 7219: は暗号化機能は使用できません。特別に @file{--enable-encryption} を指定
 7220: して @sc{cvs} を構築する必要があります。
 7221: 
 7222: @item -z @var{gzip-level}
 7223: @cindex Compression
 7224: @cindex Gzip
 7225: 圧縮レベルを設定します。
 7226: @sc{cvs} クライアントでだけ意味を持ちます。
 7227: 
 7228: @end table
 7229: 
 7230: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7231: @node Common options
 7232: @appendixsec 共通のコマンド・オプション
 7233: @cindex Common options
 7234: @cindex Right-hand options
 7235: 
 7236: ここでは、複数の @sc{cvs} コマンドで共通に使用できる 
 7237: @samp{command_options} について説明します。
 7238: これらのオプションは、
 7239: 必ず @samp{cvs_command} の右側に付けられます。
 7240: 以下に示すオプションは、全てのコマンドで使えるわけではありません。
 7241: 各オプションは、それが意味をなすコマンドにおいてのみ使用可能です。
 7242: しかし以下のオプションを持つコマンドがあるならば、
 7243: そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。
 7244: (各コマンドの固有オプションのほとんどは、
 7245: 他の @sc{cvs} コマンドのものとは異なる意味を持っています。)
 7246: 
 7247:  @strong{警告:} @samp{history} コマンドは例外です。このコマンドには、
 7248: ここに示す標準オプションと重複する固有オプションが多くあります。
 7249: 
 7250: @table @code
 7251: @cindex Dates
 7252: @cindex Time
 7253: @cindex Specifying dates
 7254: @item -D @var{date_spec}
 7255: @var{date_spec} 以前のリビジョンのうち、最新のものを使用します。
 7256: @var{date_spec} には、過去の日付を示すものを一つだけ指定します。
 7257: 
 7258: このオプションを用いて作業ファイルを取り出すと、
 7259: 指定した日付が@dfn{貼り付け}られます。
 7260: つまり @samp{-D} オプションの引数が記録され、
 7261: これ以後の @code{update} の際に同じ日付が用いられます 
 7262: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 7263: @samp{-D} は以下のコマンドで利用できます:
 7264: @code{checkout}, @code{diff}, @code{export}, @code{history},
 7265: @code{rdiff}, @code{rtag}, @code{update}.
 7266: (@code{history} コマンドはこのオプションを少し違った方法で使用します。
 7267: @pxref{history options}).
 7268: 
 7269: @c What other formats should we accept?  I don't want
 7270: @c to start accepting a whole mess of non-standard
 7271: @c new formats (there are a lot which are in wide use in
 7272: @c one context or another), but practicality does
 7273: @c dictate some level of flexibility.
 7274: @c * POSIX.2 (e.g. touch, ls output, date) and other
 7275: @c POSIX and/or de facto unix standards (e.g. at).  The
 7276: @c practice here is too inconsistent to be of any use.
 7277: @c * VMS dates.  This is not a formal standard, but
 7278: @c there is a published specification (see SYS$ASCTIM
 7279: @c and SYS$BINTIM in the _VMS System Services Reference
 7280: @c Manual_), it is implemented consistently in VMS
 7281: @c utilities, and VMS users will expect CVS running on
 7282: @c VMS to support this format (and if we're going to do
 7283: @c that, better to make CVS support it on all
 7284: @c platforms.  Maybe).
 7285: @c
 7286: @c NOTE: The tar manual has some documentation for
 7287: @c getdate.y (just for our info; we don't want to
 7288: @c attempt to document all the formats accepted by
 7289: @c getdate.y).
 7290: @c
 7291: @c One more note: In output, CVS should consistently
 7292: @c use one date format, and that format should be one that
 7293: @c it accepts in input as well.  The former isn't
 7294: @c really true (see survey below), and I'm not
 7295: @c sure that either of those formats is accepted in
 7296: @c input.
 7297: @c
 7298: @c cvs log
 7299: @c   current 1996/01/02 13:45:31
 7300: @c   Internet 02 Jan 1996 13:45:31 UT
 7301: @c   ISO 1996-01-02 13:45:31
 7302: @c cvs ann
 7303: @c   current 02-Jan-96
 7304: @c   Internet-like 02 Jan 96
 7305: @c   ISO 96-01-02
 7306: @c cvs status
 7307: @c   current Tue Jun 11 02:54:53 1996
 7308: @c   Internet [Tue,] 11 Jun 1996 02:54:53
 7309: @c   ISO 1996-06-11 02:54:53
 7310: @c   note: date possibly should be omitted entirely for
 7311: @c   other reasons.
 7312: @c cvs editors
 7313: @c   current Tue Jun 11 02:54:53 1996 GMT
 7314: @c cvs history
 7315: @c   current 06/11 02:54 +0000
 7316: @c any others?
 7317: @c There is a good chance the proper solution has to
 7318: @c involve at least some level of letting the user
 7319: @c decide which format (with the default being the
 7320: @c formats CVS has always used; changing these might be
 7321: @c _very_ disruptive since scripts may very well be
 7322: @c parsing them).
 7323: @c
 7324: @c Another random bit of prior art concerning dates is
 7325: @c the strptime function which takes templates such as
 7326: @c "%m/%d/%y", and apparent a variant of getdate()
 7327: @c which also honors them.  See
 7328: @c X/Open CAE Specification, System Interfaces and
 7329: @c Headers Issue 4, Version 2 (September 1994), in the
 7330: @c entry for getdate() on page 231
 7331: 
 7332: @cindex Timezone, in input
 7333: @cindex Zone, time, in input
 7334: @sc{cvs} では、様々な形式で日付を指定できます。
 7335: 最も標準的なものは (International Standards Organization による) 
 7336: ISO8601 と (RFC 822 で規定され、RFC1123 で修正された) Internet e-mail
 7337: の標準です。
 7338: 
 7339: @c Probably should be doing more to spell out just what
 7340: @c the rules are, rather than just giving examples.
 7341: @c But I want to keep this simple too.
 7342: @c So I don't know....
 7343: @c A few specific issues: (1) Maybe should reassure
 7344: @c people that years after 2000
 7345: @c work (they are in the testsuite, so they do indeed
 7346: @c work).  (2) What do two digit years
 7347: @c mean?  Where do we accept them?  (3) Local times can
 7348: @c be ambiguous or nonexistent if they fall during the
 7349: @c hour when daylight savings time goes into or out of
 7350: @c effect.  Pretty obscure, so I'm not at all sure we
 7351: @c should be documenting the behavior in that case.
 7352: ISO8601 はいろんな異種があります。すこし例を挙げます:
 7353: 
 7354: @example
 7355: 1972-09-24
 7356: 1972-09-24 20:05
 7357: @end example
 7358: @c I doubt we really accept all ISO8601 format dates
 7359: @c (for example, decimal hours like 1972-09-24 20,2)
 7360: @c I'm not sure we should, many of them are pretty
 7361: @c bizarre and it has lots of gratuitous multiple ways
 7362: @c to specify the same thing.
 7363: 
 7364: ISO8601 の日付様式にはいろいろなものがあり、CVS はそれらの多くを受け付
 7365: けますが、おそらくながーい話し@emph{全部}を聞きたいとは思わないでしょ
 7366: う :-)。
 7367: 
 7368: @c Citing a URL here is kind of problematic given how
 7369: @c much they change and people who have old versions of
 7370: @c this manual, but in case we want to reinstate an
 7371: @c ISO8601 URL, a few are:
 7372: @c http://www.saqqara.demon.co.uk/datefmt.htm
 7373: @c http://www.cl.cam.ac.uk/~mgk25/iso-time.html
 7374: @c Citing some other ISO8601 source is probably even
 7375: @c worse :-).
 7376: 
 7377: Internet e-mail で使用が認められている日付に加えて、
 7378: @sc{cvs} では、いくつかのフィールドが省略されたものも使えます。
 7379: 例えば、以下のようなものです:
 7380: @c FIXME: Need to figure out better, and document,
 7381: @c what we want to allow the user to omit.
 7382: @c NOTE: "omit" does not imply "reorder".
 7383: @c FIXME: Need to cite a web page describing how to get
 7384: @c RFC's.
 7385: 
 7386: @example
 7387: 24 Sep 1972 20:05
 7388: 24 Sep
 7389: @end example
 7390: 
 7391: 特定の標準時が指定されていない場合は、日付はローカルの標準時として解釈
 7392: されます。
 7393: 
 7394: この2つの書式の使用が好まれます。しかし、@sc{cvs} は今は他の日付の書式
 7395: を幅広く受け付けます。それらはここでは故意に詳しくは説明されておらず、
 7396: @sc{cvs} の将来のバージョンはそれら全ては受け付けないかもしれません。
 7397: @c We should document and testsuite "now" and
 7398: @c "yesterday".  "now" is mentioned in the FAQ and
 7399: @c "yesterday" is mentioned in this document (and the
 7400: @c message from "cvs import" suggesting a merge
 7401: @c command).  What else?  Probably some/all of the "3
 7402: @c weeks ago" family.
 7403: @c
 7404: @c Maybe at
 7405: @c some point have CVS start give warnings on "unofficial"
 7406: @c formats (many of which might be typos or user
 7407: @c misunderstandings, and/or formats people never/rarely
 7408: @c use to specify dates)?
 7409: 
 7410: そのような書式の中に
 7411: @code{@var{月}/@var{日}/@var{年}}.  というものがあります。
 7412: これは月と日が逆の順番になっているものに慣れている人を混乱させます。
 7413: @samp{1/4/96} は1月4日であり、4月1日ではありません。
 7414: 
 7415: シェルは空白を引数の区切りにするので、
 7416: @samp{-D} の引数を引用符で囲むのを忘れてはいけません。
 7417: @samp{-D} オプションを付けたコマンド行は、次の様になるでしょう:
 7418: 
 7419: @example
 7420: $ cvs diff -D "1 hour ago" cvs.texinfo
 7421: @end example
 7422: 
 7423: @cindex Forcing a tag match
 7424: @item -f
 7425: 日付やタグ名を指定して @sc{cvs} コマンドを用いた場合、
 7426: そのタグ名を持たない (その時には存在しなかった) ファイルは、
 7427: 普通は無視されます。
 7428: タグでも日付でも引っ掛からなかったファイルを復元したい場合に、
 7429: @samp{-f} オプションを使用します 
 7430: (そのファイルの最新のリビジョンが取り出されます)。
 7431: 
 7432: @samp{-f} のときでさえ、指定したタグは存在していなければならないことに
 7433: 注意してください (すなわち、必ずしも全てのファイルというわけではなく、
 7434: いくつかのファイルにおいて)。 これは @sc{cvs} が、名前の入力を間違えた
 7435: ときにエラーを出すことを続けられるようにするためです。
 7436: 
 7437: @need 800
 7438: @samp{-f} は以下のコマンドで利用できます: 
 7439: @code{annotate}, @code{checkout}, 
 7440: @code{export}, @code{rdiff}, @code{rtag}, @code{update}.
 7441: 
 7442: @strong{警告:} @code{commit} と @code{remove} コマンドにも @samp{-f} 
 7443: オプションがありますが、異なる動作をします。@xref{commit options}, 
 7444: @ref{Removing files} 参照。
 7445: 
 7446: @item -k @var{kflag}
 7447: 既定のキーワード置換モードを変更します。
 7448: @var{kflag} の詳細は @ref{Substitution modes} 参照。
 7449: 
 7450: このオプションを用いて作業ファイルを取り出すと、
 7451: @var{kflag} が@dfn{貼り付け}られます。
 7452: つまり、このオプションを @code{checkout} や @code{update} コマンドに
 7453: 用いた場合、@sc{cvs} は指定した @var{kflag} をそのファイルに結合します。
 7454: これ以後、同ファイルに対する @code{update} コマンドには 
 7455: @var{kflag} が使用され続けます。
 7456: この効果は別の指定を行なうまで止みません。
 7457: 
 7458: @samp{-k} オプションは以下のコマンドで利用できます: @code{add}, 
 7459: @code{checkout}, @code{diff}, @code{import}, @code{update}.
 7460: 
 7461: @item -l
 7462: Local の頭文字です。再帰的にサブディレクトリを辿らず、
 7463: カレントディレクトリでのみコマンドを実行します。
 7464: 
 7465: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7466: @samp{cvs -l} と混同しないようにして下さい。
 7467: 
 7468: 以下のコマンドで利用できます: @code{annotate}, @code{checkout},
 7469: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7470: @code{export}, @code{log}, @code{rdiff}, @code{remove}, @code{rtag},
 7471: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7472: and @code{watchers}.
 7473: 
 7474: @cindex Editor, avoiding invocation of
 7475: @cindex Avoiding editor invocation
 7476: @item -m @var{message}
 7477: @item -m @var{message}
 7478: エディタを起動せず、ログ情報を @var{message} に記述します。
 7479: 
 7480: 以下のコマンドで利用できます: @code{add}, 
 7481: @code{commit}, @code{import}.
 7482: 
 7483: @item -n
 7484: @code{checkout}/@code{commit}/@code{rtag} コマンド実行時に、
 7485: 常には実行されるプログラムを実行しません。
 7486: 各コマンド実行時のプログラムは、
 7487: 管理用ファイル @file{modules} に記述されます 
 7488: (@pxref{modules})。
 7489: つまり、このオプションは @file{modules} の記述を無効にします。
 7490: 
 7491: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7492: @samp{cvs -n} と混同しないようにして下さい。
 7493: 
 7494: 以下のコマンドで利用できます:
 7495: @code{checkout}, @code{commit}, @code{export}, 
 7496: @code{rtag}.
 7497: 
 7498: @item -P
 7499: 空のディレクトリを削除 (prune) します。@ref{Removing directories} 参照。
 7500: 
 7501: @item -p
 7502: リポジトリから取得したファイルを、カレントディレクトリに置かず、
 7503: 標準出力に送り (pipe) ます。
 7504: 
 7505: 以下のコマンドで利用できます: @code{checkout}, @code{update}.
 7506: 
 7507: @item -R
 7508: 再帰的にディレクトリを辿って実行します。これは指定しなくても実行されま
 7509: す。
 7510: 
 7511: 以下のコマンドで使用可能です: @code{annotate}, @code{checkout},
 7512: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7513: @code{export}, @code{rdiff}, @code{remove}, @code{rtag},
 7514: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7515: @code{watchers}.
 7516: 
 7517: @item -r @var{tag}
 7518: @cindex HEAD, special tag
 7519: @cindex BASE, special tag
 7520: 既定の@dfn{先頭} (@dfn{head}) リビジョンの代りに、
 7521: 引数 @var{tag} で指定されたリビジョンを使用します。
 7522: @code{tag} か @code{rtag} コマンドで任意に定義されたタグの他に、
 7523: 二つの特別なタグ @samp{HEAD} と @samp{BASE} が常に利用できます。
 7524: @samp{HEAD} は、リポジトリにある最新のリビジョンを参照します。
 7525: @samp{BASE} は、作業コピーの由来となるリビジョンを参照します。
 7526: 
 7527: @c FIXME: What does HEAD really mean?  I believe that
 7528: @c the current answer is the head of the default branch
 7529: @c for all cvs commands except diff.  For diff, it
 7530: @c seems to be (a) the head of the trunk (or the default
 7531: @c branch?) if there is no sticky tag, (b) the head of the
 7532: @c branch for the sticky tag, if there is a sticky tag.
 7533: @c (b) is ugly as it differs
 7534: @c from what HEAD means for other commands, but people
 7535: @c and/or scripts are quite possibly used to it.
 7536: @c See "head" tests in sanity.sh.
 7537: @c Probably the best fix is to introduce two new
 7538: @c special tags, ".thead" for the head of the trunk,
 7539: @c and ".bhead" for the head of the current branch.
 7540: @c Then deprecate HEAD.  This has the advantage of
 7541: @c not suprising people with a change to HEAD, and a
 7542: @c side benefit of also phasing out the poorly-named
 7543: @c HEAD (see discussion of reserved tag names in node
 7544: @c "Tags").  Of course, .thead and .bhead should be
 7545: @c carefully implemented (with the implementation the
 7546: @c same for "diff" as for everyone else), test cases
 7547: @c written (similar to the ones in "head"), new tests
 7548: @c cases written for things like default branches, &c.
 7549: 
 7550: タグを指定して @code{checkout} や @code{update} コマンドを実行し、
 7551: 自分の作業ファイルを作った場合、そのタグは貼り付けられます。
 7552: つまりこのタグが記録され、以後他のものを指定するまで 
 7553: @code{update} に同じタグが使われ続けます 
 7554: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 7555: 
 7556: @var{tag} には、@ref{Tags} で説明されているような文字列や、
 7557: @ref{Branching and merging} で説明されているような枝の名前のどちらであ
 7558: ることもできます。
 7559: 
 7560: コマンド・オプション @samp{-r} と一緒に
 7561: 広域オプション @samp{-q} を指定すると、
 7562: @sc{rcs} ファイルが指定したタグを含まない場合に、
 7563: 警告出力が抑止されるので便利です。
 7564: 
 7565: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7566: @samp{cvs -r} と混同しないようにして下さい!
 7567: 
 7568: @samp{-r} は以下のコマンドで利用できます :@code{checkout},
 7569: @code{commit}, @code{diff}, @code{history}, @code{export},
 7570: @code{rdiff}, @code{rtag}, @code{update}.
 7571: 
 7572: @item -W
 7573: フィルタを適用したいファイルを指定します。
 7574: フィルタを適用したいファイルが複数あるときは、
 7575: このオプションを何個並べても構いません。
 7576: ファイル @file{.cvswrappers} での指定方法と同じ形式で指定します。
 7577: 
 7578: 以下のコマンドで利用できます: @code{import}, @code{update}.
 7579: 
 7580: @end table
 7581: 
 7582: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7583: @node admin
 7584: @appendixsec admin---管理
 7585: @cindex Admin (subcommand)
 7586: 
 7587: @itemize @bullet
 7588: @item
 7589: 必須: リポジトリ, 作業ディレクトリ
 7590: @item
 7591: 変更: リポジトリ
 7592: @item
 7593: 別名: rcs
 7594: @end itemize
 7595: 
 7596: これは雑多な管理機構への @sc{cvs} のインターフェースです。@sc{cvs} で
 7597: は役に立つか疑わしいようなものもありますが、歴史的な互換性の目的のため
 7598: に存在しています。このコマンドは@emph{必ず}再帰的に動作するため、使用
 7599: の際には細心の注意を払って下さい。
 7600: 
 7601: @cindex cvsadmin
 7602: Unix ではグループ名 @code{cvsadmin} が存在する場合、
 7603: そのグループの一員だけが @code{cvs admin} を利用できます
 7604: (誰にで実行できる @code{cvs admin -k} コマンドを除きます)。
 7605: このグループはサーバ側か、非クライアント/サーバの @sc{cvs} を実行してい
 7606: る全てのシステムで存在している必要があります。
 7607: その名前で無人のグループを作成すれば、
 7608: @code{cvs admin} の使用を全面的に禁止できます。
 7609: NT では、@code{cvsadmin} 機能は存在せず、全ての使用者が @code{cvs
 7610: admin} を実行できます。
 7611: 
 7612: @menu
 7613: * admin options::               admin のオプション
 7614: @end menu
 7615: 
 7616: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7617: @node admin options
 7618: @appendixsubsec admin のオプション
 7619: 
 7620: これらのオプションの中には @sc{cvs} での有用性に疑問符が付くものもあり
 7621: ますが、歴史的な互換性のために存在しています。中には、効果を解除するま
 7622: で、@sc{cvs} を使えなくなるものもあります!
 7623: 
 7624: @table @code
 7625: @item -A@var{oldfile}
 7626: @sc{cvs} では使用されません。@var{oldfile} の利用者一覧を、
 7627: 指定した @sc{rcs} ファイルの利用者一覧に追加します。
 7628: 
 7629: @item -a@var{logins}
 7630: @sc{cvs} では使用されません。@sc{rcs} ファイルの利用者一覧に、
 7631: @var{logins} で指定された利用者を追加します。
 7632: @var{logins} はカンマで区切った利用者の一覧です。
 7633: 
 7634: @item -b[@var{rev}]
 7635: 既定の枝を @var{rev} に設定します。@sc{cvs} では、普通は既定の枝は操作
 7636: しません。貼り付いたタグ (@pxref{Sticky tags}) を使うのがどの枝で作業
 7637: をするかを決める良い方法です。@code{cvs admin -b} を実行する理由は一つ
 7638: だけあります: ベンダー枝を使用しているときに、ベンダーのバージョンに戻
 7639: すため、です (@pxref{Reverting local changes})。@samp{-b} と引数の間に
 7640: 空白があってはいけません。
 7641: @c Hmm, we don't document the usage where rev is
 7642: @c omitted.  Maybe that usage can/should be deprecated
 7643: @c (and replaced with -bHEAD or something?) (so we can toss
 7644: @c the optional argument).  Note that -bHEAD does not
 7645: @c work, as of 17 Sep 1997, but probably will once "cvs
 7646: @c admin" is internal to CVS.
 7647: 
 7648: @cindex Comment leader
 7649: @item -c@var{string}
 7650: 註釈符を @var{string} にします。註釈符は現在のバージョンの @sc{cvs} で
 7651: も、@sc{rcs} 5.7 でも使用されていません。ですから、心配する必要は全く
 7652: ありません。@xref{Keyword substitution}.
 7653: 
 7654: @item -e[@var{logins}]
 7655: @sc{cvs} では使用されません。@var{logins} に含まれる利用者を、
 7656: @sc{rcs} ファイルの利用者一覧から削除します。
 7657: @var{logins} が省略された場合は、利用者一覧を全て削除します。
 7658: @samp{-e} と引数の間に空白があってはいけません。
 7659: 
 7660: @item -I
 7661: 標準入力が端末でない場合でも対話的に動作します。
 7662: このオプションはクライアント/サーバの @sc{cvs} では動作せず、将来の
 7663: @sc{cvs} のリリースからは消えるでしょう。
 7664: 
 7665: @item -i
 7666: @sc{cvs} では無意味です。これはリビジョンを作成することなく、新しい 
 7667: @sc{rcs} ファイルを作成して、初期化します。@sc{cvs} では、@code{cvs
 7668: add} コマンドでファイルを加えてください (@pxref{Adding files})。
 7669: 
 7670: @item -k@var{subst}
 7671: 既定のキーワード置換モードを 
 7672: @var{subst} にします。@xref{Substitution modes}.
 7673: ここで既定とした方法よりも、
 7674: @code{cvs update}, @code{cvs export}, @code{cvs checkout}
 7675: での @samp{-k} オプションが優先されます。
 7676: 
 7677: @item -l[@var{rev}]
 7678: リビジョン @var{rev} をロックします。
 7679: 枝番号が与えられた場合、その枝の最新リビジョンをロックします。
 7680: @var{rev} が省略された場合は、
 7681: 既定の枝の最新リビジョンをロックします。
 7682: 引数 と @samp{-l} の間にスペースがあってはいけません。
 7683: 
 7684: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 7685: @file{rcslock.pl} という名前のスクリプトがあります。
 7686: これを用いて上記のロック状態を、
 7687: @sc{cvs} における独占取得 (一時に一人だけがファイル編集可能な状態) 
 7688: に置き換えることができます。
 7689: 詳細はスクリプトの註釈を参照して下さい 
 7690: (寄贈物の支援と権利の放棄声明文が書かれたファイル @file{README} 
 7691: も一読して下さい)。
 7692: その註釈によれば、厳格ロックモード (既定) に設定しておく必要があります。
 7693: 
 7694: @item -L
 7695: 厳格にロックを求める設定 (厳格ロックモード) にします。
 7696: 厳格ロックモードだと、@sc{rcs} ファイルの所有者であっても、
 7697: ロックしていないファイルは格納できません。
 7698: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7699: 上記 @samp{-l} オプションの説明も参照して下さい。
 7700: 
 7701: @cindex Changing a log message
 7702: @cindex Replacing a log message
 7703: @cindex Correcting a log message
 7704: @cindex Fixing a log message
 7705: @cindex Log message, correcting
 7706: @item -m@var{rev}:@var{msg}
 7707: リビジョン @var{rev} のログ・メッセージを @var{msg} に替えます。
 7708: 
 7709: @c The rcs -M option, to suppress sending mail, has never been
 7710: @c documented as a cvs admin option.
 7711: 
 7712: @item -N@var{name}[:[@var{rev}]]
 7713: これ以前の @var{name} の設定を無効にすることを除けば、
 7714: @samp{-n} と同じように働きます。
 7715: 魔法の枝での使用法は @ref{Magic branch numbers} を参照してください。
 7716: 
 7717: @item -n@var{name}[:[@var{rev}]]
 7718: 枝またはリビジョン @var{rev} にタグ名 @var{name} を付けます。
 7719: 通常は @samp{cvs tag} か @samp{cvs rtag} を代わりに用いると良いでしょう。
 7720: @samp{:} と @var{rev} の両方を省略すると、タグ名が削除されます。
 7721: また @var{name} が既に使用されていた場合は、
 7722: エラー・メッセージが出力されます。
 7723: @var{rev} がタグ名のときは、相当する番号に置換されます。
 7724: 枝番号の後に @samp{.} を付けて @var{rev} に指定した場合、
 7725: その枝の現時点での最新リビジョンになります。
 7726: @samp{:} だけで @var{rev} を指定しなかった場合、
 7727: 既定の枝 (通常は幹) の現時点での最新リビジョンになります。
 7728: 例えば @samp{cvs admin -n@var{name}: RCS/*} は、
 7729: 指定された全ての RCS ファイルの、
 7730: 現時点での最新リビジョンに @var{name} というタグ名を付けます。
 7731: 一方 @samp{cvs admin -n@var{name}:$ RCS/*} では、
 7732: 各作業ファイルのキーワード文字列に含まれる
 7733: リビジョンに @var{name} というタグ名を付けます。
 7734: 
 7735: @cindex Deleting revisions
 7736: @cindex Outdating revisions
 7737: @cindex Saving space
 7738: @item -o@var{range}
 7739: 
 7740: @var{range} の範囲のリビジョンを消去 (@dfn{過去のものにする}) します。
 7741: 
 7742: このコマンドは何をしているかを @emph{正確に} 知っていないと非常に危険
 7743: であることに注意してください (例えば、以下の @var{rev1:}@var{rev2} と
 7744: いう構文がいかに間違いやすいかという警告を読んでください)。
 7745: 
 7746: ディスクの容量が少ないなら、このオプションは役に立つかもしれません。し
 7747: かし、使う前によく考えてください---このコマンドを取り消すためには最後
 7748: のバックアップで復元するしかありません! 不注意や、(天が禁止している) 
 7749: CVS のバグによって、計画していたものと違うリビジョンを消してしまったら、
 7750: リビジョンが消去される前のエラーを修正する機会はありません。おそらく、
 7751: まずリポジトリのコピーで試すというのは良い考えでしょう。
 7752: 
 7753: 以下のどれかで @var{range} を指定します:
 7754: 
 7755: @table @code
 7756: @item @var{rev1}::@var{rev2}
 7757: CVS が rev1 から rev2 に関連付けられた差分だけを保存し、間の段階を保存
 7758: しないように、rev1 と rev2 間の全てのリビジョンを壊します。例えば、
 7759: @samp{-o 1.3::1.5} の後では、リビジョン 1.3, リビジョン 1.5, 1.3 から 
 7760: 1.5 の差分を取得することができますが、リビジョン 1.4 や 1.3 と 1.4 の
 7761: 差分を取得することはできません。他の例です: @samp{-o 1.3::1.4} と
 7762: @samp{-o 1.3::1.3} は間に消去するリビジョンが無いので、何の効果もあり
 7763: ません。
 7764: 
 7765: @item ::@var{rev}
 7766: @var{rev} のある枝と @var{rev} 自身の間のリビジョンを壊します。枝の始
 7767: 点と @var{rev} はそのまま残ります。例えば、@samp{-o ::1.3.2.6} はリビ
 7768: ジョン 1.3.2.1, リビジョン 1.3.2.5, とその間の全てのものを消去しますが、
 7769: 1.3 と 1.3.2.6 はそのまま残します。
 7770: 
 7771: @item @var{rev}::
 7772: @var{rev} と @var{rev} のある枝の最後との間のリビジョンを壊します。リ
 7773: ビジョン @var{rev} はそのまま残りますが、先頭のリビジョンは消去されま
 7774: す。
 7775: 
 7776: @item @var{rev}
 7777: リビジョン @var{rev} を消去します。例えば、@samp{-o 1.3} は @samp{-o
 7778: 1.2::1.4} と等価です。
 7779: 
 7780: @item @var{rev1}:@var{rev2}
 7781: 同じ枝の @var{rev1} から @var{rev2} のリビジョンを、それを含めて消去し
 7782: ます。@var{rev1} や @var{rev2} やその間の全てのリビジョンを取得するこ
 7783: とはできなくなります。例えば、コマンド @samp{cvs admin -oR_1_01:R_1_02
 7784: .} はほとんど役に立ちません。それは、タグ R_1_02 までのリビジョンを、
 7785: それを含めて消去するということです。でも注意してください! R_1_02 と 
 7786: R_1_03 で変更されていないファイルがあれば、そのファイルはタグ R_1_02 
 7787: と R_1_03 で@emph{同じ}数値リビジョン番号になっています。ですから、
 7788: R_1_02 を取得できなるだけではありません。R_1_03 もテープから復元しなけ
 7789: ればならなくなります! たいていの場合、代わりに @var{rev}::@var{rev2}
 7790: と指定しようと思うでしょう。
 7791: 
 7792: @item :@var{rev}
 7793: @var{rev} のある枝の最初から、@var{rev} までのリビジョンを、それを含め
 7794: て消去します。
 7795: 
 7796: @item @var{rev}:
 7797: @var{rev} のある枝の最後から、@var{rev} までのリビジョンを、それを含め
 7798: て消去します。
 7799: @end table
 7800: 
 7801: 消去されるべきリビジョンは全て枝やロックを持っていてはいけません。
 7802: 
 7803: 消去されるべきリビジョンにタグ名があり、@samp{::} 構文のどれかを指定
 7804: すると、@sc{cvs} はエラーを出して、どのリビジョンも消去されません。タ
 7805: グ名とリビジョンの両方を消去したいなら、まず @code{cvs tag -d} でタグ
 7806: 名を消去し、それから @code{cvs admin -o} を実行します。@samp{::} でな
 7807: い構文をいてい すると、@sc{cvs} はリビジョンを消去しますが、タグ名を存
 7808: 在しないリビジョン指すタグ名として残します。この振舞いは @sc{cvs} の以
 7809: 前のバージョンとの互換性のために残されています。しかし、これは便利では
 7810: ありませんので、将来は @samp{::} の場合と同様の振舞いに変更されるかも
 7811: しれません。
 7812: 
 7813: @sc{cvs} が枝を扱う方法のために、@var{rev} は、もし枝であれば名前で指
 7814: 定することはできません。説明は、@xref{Magic branch numbers}.
 7815: @c FIXME: is this still true?  I suspect not.
 7816: 
 7817: だれも壊したリビジョンのコピーを取り出していないことを確認してください。
 7818: 誰かがそれを編集して、格納し直そうとすると、変なことが起こります。この
 7819: ため、このオプションは無駄な格納を戻すためには良い方法ではありません。
 7820: 代わりにその変更を元に戻すための新しいリビジョンを格納してください 
 7821: (@pxref{Merging two revisions})。
 7822: 
 7823: @item -q
 7824: 簡素な (quiet) 表示、つまり実行時に診断情報を表示しません。
 7825: 
 7826: @item -s@var{state}[:@var{rev}]
 7827: @sc{cvs} でも使用します。
 7828: リビジョン @var{rev} の状態を識別する文字列を @var{state} にします。
 7829: @var{rev} が枝番号の場合、その枝の最新リビジョンの状態を変更します。
 7830: @var{rev} を省略すると、既定の枝の最新リビジョンを変更します。
 7831: @var{state} には、どのような文字列を用いても構いません。
 7832: 通常使用されるのは、@samp{Exp} (実験段階), @samp{Stab} (安定動作), 
 7833: @samp{Rel} (出荷済) といった組み合わせです。
 7834: 既定では、新しく作成されたリビジョンの状態は @samp{Exp} にされます。
 7835: 各リビジョンの状態は、@samp{cvs log} (@pxref{log}) の出力や、
 7836: キーワード @samp{$@asis{}Log$}, @samp{$@asis{}State$}
 7837: (@pxref{Keyword substitution}) の内容で確認できます。
 7838: ここで、@sc{cvs} が @code{dead} という状態を
 7839: 独自の目的で用いることに注意して下さい。
 7840: @code{dead} 状態を扱う際には、@code{cvs remove} 
 7841: や @code{cvs add} といったコマンドを使用し、
 7842: @samp{cvs admin -s} を使用してはいけません。
 7843: 
 7844: @item -t[@var{file}]
 7845: @sc{cvs} でも使用します。
 7846: @sc{rcs} ファイルの説明文を @var{file} の内容に書き換えます。
 7847: @var{file} のパス名は @samp{-} で始まってはいけません。
 7848: 各ファイルの説明文は @samp{cvs log} (@pxref{log}) の出力で確認できます。
 7849: @samp{-t} と引数の間に空白があってはいけません。
 7850: 
 7851: @var{file} が省略された場合、標準入力が用いられ、
 7852: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7853: 対話的動作が可能なら入力促進も可能です。@samp{-I} を参照してださい。
 7854: クライアント/サーバの @sc{cvs} では標準入力からの読み込みは動作せず、
 7855: 将来の @sc{cvs} のリリースでは変更されるかもしれません。
 7856: @c Changing it to doeditor() is the most obvious thing
 7857: @c (but with a different syntax, as we would like to
 7858: @c phase out optional arguments).  I don't know.  I'm
 7859: @c tempted to say the whole concept is unnecessary.
 7860: 
 7861: @item -t-@var{string}
 7862: @samp{-t@var{file}} と同様です。
 7863: @sc{rcs} ファイルの説明文を @var{string} に書き換えます。
 7864: @samp{-t} と引数の間に空白があってはいけません。
 7865: 
 7866: @c The rcs -T option, do not update last-mod time for
 7867: @c minor changes, has never been documented as a
 7868: @c cvs admin option.
 7869: 
 7870: @item -U
 7871: 厳格にはロックしない設定 (非厳格ロックモード) にします。
 7872: 非厳格ロックモードだと、@sc{rcs} ファイルの所有者ならば、
 7873: ロックしていないファイルも格納できます。
 7874: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7875: 上記 @samp{-l} オプションの説明も参照して下さい。
 7876: 
 7877: @item -u[@var{rev}]
 7878: このオプションを @sc{cvs} で使用する際の説明は、
 7879: 上記 @samp{-l} オプションを参照して下さい。
 7880: リビジョン @var{rev} のロックを解除します。
 7881: 枝を指定した場合、その枝の最新リビジョンのロックを解除します。
 7882: @var{rev} を省略すると、その人物が行なった最後のロックを解除します。
 7883: 通常は、ロックを掛けた人物だけがロックを解除できます。
 7884: 誰か他の人物がロックを解除した場合には、
 7885: ロックを掛けた人物にメールが送信されます。
 7886: このメールにはロックを解除した理由等が書き添えられます。
 7887: 連絡文はロックを解除した人物が入力し、
 7888: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7889: @samp{-u} とその引数の間に空白があってはいけません。
 7890: @c In the future "send mail" probably will go via the
 7891: @c CVSROOT/notify mechanism.  But for now it means
 7892: @c whatever it means to "rcs".
 7893: 
 7894: @item -V@var{n}
 7895: 前のバージョンの @sc{cvs} ではこのオプションはバージョン @var{n} の 
 7896: @sc{rcs} ファイルが認識できる @sc{rcs} ファイルを書くことを意味してい
 7897: ましたが、今は旧式となり、それを指定するとエラーを起こします。
 7898: @c Note that -V without an argument has never been
 7899: @c documented as a cvs admin option.
 7900: 
 7901: @item -x@var{suffixes}
 7902: 前のバージョンの @sc{cvs} では、これは @sc{rcs} ファイルの名前を指定す
 7903: るための方法として説明されていました。しかし、@sc{cvs} は常に @sc{cvs} 
 7904: で使用される @sc{rcs} ファイルは @samp{,v} で終わることを要求してきま
 7905: したので、このオプションは今まで役に立ったことはありません。
 7906: 
 7907: @c The rcs -z option, to specify the timezone, has
 7908: @c never been documented as a cvs admin option.
 7909: @end table
 7910: 
 7911: 
 7912: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7913: @node checkout
 7914: @appendixsec checkout---編集の為にソースを取り出す
 7915: @cindex checkout (subcommand)
 7916: @cindex co (subcommand)
 7917: 
 7918: @itemize @bullet
 7919: @item
 7920: 書式: checkout [options] modules@dots{}
 7921: @item
 7922: 必須: リポジトリ
 7923: @item
 7924: 変更: 作業ディレクトリ
 7925: @item
 7926: 別名: co, get
 7927: @end itemize
 7928: 
 7929: @var{modules} で指定されたモジュールの作業ディレクトリを作成、
 7930: もしくは更新し、
 7931: その中にソース・ファイルをコピーします。
 7932: @sc{cvs} のほとんどのコマンドは作業ディレクトリを扱うものなので、
 7933: まず @code{checkout} を実行しておく必要があります。
 7934: 
 7935: @var{modules} は、
 7936: リポジトリ中のディレクトリやファイルへの相対パスだけでなく、
 7937: ディレクトリやファイルの集合に対する別名でも構いません。
 7938: 別名は管理用ファイル @file{modules} で定義します 
 7939: @xref{modules}.
 7940: @c Needs an example, particularly of the non-"modules"
 7941: @c case but probably of both.
 7942: 
 7943: @c FIXME: this seems like a very odd place to introduce
 7944: @c people to how CVS works.  The bit about unreserved
 7945: @c checkouts is also misleading as it depends on how
 7946: @c things are set up.
 7947: 指定したモジュールにもよりますが、
 7948: @code{checkout} は再帰的にディレクトリを作成し、
 7949: そこに適切なソース・ファイルを入れていきます。
 7950: そして (他の開発者が各自のコピーを編集しているかどうかに関わらず)、
 7951: 好きなときに自分のソース・ファイルを編集し、
 7952: 他人の変更を取り入れるために更新したり、
 7953: 自分の変更をリポジトリに反映するために格納したりします。
 7954: 
 7955: @code{checkout} で作成されるディレクトリに注意して下さい。
 7956: 最上位のディレクトリは、
 7957: 必ず @code{checkout} を実行したディレクトリに追加され、
 7958: 通常は指定したモジュールと同じ名前になります。
 7959: モジュールに別名が定義されている場合、
 7960: サブディレクトリは違う名前になりますが心配は要りません。
 7961: @code{checkout} の処理中、各ファイルを作業領域に展開したと同時に
 7962: その相対パスが表示されますから、
 7963: この表示でサブディレクトリを確認して下さい 
 7964: (広域オプション @samp{-Q} を付けた場合は表示がありません)。
 7965: 
 7966: @sc{cvs} にオプション @samp{-r} が付けられた場合 
 7967: (@pxref{Global options})、
 7968: 環境変数 @code{CVSREAD} が設定されていた場合 
 7969: (@pxref{Environment variables})、
 7970: ファイルが監視されていた場合 
 7971: (@pxref{Watches}) を除いて、
 7972: @code{checkout} が作成するファイルは読み書き可能な状態になります。
 7973: 
 7974: @code{checkout} で作成したディレクトリの上で、
 7975: 再度 @code{checkout} を実行しても構わないということに注意してください。
 7976: これはリポジトリに作成された新しいディレクトリが作業領域に現れるという
 7977: 点で、@code{update} コマンドに @samp{-d} オプションを付けるのと同様の
 7978: 効果があります。しかし、@code{update} は引数にディレクトリ名を取ります
 7979: が、@code{checkout} は引数にモジュール名を取ります。@code{checkout} を
 7980: この様に使うためには、最上位のディレクトリから実行しなければなりません
 7981: ので (普段 @code{checkout} を実行する場所です)、存在するディレクトリを
 7982: 更新するために @code{checkout} を実行する前に、ディレクトリを最上位の
 7983: ディレクトリに変更することを忘れないでください。
 7984: 
 7985: @code{checkout} コマンドの出力は @ref{update output} を参照して下さい。
 7986: 
 7987: @menu
 7988: * checkout options::            checkout のオプション
 7989: * checkout examples::           checkout の使用例
 7990: @end menu
 7991: 
 7992: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7993: @node checkout options
 7994: @appendixsubsec checkout のオプション
 7995: 
 7996: @code{checkout} では、以下の標準オプションが利用できます 
 7997: (完全な記述は @pxref{Common options}):
 7998: 
 7999: @table @code
 8000: @item -D @var{date}
 8001: @var{date} 以前の最も新しいリビジョンを取り出します。
 8002: このオプションは貼り付けられ、
 8003: 勝手に @samp{-P} オプションも実行されます。
 8004: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 8005: 
 8006: @item -f
 8007: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 8008: 指定したリビジョンが見付からなかった場合、
 8009: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 8010: 
 8011: @item -k @var{kflag}
 8012: キーワード置換モードを @var{kflag} に指定します。
 8013: 詳細は @ref{Substitution modes} を参照。
 8014: このオプションは貼り付けられます。つまりこれ以後、
 8015: この作業ディレクトリでファイルが更新されるときには、
 8016: 同じ @var{kflag} が使用され続けます。
 8017: @code{status} コマンドを用いて
 8018: 貼り付いたオプションを見ることができます。
 8019: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 8020: 
 8021: @item -l
 8022: Local、つまり現在の作業ディレクトリでのみコマンドが
 8023: 実行されます。
 8024: 
 8025: @item -n
 8026: ファイルを取り出したとき、普段は実行されるプログラムを実行しません。
 8027: このプログラムは管理用ファイル @file{modules} の
 8028: オプション @samp{-o} で指定されます (@pxref{modules})。
 8029: 
 8030: @item -P
 8031: 空になったディレクトリを削除 (prune) します。@ref{Moving directories}
 8032: を参照してください。
 8033: 
 8034: @item -p
 8035: ファイルを標準出力に送り (pipe) ます。
 8036: 
 8037: @item -R
 8038: ディレクトリを再帰的に取り出します。このオプションは指定しなくても実行
 8039: されます。
 8040: 
 8041: @item -r @var{tag}
 8042: @var{tag} で指定されたリビジョンを取り出します。
 8043: このオプションは貼り付けられ、
 8044: @samp{-P} オプションも勝手に実行されます。
 8045: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 8046: @end table
 8047: 
 8048: さらに @code{checkout} では次の固有オプションも使用可能です:
 8049: 
 8050: @table @code
 8051: @item -A
 8052: 全ての貼り付いたタグや日付、
 8053: また @samp{-k} オプションの指定を剥がします。
 8054: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags} を参照してくだ
 8055: さい。
 8056: 
 8057: @item -c
 8058: 管理用ファイル @file{modules} の内容を、
 8059: アルファベット順に並べて標準出力に出します。
 8060: 作業ディレクトリは全く変更されません。
 8061: 
 8062: @item -d @var{dir}
 8063: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 8064: 一般的に、このフラグは @samp{mkdir @var{dir}; cd @var{dir}} の後に 
 8065: @samp{-d} フラグ無しで checkout コマンドを実行することと同じです。
 8066: 
 8067: しかし、重要な例外があります。単独の項目を取り出しているときには、出力
 8068: に間に空のディレクトリが無いディレクトリが現れた方がとても便利です。こ
 8069: の場合@emph{のみ}、CVS は空のディレクトリを避けるためにパス名を ``短く'' 
 8070: します。
 8071: 
 8072: 例えば、ファイル @samp{bar.c} がある @samp{foo} というモジュールがある
 8073: とすると、コマンド @samp{cvs co -d dir foo} はディレクトリ @samp{dir}
 8074: を作成し、中に @samp{bar.c} を置きます。同様に、サブディレクトリ 
 8075: @samp{baz} があり、その中に @samp{quux.c} のあるモジュール @samp{bar} 
 8076: があるとすると、コマンド @samp{cvs -d dir co bar/baz} はディレクトリ 
 8077: @samp{dir} 作成し、その中に @samp{quux.c} を置きます。
 8078: 
 8079: @samp{-N} フラグを使うと、この振舞いは抑制されます。上と同じモジュール
 8080: の定義で、@samp{cvs co -N -d dir foo} はディレクトリ @samp{dir/foo} を
 8081: 作成してその中に @samp{bar.c} を置き、@samp{cvs co -N -d dir bar/baz}
 8082: はディクトリ @samp{dir/bar/baz} を作成してその中に @samp{quux.c} を置
 8083: きます。
 8084: 
 8085: @item -j @var{tag}
 8086: @samp{-j} オプションを二つ指定した場合、
 8087: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 8088: 作業ディレクトリにマージします。
 8089: 
 8090: @samp{-j} オプションが一つの場合、
 8091: その分岐リビジョンから指定したリビジョンへの変更を、
 8092: 作業ディレクトリにマージします。
 8093: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 8094: @samp{-j} で指定したリビジョンとの共通の祖先です。
 8095: 
 8096: @samp{-j} オプションに枝を指定する場合、
 8097: 日付の指定を付加することができます。
 8098: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 8099: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 8100: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 8101: 
 8102: @xref{Branching and merging}.
 8103: 
 8104: @item -N
 8105: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 8106: このオプションを指定した場合、
 8107: 単独モジュールを取り出したときに、
 8108: 作業ディレクトリのモジュールパスを ``短く'' しません。例と説明は 
 8109: @samp{-d} フラグを参照してください。
 8110: 
 8111: @item -s
 8112: @samp{-c} と同様ですが、全てのモジュールの状態を
 8113: アルファベット順に並べて標準出力に出します。
 8114: モジュールの状態を設定するために管理用ファイル @file{modules} の中で使
 8115: われるオプション @samp{-s} の情報は、@xref{modules}.
 8116: @end table
 8117: 
 8118: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8119: @node checkout examples
 8120: @appendixsubsec checkout の使用例
 8121: 
 8122: モジュール @samp{tc} のコピーを取り出します:
 8123: 
 8124: @example
 8125: $ cvs checkout tc
 8126: @end example
 8127: 
 8128: モジュール @samp{tc} を昨日の状態で取り出します:
 8129: 
 8130: @example
 8131: $ cvs checkout -D yesterday tc
 8132: @end example
 8133: 
 8134: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8135: @node commit
 8136: @appendixsec commit---ファイルをリポジトリに格納する
 8137: @cindex commit (subcommand)
 8138: 
 8139: @itemize @bullet
 8140: @item
 8141: 書式: commit [-lnRf] [-m 'log_message' |
 8142: -F file] [-r revision] [files@dots{}]
 8143: @item
 8144: 必須: 作業ディレクトリ, リポジトリ
 8145: @item
 8146: 変更: リポジトリ
 8147: @item
 8148: 別名: ci
 8149: @end itemize
 8150: 
 8151: @code{commit} は、作業ファイルに対する変更を
 8152: リポジトリに組み入れる際に使用します。
 8153: 
 8154: 格納するファイルを特に指定しなければ、
 8155: 現在の作業ディレクトリの全ファイルが調査され、
 8156: 変更が加えられたファイルだけがリポジトリに格納されます。
 8157: 既定 (もしくは明示的にオプション @samp{-R} が指定された場合) では、
 8158: サブディレクトリのファイルも調査され、変更されていれば格納されます。
 8159: オプション @samp{-l} を指定して、
 8160: @code{commit} の動作を現在のディレクトリだけに留めることも可能です。
 8161: 
 8162: @code{commit} は、選択されたファイルが
 8163: リポジトリの最新リビジョンであるかどうか確認します。
 8164: 指定されたファイルの中に @code{update} (@pxref{update}) 
 8165: が必要なものが一つでもあれば、その旨が表示され、
 8166: 格納せずに終了します。
 8167: @code{commit} はあえて @code{update} コマンドを呼び出さず、
 8168: 開発者自身に適切な時期を判断してもらいます。
 8169: 
 8170: 全てが正常ならば、ログ・メッセージを記すためにエディタが起動されます。
 8171: ログ・メッセージは幾つかの処理プログラムに送られると同時に 
 8172: (@ref{modules} と @ref{loginfo} を参照)、
 8173: リポジトリ中の @sc{rcs} ファイルにも記録されます。
 8174: このログ・メッセージを参照するには @code{log} コマンドを
 8175: 用いて下さい。@ref{log} 参照。
 8176: オプション @samp{-m @var{message}} で
 8177: コマンド行にログ・メッセージを記述したり、
 8178: オプション @samp{-F @var{file}} で
 8179: ログ・メッセージを記述したファイルを指定すれば、
 8180: エディタを起動しなくて済みます。
 8181: 
 8182: @menu
 8183: * commit options::              commit のオプション
 8184: * commit examples::             commit の使用例
 8185: @end menu
 8186: 
 8187: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8188: @node commit options
 8189: @appendixsubsec commit のオプション
 8190: 
 8191: @code{commit} では、以下の標準オプションが利用できます 
 8192: (完全な記述は @pxref{Common options}):
 8193: 
 8194: @table @code
 8195: @item -l
 8196: Local、つまり現在の作業ディレクトリでのみコマンドが
 8197: 実行されます。
 8198: 
 8199: @item -n
 8200: モジュールのプログラムを実行しません。
 8201: 
 8202: @item -R
 8203: ディレクトリを再帰的に格納します。
 8204: このオプションは指定しなくても実行されます。
 8205: 
 8206: @item -r @var{revision}
 8207: @var{revision} に格納します。
 8208: @var{revision} には、枝もしくは、
 8209: 既存の全てのリビジョン番号よりも大きい番号を持つ
 8210: 幹上のリビジョンを指定しなくてはいけません 
 8211: (@pxref{Assigning revisions})。
 8212: 枝上のリビジョンを指定して格納することはできません。
 8213: @c FIXME: Need xref for branch case.
 8214: @end table
 8215: 
 8216: さらに @code{commit} では以下のオプションも使用可能です:
 8217: 
 8218: @table @code
 8219: @item -F @var{file}
 8220: エディタを起動せず @var{file} からログ・メッセージを読み込みます。
 8221: 
 8222: @item -f
 8223: これは @ref{Common options} のオプション @samp{-f} に記述される
 8224: 標準的な動作とは異なることに注意して下さい。
 8225: 
 8226: 作業ファイルに何も変更を加えていない場合でも、
 8227: 無理矢理新しいリビジョンとして格納します。
 8228: 現在の @var{file} のリビジョンを 1.7 と仮定したとき、
 8229: 次の二つのコマンドの実行結果は同じになります:
 8230: 
 8231: @example
 8232: $ cvs commit -f @var{file}
 8233: $ cvs commit -r 1.8 @var{file}
 8234: @end example
 8235: 
 8236: @c This is odd, but it's how CVS has worked for some
 8237: @c time.
 8238: @samp{-f} オプションは再帰を使いません (すなわち、@samp{-l} を含んでい
 8239: ます)。全てのサブディレクトリの全てのファイルの新しいリビジョンの格納
 8240: を @sc{cvs} 強制するには、@samp{-f -R} を使用する必要があります。
 8241: 
 8242: @item -m @var{message}
 8243: エディタを起動せず、@var{message} をログ・メッセージとします。
 8244: @end table
 8245: 
 8246: @need 2000
 8247: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8248: @node commit examples
 8249: @appendixsubsec commit の使用例
 8250: 
 8251: @c FIXME: this material wants to be somewhere
 8252: @c in "Branching and merging".
 8253: 
 8254: @appendixsubsubsec 枝に対して格納する
 8255: 
 8256: オプション @samp{-r} を用いて、枝リビジョン (リビジョン番号が
 8257: 偶数個のドットを含むもの) に格納することができます。
 8258: 枝リビジョンは @code{rtag} か @code{tag} コマンドに
 8259: オプション @samp{-b} を指定して作成します 
 8260: (@pxref{Branching and merging})。
 8261: そして @code{checkout} か @code{update} で、
 8262: 新しく作成した枝からソースを取り出します。
 8263: その結果、この作業ソースに対する変更を @code{commit} すると、
 8264: 全て自動的に枝リビジョンの方に追加され、
 8265: 幹の開発系統は全く影響を受けません。
 8266: 例えば、バージョン 1.2 の製品に対するパッチを作成する必要があるけれど、
 8267: 既にバージョン 2.0 の開発が始まっているような場合、
 8268: 以下のようにします:
 8269: 
 8270: @example
 8271: $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
 8272: $ cvs checkout -r FCS1_2_Patch product_module
 8273: $ cd product_module
 8274: [[ hack away ]]
 8275: $ cvs commit
 8276: @end example
 8277: 
 8278: @noindent
 8279: オプション @samp{-r} は作業ディレクトリに貼り付けられるため、
 8280: これを指定する必要はありません。
 8281: 
 8282: @appendixsubsubsec 編集後に枝を作成する
 8283: 
 8284: 例えば、先週取り出したリビジョンを元にして、
 8285: 極めて実験的な変更をソフトウェアに加えてきたとします。
 8286: ここで実験に他の開発者を加えたいけれど、
 8287: 幹の開発系統を妨げたくない場合は、
 8288: その変更点を新しい枝に格納すれば良いでしょう。
 8289: すると他の開発者も実験中のコードを取り出して、
 8290: @sc{cvs} の衝突解決の恩恵を全て受けることができます。
 8291: このシナリオは次のようになるでしょう:
 8292: 
 8293: @c FIXME: Should we be recommending tagging the branchpoint?
 8294: @example
 8295: [[ hacked sources are present ]]
 8296: $ cvs tag -b EXPR1
 8297: $ cvs update -r EXPR1
 8298: $ cvs commit
 8299: @end example
 8300: 
 8301: @code{update} コマンドで、全てのファイルに
 8302: オプション @samp{-r EXPR1} が貼り付けられます。
 8303: このとき、@code{update} コマンドでは
 8304: ファイルに対する変更が削除されないことに注意して下さい。
 8305: @samp{-r} が貼り付けられているため、
 8306: @code{commit} すれば自動的に正しい枝に変更が格納されます。
 8307: これは次の手順もあります:
 8308: 
 8309: @c FIXME: Should we be recommending tagging the branchpoint?
 8310: @example
 8311: [[ hacked sources are present ]]
 8312: $ cvs tag -b EXPR1
 8313: $ cvs commit -r EXPR1
 8314: @end example
 8315: 
 8316: @noindent
 8317: しかしこの場合、
 8318: 変更されていたファイルだけに @samp{-r EXPR1} が貼り付けられます。
 8319: 従って別のファイルを変更して、フラグ @samp{-r EXPR1} を付けずに
 8320: 格納した場合、誤って幹に格納されてしまいます。
 8321: 
 8322: 他の開発者が実験に参加する際には、
 8323: 単純に以下のようにして下さい:
 8324: 
 8325: @example
 8326: $ cvs checkout -r EXPR1 whatever_module
 8327: @end example
 8328: 
 8329: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8330: @node diff
 8331: @appendixsec diff---リビジョン間の差分の表示
 8332: @cindex diff (subcommand)
 8333: 
 8334: @itemize @bullet
 8335: @item
 8336: 書式: diff [-lR] [format_options] [[-r rev1 | -D date1] [-r rev2 |  -D date2]] [files@dots{}]
 8337: @item
 8338: 必須: 作業ディレクトリ, リポジトリ
 8339: @item
 8340: 変更: なし
 8341: @end itemize
 8342: 
 8343: @code{diff} コマンドは、
 8344: 別々のリビジョン間の差異を比較するのに使用します。
 8345: 特にオプションを指定しない場合、
 8346: 作業ファイルをその由来となったリビジョンと比較し、
 8347: 検出された全ての差異を報告します。
 8348: 
 8349: ファイル名を指定した場合、そのファイルについてのみ比較します。
 8350: ディレクトリを指定した場合、その下の全てのファイルを比較します。
 8351: 
 8352: diff の終了状態は他の @sc{cvs} コマンドと違います。詳細は @ref{Exit
 8353: status} を参照してください。
 8354: 
 8355: @menu
 8356: * diff options::                diff のオプション
 8357: * diff examples::               diff の使用例
 8358: @end menu
 8359: 
 8360: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8361: @node diff options
 8362: @appendixsubsec diff のオプション
 8363: 
 8364: @code{diff} では、以下の標準オプションが利用できます 
 8365: (完全な記述は @pxref{Common options}):
 8366: 
 8367: @table @code
 8368: @item -D @var{date}
 8369: @var{date} 以前の最も新しいリビジョンを利用します。
 8370: このオプションを比較に用いた時の効果は @samp{-r} を参照して下さい。
 8371: 
 8372: @item -k @var{kflag}
 8373: @var{kfalg} に従ってキーワード置換を行います。@ref{Keyword
 8374: substitution}, 参照。
 8375: 
 8376: @item -l
 8377: Local、つまり現在の作業ディレクトリでのみコマンドが
 8378: 実行されます。
 8379: 
 8380: @item -R
 8381: ディレクトリを再帰的に調べます。
 8382: このオプションは指定しなくても実行されます。
 8383: 
 8384: @item -r @var{tag}
 8385: リビジョン @var{tag} と比較します。
 8386: オプション @samp{-r} は最大二つまで使用できます。
 8387: オプション @samp{-r} を指定しない場合、
 8388: 作業ファイルをその由来となったリビジョンと比較します。
 8389: オプション @samp{-r} を一つ指定した場合、
 8390: 指定したリビジョンと作業ファイルとを比較します。
 8391: オプション @samp{-r} を二つ指定した場合、
 8392: 指定した二つのリビジョンを比較します 
 8393: (作業ファイルが結果に影響を与えることはありません)。
 8394: @c We should be a lot more explicit, with examples,
 8395: @c about the difference between "cvs diff" and "cvs
 8396: @c diff -r HEAD".  This often confuses new users.
 8397: 
 8398: 一つもしくは両方のオプション @samp{-r} を、前述の
 8399: オプション @samp{-D @var{date}} と交換することができます。
 8400: @end table
 8401: 
 8402: @c Conceptually, this is a disaster.  There are 3
 8403: @c zillion diff formats that we support via the diff
 8404: @c library.  It is not obvious to me that we should
 8405: @c document them all.  Maybe just the most common ones
 8406: @c like -c and -u, and think about phasing out the
 8407: @c obscure ones.
 8408: @c FIXCVS: also should be a way to specify an external
 8409: @c diff program (which can be different for different
 8410: @c file types) and pass through
 8411: @c arbitrary options, so that the user can do
 8412: @c "--pass=-Z --pass=foo" or something even if CVS
 8413: @c doesn't know about the "-Z foo" option to diff.
 8414: @c This would fit nicely with deprecating/eliminating
 8415: @c the obscure options of the diff library, because it
 8416: @c would let people specify an external GNU diff if
 8417: @c they are into that sort of thing.
 8418: 以下のオプションは出力の書式を指定します。
 8419: 意味は GNU diff と同じです。
 8420: 
 8421: @example
 8422: -0 -1 -2 -3 -4 -5 -6 -7 -8 -9
 8423: --binary
 8424: --brief
 8425: --changed-group-format=@var{arg}
 8426: -c
 8427:   -C @var{nlines}
 8428:   --context[=@var{lines}]
 8429: -e --ed
 8430: -t --expand-tabs
 8431: -f --forward-ed
 8432: --horizon-lines=@var{arg}
 8433: --ifdef=@var{arg}
 8434: -w --ignore-all-space
 8435: -B --ignore-blank-lines
 8436: -i --ignore-case
 8437: -I @var{regexp}
 8438:    --ignore-matching-lines=@var{regexp}
 8439: -h
 8440: -b --ignore-space-change
 8441: -T --initial-tab
 8442: -L @var{label}
 8443:   --label=@var{label}
 8444: --left-column
 8445: -d --minimal
 8446: -N --new-file
 8447: --new-line-format=@var{arg}
 8448: --old-line-format=@var{arg}
 8449: --paginate
 8450: -n --rcs
 8451: -s --report-identical-files
 8452: -p
 8453: --show-c-function
 8454: -y --side-by-side
 8455: -F @var{regexp}
 8456: --show-function-line=@var{regexp}
 8457: -H --speed-large-files
 8458: --suppress-common-lines
 8459: -a --text
 8460: --unchanged-group-format=@var{arg}
 8461: -u
 8462:   -U @var{nlines}
 8463:   --unified[=@var{lines}]
 8464: @c FIXCVS: This option is accepted by src/diff.c but
 8465: @c not diff/diff.c; it would appear that any attempt to
 8466: @c use it would get an error.
 8467: -V @var{arg}
 8468: -W @var{columns}
 8469:   --width=@var{columns}
 8470: @end example
 8471: 
 8472: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8473: @node diff examples
 8474: @appendixsubsec diff の使用例
 8475: 
 8476: 次の実行例は、@file{backend.c} のリビジョン 1.14 と 1.19 間の差分を、
 8477: unidiff 形式 (フラグ @samp{-u}) で出力します。
 8478: またキーワード置換を止めるために @samp{-kk} を指定し、
 8479: キーワード置換による差分を無視します。
 8480: 
 8481: @example
 8482: $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
 8483: @end example
 8484: 
 8485: タグ RELEASE_1_0 が付けられたファイルの集合から、
 8486: 実験用の枝 EXPR1 が派生していると仮定します。
 8487: この枝に加えられた変更を見るには、次のようにします:
 8488: 
 8489: @example
 8490: $ cvs diff -r RELEASE_1_0 -r EXPR1
 8491: @end example
 8492: 
 8493: 次の実行例では、二つのリリース間の差分を context 形式で出力します:
 8494: 
 8495: @example
 8496: $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
 8497: @end example
 8498: 
 8499: ChangeLogs を運用している場合、
 8500: 変更を格納する前に次の行のようなコマンドを実行すると、
 8501: ChangeLogs の記載事項を入力するのに役立つでしょう。
 8502: 作業ファイルに加えた変更点のうち、格納していないもの全てを表示します。
 8503: 
 8504: @example
 8505: $ cvs diff -u | less
 8506: @end example
 8507: 
 8508: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8509: @node export
 8510: @appendixsec export---CVS からソースを取り出す, checkout に類似
 8511: @cindex export (subcommand)
 8512: 
 8513: @itemize @bullet
 8514: @item
 8515: 書式: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
 8516: @item
 8517: 必須: リポジトリ
 8518: @item
 8519: 変更: 現在のディレクトリ
 8520: @end itemize
 8521: 
 8522: このコマンドは @code{checkout} の変形で、
 8523: @var{module} のソースのコピーを、
 8524: @sc{cvs} の管理用ディレクトリを除いた状態で取り出します。
 8525: 例えば出荷用のソースを準備するときなどに @code{export} を使います。
 8526: 出荷したソースを後で再現できることを確認するため、使用の際には 
 8527: (@samp{-D} か @samp{-r} による) 日付かタグの指定が要求されます。
 8528: 
 8529: @code{cvs export} に @samp{-kv} を指定すると便利です。
 8530: この指定で全てのキーワードが展開されるため、
 8531: 出荷先で @code{import} されても
 8532: キーワードによるリビジョン情報が失われません。
 8533: しかしモジュールがバイナリ・ファイルを含む場合は、
 8534: 正しく処理されない可能性があるので注意が必要です。
 8535: また @samp{-kv} を使用した後では、@code{ident} コマンド (@sc{rcs} を
 8536: 構成するコマンドの一つです---@samp{ident(1)} を参照) を使用して、
 8537: キーワード文字列を抜き出すことができません。
 8538: 従って @code{ident} を使用するつもりなら、
 8539: @samp{-kv} を指定してはいけません。
 8540: 
 8541: @menu
 8542: * export options::              export のオプション
 8543: @end menu
 8544: 
 8545: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8546: @node export options
 8547: @appendixsubsec export のオプション
 8548: 
 8549: @code{export} では、以下の標準オプションが利用できます 
 8550: (完全な記述は @pxref{Common options}):
 8551: 
 8552: @table @code
 8553: @item -D @var{date}
 8554: @var{date} 以前の最も新しいリビジョンを取り出します。
 8555: 
 8556: @item -f
 8557: 指定したリビジョンが見付からなかった場合、
 8558: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 8559: 
 8560: @item -l
 8561: Local、つまり現在の作業ディレクトリでのみコマンドが
 8562: 実行されます。
 8563: 
 8564: @item -n
 8565: ファイルを取り出したとき、通常実行されるプログラムを実行しません。
 8566: 
 8567: @item -R
 8568: ディレクトリを再帰的に取り出します。
 8569: このオプションは指定しなくても実行されます。
 8570: 
 8571: @item -r @var{tag}
 8572: @var{tag} で指定されたリビジョンを取り出します。
 8573: @end table
 8574: 
 8575: さらに (@code{checkout} と @code{export} で共通な) 
 8576: 以下のオプションも使用可能です:
 8577: 
 8578: @table @code
 8579: @item -d @var{dir}
 8580: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 8581: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8582: 
 8583: @item -k @var{subst}
 8584: キーワード置換モードを設定します (@pxref{Substitution modes})。
 8585: 
 8586: @item -N
 8587: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 8588: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8589: @end table
 8590: 
 8591: @ignore
 8592: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8593: @c @node export examples
 8594: @appendixsubsec export examples
 8595: 
 8596: Contributed examples are gratefully accepted.
 8597: @c -- Examples here!!
 8598: @end ignore
 8599: 
 8600: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8601: @node history
 8602: @appendixsec history---ファイルと使用者の状態を表示
 8603: @cindex history (subcommand)
 8604: 
 8605: @itemize @bullet
 8606: @item
 8607: 書式:     history [-report] [-flags] [-options args] [files@dots{}]
 8608: @item
 8609: 必須: ファイル @file{$CVSROOT/CVSROOT/history}
 8610: @item
 8611: 変更: なし
 8612: @end itemize
 8613: 
 8614: @sc{cvs} は、@code{checkout}, @code{commit}, @code{rtag}, 
 8615: @code{update}, @code{release} コマンドの実行履歴を、
 8616: ファイル @file{history} に記録しています。
 8617: @code{history} を使って、様々な形式で
 8618: この情報を表示することができます。
 8619: 
 8620: ログを記録したい場合は、ファイル @file{$CVSROOT/CVSROOT/history} を
 8621: 作成する必要があります。
 8622: 
 8623: @strong{警告:} @code{history} は、@samp{-f}, @samp{-l}, @samp{-n}, 
 8624: @samp{-p} を通常の @sc{cvs} コマンドで用いられるものとは
 8625: 異なる意味で使用しています (@pxref{Common options})。
 8626: 
 8627: @menu
 8628: * history options::             history のオプション
 8629: @end menu
 8630: 
 8631: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8632: @node history options
 8633: @appendixsubsec history のオプション
 8634: 
 8635: 次のオプション (コマンド書式で @samp{-report} の部分) によって、
 8636: 生成する報告の種類を決定します:
 8637: 
 8638: @table @code
 8639: @item -c
 8640: 現在までに使用された @code{commit} (つまりリポジトリの変更) 
 8641: について報告します。
 8642: 
 8643: @item -e
 8644: 全て (全記録種別) を報告します。全ての記録種別に @samp{-x} を指定する
 8645: ことと等価です。もちろん、@samp{-e} は将来のバージョンの @sc{cvs} に加
 8646: えられた記録種別も含みます。特定の記録種別だけを扱うことのできるスクリ
 8647: プトを書いているなら、@samp{-x} を指定する方が良いでしょう。
 8648: 
 8649: @item -m @var{module}
 8650: 特定のモジュールについて報告します 
 8651: (必要ならば複数の @samp{-m} をコマンド行に並べても構いません)。
 8652: 
 8653: @item -o
 8654: 取り出されたモジュールについて報告します。
 8655: 
 8656: @item -T
 8657: 全てのタグについて報告します。
 8658: 
 8659: @item -x @var{type}
 8660: 報告を受けたい記録種別の組を @var{type} に指定して、
 8661: @sc{cvs} の実行履歴から取り出します。
 8662: 種別は各々一文字で表され、これを組み合わせて指定します。
 8663: 
 8664: 以下のコマンドには、各々一つの記録種別を割り当てています:
 8665: 
 8666: @table @code
 8667: @item F
 8668: release
 8669: @item O
 8670: checkout
 8671: @item E
 8672: export
 8673: @item T
 8674: rtag
 8675: @end table
 8676: 
 8677: @noindent
 8678: 更新の結果は、以下の四つの記録種別のうちのどれかになります:
 8679: 
 8680: @table @code
 8681: @item C
 8682: マージを実行した結果、衝突が検出された場合 (手動でのマージが必要)。
 8683: @item G
 8684: マージを実行して成功した場合。
 8685: @item U
 8686: 作業ファイルがリポジトリからコピーされた場合。
 8687: @item W
 8688: (リポジトリから相当するファイルが削除されたため) 
 8689: 更新の際に作業ファイルが削除された場合。
 8690: @end table
 8691: 
 8692: @noindent
 8693: 格納の結果は、以下の三つの記録種別のうちのどれかになります:
 8694: 
 8695: @table @code
 8696: @item A
 8697: ファイルが初めて追加された場合。
 8698: @item M
 8699: ファイルが修正された場合。
 8700: @item R
 8701: ファイルが削除された場合。
 8702: @end table
 8703: @end table
 8704: 
 8705: 次のオプション (コマンド書式で @samp{-flags} の部分) によって、
 8706: 報告の範囲を限定もしくは拡大します。引数はありません:
 8707: 
 8708: @table @code
 8709: @item -a
 8710: 全ての使用者の情報を表示します 
 8711: (既定では @code{history} を実行した人物の情報のみを表示します)。
 8712: 
 8713: @item -l
 8714: 最後の変更のみを表示します。
 8715: 
 8716: @item -w
 8717: @code{history} を実行したのと同じ作業ディレクトリから行われた
 8718: 変更に関する記録のみを表示します。
 8719: @end table
 8720: 
 8721: 次のオプション (コマンド書式で @samp{-options @var{args}} の部分) は、
 8722: 引数に基づいて報告の範囲を限定します:
 8723: 
 8724: @table @code
 8725: @item -b @var{str}
 8726: モジュール名, ファイル名, リポジトリのパスのいずれかに、
 8727: 文字列 @var{str} が含まれる記録のみを表示します。
 8728: 
 8729: @item -D @var{date}
 8730: @var{date} 以降のデータを表示します。
 8731: 普通の @samp{-D @var{date}} は @var{date} 以前の
 8732: 最新リビジョンを選択しますから、少し意味が違います。
 8733: 
 8734: @item -f @var{file}
 8735: 特定のファイルのデータを表示します (@samp{-f} オプションをコマンド行で
 8736: 複数指定することができます)。これはコマンド行でファイルを指定するのと
 8737: 等価です。
 8738: 
 8739: @item -n @var{module}
 8740: 特定のモジュールのデータを表示します (複数の @samp{-n} をコマンド行で
 8741: 並べることができます)。
 8742: 
 8743: @item -p @var{repository}
 8744: 指定したリポジトリのデータを表示します 
 8745: (必要ならば複数の @samp{-p} をコマンド行に並べても構いません。)
 8746: 
 8747: @item -r @var{rev}
 8748: リビジョンもしくはタグを @var{rev} に指定して、
 8749: このリビジョン以降の記録を表示します。
 8750: 実行時に全ての @sc{rcs} ファイルについて @var{rev} を検索します。
 8751: 
 8752: @item -t @var{tag}
 8753: 履歴ファイルにタグ @var{tag} が
 8754: 追加された後の記録を表示します。
 8755: このオプションを指定した場合、@sc{rcs} ファイルを検索せず、
 8756: 履歴ファイルのみを参照するため、
 8757: オプション @samp{-r} の場合よりもかなり高速です。
 8758: 
 8759: @item -u @var{name}
 8760: @var{name} で指定された使用者の記録を表示します。
 8761: 
 8762: @item -z @var{timezone}
 8763: 選択された登録の時間を UTC の代わりに指定された標準時を用いて表示しま
 8764: す。
 8765: @end table
 8766: 
 8767: @ignore
 8768: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8769: @c @node history examples
 8770: @appendixsubsec history examples
 8771: 
 8772: Contributed examples will gratefully be accepted.
 8773: @c -- Examples here!
 8774: @end ignore
 8775: 
 8776: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8777: @node import
 8778: @appendixsec import---CVS にソースを取り込む, ベンダー枝を使用
 8779: @cindex import (subcommand)
 8780: 
 8781: @c FIXME: This node is way too long for one which has subnodes.
 8782: 
 8783: @itemize @bullet
 8784: @item
 8785: 書式: import [-options] repository vendortag releasetag@dots{}
 8786: @item
 8787: 必須: リポジトリ, ソースの配布ディレクトリ
 8788: @item
 8789: 変更: リポジトリ
 8790: @end itemize
 8791: 
 8792: @code{import} を用いて、外部の供給元 (例えばソース・ベンダー) 
 8793: からのソース配布物全体を、自分のリポジトリに取り入れることができます。
 8794: リポジトリを最初に作成する場合と、外部の供給元がモジュールを
 8795: 大幅に更新した場合の両方でこのコマンドを用います。
 8796: この件については @xref{Tracking sources}.
 8797: 
 8798: @var{repository} には、リポジトリにするディレクトリの名前 
 8799: (もしくは、ディレクトリへのパス) を、
 8800: @sc{cvs} のルート・ディレクトリからの相対パス名で指定します。
 8801: 指定したディレクトリが存在しなくても自動的に作成されます。
 8802: 
 8803: (前回の import から) ずっと変更を加えてきたリポジトリに対し、
 8804: ソースを更新するために import を用いると、
 8805: 互いの開発系統間で衝突が発生したファイル全てが報告されます。
 8806: この時 import から具体的な指示がありますので、
 8807: それを参考にしながら @samp{checkout -j} を使って変更点を取り入れて下さい。
 8808: 
 8809: @sc{cvs} は無視するように設定されたファイルは (@pxref{cvsignore})、
 8810: 取り込まず、無視したことを示すため 
 8811: @samp{I } に続けてファイル名を表示します 
 8812: (出力に関する完全な説明は @pxref{import output})。
 8813: 
 8814: @file{$CVSROOT/CVSROOT/cvswrappers} が存在する場合、
 8815: このファイルの記述に合致するファイルやディレクトリは
 8816: 各々一括して扱われ、リポジトリに取り込まれる前に、
 8817: 適切なフィルタが適用されます。@xref{Wrappers}.
 8818: 
 8819: 外部からのソースは第一層の枝、既定だと 1.1.1 に保存されます。
 8820: 以降の更新は全てこの枝の葉となります。
 8821: 例えば最初に取り込んだソース集合のファイルは
 8822: リビジョン 1.1.1.1 になり、次の取り込みで
 8823: そのファイルが更新された場合には 1.1.1.2 となり、以下同様に続きます。
 8824: 
 8825: 少なくとも次の三つの引数を指定する必要があります。
 8826: まずソース集合を識別するために @var{repository} が必要です。
 8827: 次の @var{vendortag} は枝全体 (例えば 1.1.1) を示すタグ名です。
 8828: そして @code{import} を実行する度に作成される葉のうち、
 8829: どの葉のファイルかを識別するため、
 8830: 最低一つの @var{releasetag} を指定しなくてはいけません。
 8831: 
 8832: @c I'm not completely sure this belongs here.  But
 8833: @c we need to say it _somewhere_ reasonably obvious; it
 8834: @c is a common misconception among people first learning CVS
 8835: @code{import} はそれを起動したディレクトリを変更 @emph{しない} という
 8836: ことに注意してください。特に、ディレクトリを @sc{cvs} の作業ディレクト
 8837: リとして設定しないことに注意してください。もし作業をしたいなら、まずソー
 8838: スを取り込んで、それから違うディレクトリに取り出してください 
 8839: (@pxref{Getting the source})。
 8840: 
 8841: @menu
 8842: * import options::              import のオプション
 8843: * import output::               import の出力
 8844: * import examples::             import の使用例
 8845: @end menu
 8846: 
 8847: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8848: @node import options
 8849: @appendixsubsec import のオプション
 8850: 
 8851: @code{import} では、以下の標準オプションが利用できます 
 8852: (完全な記述は @pxref{Common options}):
 8853: 
 8854: @table @code
 8855: @item -m @var{message}
 8856: エディタを立ち上げる代りに、@var{message} をログ情報に指定します。
 8857: @end table
 8858: 
 8859: 以下のような追加の特別なオプションがあります。
 8860: 
 8861: @table @code
 8862: @item -b @var{branch}
 8863: @ref{Multiple vendor branches} 参照。
 8864: 
 8865: @item -k @var{subst}
 8866: 希望するキーワード置換モードを指定します。
 8867: この設定は、新たに取り入れる全てのファイルに適用されますが、
 8868: リポジトリに既に存在するファイルには適用されません。
 8869: @samp{-k} に使用できる設定の一覧は @ref{Substitution modes} 参照。
 8870: 
 8871: @item -I @var{name}
 8872: 取り込む際に無視するファイル名を指定します。
 8873: 無視したいファイルが複数あるときは、
 8874: このオプションを何個並べても構いません。
 8875: 全てのファイルを無視したくない場合は、
 8876: (それらは既定では無視されるとしても) `-I !' と指定して下さい。
 8877: 
 8878: @var{name} には、ファイル @file{.cvsignore} と同じ
 8879: ファイル名形式が使用できます。@xref{cvsignore}.
 8880: @c -- Is this really true?
 8881: 
 8882: @item -W @var{spec}
 8883: 取り込む際に、
 8884: フィルタを適用したいファイル名を指定します。
 8885: フィルタを適用したいファイルが複数あるときは、
 8886: このオプションを何個並べても構いません。
 8887: 
 8888: @var{spec} には、ファイル @file{.cvswrappers} と同じ
 8889: ファイル名形式が使用できます。@xref{Wrappers}.
 8890: @end table
 8891: 
 8892: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8893: @node import output
 8894: @appendixsubsec import の出力
 8895: 
 8896: @code{import} の進行状況を知らせるために、
 8897: 処理中のファイル名が一行ずつ表示され、
 8898: 行頭にはファイルの状態を示す文字が付加されます:
 8899: 
 8900: @table @code
 8901: @item U @var{file}
 8902: このファイルが既にリポジトリに存在し、かつ変更されてないことを示します。
 8903: (必要ならば) 新しいリビジョンが作成されます。
 8904: 
 8905: @item N @var{file}
 8906: このファイルが新規であり、リポジトリに追加されたことを示します。
 8907: 
 8908: @item C @var{file}
 8909: このファイルが既にリポジトリに存在し、かつ変更されていて、
 8910: マージが必要であることを示します。
 8911: 
 8912: @item I @var{file}
 8913: このファイルが無視されることを示します (@pxref{cvsignore})。
 8914: 
 8915: @cindex Symbolic link, importing
 8916: @cindex Link, symbolic, importing
 8917: @c FIXME: also (somewhere else) probably
 8918: @c should be documenting what happens if you "cvs add"
 8919: @c a symbolic link.  Also maybe what happens if
 8920: @c you manually create symbolic links within the
 8921: @c repository (? - not sure why we'd want to suggest
 8922: @c doing that).
 8923: @item L @var{file}
 8924: このファイルがシンボリック・リンクであることを示します。
 8925: @code{cvs import} はシンボリック・リンクを無視します。いろんな人が定期
 8926: 的にこの振舞いは変更されるべきだと提案しますが、どれに変更されるべきか
 8927: についての同意があるとすれば、それは明らかでないように思われます。
 8928: (管理用ファイル @file{modules} の各種オプションを checkout や update
 8929: 等でシンボリック・リンクを再生成するために使うことができます。
 8930: @pxref{modules}。)
 8931: @end table
 8932: 
 8933: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8934: @node import examples
 8935: @appendixsubsec import の使用例
 8936: 
 8937: @ref{Tracking sources} と @ref{From files} を参照して下さい。
 8938: 
 8939: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8940: @node log
 8941: @appendixsec log---ファイルのログ情報を表示
 8942: @cindex log (subcommand)
 8943: 
 8944: @itemize @bullet
 8945: @item
 8946: 書式: log [options] [files@dots{}]
 8947: @item
 8948: 必須: リポジトリ, 作業ディレクトリ
 8949: @item
 8950: 変更: なし
 8951: @end itemize
 8952: 
 8953: ファイルのログ情報を表示します。以前の @code{log} は 
 8954: @sc{rcs} のコマンド @code{rlog} を呼び出していましたが、
 8955: 現在はそうではありません。しかしこのような経緯から、
 8956: このコマンドの出力やオプションは、
 8957: 他の @sc{cvs} コマンドとは異なったものになっています。
 8958: 
 8959: @cindex Timezone, in output
 8960: @cindex Zone, time, in output
 8961: @c Kind of a funny place to document the timezone used
 8962: @c in output from commands other than @code{log}.
 8963: @c There is also more we need to say about this,
 8964: @c including what happens in a client/server environment.
 8965: このコマンドの出力には、@sc{rcs} ファイルの所在、
 8966: @dfn{先頭}リビジョン (幹の最新リビジョン)、
 8967: 全てのタグ名などが含まれます。
 8968: 各リビジョンに対しては、リビジョン番号、格納者、
 8969: 追加/削除された行数、ログ・メッセージが表示されます。
 8970: また時間は全て協定世界時 (UTC) で表示されます。
 8971: (@sc{cvs} の他の部分では地方時間帯による時刻を表示します。)
 8972: @c FIXCVS: need a better way to control the timezone
 8973: @c used in output.  Previous/current versions of CVS did/do
 8974: @c sometimes support -z in RCSINIT, and/or an
 8975: @c undocumented (except by reference to 'rlog') -z option
 8976: @c to cvs log, but this has not been a consistent,
 8977: @c documented feature.  Perhaps a new global option,
 8978: @c where LT means the client's timezone, which the
 8979: @c client then communicates to the server, is the
 8980: @c right solution.
 8981: 
 8982: @strong{警告:} @code{log} は @samp{-R} を @sc{cvs} 普通の使用と衝突す
 8983: る方法で使います (@pxref{Common options})。
 8984: 
 8985: @menu
 8986: * log options::                 log のオプション
 8987: * log examples::                log の例
 8988: @end menu
 8989: 
 8990: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8991: @node log options
 8992: @appendixsubsec log のオプション
 8993: 
 8994: オプションを指定しなければ、@code{log} は利用できる全ての
 8995: 情報を表示します。つまりオプションは全て出力を制限するものです。
 8996: 
 8997: @table @code
 8998: @item -b
 8999: 既定の枝 (通常は幹で最も大きな番号の枝) に関する情報を表示します。
 9000: 
 9001: @item -d @var{dates}
 9002: @var{dates} に示されたリビジョンの情報を表示します。
 9003: @var{dates} には格納日時の範囲をセミコロンで区切って記述します。
 9004: 日時の表現形式は他の @sc{cvs} コマンドの 
 9005: @samp{-D} オプションと同じです (@pxref{Common options})。
 9006: それを次のように組み合わせて、格納日時の範囲を表現します:
 9007: 
 9008: @c Should we be thinking about accepting ISO8601
 9009: @c ranges?  For example "1972-09-10/1972-09-12".
 9010: @table @code
 9011: @item @var{d1}<@var{d2}
 9012: @itemx @var{d2}>@var{d1}
 9013: @var{d1} から @var{d2} までの間に格納されたリビジョンを選択します。
 9014: 
 9015: @item <@var{d}
 9016: @itemx @var{d}>
 9017: @var{d} より前に格納された全てのリビジョンを選択します。
 9018: 
 9019: @item @var{d}<
 9020: @itemx >@var{d}
 9021: @var{d} より後に格納された全てのリビジョンを選択します。
 9022: 
 9023: @item @var{d}
 9024: @var{d} 以前の最新のリビジョンを一つ選択します。
 9025: @end table
 9026: 
 9027: @samp{>} や @samp{<} の後に @samp{=} を付ければ、端を含まない
 9028: 範囲指定ではなく、端を含むような範囲指定が可能です。
 9029: 
 9030: 要素の区切りがセミコロン @samp{;} であることに注意して下さい。
 9031: 
 9032: @item -h
 9033: @sc{rcs} ファイルの名前, 作業ディレクトリのファイル名, 先頭リビジョン,
 9034: 既定の枝, 利用者一覧, ロックモード, タグ名, 拡張子を表示します。
 9035: 
 9036: @item -l
 9037: Local、つまり現在の作業ディレクトリでのみコマンドが
 9038: 実行されます。(これを指定しない場合再帰的に実行されます)。
 9039: 
 9040: @item -N
 9041: このファイルではタグ名の一覧を表示しません。
 9042: タグ名を多く使用していると、その表示だけで3ページ以上のタグ情報を 
 9043: "more" することになります。
 9044: タグ名を省略したログ情報でも構わないときは、
 9045: このオプションを指定すると便利です。
 9046: 
 9047: @item -R
 9048: @sc{rcs} ファイルの名前だけを表示します。
 9049: 
 9050: @c Note that using a bare revision (in addition to not
 9051: @c being explicitly documented here) is potentially
 9052: @c confusing; it shows the log message to get from the
 9053: @c previous revision to that revision.  "-r1.3 -r1.6"
 9054: @c (equivalent to "-r1.3,1.6") is even worse; it
 9055: @c prints the messages to get from 1.2 to 1.3 and 1.5
 9056: @c to 1.6.  By analogy with "cvs diff", users might
 9057: @c expect that it is more like specifying a range.
 9058: @c It is not 100% clear to me how much of this should
 9059: @c be documented (for example, multiple -r options
 9060: @c perhaps could/should be deprecated given the false
 9061: @c analogy with "cvs diff").
 9062: @c In general, this section should be rewritten to talk
 9063: @c about messages to get from revision rev1 to rev2,
 9064: @c rather than messages for revision rev2 (that is, the
 9065: @c messages are associated with a change not a static
 9066: @c revision and failing to make this distinction causes
 9067: @c much confusion).
 9068: @item -r@var{revisions}
 9069: @var{revisions} に示されたリビジョンの情報を表示します。
 9070: @var{revisions} にはリビジョンの範囲をカンマで区切って記述します。
 9071: 利用可能な範囲指定の書式を次に示します:
 9072: 
 9073: @table @code
 9074: @item @var{rev1}:@var{rev2}
 9075: @var{rev1} から @var{rev2} までのリビジョンを選択します (同じ枝である
 9076: 必要があります)。
 9077: 
 9078: @item :@var{rev}
 9079: 枝の最初から @var{rev} までのリビジョンを選択します。
 9080: 
 9081: @item @var{rev}:
 9082: @var{rev} から同じ枝の最後のリビジョンまでを選択します。
 9083: 
 9084: @item @var{branch}
 9085: 枝 @var{branch} にある全てのリビジョンを選択します。
 9086: 
 9087: @item @var{branch1}:@var{branch2}
 9088: この範囲内の枝にある全てのリビジョンを選択します。
 9089: 
 9090: @item @var{branch}.
 9091: 枝 @var{branch} の最新リビジョンを選択します。
 9092: @end table
 9093: 
 9094: リビジョンを指定せず @samp{-r} だけを指定した場合、
 9095: 既定の枝、通常は幹の最新リビジョンを選択します。
 9096: 従って @samp{-r} と引数との間に空白を入れないようにして下さい。
 9097: 
 9098: @item -s @var{states}
 9099: @var{states} と状態が一致するリビジョンの情報を表示します。
 9100: @var{states} にはファイルの状態をカンマで区切って記述します。
 9101: 
 9102: @item -t
 9103: @samp{-h} の情報に、ファイルの説明文を追加して表示します。
 9104: 
 9105: @item -w@var{logins}
 9106: @var{logins} に示された使用者が格納したリビジョンの情報を表示します。
 9107: @var{logins} には使用者名をカンマで区切って記述します。
 9108: @var{logins} を省略した場合、コマンドを起動した人物の
 9109: 使用者名が用いられます。
 9110: 従って @samp{-w} と引数との間に空白を入れないようにして下さい。
 9111: @end table
 9112: 
 9113: @code{log} は、オプション @samp{-d}, @samp{-s}, @samp{-w} の
 9114: 全てに適合し、かつ @samp{-b}, @samp{-r} のいずれかに適合した
 9115: リビジョンに関する情報を表示します。
 9116: 
 9117: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9118: @node log examples
 9119: @appendixsubsec log の使用例
 9120: 
 9121: 使用例を募集しています。
 9122: 
 9123: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 9124: @node rdiff
 9125: @appendixsec rdiff---リリース間の `patch' 形式の差分
 9126: @cindex rdiff (subcommand)
 9127: 
 9128: @itemize @bullet
 9129: @item
 9130: 書式: rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules@dots{}
 9131: @item
 9132: 必須: リポジトリ
 9133: @item
 9134: 変更: なし
 9135: @item
 9136: 別名: patch
 9137: @end itemize
 9138: 
 9139: 二つのリリース間の差分を、
 9140: Larry Wall の @samp{patch(1)} ファイル形式で生成します。
 9141: この出力を直接 @code{patch} プログラムに食わせて、
 9142: 古いリリースを新しいリリースに更新できます。
 9143: (これは作業ディレクトリを必要とせず、直接リポジトリを操作する
 9144: 数少ない @sc{cvs} コマンドの一つです。) 
 9145: このコマンドの実行結果は標準出力に送られます。
 9146: 
 9147: 一つないし二つのリビジョンか日付の組み合わせを 
 9148: (標準オプション @samp{-r} や @samp{-D} を用いて) 
 9149: 指定することができます。
 9150: リビジョンか日付を一つだけ指定した場合、
 9151: 指定したものと @sc{rcs} ファイルの先頭リビジョンとの差分が
 9152: パッチ・ファイルとして出力されます。
 9153: 
 9154: ソフトウェア配布物が複数のディレクトリから構成される場合、
 9155: 別のディレクトリに置かれた古いソースを参照するために、
 9156: @code{patch} コマンドにオプション @samp{-p} を
 9157: 指定する必要があるかも知れません。
 9158: 
 9159: @menu
 9160: * rdiff options::               rdiff のオプション
 9161: * rdiff examples::              rdiff の使用例
 9162: @end menu
 9163: 
 9164: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9165: @node rdiff options
 9166: @appendixsubsec rdiff のオプション
 9167: 
 9168: @code{rdiff} では、以下の標準オプションが利用できます 
 9169: (完全な記述は @pxref{Common options}):
 9170: 
 9171: @table @code
 9172: @item -D @var{date}
 9173: @var{date} 以前の最も新しいリビジョンを利用します。
 9174: 
 9175: @item -f
 9176: 指定したリビジョンが見付からなかった場合、
 9177: (そのファイルを無視せずに) 最も新しいリビションを用います。
 9178: 
 9179: @item -l
 9180: Local、つまり現在の作業ディレクトリでのみコマンドが
 9181: 実行されます。
 9182: 
 9183: @item -R
 9184: ディレクトリを再帰的に検査します。
 9185: このオプションは指定しなくても実行されます。
 9186: 
 9187: @item -r @var{tag}
 9188: @var{tag} で指定されたリビジョンを用います。
 9189: @end table
 9190: 
 9191: さらに以下のオプションも使用可能です:
 9192: 
 9193: @table @code
 9194: @item -c
 9195: Context 形式で出力します。
 9196: これが既定形式なので指定する必要はありません。
 9197: 
 9198: @item -s
 9199: パッチの代りに変更要旨だけが報告されます。
 9200: 指定したリリース間で変更されたり追加されたファイルの情報が
 9201: 標準出力に送られます。
 9202: これは例えば、二つの日付やリビジョン間で変更された
 9203: ファイルを一覧するのに便利です。
 9204: 
 9205: @item -t
 9206: 先頭にある二つのリビジョン間の差分を標準出力に送ります。
 9207: これは、そのファイルの最新の変更点を見るときに使います。
 9208: 
 9209: @item -u
 9210: Context 形式ではなく、unidiff 形式を用います。
 9211: 古いバージョンの @code{patch} プログラムは unidiff 形式を扱えないので、
 9212: パッチをネットに投稿するつもりならば、
 9213: @samp{-u} を使用しない方が賢明でしょう。
 9214: 
 9215: @item -V @var{vn}
 9216: @sc{rcs} のバージョン @var{vn} における展開方法に従って、
 9217:  キーワードを展開します 
 9218: (@sc{rcs} のバージョン 5 で展開方法が変更されました)。
 9219: このオプションはもう使用できないことに注意してください。
 9220: CVS は @sc{rcs} バージョン 5 がするように常にキーワードを展開します。
 9221: @end table
 9222: 
 9223: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9224: @node rdiff examples
 9225: @appendixsubsec rdiff の使用例
 9226: 
 9227: @t{foo@@example.net} から、
 9228: コンパイラ @samp{tc} をリリース 1.2 から 1.4 へ更新したい、
 9229: というメールを受け取ったと仮定します。
 9230: 手元にそんなパッチがない場合でも、
 9231: @sc{cvs} なら次のようなコマンドを使って簡単に対応できます:
 9232: 
 9233: @example
 9234: $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
 9235: $$ Mail -s 'The patches you asked for' foo@@example.net
 9236: @end example
 9237: 
 9238: リリース 1.3 のバグ修正用に枝 @samp{R_1_3fix} を作成し、
 9239: 修正後のリリース 1.3.1 にタグ @samp{R_1_3_1} を付けたと仮定します。
 9240: この枝に対して、修正版以降に加えられた開発の概略を知りたい場合は、
 9241: 次のようなコマンドを使います:
 9242: 
 9243: @example
 9244: $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
 9245: cvs rdiff: Diffing module-name
 9246: File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
 9247: File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
 9248: File bar.h,v changed from revision 1.29.2.1 to 1.2
 9249: @end example
 9250: 
 9251: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 9252: @node release
 9253: @appendixsec release---モジュールの放棄を表明する
 9254: @cindex release (subcommand)
 9255: 
 9256: @itemize @bullet
 9257: @item
 9258: 書式: release [-d] directories@dots{}
 9259: @item
 9260: 必須: 作業ディレクトリ
 9261: @item
 9262: 変更: 作業ディレクトリ, history のログ情報
 9263: @end itemize
 9264: 
 9265: このコマンドは @samp{cvs checkout} の効果を安全に消し去ります。
 9266: @sc{cvs} はファイルをロックしないため、
 9267: このコマンドが絶対に必要なわけではありません。
 9268: 作業ディレクトリを単に削除したいなら、それでも構いません。
 9269: ただしこの場合、うっかりすると変更内容を失う恐れがあります。
 9270: またファイル @file{history} (@pxref{history file}) にも、
 9271: 作業ディレクトリを放棄したという情報が残りません。
 9272: 
 9273: これらの問題を避けるためにも @samp{cvs release} を使用して下さい。
 9274: このコマンドは、未格納の変更点が残ってないかどうか調べます。
 9275: 次に @sc{cvs} の作業ディレクトリのすぐ上で実行しているかどうか調べます。
 9276: さらに作業ディレクトリに記録されたリポジトリが、
 9277: モジュールに定義されているリポジトリと等しいかどうか調べます。
 9278: 
 9279: 上記全ての条件が満たされた場合にだけ、
 9280: (作業ディレクトリを故意に放棄した証拠として) 
 9281: @sc{cvs} の履歴ログ に @samp{cvs release} の実行記録が残されます。
 9282: 
 9283: @menu
 9284: * release options::             release のオプション
 9285: * release output::              release の出力
 9286: * release examples::            release の使用例
 9287: @end menu
 9288: 
 9289: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9290: @node release options
 9291: @appendixsubsec release のオプション
 9292: 
 9293: @code{release} ではオプションが一つだけ利用できます:
 9294: 
 9295: @table @code
 9296: @item -d
 9297: 放棄判定に成功したとき、作業ディレクトリを削除します。
 9298: このフラグを指定しない場合、
 9299: 作業ディレクトリはそのまま残されます。
 9300: 
 9301: @strong{警告:}  @code{release} コマンドは
 9302: 全てのディレクトリとファイルを再帰的に削除していきます。
 9303: これには重篤な副作用があり、作業ディレクトリに作成したけれど、
 9304: リポジトリには追加してないディレクトリ全てが、
 9305: (@code{add} コマンド使って。@pxref{Adding files})
 9306: 何の表示も無く削除されます---その中身が空でなくても!
 9307: @end table
 9308: 
 9309: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9310: @node release output
 9311: @appendixsubsec release の出力
 9312: 
 9313: @code{release} によって作業ディレクトリを放棄する前に、
 9314: 最新でないファイルそれぞれについて一行ずつ状態を表示します。
 9315: 
 9316: @strong{警告:}  作成はしたけれど、@code{add} コマンドを用いて 
 9317: (@pxref{Adding files}) @sc{cvs} のディレクトリ階層に
 9318: 加えてないディレクトリは、全て中身があっても完全に無視され 
 9319: (@samp{-d} が指定されていれば削除され) ます。
 9320: @c FIXCVS: This is a bug.  But is it true?  I think
 9321: @c maybe they print "? dir" now.
 9322: 
 9323: @table @code
 9324: @item U @var{file}
 9325: @itemx P @var{file}
 9326: より新しいリビジョンがリポジトリに存在し、
 9327: かつ作業ファイルが編集されてないことを示します。
 9328: (@samp{U} と @samp{P} は同じです。)
 9329: 
 9330: @item A @var{file}
 9331: 作業ディレクトリにファイルが追加されたけれど、
 9332: まだリポジトリには格納されてないことを示します。
 9333: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 9334: 
 9335: @item R @var{file}
 9336: 作業ファイルは削除されているけれど、まだこの変更が格納されてないため、
 9337: リポジトリからは削除されてないことを示します。@xref{commit}.
 9338: 
 9339: @item M @var{file}
 9340: 作業ディレクトでファイルが修正されています。リポジトリにも新しいリビジョ
 9341: ンがあるかもしれません。
 9342: 
 9343: @item ? @var{file}
 9344: 作業ディレクトリに @var{file} というファイルがあるが、
 9345: リポジトリには対応するファイルが無く、
 9346: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 9347: (@samp{-I} オプションの説明の参照と、@pxref{cvsignore})。
 9348: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 9349: @end table
 9350: 
 9351: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9352: @node release examples
 9353: @appendixsubsec release の使用例
 9354: 
 9355: ディレクトリ @file{tc} の放棄判定をしてから作業ディレクトリを削除しま
 9356: す。
 9357: 
 9358: @example
 9359: $ cd ..         # @r{@samp{cvs release} は作業ディレクトリの}
 9360:                 # @r{すぐ上で実行しなくてはいけません。}
 9361: $ cvs release -d tc
 9362: You have [0] altered files in this repository.
 9363: Are you sure you want to release (and delete) directory `tc': y
 9364: $
 9365: @end example
 9366: 
 9367: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 9368: @node update
 9369: @appendixsec update---作業コピーをリポジトリと一致させる
 9370: @cindex update (subcommand)
 9371: 
 9372: @itemize @bullet
 9373: @item
 9374: 書式: update [-AdflPpR] [-d] [-r tag|-D date] files@dots{}
 9375: @item
 9376: 必須: リポジトリ, 作業ディレクトリ
 9377: @item
 9378: 変更: 作業ディレクトリ
 9379: @end itemize
 9380: 
 9381: 共有するリポジトリから作業コピーを取り出した後でも、
 9382: 他の開発者はリポジトリのソースを変更し続けるでしょう。
 9383: 開発工程の然るべき時に @code{update} コマンドを使えば、
 9384: 最後の @code{checkout} や @code{update} 以降の、
 9385: どのリビジョンでも取り入れることができます。
 9386: 
 9387: @menu
 9388: * update options::              update のオプション
 9389: * update output::               update の出力
 9390: @end menu
 9391: 
 9392: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9393: @node update options
 9394: @appendixsubsec update のオプション
 9395: 
 9396: @code{update} では、以下の標準オプションが利用できます 
 9397: (完全な記述は @pxref{Common options}):
 9398: 
 9399: @table @code
 9400: @item -D date
 9401: @var{date} 以前の最も新しいリビジョンを利用します。
 9402: このオプションは貼り付けられ、
 9403: 勝手に @samp{-P} オプションも実行されます。
 9404: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9405: 
 9406: @item -f
 9407: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 9408: 指定したリビジョンが見付からなかった場合、
 9409: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 9410: 
 9411: @item -k @var{kflag}
 9412: キーワード置換モードを @var{kflag} に指定します。
 9413: 詳細は @ref{Substitution modes} を参照。
 9414: このオプションは貼り付けられます。つまりこれ以後、
 9415: この作業ディレクトリでファイルが更新されるときには、
 9416: 同じ @var{kflag} が使用され続けます。
 9417: @code{status} コマンドを用いて
 9418: 貼り付いたオプションを見ることができます。
 9419: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 9420: 
 9421: @item -l
 9422: Local、つまり現在の作業ディレクトリでのみコマンドが
 9423: 実行されます。@xref{Recursive behavior}.
 9424: 
 9425: @item -P
 9426: 空になったディレクトリを削除 (prune) します。
 9427: @ref{Moving directories} 参照。
 9428: 
 9429: @item -p
 9430: ファイルを標準出力に送り (pipe) ます。
 9431: 
 9432: @item -R
 9433: ディレクトリを再帰的に更新します (既定)。@xref{Recursive behavior}.
 9434: 
 9435: @item -r rev
 9436: @var{tag} で指定されたリビジョン/タグを取り出します。
 9437: このオプションは貼り付けられ、
 9438: @samp{-P} オプションも勝手に実行されます。
 9439: 貼り付いたタグ/日付についての詳細は @pxref{Sticky tags}.
 9440: @end table
 9441: 
 9442: @need 800
 9443: さらに @code{update} では次の固有オプションも使用可能です。
 9444: 
 9445: @table @code
 9446: @item -A
 9447: 貼り付いた全てのタグや日付、
 9448: また @samp{-k} オプションの指定を剥がします。
 9449: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9450: 
 9451: @item -C
 9452: 手元で修正されたファイルをリポジトリの無修正のもので上書きします (修正
 9453: されたファイルは @file{.#@var{file}.@var{revision}} に保存されます。)
 9454: 
 9455: @item -d
 9456: リポジトリに存在し、
 9457: 作業ディレクトリに無いディレクトリを作成します。
 9458: 通常は作業ディレクトリに既に存在するものだけが、
 9459: @code{update} の対象となります。
 9460: 
 9461: 最初に @code{checkout} した後にリポジトリに作成された、
 9462: 新たなディレクトリを取り出すときに使用します。
 9463: しかし残念なことに副作用があります。
 9464: 作業ディレクトリを作成するときに、
 9465: (モジュール名を利用したり、
 9466: コマンド行で望みのファイルやディレクトリを明示したりして) 
 9467: 特定のディレクトリを故意に避けていた場合、
 9468: @samp{-d} を使用すると余計なディレクトリまで作成されてしまいます。
 9469: 
 9470: @item -I @var{name}
 9471: @code{update} の際に、
 9472: @var{name} と一致するファイル名が無視されます。
 9473: 無視したいファイルが複数あるときは、
 9474: コマンド行に @samp{-I} を必要なだけ並べても構いません。
 9475: 全てのファイルを無視したくない場合は、
 9476: @samp{-I !} と指定して下さい。
 9477: @sc{cvs} にファイルを無視させる他の方法は @xref{cvsignore}.
 9478: 
 9479: @item -W@var{spec}
 9480: @code{update} の際に、
 9481: フィルタを掛けるべきファイル名を指定します。
 9482: このオプションは繰り返し利用することができます。
 9483: 
 9484: @file{.cvswrappers} と同じ形式を用いて、
 9485: @var{spec} にファイル名を指定します。@xref{Wrappers}.
 9486: 
 9487: @item -j@var{revision}
 9488: @samp{-j} オプションを二つ指定した場合、
 9489: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 9490: 作業ディレクトリにマージします。
 9491: 
 9492: @samp{-j} オプションが一つの場合、
 9493: その分岐リビジョンから指定したリビジョンへの変更を、
 9494: 作業ディレクトリにマージします。
 9495: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 9496: @samp{-j} で指定したリビジョンとの共通の祖先です。
 9497: 
 9498: @samp{-j} オプションに枝を指定する場合、
 9499: 日付の指定を付加することができます。
 9500: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 9501: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 9502: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 9503: 
 9504: @xref{Branching and merging}.
 9505: 
 9506: @end table
 9507: 
 9508: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9509: @node update output
 9510: @appendixsubsec update の出力
 9511: 
 9512: @code{update} や @code{checkout} の進行状況を知らせるために、
 9513: 処理中のファイル名が一行ずつ表示され、
 9514: 行頭にはファイルの状態を示す文字が付加されます:
 9515: 
 9516: @table @code
 9517: @item U @var{file}
 9518: リポジトリと一致するようにファイルが更新されたことを示します。
 9519: リポジトリに存在するファイルが作業ディレクトリに無かった場合や、
 9520: 修正していない作業コピーよりも新しいバージョンが
 9521: リポジトリに格納されていた場合の処理です。
 9522: 
 9523: @item P @var{file}
 9524: @samp{U} と同様ですが、@sc{cvs} サーバはファイル全体ではなく、パッチを
 9525: 送ります。2つ共結果は同じです。
 9526: 
 9527: @item A @var{file}
 9528: 作業ディレクトリにファイルが加えられ、それをリポジトリに
 9529: 反映するために @samp{commit} の実行が必要な状態を示します。
 9530: つまりファイルの格納を忘れないように注意を促しています。
 9531: 
 9532: @item R @var{file}
 9533: 作業ディレクトリからファイルが削除され、それをリポジトリに
 9534: 反映するために @samp{commit} の実行が必要な状態を示します。
 9535: つまりファイルの格納を忘れないように注意を促しています。
 9536: 
 9537: @item M @var{file}
 9538: 作業ディレクトリで修正されたファイルであることを示します。
 9539: 
 9540: @samp{M} は、ファイルに対する次の二つの修正状態のうちの一方を示します。
 9541: 一つ目は、リポジトリの当該ファイルが修正されていないため、
 9542: このファイルはあなたが最後に見たときと同じ状態にある場合です。
 9543: 二つ目は、作業コピーと同様に、
 9544: リポジトリの当該ファイルも修正されていたため、
 9545: これらを作業ディレクトリでマージした結果、
 9546: 衝突することなく正常に処理された場合です。
 9547: 
 9548: ファイルのマージが行われるとその旨が表示され、
 9549: (@code{update} が実行される前と同じ内容の) 
 9550: 作業ファイルのバックアップ・コピーが生成されます。
 9551: @code{update} の実行中にそのファイルの名前もちゃんと表示されます。
 9552: 
 9553: @item C @var{file}
 9554: @cindex .# files
 9555: @cindex __ files (VMS)
 9556: @var{file} の作業コピーへの変更とリポジトリでの変更をマージした際に、
 9557: 衝突が見つかったことを示します。
 9558: @var{file} (作業コピー) は
 9559: 2つのリビジョンをマージしようとした結果に置き換えられ、
 9560: 元のファイルは @file{.#@var{file}.@var{revision}} という名前で、
 9561: 作業ディレクトリに保存されます。ここで @var{revision} は、
 9562: ファイルの修正を開始した時点での @sc{rcs} 
 9563: リビジョンです。@ref{Conflicts example} の説明を参考にして
 9564: 衝突を解決して下さい。
 9565: @c "some systems" as in out-of-the-box OSes?  Not as
 9566: @c far as I know.  We need to advise sysadmins as well
 9567: @c as users how to set up this kind of purge, if that is
 9568: @c what they want.
 9569: @c We also might want to think about cleaner solutions,
 9570: @c like having CVS remove the .# file once the conflict
 9571: @c has been resolved or something like that.
 9572: (@file{.#} で始まるファイルを数日間利用しなかった場合、
 9573: 自動的に削除するシステムがあることに注意して下さい。
 9574: 元のファイルを保存したい場合は名前を変更すると良いでしょう。) 
 9575: @sc{vms} ではファイル名の先頭に、
 9576: @file{.#} ではなく @file{__} を使用します。
 9577: 
 9578: @item ? @var{file}
 9579: 作業ディレクトリに @var{file} というファイルがあるけれど、
 9580: リポジトリには対応するファイルが無く、
 9581: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 9582: (@samp{-I} オプションの説明及び @pxref{cvsignore} を参照)。
 9583: @end table
 9584: 
 9585: @node Invoking CVS
 9586: @appendix CVS コマンドの簡単な便覧
 9587: @cindex Command reference
 9588: @cindex Reference, commands
 9589: @cindex Invoking CVS
 9590: 
 9591: この付録は、それぞれのコマンドや機能が詳しく説明されているところへの参
 9592: 照とともに、@sc{cvs} の実行のしかたを説明します。他の参照は、@code{cvs
 9593: --help} コマンドを実行するか、@ref{Index} を参照してください。
 9594: 
 9595: @sc{cvs} コマンドは以下の様になります:
 9596: 
 9597: @example
 9598: cvs [ @var{global_options} ] @var{command} [ @var{command_options} ] [ @var{command_args} ]
 9599: @end example
 9600: 
 9601: 標準オプション:
 9602: 
 9603: @table @code
 9604: @item --allow-root=@var{rootdir}
 9605: 正しい @sc{cvsroot} ディレクトリを指定します (サーバのみ) (@sc{cvs} 
 9606: 1.9 以前にはありません)。 @ref{Password authentication server} 参照。
 9607: 
 9608: @item -a
 9609: 全ての通信を認証します (クライアントのみ) (@sc{cvs} 1.9 以前にはありま
 9610: せん)。@ref{Global options} 参照。
 9611: 
 9612: @item -b
 9613: RCS の位置を指定します (@sc{cvs} 1.9 以前)。@ref{Global options} 参照。
 9614: 
 9615: @item -d @var{root}
 9616: @sc{cvsroot} を指定します。@ref{Repository} 参照。
 9617: 
 9618: @item -e @var{editor}
 9619: @var{editor} でメッセージを編集します。@ref{Committing your changes} 
 9620: 参照。
 9621: 
 9622: @item -f
 9623: @file{~/.cvsrc} ファイルを読み込みません。@ref{Global options} 参照。
 9624: 
 9625: @item -H
 9626: @itemx --help
 9627: ヘルプメッセージを印字します。@ref{Global options} 参照。
 9628: 
 9629: @item -l
 9630: @file{$CVSROOT/CVSROOT/history} ファイルにログを残しません。
 9631: @ref{Global options} 参照。
 9632: 
 9633: @item -n
 9634: どのファイルも変更しません。@ref{Global options} 参照。
 9635: 
 9636: @item -Q
 9637: 本当に出力を抑えます。@ref{Global options} 参照。
 9638: 
 9639: @item -q
 9640: 少しばかり出力を抑えます。@ref{Global options} 参照。
 9641: 
 9642: @item -r
 9643: 新しい作業ファイルを読み込み専用にします。@ref{Global options} 参照。
 9644: 
 9645: @item -s @var{variable}=@var{value}
 9646: 使用者変数を設定します。@ref{Variables} 参照。
 9647: 
 9648: @item -T @var{tempdir}
 9649: 一時ファイルを @var{tempdir} に置きます。@ref{Global options} 参照。
 9650: 
 9651: @item -t
 9652: @sc{cvs} の実行を追跡します。@ref{Global options} 参照。
 9653: 
 9654: @item -v
 9655: @item --version
 9656: @sc{cvs} のバージョンと著作権情報を表示します。
 9657: 
 9658: @item -w
 9659: 新しいファイルを読み込み書き込み可にします。@ref{Global options} 参照。
 9660: 
 9661: @item -x
 9662: 全ての通信を暗号化します (クライアントのみ)。@ref{Global options} 参照。
 9663: 
 9664: @item -z @var{gzip-level}
 9665: @cindex Compression
 9666: @cindex Gzip
 9667: 圧縮の度合を設定します (クライアントのみ)。
 9668: @c FIXME: what are the valid values for gzip-level.
 9669: @c And shouldn't this be documented in at least a
 9670: @c little bit of detail somewhere?
 9671: 
 9672: @end table
 9673: 
 9674: キーワード展開モード (@pxref{Substitution modes}):
 9675: 
 9676: @example
 9677: -kkv  $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
 9678: -kkvl $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9679: -kk   $@asis{}Id$
 9680: -kv   file1,v 1.1 1993/12/09 03:21:13 joe Exp
 9681: -ko   @i{非展開}
 9682: -kb   @i{非展開、ファイルはバイナリ}
 9683: @end example
 9684: 
 9685: キーワード (@pxref{Keyword list}):
 9686: 
 9687: @example
 9688: $@asis{}Author: joe $
 9689: $@asis{}Date: 1993/12/09 03:21:13 $
 9690: $@asis{}Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9691: $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9692: $@asis{}Locker: harry $
 9693: $@asis{}Name: snapshot_1_14 $
 9694: $@asis{}RCSfile: file1,v $
 9695: $@asis{}Revision: 1.1 $
 9696: $@asis{}Source: /home/files/file1,v $
 9697: $@asis{}State: Exp $
 9698: $@asis{}Log: file1,v $
 9699: Revision 1.1  1993/12/09 03:30:17  joe
 9700: Initial revision
 9701: 
 9702: @end example
 9703: 
 9704: @c The idea behind this table is that we want each item
 9705: @c to be a sentence or two at most.  Preferably a
 9706: @c single line.
 9707: @c
 9708: @c In some cases refs to "foo options" are just to get
 9709: @c this thing written quickly, not because the "foo
 9710: @c options" node is really the best place to point.
 9711: コマンド、コマンドのオプション、コマンドの引数:
 9712: 
 9713: @table @code
 9714: @item add [@var{options}] [@var{files}@dots{}]
 9715: 新しいファイル/ディレクトリを加えます。@ref{Adding files} 参照。
 9716: 
 9717: @table @code
 9718: @item -k @var{kflag}
 9719: キーワード展開を設定します。
 9720: 
 9721: @item -m @var{msg}
 9722: ファイルの説明を設定します。
 9723: @end table
 9724: 
 9725: @item admin [@var{options}] [@var{files}@dots{}]
 9726: リポジトリの履歴ファイルの管理です。@ref{admin} 参照。
 9727: @c This list omits those options which are not
 9728: @c documented as being useful with CVS.  That might be
 9729: @c a mistake...
 9730: 
 9731: @table @code
 9732: @item -b[@var{rev}]
 9733: 既定枝を設定します。@ref{Reverting local changes} 参照。
 9734: 
 9735: @item -c@var{string}
 9736: 註釈符を設定します。
 9737: 
 9738: @item -k@var{subst}
 9739: キーワード置換を設定します。@ref{Keyword substitution} 参照。
 9740: 
 9741: @item -l[@var{rev}]
 9742: @var{rev} か、最新のリビジョンをロックします。
 9743: 
 9744: @item -m@var{rev}:@var{msg}
 9745: リビジョン @var{rev} のログメッセージを @var{msg} で置換します。
 9746: 
 9747: @item -o@var{range}
 9748: リポジトリからリビジョンを消去します。@ref{admin options} 参照。
 9749: 
 9750: @item -q
 9751: 静かに実行します。診断情報を印字しません。
 9752: 
 9753: @item -s@var{state}[:@var{rev}]
 9754: 状態を設定します。
 9755: 
 9756: @c Does not work for client/server CVS
 9757: @item -t
 9758: 標準入力からファイルの説明を設定します。
 9759: 
 9760: @item -t@var{file}
 9761: ファイルの説明を @var{file} から設定します。
 9762: 
 9763: @item -t-@var{string}
 9764: ファイルの説明を @var{string} にします。
 9765: 
 9766: @item -u[@var{rev}]
 9767: リビジョン @var{rev} か、最新のリビジョンのロックを外します。
 9768: @end table
 9769: 
 9770: @item annotate [@var{options}] [@var{files}@dots{}]
 9771: それぞれの行が修正された最新のリビジョンを表示します。@ref{annotate}
 9772: 参照。
 9773: 
 9774: @table @code
 9775: @item -D @var{date}
 9776: @var{date} 以前で一番新しいリビジョンを annotate します。@ref{Common
 9777: options} 参照。
 9778: 
 9779: @item -f
 9780: タグ/日付が見つからない場合は先頭のリビジョンを使います。@ref{Common
 9781: options} 参照。
 9782: 
 9783: @item -l
 9784: Local、つまり現在の作業ディレクトリでのみコマンドが
 9785: 実行されます。@xref{Recursive behavior}.
 9786: 
 9787: @item -R
 9788: 再帰的に動作します (既定動作)。@xref{Recursive behavior}.
 9789: 
 9790: @item -r @var{tag}
 9791: リビジョン @var{tag} を annotate します。@ref{Common options} 参照。
 9792: @end table
 9793: 
 9794: @item checkout [@var{options}] @var{modules}@dots{}
 9795: ソースのコピーを取得します。@ref{checkout} 参照。
 9796: 
 9797: @table @code
 9798: @item -A
 9799: 貼り付いたタグ/日付/オプションを元に戻します。@ref{Sticky tags} と 
 9800: @ref{Keyword substitution} 参照。
 9801: 
 9802: @item -c
 9803: モジュールデータベースを出力します。@ref{checkout options}.
 9804: 
 9805: @item -D @var{date}
 9806: @var{date} のリビジョンを取り出します (貼り付きます)。@ref{Common
 9807: options} 参照。
 9808: 
 9809: @item -d @var{dir}
 9810: @var{dir} に取り出します。@ref{checkout options} 参照。
 9811: 
 9812: @item -f
 9813: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9814: options} 参照。
 9815: 
 9816: @c Probably want to use rev1/rev2 style like for diff
 9817: @c -r.  Here and in on-line help.
 9818: @item -j @var{rev}
 9819: 変更をマージします。@ref{checkout options} 参照。
 9820: 
 9821: @item -k @var{kflag}
 9822: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9823: 
 9824: @item -l
 9825: Local、つまり現在の作業ディレクトリでのみコマンドが
 9826: 実行されます。@xref{Recursive behavior}.
 9827: 
 9828: @item -N
 9829: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{checkout
 9830: options} 参照。
 9831: 
 9832: @item -n
 9833: モジュールプログラム (もしあれば) を実行しません。@ref{checkout
 9834: options} 参照。
 9835: 
 9836: @item -P
 9837: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9838: 
 9839: @item -p
 9840: ファイルを標準出力に取り出します (貼り付きを避けます)。@ref{checkout
 9841: options}。
 9842: 
 9843: @item -R
 9844: 再帰的に動作します(既定動作です)。@xref{Recursive behavior}.
 9845: 
 9846: @item -r @var{tag}
 9847: リビジョン @var{tag} を取り出します。@ref{Common options} 参照。
 9848: 
 9849: @item -s
 9850: -c と似ていますが、モジュールの状態を含みます。@ref{checkout options} 
 9851: 参照。
 9852: @end table
 9853: 
 9854: @item commit [@var{options}] [@var{files}@dots{}]
 9855: 変更をリポジトリに格納します。@ref{commit} 参照。
 9856: 
 9857: @table @code
 9858: @item -F @var{file}
 9859: @var{file} からログメッセージを読み込みます。@ref{commit options} 参照。
 9860: 
 9861: @item -f
 9862: @c What is this "disables recursion"?  It is from the
 9863: @c on-line help; is it documented in this manual?
 9864: ファイルを強制的に格納します。再帰的動作を使用不可にします。
 9865: @ref{commit options} 参照。
 9866: 
 9867: @item -l
 9868: Local、つまり現在の作業ディレクトリでのみコマンドが
 9869: 実行されます。@xref{Recursive behavior}.
 9870: 
 9871: @item -m @var{msg}
 9872: @var{msg} をログメッセージとして使います。@ref{commit options} 参照。
 9873: 
 9874: @item -n
 9875: モジュールプログラム (もしあれば) を実行しません。@ref{commit options}
 9876: 参照。
 9877: 
 9878: @item -R
 9879: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9880: 
 9881: @item -r @var{rev}
 9882: @var{rev} に格納します。@ref{commit options} 参照。
 9883: @c FIXME: should be dragging over text from
 9884: @c commit options, especially if it can be cleaned up
 9885: @c and made concise enough.
 9886: @end table
 9887: 
 9888: @item diff [@var{options}] [@var{files}@dots{}]
 9889: リビジョン間の差分を表示します。@ref{diff} 参照。以下のオプションに加
 9890: えて、出力様式を変更するいろいろなオプションを受け付けます。例えば、
 9891: context diff のための @samp{-c} です。
 9892: 
 9893: @table @code
 9894: @item -D @var{date1}
 9895: 作業ディレクトと日付のリビジョンの差分を取ります。@ref{diff options}
 9896: 参照。
 9897: 
 9898: @item -D @var{date2}
 9899: @var{rev1}/@var{date1} と @var{date2} 間の差分を取ります。@ref{diff
 9900: options} 参照。
 9901: 
 9902: @item -l
 9903: Local、つまり現在の作業ディレクトリでのみコマンドが
 9904: 実行されます。@ref{Recursive behavior} 参照。
 9905: 
 9906: @item -N
 9907: 追加されたり削除されたりしたファイルの差分も含みます。@ref{diff
 9908: options} 参照。
 9909: 
 9910: @item -R
 9911: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9912: 
 9913: @item -r @var{rev1}
 9914: リビジョン @var{rev1} と作業ファイル間の差分を取ります。@ref{diff
 9915: options} 参照。
 9916: 
 9917: @item -r @var{rev2}
 9918: @var{rev1}/@var{date1} と @var{rev2} 間の差分を取ります。@ref{diff
 9919: options} 参照。
 9920: @end table
 9921: 
 9922: @item edit [@var{options}] [@var{files}@dots{}]
 9923: 監視下のファイルを編集する準備をします。@ref{Editing files} 参照。
 9924: 
 9925: @table @code
 9926: @item -a @var{actions}
 9927: 一時監視のための動作を指定します。引数は @code{actions}, @code{edit},
 9928: @code{unedit}, @code{commit}, @code{all}, @code{none} のどれかです。
 9929: @ref{Editing files} 参照。
 9930: 
 9931: @item -l
 9932: Local、つまり現在の作業ディレクトリでのみコマンドが
 9933: 実行されます。@xref{Recursive behavior}.
 9934: 
 9935: @item -R
 9936: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9937: @end table
 9938: 
 9939: @item editors [@var{options}] [@var{files}@dots{}]
 9940: 誰が監視下のファイルを編集しているを見ます。@ref{Watch information} 参
 9941: 照。
 9942: 
 9943: @table @code
 9944: @item -l
 9945: Local、つまり現在の作業ディレクトリでのみコマンドが
 9946: 実行されます。@ref{Recursive behavior} 参照。
 9947: 
 9948: @item -R
 9949: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9950: @end table
 9951: 
 9952: @item export [@var{options}] @var{modules}@dots{}
 9953: CVS からフィルを export するときに使います。@ref{export} 参照。
 9954: 
 9955: @table @code
 9956: @item -D @var{date}
 9957: @var{date} のリビジョンを取り出します。@ref{Common options} 参照。
 9958: 
 9959: @item -d @var{dir}
 9960: @var{dir} に取り出します。@ref{export options} 参照。
 9961: 
 9962: @item -f
 9963: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9964: options} 参照。
 9965: 
 9966: @item -k @var{kflag}
 9967: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9968: 
 9969: @item -l
 9970: Local、つまり現在の作業ディレクトリでのみコマンドが
 9971: 実行されます。@ref{Recursive behavior} 参照。
 9972: 
 9973: @item -N
 9974: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{export
 9975: options} 参照。
 9976: 
 9977: @item -n
 9978: モジュールプログラム (もしあっても) を実行しません。@ref{export
 9979: options} 参照。
 9980: 
 9981: @item -P
 9982: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9983: 
 9984: @item -R
 9985: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9986: 
 9987: @item -r @var{tag}
 9988: リビジョン @var{tag} を取り出します。@ref{Common options} 参照。
 9989: @end table
 9990: 
 9991: @item history [@var{options}] [@var{files}@dots{}]
 9992: リポジトリ接続履歴を表示します。@ref{history} 参照。
 9993: 
 9994: @table @code
 9995: @item -a
 9996: 全ての使用者にします (既定は自分自身です)。@ref{history options} 参照。
 9997: 
 9998: @item -b @var{str}
 9999: モジュール名, ファイル名, リポジトリのパスのいずれかに、
10000: 文字列 @var{str} が含まれる記録のみを表示します。@ref{history options}
10001: 参照。
10002: 
10003: @item -c
10004: 格納された (修正された) ファイルについて報告します。@ref{history
10005: options} 参照。
10006: 
10007: @item -D @var{date}
10008: @var{date} から。@ref{history options} 参照。
10009: 
10010: @item -e
10011: 全ての記録種別について報告します。@ref{history options} 参照。
10012: 
10013: @item -l
10014: 最後に修正された (格納されたか、修正されたという報告) もの。
10015: @ref{history options} 参照。
10016: 
10017: @item -m @var{module}
10018: @var{module} について報告します (繰り返し可能)。@ref{history options}
10019: 参照。
10020: 
10021: @item -n @var{module}
10022: @var{module} だけ。@ref{history options} 参照。
10023: 
10024: @item -o
10025: 取り出されたモジュールについて報告します。@ref{history options} 参照。
10026: 
10027: @item -r @var{rev}
10028: リビジョン @var{rev} から。@ref{history options} 参照。
10029: Since revision @var{rev}.  See @ref{history options}.
10030: 
10031: @item -T
10032: @c What the @#$@# is a TAG?  Same as a tag?  This
10033: @c wording is also in the online-line help.
10034: 全てのタグについて報告します。@ref{history options} 参照。
10035: 
10036: @item -t @var{tag}
10037: tag の記録が履歴ファイルに (誰かによって) 置かれてから。@ref{history
10038: options} 参照。
10039: 
10040: @item -u @var{user}
10041: 使用者 @var{user} (繰り返し可能)。@ref{history options} 参照。
10042: 
10043: @item -w
10044: 作業ディレクトリが合わなくてはいけません。@ref{history options} 参照。
10045: 
10046: @item -x @var{types}
10047: @var{types} について報告します。@code{TOEFWUCGMAR} から1つ以上指定しま
10048: す。@ref{history options} 参照。
10049: 
10050: @item -z @var{zone}
10051: 標準時間帯 @var{zone} で出力します。@ref{history options} 参照。
10052: @end table
10053: 
10054: @item import [@var{options}] @var{repository} @var{vendor-tag} @var{release-tags}@dots{}
10055: ベンダー枝を使用して CVS にファイルを持ち込みます。@ref{import} 参照。
10056: 
10057: @table @code
10058: @item -b @var{bra}
10059: ベンダー枝 @var{bra} に持ち込みます。@ref{Multiple vendor branches} 参
10060: 照。
10061: 
10062: @item -d
10063: ファイルの修正時刻を持ち込みの時間として使用します。@ref{import
10064: options} 参照。
10065: 
10066: @item -k @var{kflag}
10067: 既定のキーワード置換モードを設定します。@ref{import options} 参照。
10068: 
10069: @item -m @var{msg}
10070: @var{msg} をログメッセージに使います。@ref{import options} 参照。
10071: 
10072: @item -I @var{ign}
10073: 無視するファイルです (無効にするためには ! を使います)。@ref{import
10074: options} 参照。
10075: 
10076: @item -W @var{spec}
10077: ラッパーです。@ref{import options} 参照。
10078: @end table
10079: 
10080: @item init
10081: 存在しない場合は CVS リポジトリを作成します。@ref{Creating a
10082: repository} 参照。
10083: 
10084: @item log [@var{options}] [@var{files}@dots{}]
10085: ファイルの履歴情報を印字します。@ref{log} 参照。
10086: 
10087: @table @code
10088: @item -b
10089: 既定枝のリビジョンのみを一覧表示します。@ref{log options} 参照。
10090: 
10091: @item -d @var{dates}
10092: 日付を指定します (範囲は @var{d1}<@var{d2} で、それ以前の最新は 
10093: @var{d} で)。@ref{log options} 参照。
10094: Specify dates (@var{d1}<@var{d2} for range, @var{d} for
10095: latest before).  See @ref{log options}.
10096: 
10097: @item -h
10098: ヘッダーのみを印字します。@ref{log options} 参照。
10099: 
10100: @item -l
10101: Local、つまり現在の作業ディレクトリでのみコマンドが
10102: 実行されます。@ref{Recursive behavior} 参照。
10103: 
10104: @item -N
10105: タグを一覧表示しません。@ref{log options} 参照。
10106: 
10107: @item -R
10108: RCS ファイルの名前のみを印字します。@ref{log options} 参照。
10109: 
10110: @item -r@var{revs}
10111: リビジョン @var{revs} のみを一覧表示します。@ref{log options} 参照。
10112: 
10113: @item -s @var{states}
10114: 指定された状態のリビジョンのみを一覧表示します。@ref{log options} 参照。
10115: 
10116: @item -t
10117: ヘッダーと説明文のみを印字します。@ref{log options} 参照。
10118: 
10119: @item -w@var{logins}
10120: logins で指定された使用者が格納したリビジョンのみを一覧表示します。
10121: @ref{log options} 参照。
10122: @end table
10123: 
10124: @item login
10125: 認証サーバのパスワードの入力を促進します。@ref{Password authentication
10126: client} 参照。
10127: 
10128: @item logout
10129: 保存されている認証サーバのパスワードを消去します。
10130: @ref{Password authentication client} 参照。
10131: 
10132: @item rdiff [@var{options}] @var{modules}@dots{}
10133: リリース間の差分を表示します。@ref{rdiff} 参照。
10134: 
10135: @table @code
10136: @item -c
10137: Context diff 出力様式です (既定)。@ref{rdiff options} 参照。
10138: 
10139: @item -D @var{date}
10140: @var{date} に基づいたリビジョンを選択します。@ref{Common options} 参照。
10141: 
10142: @item -f
10143: タグ/日付が見つからない場合は先頭のリビジョンを使用します。@ref{Common
10144: options} 参照。
10145: 
10146: @item -l
10147: Local、つまり現在の作業ディレクトリでのみコマンドが
10148: 実行されます。@ref{Recursive behavior} 参照。
10149: 
10150: @item -R
10151: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10152: 
10153: @item -r @var{rev}
10154: @var{rev} に基づいたリビジョンを選択します。@ref{Common options} 参照。
10155: 
10156: @item -s
10157: 短いパッチです - ファイルにつき一行です。@ref{rdiff options} 参照。
10158: 
10159: @item -t
10160: 先頭の2つの差分です - ファイルへの最後の変更です。@ref{diff options}
10161: 参照。
10162: 
10163: @item -u
10164: Unidiff 出力様式です。@ref{rdiff options} 参照。
10165: 
10166: @item -V @var{vers}
10167: RCS バージョン @var{vers} をキーワード展開に使用します (旧式)。
10168: @ref{rdiff options} 参照。
10169: @end table
10170: 
10171: @item release [@var{options}] @var{directory}
10172: ディレクトリがもう使われていないことを示します。@ref{release} 参照。
10173: 
10174: @table @code
10175: @item -d
10176: 与えられたディレクトリを消去します。@ref{release options} 参照。
10177: @end table
10178: 
10179: @item remove [@var{options}] [@var{files}@dots{}]
10180: リポジトリから登録を消去します。@ref{Removing files} 参照。
10181: 
10182: @table @code
10183: @item -f
10184: 削除する前にファイルを消去します。@ref{Removing files} 参照。
10185: 
10186: @item -l
10187: Local、つまり現在の作業ディレクトリでのみコマンドが
10188: 実行されます。@ref{Recursive behavior} 参照。
10189: 
10190: @item -R
10191: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10192: @end table
10193: 
10194: @item rtag [@var{options}] @var{tag} @var{modules}@dots{}
10195: モジュールにタグ名を追加します。@ref{Revisions} と @ref{Branching and
10196: merging} 参照。
10197: 
10198: @table @code
10199: @item -a
10200: 削除されたファイルからそうでない場合に付いているタグを消去します。
10201: @ref{Tagging add/remove} 参照。
10202: 
10203: @item -b
10204: @var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。
10205: 
10206: @item -D @var{date}
10207: @var{date} のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。
10208: 
10209: @item -d
10210: @var{タグ} を消去します。@ref{Modifying tags} 参照。
10211: 
10212: @item -F
10213: 既に @var{タグ} が存在していれば移動します。@ref{Modifying tags} 参照。
10214: 
10215: @item -f
10216: タグ/日付が見つからなければ、先頭のリビジョンとの合致を強制します。
10217: @ref{Tagging by date/tag} 参照。
10218: 
10219: @item -l
10220: Local、つまり現在の作業ディレクトリでのみコマンドが
10221: 実行されます。@ref{Recursive behavior} 参照。
10222: 
10223: @item -n
10224: タグプログラムを実行しません。@ref{Common options} 参照。
10225: 
10226: @item -R
10227: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10228: 
10229: @item -r @var{rev}
10230: 存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参照。
10231: @end table
10232: 
10233: @item status [@var{options}] @var{files}@dots{}
10234: 作業ディレクトリの状態の情報を表示します。@ref{File status} 参照。
10235: 
10236: @table @code
10237: @item -l
10238: Local、つまり現在の作業ディレクトリでのみコマンドが
10239: 実行されます。@ref{Recursive behavior} 参照。
10240: 
10241: @item -R
10242: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10243: 
10244: @item -v
10245: ファイルにタグ情報を含めます。@ref{Tags} 参照。
10246: @end table
10247: 
10248: @item tag [@var{options}] @var{tag} [@var{files}@dots{}]
10249: ファイルの取り出されたリビジョンにタグ名を追加します。@ref{Revisions}
10250: と @ref{Branching and merging} 参照。
10251: 
10252: @table @code
10253: @item -b
10254: @var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。
10255: 
10256: @item -c
10257: 作業ファイルが無修正かどうかを調べます。@ref{Tagging the working
10258: directory} 参照。
10259: 
10260: @item -D @var{date}
10261: @var{date} の時点のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。
10262: 
10263: @item -d
10264: @var{タグ} を消去します。@ref{Modifying tags} 参照。
10265: 
10266: @item -F
10267: タグが存在していればそれを移動します。@ref{Tagging by date/tag} 参照。
10268: 
10269: @item -f
10270: タグ/日付が見つからなければ先頭のリビジョンとの合致を強制します。
10271: @ref{Tagging by date/tag} 参照。
10272: 
10273: @item -l
10274: Local、つまり現在の作業ディレクトリでのみコマンドが
10275: 実行されます。@ref{Recursive behavior} 参照。
10276: 
10277: @item -R
10278: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10279: 
10280: @item -r @var{rev}
10281: 存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参
10282: 照。
10283: @end table
10284: 
10285: @item unedit [@var{options}] [@var{files}@dots{}]
10286: edit コマンドの効果を取り消します。@ref{Editing files} 参照。
10287: 
10288: @table @code
10289: @item -a @var{actions}
10290: @var{actions} は @code{edit}, @code{unedit}, @code{commit},
10291: @code{all},  @code{none} のどれかです。@ref{Editing files} 参照。
10292: 
10293: @item -l
10294: Local、つまり現在の作業ディレクトリでのみコマンドが
10295: 実行されます。@ref{Recursive behavior} 参照。
10296: 
10297: @item -R
10298: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10299: @end table
10300: 
10301: @item update [@var{options}] [@var{files}@dots{}]
10302: 作業木とリポジトリとの同期を取ります。@ref{update} 参照。
10303: 
10304: @table @code
10305: @item -A
10306: 貼り付いたタグ/日付/オプションを取ります。@ref{Sticky tags} と
10307: @ref{Keyword substitution} 参照。
10308: 
10309: @item -C
10310: 手元で修正されたファイルをリポジトリの無修正のもので上書きします (修正
10311: されたファイルは @file{.#@var{file}.@var{revision}} に保存されます。)
10312: 
10313: @item -D @var{date}
10314: @var{date} 時点でのリビジョンを取り出します (貼り付きます)。
10315: @ref{Common options} 参照。
10316: 
10317: @item -d
10318: ディレクトリを作成します。@ref{update options} 参照。
10319: 
10320: @item -f
10321: タグ/日付が見つからなければ先頭のリビジョンを使用します。@ref{Common
10322: options} 参照。
10323: 
10324: @item -I @var{ign}
10325: ファイルを無視します (無効にするためには ! を使います)。@ref{import
10326: options} 参照。
10327: 
10328: @c Probably want to use rev1/rev2 style like for diff
10329: @c -r.  Here and in on-line help.
10330: @item -j @var{rev}
10331: 変更をマージします。@ref{update options} 参照。
10332: 
10333: @item -k @var{kflag}
10334: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
10335: 
10336: @item -l
10337: Local、つまり現在の作業ディレクトリでのみコマンドが
10338: 実行されます。@ref{Recursive behavior} 参照。
10339: 
10340: @item -P
10341: 空のディレクトリを削除します。@ref{Moving directories} 参照。
10342: 
10343: @item -p
10344: ファイルを標準出力に取り出します (貼り付きを回避します)。@ref{update
10345: options} 参照。
10346: 
10347: @item -R
10348: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10349: 
10350: @item -r @var{tag}
10351: リビジョン @var{tag} を取り出します (貼り付きます)。@ref{Common
10352: options} 参照。
10353: 
10354: @item -W @var{spec}
10355: ラッパーです。@ref{import options} 参照。
10356: @end table
10357: 
10358: @item watch [on|off|add|remove] [@var{options}] [@var{files}@dots{}]
10359: 
10360: on/off: ファイルの読み込み専用取り出しを on/off します。@ref{Setting a
10361: watch} 参照。
10362: 
10363: add/remove: 動作の通知を追加削除します。@ref{Getting Notified} 参照。
10364: 
10365: @table @code
10366: @item -a @var{actions}
10367: 一時監視への動作を指定します。
10368: @var{actions} は @code{edit}, @code{unedit},
10369: @code{commit}, @code{all}, @code{none} のどれかです。
10370: @ref{Editing files} 参照。
10371: 
10372: @item -l
10373: Local、つまり現在の作業ディレクトリでのみコマンドが
10374: 実行されます。@ref{Recursive behavior} 参照。
10375: 
10376: @item -R
10377: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10378: @end table
10379: 
10380: @item watchers [@var{options}] [@var{files}@dots{}]
10381: 誰がファイル監視しているかを見ます。@ref{Watch information} 参照。
10382: 
10383: @table @code
10384: @item -l
10385: Local、つまり現在の作業ディレクトリでのみコマンドが
10386: 実行されます。@ref{Recursive behavior} 参照。
10387: 
10388: @item -R
10389: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10390: @end table
10391: 
10392: @end table
10393: 
10394: @c ---------------------------------------------------------------------
10395: @node Administrative files
10396: @appendix 管理用ファイル便覧
10397: @cindex Administrative files (reference)
10398: @cindex Files, reference manual
10399: @cindex Reference manual (files)
10400: @cindex CVSROOT (file)
10401: 
10402: @c FIXME?  Somewhere there needs to be a more "how-to"
10403: @c guide to writing these.  I think the triggers
10404: @c (commitinfo, loginfo, taginfo, &c) are perhaps a
10405: @c different case than files like modules.  One
10406: @c particular issue that people sometimes are
10407: @c (unnecessarily?) worried about is performance, and
10408: @c the impact of writing in perl or sh or ____.
10409: リポジトリ中のディレクトリ @file{$CVSROOT/CVSROOT} に、
10410: @sc{cvs} を支援する多くのファイルが置かれます。
10411: これらのファイルが無いと @sc{cvs} の能力が制限されてしまいますが、
10412: 適切に設定すれば種々の操作を簡略化することができます。
10413: これらを編集する方法は @ref{Intro administrative files} 参照。
10414: 
10415: これらの内で最も重要なファイルは @file{modules} で、
10416: リポジトリ内のモジュールを定義します。
10417: 
10418: @menu
10419: * modules::                     モジュールを定義する
10420: * Wrappers::                    ファイル名の応じてバイナリかどうかを指定する
10421: * commit files::                格納を支援するファイル
10422: * commitinfo::                  格納前にチェックする
10423: * verifymsg::                   ログメッセージはどのように評価されるのか?
10424: * editinfo::                    ログ・メッセージの作成方法を指示
10425:                                 (旧式)
10426: * loginfo::                     ログ・メッセージをどこに送るか?
10427: * rcsinfo::                     ログ・メッセージの雛型
10428: * cvsignore::                   無視するファイルを設定する
10429: * checkoutlist::                自分自身の管理ファイルを追加する
10430: * history file::                履歴情報を記録する
10431: * Variables::                   各種変数の展開
10432: * config::                      その他の CVS の設定
10433: @end menu
10434: 
10435: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10436: @node modules
10437: @appendixsec The modules file
10438: @cindex Modules (admin file)
10439: @cindex Defining modules (reference manual)
10440: 
10441: 管理用ファイル @file{modules} には、
10442: ソース・コードの集合体の名前の定義を記述します。
10443: 新たな定義を @sc{cvs} に理解させるには、
10444: @sc{cvs} を用いてファイル @file{modules} を修正して下さい 
10445: (@code{add}, @code{commit} など普通のコマンドを使用します)。
10446: 
10447: ファイル @file{modules} には、モジュールの定義だけでなく、
10448: 空白行や註釈行 (@samp{#} で始まる行) も記述できます。
10449: またバックスラッシュ (@samp{\}) を行の最後に加えて、
10450: 長い行を次の行にまで続けることができます。
10451: 
10452: モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア
10453: ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト
10454: リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには 
10455: @file{first-dir} というディレクトリがあり、そこには @file{file1} と 
10456: @file{file2} というファイルがあり、@file{sdir} というディレクトリがあ
10457: ります。@file{first-dir/sdir} には @file{sfile} というファイルがありま
10458: す。
10459: 
10460: @c FIXME: should test all the examples in this section.
10461: 
10462: @menu
10463: * Alias modules::             一番簡単なモジュール
10464: * Regular modules::
10465: * Ampersand modules::
10466: * Excluding directories::     モジュールからディレクトリを除外する
10467: * Module options::            一般とアンドモジュールはオプションを取れる
10468: * Module program options::    modules の ``プログラムオプション'' の
10469:                               プログラムの動作方法
10470: @end menu
10471: 
10472: @node Alias modules
10473: @appendixsubsec 別名モジュール
10474: @cindex Alias modules
10475: @cindex -a, in modules file
10476: 
10477: 別名モジュールが一番簡単な種類のモジュールです:
10478: 
10479: @table @code
10480: @item @var{mname} -a @var{aliases}@dots{}
10481: これはモジュール @var{mname} の最も簡単な定義方法を表わします。
10482: @samp{-a} フラグは単純に別名の定義を行います:
10483: @sc{cvs} に (コマンドの引数として) @var{mname} が与えられると、
10484: @var{aliases} に記述された名前の一覧を代りに使用します。
10485: @var{aliases} は他のモジュール名もしくはパス名から構成します。
10486: @var{aliases} にパス名を使用した場合、
10487: @sc{cvs} の引数にパス名を明示した場合と同じく、
10488: @code{checkout} したとき途中の全てのディレクトリが
10489: 作業ディレクトリに作成されます。
10490: @end table
10491: 
10492: 例えば、モジュールファイルの内容が以下のようであると:
10493: 
10494: @example
10495: amodule -a first-dir
10496: @end example
10497: 
10498: @noindent
10499: 次の2つのコマンドは等価です:
10500: 
10501: @example
10502: $ cvs co amodule
10503: $ cvs co first-dir
10504: @end example
10505: 
10506: @noindent
10507: そして、それらは以下のような出力を出します:
10508: 
10509: @example
10510: cvs checkout: Updating first-dir
10511: U first-dir/file1
10512: U first-dir/file2
10513: cvs checkout: Updating first-dir/sdir
10514: U first-dir/sdir/sfile
10515: @end example
10516: 
10517: @node Regular modules
10518: @appendixsubsec 一般モジュール
10519: @cindex Regular modules
10520: 
10521: @table @code
10522: @item @var{mname} [ options ] @var{dir} [ @var{files}@dots{} ]
10523: この形式のモジュール定義を最も単純にすると、
10524: @samp{@var{mname} @var{dir}} となります。
10525: これはディレクトリ @var{dir} の全てのファイルを、
10526: モジュール @var{mname} と定義します。
10527: @var{dir} は (@code{$CVSROOT} から) 
10528: ソースのあるディレクトリへの相対パス名です。
10529: この場合にソースを取り出すと、
10530: @var{mname} というディレクトリだけが作業ディレクトリに作成されます。
10531: つまり @var{dir} が複数のディレクトリ階層から成るパス名であっても、
10532: 既定では途中のディレクトリ階層は使用されません。
10533: @end table
10534: 
10535: 例えば、モジュールが以下で定義されていると:
10536: 
10537: @example
10538: regmodule first-dir
10539: @end example
10540: 
10541: @noindent
10542: regmodule は first-dir のファイルを含みます:
10543: 
10544: @example
10545: $ cvs co regmodule
10546: cvs checkout: Updating regmodule
10547: U regmodule/file1
10548: U regmodule/file2
10549: cvs checkout: Updating regmodule/sdir
10550: U regmodule/sdir/sfile
10551: $
10552: @end example
10553: 
10554: @var{dir} の後で明示的にモジュールを指定することで、特定のファイルをディ
10555: レクトリ @var{dir} から選択することができます。例:
10556: 
10557: @example
10558: regfiles first-dir/sdir sfile
10559: @end example
10560: 
10561: @noindent
10562: この定義により、regfiles モジュールを取得すると、一覧に挙げられたファ
10563: イルがある単独のディレクトリ @file{regfiles} を作成し、それは @sc{cvs}
10564: のソースリポジトリのより深いディレクトリから来ています。
10565: 
10566: @example
10567: $ cvs co regfiles
10568: U regfiles/sfile
10569: $
10570: @end example
10571: 
10572: @node Ampersand modules
10573: @appendixsubsec アンドモジュール
10574: @cindex Ampersand modules
10575: @cindex &, in modules file
10576: 
10577: モジュール定義は定義に @samp{&@var{module}} を含めることで他のモジュー
10578: ルを参照することができます。
10579: @example
10580: @var{mname} [ options ] @var{&module}@dots{}
10581: @end example
10582: 
10583: そうすると、モジュールを取得したときに、モジュールのあるディレクトリで、
10584: それぞれのモジュールのためのサブディレクトリを作成します。
10585: 
10586: @example
10587: ampermod &first-dir
10588: @end example
10589: 
10590: そうすると、checkout は @code{ampermod} ディレクトリを作成し、それには 
10591: @code{first-dir} というディレクトリがあり、それは今度は自分の全てのファ
10592: イルとディレクトリを持っています。例えば、コマンド
10593: 
10594: @example
10595: $ cvs co ampermod
10596: @end example
10597: 
10598: @noindent
10599: は以下のファイルを作成します:
10600: 
10601: @example
10602: ampermod/first-dir/file1
10603: ampermod/first-dir/file2
10604: ampermod/first-dir/sdir/sfile
10605: @end example
10606: 
10607: ここには、一つ癖/バグがあります: @sc{cvs} が印字するメッセージは 
10608: @file{ampermod} を省略するので、ファイルが取り出された位置を正確に表示
10609: しません。
10610: 
10611: @example
10612: $ cvs co ampermod
10613: cvs checkout: Updating first-dir
10614: U first-dir/file1
10615: U first-dir/file2
10616: cvs checkout: Updating first-dir/sdir
10617: U first-dir/sdir/sfile
10618: $
10619: @end example
10620: 
10621: このバグっぽい動作に頼らないでください。@sc{cvs} の将来のリリースでは
10622: 修正されているかもしれません。
10623: 
10624: @c FIXCVS: What happens if regular and & modules are
10625: @c combined, as in "ampermodule first-dir &second-dir"?
10626: @c When I tried it, it seemed to just ignore the
10627: @c "first-dir".  I think perhaps it should be an error
10628: @c (but this needs further investigation).
10629: @c In addition to discussing what each one does, we
10630: @c should put in a few words about why you would use one or
10631: @c the other in various situations.
10632: 
10633: @node Excluding directories
10634: @appendixsubsec ディレクトリの除外
10635: @cindex Excluding directories, in modules file
10636: @cindex !, in modules file
10637: 
10638: 別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符 
10639: (@samp{!}) を付けることで、特定のディレクトリを除外することができます。
10640: 
10641: 例えば、モジュールファイルが以下のようになっていると:
10642: 
10643: @example
10644: exmodule -a !first-dir/sdir first-dir
10645: @end example
10646: 
10647: モジュール @samp{exmodule} を取り出すと、サブディレクトリ 
10648: @samp{first-dir/sdir} にあるファイル以外の全てを取り出します。
10649: @c Note that the "!first-dir/sdir" sometimes must be listed
10650: @c before "first-dir".  That seems like a probable bug, in which
10651: @c case perhaps it should be fixed (to allow either
10652: @c order) rather than documented.  See modules4 in testsuite.
10653: 
10654: @node Module options
10655: @appendixsubsec モジュールのオプション
10656: @cindex Options, in modules file
10657: 
10658: 標準モジュールとアンドモジュールのどちらもオプションを含むことができ、
10659: それはモジュールの追加情報を提供します。
10660: 
10661: @table @code
10662: @cindex -d, in modules file
10663: @item -d @var{name}
10664: 作業ディレクトリの名前をモジュール名とは別のものにします。
10665: @c FIXME: Needs a bunch of examples, analogous to the
10666: @c examples for alias, regular, and ampersand modules
10667: @c which show where the files go without -d.
10668: 
10669: @cindex Export program
10670: @cindex -e, in modules file
10671: @item -e @var{prog}
10672: モジュールのファイルが export されたときに常に実行されるプログラム
10673: @var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
10674: 行されます。
10675: @c FIXME: Is it run on server? client?
10676: 
10677: @cindex Checkin program
10678: @cindex -i, in modules file
10679: @item -i @var{prog}
10680: モジュールのファイルが格納されたときに常に実行されるプログラム 
10681: @var{prog} を指定します。@var{prog} はソースリポジトリの影響を受けるディ
10682: レクトリのフルパス名である唯一の引数と共に実行されます。
10683: @file{commitinfo}, @file{loginfo}, @file{veryfymsg} ファイルは格納時に
10684: プログラムを呼ぶ他の方法を提供します。
10685: @c FIXME: Is it run on server? client?
10686: 
10687: @cindex Checkout program
10688: @cindex -o, in modules file
10689: @item -o @var{prog}
10690: ファイルのモジュールが取り出されたときに常に実行されるプログラム 
10691: @var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
10692: 行されます。
10693: @c FIXME: Is it run on server? client?
10694: 
10695: @cindex Status of a module
10696: @cindex Module status
10697: @cindex -s, in modules file
10698: @item -s @var{status}
10699: モジュールに状態を割当てます。モジュールファイルが @samp{cvs checkout
10700: -s} で印字されると、モジュールが主モジュール状態に従って並び換えられ、
10701: それからモジュール名に従って並び換えられます。このオプションは他に意味
10702: はありません。状態以外のいくつかのことにこのオプションを使うことができ
10703: ます: 例えば、このモジュールに責任のある人の一覧などです。
10704: 
10705: @cindex Tag program
10706: @cindex -t, in modules file
10707: @item -t @var{prog}
10708: モジュールのファイルが @code{rtag} でタグ付けされたときに常に実行され
10709: るプログラム @var{prog} を指定します。@var{prog} は2つの引数と共に実行
10710: されます: モジュール名と @code{rtag} に指定されたタグ名です。
10711: @code{tag} が行われたときは実行されません。一般的に、taginfo の方が良
10712: い解決法です (@pxref{user-defined logging})。
10713: @c FIXME: Is it run on server? client?
10714: @c Problems with -t include:
10715: @c * It is run after the tag not before
10716: @c * It doesn't get passed all the information that
10717: @c   taginfo does ("mov", &c).
10718: @c * It only is run for rtag, not tag.
10719: 
10720: @cindex Update program
10721: @cindex -u, in modules file
10722: @item -u @var{prog}
10723: 取り出されたモジュールの最上位のディレクトリで @samp{cvs} が行なわれた
10724: ときに常に実行されるプログラム @var{protg} を指定します。@var{prog} は
10725: 単独の引数、このモジュールのソースリポジトリのフルパスとともに実行され
10726: ます。
10727: @c FIXME: Is it run on server? client?
10728: @c One drawback of -u and -i are that CVS/Update.prog
10729: @c and CVS/Checkin.prog only get updated on initial
10730: @c checkout, and don't get updated if the modules file
10731: @c changes.  Also, the user can edit them, which means
10732: @c they are no good for security-type stuff.
10733: @end table
10734: 
10735: ``プログラムオション'' プログラムがどのように実行されているのかを見る
10736: ために @ref{Module program options} も参照した方が良いでしょう。
10737: 
10738: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10739: 
10740: @node Module program options
10741: @appendixsubsec modules ファイルの ``プログラムオプション'' のプログラムがどのように実行されるか
10742: @cindex Modules file program options
10743: @cindex -u, in modules file
10744: @cindex -t, in modules file
10745: @cindex -o, in modules file
10746: @cindex -i, in modules file
10747: @cindex -e, in modules file
10748: 
10749: @noindent
10750: checkout, rtag, export ではプログラムはサーバ側が基で、以下のものが適
10751: 用されます:-
10752: 
10753: 遠隔接続方法 (pserver, ext など) を使っているときは、CVS はこのプログ
10754: ラムをサーバ上で一時ディレクトリから実行します。プログラムはパス上で検
10755: 索されます。
10756: 
10757: ``ローカル接続'' 使っているときは (ローカルや、遠隔の NFS ファイルシス
10758: テムを使用しているとき、すなわちリポジトリがパスのみに設定されていると
10759: き)、プログラムはもし見つかれば新しく取り出されたディレクトリから実行
10760: され、そうでない場合は代わりにパスが検索されます。
10761: 
10762: @noindent
10763: commit と update プログラムはローカルが基で、以下のように実行されます:-
10764: 
10765: プログラムは常にローカルで実行されます。これらのオプションが modules管
10766: 理ファイルで更新された場合は再びディレクトリを checkout する必要があり
10767: ます。ファイル CVS/Checkin.prog はオプション `-i' が modules ファイル
10768: で設定されており、ファイル CVS/Update.prog は同様に `-u' が設定されて
10769: います。プログラムは常にクライアント側の取り出されたコピーの最上位から
10770: 実行されます。これも、プログラムはまず取り出されたコピー上を探し、それ
10771: からパスを使って検索されます。
10772: 
10773: commit と update はローカルリポジトリ接続を使っているとき @emph{のみ} 
10774: に動作することにも注意してください---pserver や他の遠隔 CVS からソース
10775: が取り出されているときは、そのファイルは単純に作成されません。
10776: 
10777: プログラムは全て操作がちゃんと終了した後に実行されます。
10778: 
10779: 
10780: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10781: @node Wrappers
10782: @appendixsec cvswrappers ファイル
10783: @cindex cvswrappers (admin file)
10784: @cindex CVSWRAPPERS, environment variable
10785: @cindex Wrappers
10786: 
10787: @c FIXME: need some better way of separating this out
10788: @c by functionality.  -t/-f is one feature, -m is
10789: @c another, and -k is a third.  And this discussion
10790: @c should be better motivated (e.g. start with the
10791: @c problems, then explain how the feature solves it).
10792: 
10793: Wrapper とは操作中のファイル名に基づいて設定を制御することを可能にする
10794: @sc{cvs} の機能のことです。設定は、バイナリ・ファイルには @samp{-k} で、
10795: マージできないテキスト・ファイルには @samp{-m} です。
10796: 
10797: @ignore
10798: Wrapper 機能を用いれば、ファイルを @sc{cvs} に取り込む/取り出す際に、
10799: 適切な方法で変換するように設定することができます。
10800: 
10801: 管理用ファイル @file{cvswrappers} には、
10802: ファイル名に合致する正規表現と、
10803: そのファイルに対して実行されるスクリプトが記述されます。
10804: 個々のファイルやディレクトリに対して、二つのスクリプトが記述できます。
10805: 各々リポジトリに格納する前 (@samp{-t} フラグが付けられます) と、
10806: リポジトリから取り出すとき (@samp{-f} フラグが付けられます) に
10807: 実行するものです。@samp{-t}/@samp{-f} 機能はクライアント/サーバの 
10808: @sc{cvs} では動作しません。
10809: @c I think maybe -t/-f works client/server if a single
10810: @c file converts to/from a single file, as opposed to
10811: @c the file<->directory case.  Could use more
10812: @c investigation...
10813: @end ignore
10814: 
10815: また、非バイナリ・ファイルを更新するときの
10816: マージ方針について記述するオプション @samp{-m} があります。
10817: @code{MERGE} は @sc{cvs} が通常用いる方法です:
10818: ファイルをマージしようとすることを意味します。@code{COPY} は @code{cvs
10819: update} はファイルのマージを拒否するという意味で、@samp{-kb} でバイナ
10820: リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
10821: されていれば、@samp{-m 'COPY'} を指定する必要はありません。
10822: CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
10823: ために使用者が @sc{cvs} の外の機構を使用することを要求します。
10824: @strong{警告}: @sc{cvs} 1.9 以前では @code{COPY} を使わないでくださ
10825: い---それらのバージョンの @sc{cvs} はあるバージョンを別の物の上にコピー
10826: し、以前の内容を消し去ってしまいます。
10827: @c Ordinarily we don't document the behavior of old
10828: @c versions.  But this one is so dangerous, I think we
10829: @c must.  I almost renamed it to -m 'NOMERGE' so we
10830: @c could say "never use -m 'COPY'".
10831: Wrapper オプション @samp{-m} は更新時のマージ方針にのみ影響し、
10832: ファイルの格納方法には影響しません。
10833: バイナリ・ファイルの詳細は @ref{Binary files} 参照。
10834: 
10835: 管理用ファイル @file{cvswrappers} の基本的な書式:
10836: 
10837: @c FIXME: @example is all wrong for this.  Use @deffn or
10838: @c something more sensible.
10839: @example
10840: ワイルドカード    [オプション 値][オプション 値]...
10841: 
10842: 利用できるオプションを以下に挙げます。
10843: @ignore
10844: -f                取得時のフィルタ        値: フィルタのパス
10845: -t                格納時のフィルタ        値: フィルタのパス
10846: @end ignore
10847: -m                マージ方針              値: MERGE か COPY
10848: -k                キーワード展開          値: 置換モード
10849: 
10850: 値は以下のように単引用符で囲みます。
10851: @end example
10852: 
10853: @ignore
10854: @example
10855: *.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
10856: *.c      -t 'indent %s %s'
10857: @end example
10858: @c When does the filter need to be an absolute pathname
10859: @c and when will something like the above work?  I
10860: @c suspect it relates to the PATH of the server (which
10861: @c in turn depends on all kinds of stuff, e.g. inetd
10862: @c for pserver).  I'm not sure whether/where to discuss
10863: @c this.
10864: @c FIXME: What do the %s's stand for?
10865: 
10866: @noindent
10867: @file{cvswrappers} の上側の例では、
10868: @samp{.nib} で終わる全てのファイル/ディレクトリを、
10869: リポジトリに格納する前に @file{wrap} プログラムで
10870: 整形することが記述されています。
10871: リポジトリから取り出す際には @file{unwrap} プログラムが用いられます。
10872: またファイルを更新する際には
10873: @code{COPY} する方針を採ることが記述されています 
10874: (すなわち、マージを行いません)。
10875: 
10876: @c What pitfalls arise when using indent this way?  Is
10877: @c it a winning thing to do?  Would be nice to at least
10878: @c hint at those issues; we want our examples to tell
10879: @c how to solve problems, not just to say that cvs can
10880: @c do certain things.
10881: 最後の行の例では、@samp{.c} で終わるファイル全てを、
10882: リポジトリに格納する前に @file{indent} で整形することが記述されています。
10883: 前の例とは異なり、リポジトリから取り出す際には整形されません。
10884: @noindent
10885: @samp{-t} に記述されるフィルタには二つの引数が与えられます。
10886: 最初は整形されるファイル/ディレクトリで、
10887: 次には整形された結果が出力されるファイルのパス名です。
10888: 
10889: @noindent
10890: @samp{-f} に記述されるフィルタには、
10891: 整形されるファイル名が引数として与えられます。
10892: 整形された結果は、作業ディレクトリにファイルとして置かれます。
10893: 
10894: @samp{-t}/@samp{-f} 機能は CVS の操作の一部分---ファ
10895: イルが修正されたとき---を便利に扱えません。CVS はまだファイル (もしく
10896: はディレクトリ) が存在することを望み、その修正時刻をファイルが修正され
10897: たかどうかを決定するために使います。もし CVS が間違ってファイルが未修
10898: 正であると考えれば (例えば、ディレクトリは無変更だけど、その中のファイ
10899: ルのどれかが変更されたとき)、@code{cvs commit} に @samp{-f} オプション
10900: を指定することでとにかくファイルの格納を強制できます (@pxref{commit
10901: options})。
10902: @c This is, of course, a serious design flaw in -t/-f.
10903: @c Probably the whole functionality needs to be
10904: @c redesigned (starting from requirements) to fix this.
10905: @end ignore
10906: 
10907: @c FIXME: We don't document -W or point to where it is
10908: @c documented.  Or .cvswrappers.
10909: 例えば、@samp{.exe} で終わるファイルをバイナリとして扱いながら、
10910: ディレクトリを取り入れます:
10911: 
10912: @example
10913: cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
10914: @end example
10915: 
10916: @c Another good example, would be storing files
10917: @c (e.g. binary files) compressed in the repository.
10918: @c 	::::::::::::::::::
10919: @c 	cvswrappers
10920: @c 	::::::::::::::::::
10921: @c 	*.t12 -m 'COPY'
10922: @c 	*.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
10923: @c
10924: @c	::::::::::::::::::
10925: @c	gunzipcp
10926: @c	::::::::::::::::::
10927: @c	:
10928: @c	[ -f $1 ] || exit 1
10929: @c	zcat $1 > /tmp/.#$1.$$
10930: @c	mv /tmp/.#$1.$$ $1
10931: @c
10932: @c	::::::::::::::::::
10933: @c	gzipcp
10934: @c	::::::::::::::::::
10935: @c	:
10936: @c	DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
10937: @c	if [ ! -d $DIRNAME ] ; then
10938: @c	      DIRNAME=`echo $1 | sed -e "s|.*/||g"`
10939: @c	fi
10940: @c	gzip -c  $DIRNAME  > $2
10941: @c One catch--"cvs diff" will not invoke the wrappers
10942: @c (probably a CVS bug, although I haven't thought it out).
10943: 
10944: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10945: @node commit files
10946: @appendixsec 格納を支援するファイル
10947: @cindex Commit files
10948: 
10949: ファイル @file{modules} 中の @samp{-i} フラグは、
10950: ファイルが格納された時に特定のプログラムを実行するのに用いられます 
10951: (@pxref{modules})。
10952: この節で説明するファイルは、
10953: ファイルの格納時にプログラムを実行するための、
10954: より柔軟な方法を提供します。
10955: 
10956: 格納時に実行できるプログラムは三種類に分けられます。
10957: これらのプログラムはリポジトリ中のファイルに記述されます。
10958: 次に示すのは、
10959: ファイル名と、対応するプログラムに必要な機能を示したものです。
10960: 
10961: @table @file
10962: @item commitinfo
10963: ここに記述されるプログラムは、
10964: 格納が許されるかどうか判断する責任を持ちます。
10965: このプログラムが正常終了しなければ、
10966: 格納が中止されます。
10967: 
10968: @item verifymsg
10969: 指定されたプログラムはログメッセージを評価するために使用され、それは全
10970: ての要求部分を備えているかを検証するかもしれません。これはログメッセー
10971: ジの雛型を保持することのできる @file{rcsinfo} ファイルと組合せて使うと
10972: とても役に立ちます (@pxref{rcsinfo})。
10973: 
10974: @item editinfo
10975: ここに記述されるプログラムは、
10976: ログ・メッセージを編集するのに用いられ、
10977: 全ての要求される項目が含まれるかどうか可能な限り確かめます。
10978: ログ・メッセージの雛型を記述する @file{rcsinfo} ファイルと
10979: 組み合せることで、より便利になります (@pxref{rcsinfo})。(旧式)
10980: 
10981: @item loginfo
10982: ここに記述されるプログラムは、
10983: 格納が完了した時点で呼び出されます。
10984: ログ・メッセージと追加情報とを受け取り、ファイルに格納するか、
10985: 特定の人物にメールとして出すか、またはニュース・グループに投稿するとか、
10986: または@dots{} あなたの想像力だけがその制限です。
10987: @end table
10988: 
10989: @menu
10990: * syntax::                      共通の構文
10991: @end menu
10992: 
10993: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10994: @node syntax
10995: @appendixsubsec 共通の構文
10996: @cindex Info files (syntax)
10997: @cindex Syntax of info files
10998: @cindex Common syntax of info files
10999: 
11000: @c FIXME: having this so totally separate from the
11001: @c Variables node is rather bogus.
11002: 
11003: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{editinfo},
11004: @file{verifymsg}, などのような管理ファイルには共通の書式があります。
11005: 各ファイルの目的は後述します。
11006: ここでは共通の構文について説明します。
11007: 
11008: @cindex Regular expression syntax
11009: 各行は次の要素から構成されます:
11010: @itemize @bullet
11011: @item
11012: @c Say anything about DEFAULT and ALL?  Right now we
11013: @c leave that to the description of each file (and in fact
11014: @c the practice is inconsistent which is really annoying).
11015: 正規表現。これは GNU emacs で使われる構文の基本正規表現です。
11016: @c FIXME: What we probably should be saying is "POSIX Basic
11017: @c Regular Expression with the following extensions (`\('
11018: @c `\|' '+' etc)"
11019: @c rather than define it with reference to emacs.
11020: @c The reference to emacs is not strictly speaking
11021: @c true, as we don't support \=, \s, or \S.  Also it isn't
11022: @c clear we should document and/or promise to continue to
11023: @c support all the obscure emacs extensions like \<.
11024: @c Also need to better cite (or include) full
11025: @c documentation for the syntax.
11026: @c Also see comment in configure.in about what happens to the
11027: @c syntax if we pick up a system-supplied regexp matcher.
11028: 
11029: @item
11030: 項目間の空白---一つ以上のスペース又はタブです。
11031: 
11032: @item
11033: ファイル名又はコマンド行の形式。
11034: @end itemize
11035: 
11036: @noindent
11037: 空白行は無視されます。
11038: また @samp{#} という文字で始まる行は註釈行として扱われます。
11039: 残念ながら、長い行を複数行に分割することは@emph{できません}。
11040: 
11041: リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。
11042: 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。
11043: 
11044: @c FIXME: need an example.  In particular, show what
11045: @c the regular expression is matched against (one
11046: @c ordinarily clueful person got confused about whether it
11047: @c includes the filename--"directory name" above should be
11048: @c unambiguous but there is nothing like an example to
11049: @c confirm people's understanding of this sort of thing).
11050: 
11051: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11052: @node commitinfo
11053: @appendixsec 管理用ファイル commitinfo
11054: @cindex Commitinfo
11055: @cindex Checking commits
11056: @cindex Precommit checking
11057: 
11058: @samp{cvs commit} を実行する直前に必ず実行したいプログラムを、
11059: ファイル @file{commitinfo} に記述します。
11060: 修正、追加、削除されたファイルを格納しても良いかどうか、
11061: このプログラムを用いて格納前に判断します。
11062: 例えば、変更されたファイルがあなたのサイトの
11063: コーディング・スタイルの標準に従っているか確かめることもできます。
11064: 
11065: 前に書いたように、@file{commitinfo} の各行は、第一項の正規表現、
11066: 残りの部分のコマンド行形式から構成されます。
11067: コマンド行の部分には、
11068: プログラム名と適切な数の引数とを記述することができます。
11069: また実行の際には、リポジトリのフルパスと
11070: 格納しようとするファイル名 (追加, 削除, 修正されたファイル名) 
11071: がコマンド行の最後に与えられます。
11072: 
11073: @cindex Exit status, of commitinfo
11074: リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。
11075: そしてコマンドが非零で終了した場合は、格納が中止されます。
11076: @c FIXME: need example(s) of what "directory within the
11077: @c repository" means.
11078: 
11079: @cindex DEFAULT in commitinfo
11080: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11081: ファイル中のどの正規表現にも合致しない場合に適用されます。
11082: 
11083: @cindex ALL in commitinfo
11084: 第一項が @samp{ALL} である行全てが、
11085: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11086: 
11087: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
11088: @file{commitinfo} に記述された行は、
11089: クライアント側ではなく@emph{別のマシン} (サーバ) 側で実行されます 
11090: (@pxref{Remote repositories})。
11091: 
11092: @c FIXME: should discuss using commitinfo to control
11093: @c who has checkin access to what (e.g. Joe can check into
11094: @c directories a, b, and c, and Mary can check into
11095: @c directories b, c, and d--note this case cannot be
11096: @c conveniently handled with unix groups).  Of course,
11097: @c adding a new set of features to CVS might be a more
11098: @c natural way to fix this problem than telling people to
11099: @c use commitinfo.
11100: @c FIXME: Should make some reference, especially in
11101: @c the context of controlling who has access, to the fact
11102: @c that commitinfo can be circumvented.  Perhaps
11103: @c mention SETXID (but has it been carefully examined
11104: @c for holes?).  This fits in with the discussion of
11105: @c general CVS security in "Password authentication
11106: @c security" (the bit which is not pserver-specific).
11107: 
11108: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11109: @node verifymsg
11110: @appendixsec ログメッセージの検証
11111: @cindex verifymsg (admin file)
11112: @cindex Log message, verifying
11113: 
11114: 一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために
11115: そのメッセージを評価することができます。ログメッセージを検証するための
11116: プログラムを指定するために @file{verifymsg} ファイルを使用することがで
11117: きます。このプログラムは入力されたメッセージに必要なフィールドがあるか
11118: どうかを調べる簡単なスプリプトでも良いでしょう。
11119: 
11120: @file{verifymsg} ファイルは、ログメッセージの雛型を指定するために使う
11121: ことのできる @file{rcsinfo} ファイルと一緒に使用されたときにとても役に
11122: 立つことが多いです。
11123: 
11124: @file{verifymsg} ファイルは正規表現とコマンド行の雛型から成ります。雛
11125: 型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで
11126: きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加
11127: されます。
11128: 
11129: 一つ注意しなければならないのは、@samp{ALL} キーワードは使えないという
11130: ことです。一行以上合致した場合、最初のものが使われます。これはディレク
11131: トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき
11132: に役に立ちます。
11133: 
11134: @cindex DEFAULT in verifymsg
11135: リポジトリ名がこのファイルのどの正規表現にも合致しなければ、
11136: @samp{DEFAULT} が指定されていると、それが使用されます。
11137: 
11138: @cindex Exit status, of verifymsg
11139: 検証スクリプトが非零の値で終了すれば、格納は中止されます。
11140: 
11141: 検証スクリプトはログメセージを変更できないことに注意してください。単に
11142: 受け入れるか拒否するかのどちらかです。
11143: @c FIXME?  Is this an annoying limitation?  It would be
11144: @c relatively easy to fix (although it would *not* be a
11145: @c good idea for a verifymsg script to interact with the user
11146: @c at least in the client/server case because of locks
11147: @c and all that jazz).
11148: 
11149: 以下は、@file{verifymsg} ファイルのちょっとしたばかげた例と、それに対
11150: 応する @file{rcsinfo} ファイル、ログメッセージの雛型と検証スクリプトで
11151: す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの
11152: 最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの
11153: です。以下の雛型ファイルは @file{/usr/cvssupport/tc.template} にありま
11154: す。
11155: 
11156: @example
11157: BugId:
11158: @end example
11159: 
11160: スクリプト @file{/usr/cvssupoort/bugid.verify} はログメッセージの評価
11161: に使われます。
11162: 
11163: @example
11164: #!/bin/sh
11165: #
11166: #       bugid.verify filename
11167: #
11168: #  Verify that the log message contains a valid bugid
11169: #  on the first line.
11170: #
11171: if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
11172:     exit 0
11173: else
11174:     echo "No BugId found."
11175:     exit 1
11176: fi
11177: @end example
11178: 
11179: @file{verifymsg} ファイルには以下の行があります:
11180: 
11181: @example
11182: ^tc     /usr/cvssupport/bugid.verify
11183: @end example
11184: 
11185: @file{rcsinfo} ファイルには以下の行があります:
11186: 
11187: @example
11188: ^tc     /usr/cvssupport/tc.template
11189: @end example
11190: 
11191: 
11192: 
11193: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11194: @node editinfo
11195: @appendixsec Editinfo
11196: @cindex editinfo (admin file)
11197: @cindex Editor, specifying per module
11198: @cindex Per-module editor
11199: @cindex Log messages, editing
11200: 
11201: @emph{注意:} @file{editinfo} 機能は旧式になっています。ログメッセージ
11202: の既定のエディタを設定するためには、@code{EDITOR} 環境変数 
11203: (@pxref{Environment variables}) か @samp{-e} 広域オプション
11204: (@pxref{Global options}) を使用してください。ログメッセージを評価する
11205: ための @file{verifymsg} 機能を使うための情報は @ref{verifymsg} を参照
11206: してください。
11207: 
11208: いつも同じ形式でログ・メッセージを記録したい場合に、
11209: ログ・メッセージを編集するプログラムを @file{editinfo} に
11210: 指定することができます。
11211: 指定するプログラムは、
11212: ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、
11213: エディタを呼び出して、入力されたメッセージが必要項目を
11214: 満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。
11215: 
11216: 合致する行が @file{editinfo} になかった場合、
11217: 環境変数 @code{$CVSEDITOR} に指定されたエディタを使用します。
11218: この環境変数が設定されていない場合には、
11219: 環境変数 @code{$EDITOR} に指定されたエディタを代わりにします。
11220: そしてこの環境変数も設定されていない場合は、
11221: 既定のものが使われます。@ref{Committing your changes} 参照。
11222: 
11223: @file{rcsinfo} にログ・メッセージの雛型を指定すると、
11224: より効果的に @file{editinfo} を利用できるでしょう。
11225: 
11226: @file{editinfo} の各行は、第一項の正規表現、
11227: 残りの部分のコマンド行形式から構成されます。
11228: コマンド行の部分には、
11229: プログラム名と適切な数の引数とを記述することができます。
11230: また実行の際には、ログ・メッセージの雛型へのフルパス
11231: がコマンド行の最後に与えられます。
11232: 
11233: @samp{ALL} が利用できないことに注意して下さい。
11234: 合致する行が複数あった場合は、最初の行が実行されます。
11235: これは、モジュールの編集スクリプトが設定されていて、
11236: サブディレクトリでは別のものを使用したい場合を考慮しています。
11237: 
11238: @cindex DEFAULT in editinfo
11239: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11240: ファイル中のどの正規表現にも合致しない場合に適用されます。
11241: 
11242: 編集スクリプトが非零で終了した場合は、格納が中止されます。
11243: 
11244: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合や、
11245: @code{cvs commit} の @samp{-m} または @samp{-F} オプションを
11246: 使用した場合、@file{editinfo} は参照されません。
11247: この問題を解決する良い方法は今のところありません。
11248: 代わりに @file{verifymsg} を使ってください。
11249: 
11250: @menu
11251: * editinfo example::            editinfo 記述例
11252: @end menu
11253: 
11254: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11255: @node editinfo example
11256: @appendixsubsec editinfo 記述例
11257: 
11258: 次に、ちょっとアホくさい @file{editinfo} の使用例を、
11259: 対応する @file{rcsinfo}、ログ・メッセージの雛型、
11260: エディタ・スクリプトと併わせて紹介します。
11261: まずログ・メッセージの雛型ですが、
11262: 最初の行に必ずバグ番号を記録するように促し、
11263: 残りは自由に記述してもらいます。
11264: この雛型は @file{/usr/cvssupport/tc.template} に置くことにします。
11265: 
11266: @example
11267: BugId:
11268: @end example
11269: 
11270: ログ・メッセージを編集するため、
11271: 次のスクリプト @file{/usr/cvssupport/bugid.edit} を使用します。
11272: 
11273: @example
11274: #!/bin/sh
11275: #
11276: #       bugid.edit filename
11277: #
11278: #  Call $EDITOR on FILENAME, and verify that the
11279: #  resulting file contains a valid bugid on the first
11280: #  line.
11281: if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
11282: if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
11283: $CVSEDITOR $1
11284: until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
11285: do  echo -n  "No BugId found.  Edit again? ([y]/n)"
11286:     read ans
11287:     case $@{ans@} in
11288:         n*) exit 1;;
11289:     esac
11290:     $CVSEDITOR $1
11291: done
11292: @end example
11293: 
11294: ファイル @file{editinfo} には次の行を記述します:
11295: 
11296: @example
11297: ^tc     /usr/cvssupport/bugid.edit
11298: @end example
11299: 
11300: ファイル @file{rcsinfo} には次の行を記述します:
11301: 
11302: @example
11303: ^tc     /usr/cvssupport/tc.template
11304: @end example
11305: 
11306: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11307: @node loginfo
11308: @appendixsec 管理用ファイル loginfo
11309: @cindex loginfo (admin file)
11310: @cindex Storing log messages
11311: @cindex Mailing log messages
11312: @cindex Distributing log messages
11313: @cindex Log messages
11314: 
11315: @c "cvs commit" is not quite right.  What we
11316: @c mean is "when the repository gets changed" which
11317: @c also includes "cvs import" and "cvs add" on a directory.
11318: @file{loginfo} を用いて、
11319: @samp{cvs commit} によるログ情報の送り先を管理します。
11320: 各行の第一項には正規表現が記述され、
11321: 行の残りの部分はフィルタでなくてはいけません。
11322: 変更を加えたディレクトリを 
11323: @code{$CVSROOT} からの相対パスで表わしたものと、
11324: 各行の正規表現が合致するかどうか試されます。
11325: 合致した場合は、
11326: その行の残りの部分であるフィルタ・プログラムの標準入力に、
11327: ログ情報を与えます。
11328: 
11329: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11330: ファイル中のどの正規表現にも合致しない場合に適用されます。
11331: 
11332: 第一項が @samp{ALL} である行全てが、
11333: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11334: 
11335: 正規表現が合致する最初の行が実行されます。
11336: 
11337: ファイル @file{loginfo} の構文についての記述は @xref{commit files}.
11338: 
11339: 使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は 
11340: @samp{%} の後に空白か、単独のフォーマット文字、もしくは分離器 
11341: @samp{@{} と @samp{@}} に囲まれたいくつかのフォーマット文字が続いた物
11342: です。フォーマット文字は:
11343: 
11344: @table @t
11345: @item s
11346: ファイル名
11347: @item V
11348: 古いバージョン番号 (格納前)
11349: @item v
11350: 新しいバージョン番号 (格納後)
11351: @end table
11352: 
11353: フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます
11354: (フィールドを分離するコンマはまだ提供されされています。)
11355: 
11356: 例えば、有効なフォーマット文字列は @samp{%}, @samp{%s}, @samp{%@{s@}}, 
11357: @samp{%@{sVv@}} などです。
11358: 
11359: 出力は空白で区切られた語からなる文字列になります。下位互換のために、最
11360: 初の語はリポジトリのサブディレクトリになります。残りの語はフォーマット
11361: 文字列で要求された情報をコンマで分けたリストです。例えば、
11362: @samp{/u/src/master/yoyodyne/tc} がリポジトリで @samp{%@{sVv@}} がフォー
11363: マット文字列、3つのファイル(@t{ChangeLog}, @t{Makefile}, @t{foo.c}) が
11364: 修正されていると、出力は:
11365: 
11366: @example
11367: yoyodyne/tc ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
11368: @end example
11369: 
11370: 別の例として、@samp{%@{@}} ではリポジトリ名のみが作成されます。
11371: 
11372: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
11373: @file{loginfo} はクライアント側ではなく、@emph{別のマシン} 
11374: (サーバ) 側で実行されます 
11375: (@pxref{Remote repositories})。
11376: 
11377: @menu
11378: * loginfo example::             loginfo 記述例
11379: * Keeping a checked out copy::  格納毎にディレクトリを更新
11380: @end menu
11381: 
11382: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11383: @node loginfo example
11384: @appendixsubsec loginfo 記述例
11385: 
11386: ここで示す @file{loginfo} ファイルと付属のシェル・スクリプトは、
11387: 格納時に次のような動作をします。
11388: まず全てのログ・メッセージを 
11389: @file{$CVSROOT/CVSROOT/commitlog} に追記します。
11390: 次に全ての管理用ファイル (@file{CVSROOT} 内) の
11391: 格納時のログを @file{/usr/adm/cvsroot-log} に追記します。
11392: @file{prog1} ディクトリへの格納は @t{ceder} にメールで送られます。
11393: 
11394: @c FIXME: is it a CVS feature or bug that only the
11395: @c first matching line is used?  It is documented
11396: @c above, but is it useful?  For example, if we wanted
11397: @c to run both "cvs-log" and "Mail" for the CVSROOT
11398: @c directory, it is kind of awkward if
11399: @c only the first matching line is used.
11400: @example
11401: ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
11402: ^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
11403: ^prog1          Mail -s %s ceder
11404: @end example
11405: 
11406: シェル・スクリプト @file{/usr/local/bin/cvs-log} の内容:
11407: 
11408: @example
11409: #!/bin/sh
11410: (echo "------------------------------------------------------";
11411:  echo -n $2"  ";
11412:  date;
11413:  echo;
11414:  cat) >> $1
11415: @end example
11416: 
11417: @node Keeping a checked out copy
11418: @appendixsubsec 取得済のコピーを最新に保つ
11419: 
11420: @c What other index entries?  It seems like
11421: @c people might want to use a lot of different
11422: @c words for this functionality.
11423: @cindex Keeping a checked out copy
11424: @cindex Checked out copy, keeping
11425: @cindex Web pages, maintaining with CVS
11426: 
11427: あるディレクトリがリポジトリで管理されている場合、
11428: そのディレクトリを常に最新にしておきたい事があるでしょう。
11429: 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、
11430: @sc{cvs} で保守されたウェブ・サイトのファイルを
11431: 格納毎に更新したい場合などです。
11432: @c Can we offer more details on the web example?  Or
11433: @c point the user at how to figure it out?  This text
11434: @c strikes me as sufficient for someone who already has
11435: @c some idea of what we mean but not enough for the naive
11436: @c user/sysadmin to understand it and set it up.
11437: 
11438: これを実現するため、
11439: @code{cvs update} を実行するように @file{loginfo} を設定します。
11440: しかし単純に設定するとロックの問題が発生するので、
11441: @code{cvs update} をバックグラウンドで実行する必要があります。
11442: @c Should we try to describe the problem with locks?
11443: @c It seems like a digression for someone who just
11444: @c wants to know how to make it work.
11445: @c Another choice which might work for a single file
11446: @c is to use "cvs -n update -p" which doesn't take
11447: @c out locks (I think) but I don't see many advantages
11448: @c of that and we might as well document something which
11449: @c works for multiple files.
11450: Unix での例を以下に示します (実際は一行です):
11451: 
11452: @example
11453: ^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
11454:  cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
11455: @end example
11456: 
11457: リポジトリ中の @code{cyclic-pages} で始まるディレクトリに
11458: ファイルが格納された時、
11459: 取得済みのディレクトリ @file{/u/www/local-docs} を更新します。
11460: @c More info on some of the details?  The "sleep 2" is
11461: @c so if we are lucky the lock will be gone by the time
11462: @c we start and we can wait 2 seconds instead of 30.
11463: 
11464: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11465: @node rcsinfo
11466: @appendixsec 管理用ファイル rcsinfo
11467: @cindex rcsinfo (admin file)
11468: @cindex Form for log message
11469: @cindex Log message template
11470: @cindex Template for log message
11471: 
11472: @file{rcsinfo} には、格納時にログ・メッセージを
11473: 書き込むための書式を指定します。@file{rcsinfo} の
11474: 構文は @file{verifymsg}, @file{commitinfo}, @file{loginfo} 
11475: とほぼ同じです。@xref{syntax}.
11476: しかし他のファイルと異なり、
11477: 第二項はコマンド行形式では@emph{ありません}。
11478: 正規表現の次の部分は、ログ・メッセージの雛型を記した
11479: ファイルへのフルパス名でなくてはいけません。
11480: 
11481: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11482: ファイル中のどの正規表現にも合致しない場合に適用されます。
11483: 
11484: 第一項が @samp{ALL} である行全てが、
11485: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11486: 
11487: @c FIXME: should be offering advice, somewhere around
11488: @c here, about where to put the template file.  The
11489: @c verifymsg example uses /usr/cvssupport but doesn't
11490: @c say anything about what that directory is for or
11491: @c whether it is hardwired into CVS or who creates
11492: @c it or anything.  In particular we should say
11493: @c how to version control the template file.  A
11494: @c probably better answer than the /usr/cvssupport
11495: @c stuff is to use checkoutlist (with xref to the
11496: @c checkoutlist doc).
11497: @c Also I am starting to see a connection between
11498: @c this and the Keeping a checked out copy node.
11499: @c Probably want to say something about that.
11500: ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。
11501: しかし、@samp{cvs commit -m @var{message}} や @samp{cvs commit -f
11502: @var{file}} によってログ・メッセージを指定した場合、
11503: こちらが優先されます。
11504: 
11505: @file{rcsinfo} ファイルの記述例は @xref{verifymsg}.
11506: 
11507: @sc{cvs} が別のマシンのリポジトリを利用している場合、
11508: 最初に作業ディレクトリを取り出した時に @file{rcsinfo} に
11509: 記述されていた雛型が使用され、以後変更されません。
11510: @file{rcsinfo} や雛型を変更した場合には、
11511: 新たに作業ディレクトリを取り出す必要があります。
11512: @c Would be nice to fix CVS so this isn't needed.  For
11513: @c example, a mechanism analogous to CVS/Entries, where
11514: @c the client keeps track of what version of the template
11515: @c it has.
11516: 
11517: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11518: @node cvsignore
11519: @appendixsec cvsignore でファイルを無視する
11520: @cindex cvsignore (admin file), global
11521: @cindex Global cvsignore
11522: @cindex Ignoring files
11523: @c -- This chapter should maybe be moved to the
11524: @c tutorial part of the manual?
11525: 
11526: 作業コピーの中に、いつも決まった名前のファイルがあるけれど、
11527: @sc{cvs} の管理下には置きたくないという場合がよくあります。
11528: 例えば、ソースのコンパイル時に生成される
11529: オブジェクト・ファイルなどです。
11530: @samp{cvs update} を実行した場合には通常、
11531: これらのファイル各々に対して、
11532: 知らないファイルがあったと出力されます 
11533: (@pxref{update output})。
11534: 
11535: @sc{cvs} は、@code{update}, @code{import}, @code{release}
11536: @c -- 影響があるのはこの三つで全部か?
11537: の実行時に無視すべきファイルのリストを 
11538: (sh(1) のファイル名形式で) 保持します
11539: このリストは、以下の方法で構築されます。
11540: 
11541: @itemize @bullet
11542: @item
11543: リストは以下のファイル名形式で初期化されます: 
11544: これらは、@sc{cvs} の管理に関するものの他、
11545: 他のソース管理システムと共通のもの、
11546: 一般的なパッチ・ファイル名、オブジェクト・ファイル、
11547: 書庫ファイル、エディタのバックアップ・ファイル、
11548: 他のユーティリティの通常の生成ファイル名等から構成されます。
11549: 現在、既定で無視されるファイル名形式のリストを以下に挙げます:
11550: 
11551: @cindex Ignored files
11552: @cindex Automatically ignored files
11553: @example
11554:     RCS     SCCS    CVS     CVS.adm
11555:     RCSLOG  cvslog.*
11556:     tags    TAGS
11557:     .make.state     .nse_depinfo
11558:     *~      #*      .#*     ,*      _$*     *$
11559:     *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
11560:     *.a     *.olb   *.o     *.obj   *.so    *.exe
11561:     *.Z     *.elc   *.ln
11562:     core
11563: @end example
11564: 
11565: @item
11566: リポジトリ毎のリスト 
11567: @file{$CVSROOT/CVSROOT/cvsignore} が存在すれば、
11568: その内容がリストに付加されます。
11569: 
11570: @item
11571: 使用者毎のリスト @file{.cvsignore} が
11572: あなたのホーム・ディレクトリに存在すれば、
11573: その内容がリストに付加されます。
11574: 
11575: @item
11576: 環境変数 @code{$CVSIGNORE} の内容全てがリストに付加されます。
11577: 
11578: @item
11579: @samp{-I} オプションによって @sc{cvs} に与えられた内容が、
11580: リストに付加されます。
11581: 
11582: @item
11583: 作業ディレクトリを一通り見て @file{.cvsignore} があれば、
11584: その内容をリストに付加します。
11585: @file{.cvsignore} 内の形式は、
11586: それが含まれるディレクトリのみで有効であり、
11587: サブディレクトリに対しては効果を持ちません。
11588: @end itemize
11589: 
11590: 上記五つのファイル内で単感嘆符 (@samp{!}) を記述すると、
11591: 無視するファイルのリストが空になります。
11592: これは、通常は @sc{cvs} に無視されるファイルを、
11593: リポジトリに格納したい場合に使用します。
11594: 
11595: @code{cvs import} に @samp{-I !} を指定すると、全てを持ち込み、それは
11596: 素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
11597: でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
11598: るのがわかると思います。もし配布に @file{.cvsignore} ファイルがあると、
11599: そのファイルの形式は @samp{-I !} が指定されたとしても実行されます。唯
11600: 一の対策は持ち込むために、@file{.cvsigonre} ファイルを消去することです。
11601: これはやっかいなので、将来は @samp{-I !} はそれぞれのディレクトリの
11602: @file{.cvsignore} ファイルを上書きするように修正されるかもしれません。
11603: 
11604: 無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ
11605: れぞれの行が続いたものであることに注意してください。これは空白のある
11606: ファイル名を指定する綺麗な方法を提供しませんが、@file{foo bar} という
11607: 名前のファイルに合致させるために @file{foo?bar} のような対策を使うこと
11608: ができます (@file{fooxbar} などにも合致します)。また、現在は註釈を指定
11609: する方法が無いことにも注意してください。
11610: @c FIXCVS?  I don't _like_ this syntax at all, but
11611: @c changing it raises all the usual compatibility
11612: @c issues and I'm also not sure what to change it to.
11613: 
11614: @node checkoutlist
11615: @appendixsec checkoutlist ファイル
11616: @cindex checkoutlist
11617: 
11618: @sc{cvs} を使って自分自身のファイルを @file{CVSROOT} ディレクトリに維
11619: 持することは役に立つかもしれません。例えば、@file{logcommit.pl} という
11620: スクリプトがあり、それは以下の行を @file{commitinfo} 管理ファイルに含
11621: めることにより実行するとしましょう:
11622: 
11623: @example
11624: ALL $CVSROOT/CVSROOT/logcommit.pl
11625: @end example
11626: 
11627: @sc{cvs} で @file{logcommit.pl} を維持するためには、以下の行を 
11628: @file{checkoutlist} 管理ファイルに追加します:
11629: 
11630: @example
11631: logcommit.pl
11632: @end example
11633: 
11634: @file{checkoutlist} の形式は、一行につき @sc{cvs} を使って維持したいそ
11635: れぞれのファイルのファイル名を書いたものです。
11636: 
11637: このように @file{checkoutlist} を設定した後で、そこに一覧として挙げら
11638: れているファイルは @sc{cvs} の元からの管理ファイルと同じように機能しま
11639: す。例えば、そのファイルの一つを格納するときは、次のようなメッセージを
11640: 得るでしょう:
11641: 
11642: @example
11643: cvs commit: Rebuilding administrative file database
11644: @end example
11645: 
11646: そして、@file{CVSROOT} ディレクトリに取り出されているコピーも更新され
11647: ます。
11648: 
11649: @file{passed} (@pxref{Password authentication server}) を 
11650: @file{checkoutlist} に載せるうことはセキュリティに関する理由により
11651: 推奨されないことに注意してください。
11652: 
11653: @file{checkoutlist} で提供されるよりも一般的な文脈で取り出したコピーを
11654: 維持するための情報は、@ref{Keeping a checked out copy} を参照してくだ
11655: さい。
11656: 
11657: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11658: @node history file
11659: @appendixsec ファイル history
11660: @cindex History file
11661: @cindex Log information, saving
11662: 
11663: ファイル @file{$CVSROOT/CVSROOT/history} は、
11664: @code{history} コマンドのためにログ情報を記録します 
11665: (@pxref{history})。
11666: ログを記録したい場合には、このファイルを作成する必要があります。
11667: @code{cvs init} でリポジトリを準備すると、
11668: 自動的に作成されます (@pxref{Creating a repository})。
11669: 
11670: @file{history} ファイルの書式を説明したものは、
11671: @sc{cvs} ソース・コード内の註釈しかありません。
11672: @sc{cvs} の将来のリリースで書式が変更されるかも知れないので、
11673: このファイルは必ず @code{cvs history} を通して利用して下さい。
11674: 
11675: @node Variables
11676: @appendixsec 管理用ファイルにおける変数展開
11677: @cindex Internal variables
11678: @cindex Variables
11679: 
11680: 管理用ファイルを記述するときに、@sc{cvs} の動作環境についての
11681: 色々な情報を利用したい場合があると思います。
11682: ここでは、その実現方法を幾つか紹介します。
11683: 
11684: @sc{cvs} を実行した人物のホーム・ディレクトリを 
11685: (環境変数 @code{HOME} から) 参照するには、
11686: @samp{/} または行端の直前に @samp{~} を記述します。
11687: 同様に @var{user} のホーム・ディレクトリは、
11688: @samp{~@var{user}} と記述します。
11689: これらの変数はサーバ側で展開されるため、@code{pserver} 
11690: (@pxref{Password authenticated}) を用いる場合には正しく展開されません。
11691: この場合、@sc{cvs} を実行する人物が動作を変更できるように、
11692: ユーザ変数 (下記参照) を用いると良いでしょう。
11693: @c Based on these limitations, should we deprecate ~?
11694: @c What is it good for?  Are people using it?
11695: 
11696: @sc{cvs} 内部の情報を参照したい場合もあると思います。
11697: @sc{cvs} の内部変数は @code{$@{@var{variable}@}} という書式で参照できます。
11698: この @var{variable} は文字で始まり、
11699: アルファベットと @samp{_} から構成されます。
11700: @var{variable} に続く文字がアルファベットや @samp{_} でない場合は、
11701: @samp{@{} と @samp{@}} とを省略しても構いません。
11702: 参照可能な @sc{cvs} の内部変数には次のようなものがあります:
11703: 
11704: @table @code
11705: @item CVSROOT
11706: @cindex CVSROOT, internal variable
11707: @sc{cvs} が使用中のルート・ディレクトリを示します。
11708: ルート・ディレクトリの指定方法は、@xref{Repository}.
11709: 
11710: @item RCSBIN
11711: @cindex RCSBIN, internal variable
11712: @sc{cvs} 1.9.18 以前では、これは @sc{cvs} が @sc{rcs} プログラムを探す
11713: 場所を指定していました。@sc{cvs} はもう @sc{rcs} プログラムを実行しま
11714: せんので、今はこの内部変数を指定するとエラーになります。
11715: 
11716: @item CVSEDITOR
11717: @cindex CVSEDITOR, internal variable
11718: @itemx VISUAL
11719: @cindex VISUAL, internal variable
11720: @itemx EDITOR
11721: @cindex EDITOR, internal variable
11722: これらは @sc{cvs} が使用するエディタを示し、
11723: 全て同じ値に展開されます。
11724: 指定方法の説明は、@xref{Global options}.
11725: 
11726: @item USER
11727: @cindex USER, internal variable
11728: @sc{cvs} を実行する人物の (@sc{cvs} サーバでの) 名前に展開されます。
11729: @end table
11730: 
11731: ユーザ変数を用いれば、@sc{cvs} を実行する人物が、
11732: 管理用ファイルで用いる値を自由に設定できます。
11733: @cindex User variables
11734: ユーザ変数は、管理用ファイルに @code{$@{=@var{variable}@}} と記述します。
11735: ユーザ変数の設定は、@sc{cvs} の広域オプション @samp{-s} に、
11736: 引数 @code{@var{variable}=@var{value}} を続けます。
11737: このオプションは @file{.cvsrc} に記述しておくと良いでしょう 
11738: (@pxref{~/.cvsrc})。
11739: 
11740: 例として、実験用ディレクトリを管理用ファイルから参照するため、
11741: ユーザ変数 @code{TESTDIR} を用います。それから、以下のように @sc{cvs}
11742: を起動し、
11743: 
11744: @example
11745: cvs -s TESTDIR=/work/local/tests
11746: @end example
11747: 
11748: @noindent
11749: 管理ファイルに @code{sh $@{=TESTDIR@}/runtests} と書いてあれば、文字列
11750: は @code{sh /work/local/tests/runtests} に展開されます。
11751: 
11752: @samp{$} が上記以外の解釈を受けることはありません。
11753: また @samp{$} 自身を表現する別の方法も用意されてないため、
11754: @samp{$} という文字を引用することはできません。
11755: 
11756: @node config
11757: @appendixsec The CVSROOT/config configuration file
11758: 
11759: @cindex config, in CVSROOT
11760: @cindex CVSROOT/config
11761: 
11762: 管理ファイル @file{config} は @sc{cvs} の振舞いに影響するいろいろな雑
11763: 多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ
11764: れません。@samp{#} で始まる行は註釈と解釈されます。
11765: @c FIXME: where do we define comments for the other
11766: @c administrative files.
11767: 他の行はキーワード、@samp{=}、値からなります。この構文は厳密であること
11768: に注意してください。余分な空白やタブは使えません。
11769: @c See comments in parseinfo.c:parse_config for more
11770: @c discussion of this strictness.
11771: 
11772: 現在定義されているキーワードは:
11773: 
11774: @table @code
11775: @cindex RCSBIN, in CVSROOT/config
11776: @item RCSBIN=@var{bindir}
11777: @sc{cvs} 1.9.12 から 1.9.18 まで、この設定は @var{bindir} ディレクトリ
11778: にある @sc{rcs} プログラムを探すように @sc{cvs} に教えるために使われて
11779: いました。現在のバージョンの @sc{cvs} は @sc{rcs} プログラムを実行しま
11780: せん。互換性のためのこの設定は可能になってますが、何も起こりません。
11781: 
11782: @cindex SystemAuth, in CVSROOT/config
11783: @item SystemAuth=@var{value}
11784: @var{value} が @samp{yes} であれば、pserver は使用者を調べるときに、
11785: @file{CVSROOT/passwd} に見つからなければ、システムのデータベースを調べ
11786: にいきます。@samp{no} であれば、全ての使用者は @file{CVSROOT/passwd} 
11787: に存在している必要があります。既定値は @samp{yes} です。pserver につい
11788: ては、@ref{Password authenticated} を参照してください。
11789: 
11790: @cindex PreservePermissions, in CVSROOT/config
11791: @item PreservePermissions=@var{value}
11792: リポジトリでの、特別なデバイスファイル、シンボリック・リンク、ファイル
11793: 仕様許可、所有権に関する機能を使用可にします。既定値は @samp{no} です。
11794: このキーワード使用の完全な意味は @xref{Special Files}.
11795: 
11796: @cindex TopLevelAdmin, in CVSROOT/config
11797: @item TopLevelAdmin=@var{value}
11798: @samp{checkout} コマンドが取り出されたディレクトリ中に作成される 
11799: @samp{CVS} に加えて、新しい作業ディレクトリの最上位にも @file{CVS} ディ
11800: レクトリを作成するように修正します。既定値は @samp{no} です。
11801: 
11802: このオプションは、取り出されたサブディレクトリではなく、最上位のディレ
11803: クトリで多くのコマンドを実行するときに便利です。そこに作成される
11804: @file{CVS} ディレクトリにより、それぞれのコマンドに @code{CVSROOT} を
11805: 指定する必要がなくなります。@file{CVS/Template} ファイルの場所も提供し
11806: ます (@pxref{Working directory storage})。
11807: 
11808: @cindex LockDir, in CVSROOT/config
11809: @item LockDir=@var{directory}
11810: CVS ロックファイルをリポジトリ中のディレクトリでなく、@var{directory}
11811: に置きます。これは使用者にリポジトリから読み込みをさせたいけれど、リポ
11812: ジトリには書き込み許可を与えたくなく、@var{directory} ディレクトリのみ
11813: に書き込み許可を与えたいときに便利です。@var{directory} は作成する必要
11814: がありますが、必要ならば CVS は @var{directory} のサブディレクトリを作
11815: 成します。CVS のロックに関する情報は @ref{Concurrency} を参照してくだ
11816: さい。
11817: 
11818: @c Mention this in Compatibility section?
11819: LockDir オプションを使用可にする前に、CVS 1.9 やそれ以前のもののコピー
11820: を追跡して消去したことを確認してください。そのようなバージョンは
11821: LockDir をサポートしていませんし、それをサポートしていないというエラー
11822: を出すこともありません。結果として、もしこのようなことが起こってしまえ
11823: ば、CVS の何人かの使用者はある場所にロックを置き、他は別の場所に置くと
11824: いうことになり、リポジトリが壊れてしまう可能性があります。CVS 1.10 は
11825: LockDir をサポートしていませんが、LockDir が使用されているリポジトリで
11826: 実行されると警告を印字します。
11827: @end table
11828: 
11829: @c ---------------------------------------------------------------------
11830: @node Environment variables
11831: @appendix CVS に影響する全ての環境変数
11832: @cindex Environment variables
11833: @cindex Reference manual for variables
11834: 
11835: これは、@sc{cvs} に影響する全ての環境変数の
11836: 完全なリストです。
11837: 
11838: @table @code
11839: @cindex CVSIGNORE, environment variable
11840: @item $CVSIGNORE
11841: @sc{cvs} が無視するファイル名を、
11842: 空白で区切ったリストです。@xref{cvsignore}.
11843: 
11844: @cindex CVSWRAPPERS, environment variable
11845: @item $CVSWRAPPERS
11846: @sc{cvs} が wrapper として扱うファイル名形式を
11847: 空白で区切ったリストです。@xref{Wrappers}.
11848: 
11849: @cindex CVSREAD, environment variable
11850: @cindex Read-only files, and CVSREAD
11851: @item $CVSREAD
11852: この変数が設定されていると、
11853: @code{checkout} と @code{update} により作成される作業コピーが、
11854: 強制的に読み込み専用となります。
11855: 設定しなければ、作業ファイルの修正許可が与えられます。
11856: 
11857: @item $CVSUMASK
11858: リポジトリのファイルの使用許可を制御します。@ref{File permissions} を
11859: 参照してください。
11860: 
11861: @item $CVSROOT
11862: (@sc{rcs} のファイルが置かれる) 
11863: @sc{cvs} のリポジトリのルート・ディレクトリを、
11864: 絶対パスで指定しなければいけません。
11865: @sc{cvs} の大部分のコマンドを実行するときに、
11866: この情報が利用されます。
11867: @code{$CVSROOT} が設定されていない場合や、
11868: 他のものを優先させたい場合には、
11869: コマンド行で @samp{cvs -d cvsroot cvs_command@dots{}} 
11870: としてリポジトリを指定することができます。
11871: 一旦作業ディレクトリを取り出した後は、
11872: @sc{cvs} が適切なリポジトリを (@file{CVS/Root} に) 記録します。
11873: 従って、最初に作業ディレクトリを取り出す時を除いて、
11874: 通常はこの値に注意する必要はありません。
11875: 
11876: @item $EDITOR
11877: @itemx $CVSEDITOR
11878: @itemx $VISUAL
11879: 格納時のログ・メッセージを記録する際に、使用するプログラムを指定します。
11880: @code{$CVSEDITOR} は @code{$EDITOR} よりも優先されます。
11881: @ref{Committing your changes} を参照してください。
11882: 
11883: @cindex PATH, environment variable
11884: @item $PATH
11885: @code{$RCSBIN} が設定されておらず、
11886: @sc{cvs} にパス名が埋め込まれていない場合、
11887: 使用する全てのプログラムを捜す時に @code{$PATH} が使用されます。
11888: 
11889: @cindex HOME, environment variable
11890: @item $HOME
11891: @cindex HOMEPATH, environment variable
11892: @item $HOMEPATH
11893: @cindex HOMEDRIVE, environment variable
11894: @item $HOMEDRIVE
11895: これを使用して、@file{.cvsrc} やそのような他のファイルが置かれたディレ
11896: クトリを捜します。Unix では、CVS は @code{HOME} だけを調べます。
11897: Windows NT では、システムは @code{HOMEDRIVE} を例えば @samp{d:} に、
11898: @code{HOMEPATH} を例えば @file{\joe} に設定します。Windows 95 ではおそ
11899: らく自分自身で @code{HOMEDRIVE}と @code{HOMEPATH} を設定する必要がある
11900: でしょう。
11901: @c We are being vague about whether HOME works on
11902: @c Windows; see long comment in windows-NT/filesubr.c.
11903: 
11904: @cindex CVS_RSH, environment variable
11905: @item $CVS_RSH
11906: 接続経路に @code{:ext:} が指定された時、
11907: @sc{cvs} が接続に使用する外部プログラムを
11908: 指定します。@pxref{Connecting via rsh}。
11909: 
11910: @item $CVS_SERVER
11911: @sc{rsh} を用いたクライアント/サーバ・モードで、
11912: 別のマシンのリポジトリを利用する時に使用されます。
11913: @sc{rsh} を用いて別のマシンのリポジトリを利用する時に、
11914: サーバ側で起動するプログラムの名前を指定します。
11915: 既定値は @code{cvs} です。@pxref{Connecting via rsh}。
11916: 
11917: @item $CVS_PASSFILE
11918: クライアント/サーバ・モードで、
11919: @samp{cvs login @var{server}} が実行された時に使用されます。
11920: 既定値は @file{$HOME/.cvspass} です。
11921: @pxref{Password authentication client}。
11922: 
11923: @item $CVS_CLIENT_PORT
11924: ケルベロスを用いたクライアント/サーバ・モードで
11925: 使用されます。@pxref{Kerberos authenticated}。
11926: 
11927: @cindex CVS_RCMD_PORT, environment variable
11928: @item $CVS_RCMD_PORT
11929: クライアント/サーバ・モードで使用されます。
11930: これを設定した場合、サーバの @sc{rcmd} デーモンを利用する時に、
11931: ここで指定したポート番号が使用されます。
11932: (現在 @sc{unix} クライアントでは使用されません)。
11933: 
11934: @cindex CVS_CLIENT_LOG, environment variable
11935: @item $CVS_CLIENT_LOG
11936: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11937: これを設定した場合、
11938: サーバに送られた全てが @file{@code{$CVS_CLIENT_LOG}.in} に記録され、
11939: サーバから送られた全てが @file{@code{$CVS_CLIENT_LOG}.out} に
11940: 記録されます。
11941: 
11942: @cindex CVS_SERVER_SLEEP, environment variable
11943: @item $CVS_SERVER_SLEEP
11944: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11945: これを設定して、子プロセスを起動する前に指定した秒数を待ち、
11946: デバッガを応答させます。
11947: 
11948: @cindex CVS_IGNORE_REMOTE_ROOT, environment variable
11949: @item $CVS_IGNORE_REMOTE_ROOT
11950: @sc{cvs} 1.10 以前では、この変数を設定すると、@samp{-d} 広域オプション
11951: が指定されているときに @file{CVS/Root} を上書きするのを抑制することが
11952: できました。後のバージョンの @sc{cvs} は @file{CVS/Root} を再書き込み
11953: しませんので、@code{CVS_IGNORE_REMOTE_ROOT} は効果はありません。
11954: 
11955: @cindex COMSPEC, environment variable
11956: @item $COMSPEC
11957: OS/2 だけで使用されます。コマンド解釈プログラムを指定します。
11958: 既定値は @sc{cmd.exe} です。
11959: 
11960: @cindex TMPDIR, environment variable
11961: @item $TMPDIR
11962: @cindex TMP, environment variable
11963: @itemx $TMP
11964: @cindex TEMP, environment variable
11965: @itemx $TEMP
11966: @cindex Temporary files, location of
11967: @c This is quite nuts.  We don't talk about tempnam
11968: @c or mkstemp which we sometimes use.  The discussion
11969: @c of "Global options" is semi-incoherent.
11970: @c I'm not even sure those are the only inaccuracies.
11971: @c Furthermore, the conventions are
11972: @c pretty crazy and they should be simplified.
11973: 一時ファイルが置かれるディレクトリを指定します。
11974: @sc{cvs} サーバは @code{TMPDIR} を使用します。
11975: この指定方法は、@ref{Global options} 参照。
11976: @sc{cvs} には、(システムが提供する @code{_tmpnam} 関数経由で) 
11977: 常に @file{/tmp} を使用する部分があります。
11978: 
11979: Windows NT では (システムが提供する @code{_tempnam} 関数経由で)、
11980: @code{TMP} が使用されます。
11981: 
11982: @sc{cvs} のクライアントが用いる @code{patch} プログラムは、
11983: @code{TMPDIR} を使用します。
11984: 設定されていない場合、(少なくとも GNU patch 2.1 は) 
11985: @file{/tmp} を使用します。
11986: サーバとクライアントの両方共が @sc{cvs} 1.9.10 以降を実行しているなら、
11987: @sc{cvs} は外部の @code{patch} プログラムを呼び出しません。
11988: @end table
11989: 
11990: @node Compatibility
11991: @appendix CVS のバージョン間の互換性
11992: 
11993: @cindex CVS, versions of
11994: @cindex Versions, of CVS
11995: @cindex Compatibility, between CVS versions
11996: @c We don't mention versions older than CVS 1.3
11997: @c on the theory that it would clutter it up for the vast
11998: @c majority of people, who don't have anything that old.
11999: @c
12000: リポジトリの形式は @sc{cvs} 1.3 から互換です。@sc{cvs} 1.6 以前を使っ
12001: ていて、オプションの開発者間通信機能を使いたいときは、@ref{Watches
12002: Compatibility} を参照してください。
12003: @c If you "cvs rm" and commit using 1.3, then you'll
12004: @c want to run "rcs -sdead <file,v>" on each of the
12005: @c files in the Attic if you then want 1.5 and
12006: @c later to recognize those files as dead (I think the
12007: @c symptom if this is not done is that files reappear
12008: @c in joins).  (Wait: the above will work but really to
12009: @c be strictly correct we should suggest checking
12010: @c in a new revision rather than just changing the
12011: @c state of the head revision, shouldn't we?).
12012: @c The old convert.sh script was for this, but it never
12013: @c did get updated to reflect use of the RCS "dead"
12014: @c state.
12015: @c Note: this is tricky to document without confusing
12016: @c people--need to carefully say what CVS version we
12017: @c are talking about and keep in mind the distinction
12018: @c between a
12019: @c repository created with 1.3 and on which one now
12020: @c uses 1.5+, and a repository on which one wants to
12021: @c use both versions side by side (e.g. during a
12022: @c transition period).
12023: @c Wait, can't CVS just detect the case in which a file
12024: @c is in the Attic but the head revision is not dead?
12025: @c Not sure whether this should produce a warning or
12026: @c something, and probably needs further thought, but
12027: @c it would appear that the situation can be detected.
12028: @c
12029: @c We might want to separate out the 1.3 compatibility
12030: @c section (for repository & working directory) from the
12031: @c rest--that might help avoid confusing people who
12032: @c are upgrading (for example) from 1.6 to 1.8.
12033: @c
12034: @c A minor incompatibility is if a current version of CVS
12035: @c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
12036: @c see this as if there is no tag.  Seems to me this is
12037: @c too obscure to mention.
12038: 
12039: 作業ディレクトリ形式は @sc{cvs} 1.5 から互換です。@sc{cvs} 1.3 と 
12040: @sc{cvs} 1.5 の間で変更されました。@sc{cvs} 1.3 で取り出されたディレク
12041: トリで @sc{cvs} 1.5 か、それより新しいものを実行すると、@sc{cvs} はそ
12042: れを変換しますが、@sc{cvs} 1.3 に戻るためには、新しい作業ディレクトリ
12043: を @sc{cvs} 1.3 で取り出す必要があります。
12044: 
12045: 遠隔プロトコルは @sc{cvs} 1.5 から相互作用可能ですが、それ以前では無理
12046: です (1.5 が遠隔プロトコルのある最初の公的リリースですが、古いバージョ
12047: ンがまだあたりをうろついているかもしれません)。しかし、多くの場合、新
12048: しい機能とバグ修正の利点を得るためにクライアントとサーバの両方を更新す
12049: る必要があります。
12050: 
12051: @c Perhaps should be saying something here about the
12052: @c "D" lines in Entries (written by CVS 1.9; 1.8 and
12053: @c older don't use them).  These are supposed to be
12054: @c compatible in both directions, but I'm not sure
12055: @c they quite are 100%.  One common gripe is if you
12056: @c "rm -r" a directory and 1.9 gets confused, as it
12057: @c still sees it in Entries.  That one is fixed in
12058: @c (say) 1.9.6.  Someone else reported problems with
12059: @c starting with a directory which was checked out with
12060: @c an old version, and then using a new version, and
12061: @c some "D" lines appeared, but not for every
12062: @c directory, causing some directories to be skipped.
12063: @c They weren't sure how to reproduce this, though.
12064: 
12065: @c ---------------------------------------------------------------------
12066: @node Troubleshooting
12067: @appendix 問題の解決
12068: 
12069: @sc{cvs} の使用に問題があれば、この付録が役立つかもしれません。特定の
12070: エラーメッセージが出ているなら、そのメッセージをアルファベット順に探す
12071: ことができます。そうでない場合は、他の問題の章を眺めて説明されているか
12072: どうかを知ることができます。
12073: 
12074: @menu
12075: * Error messages::              CVS のエラーの部分的一覧
12076: * Connection::                  CVS サーバへの接続での問題
12077: * Other problems::              エラーメッセージで既に挙げられていない問題
12078: @end menu
12079: 
12080: @ignore
12081: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
12082: @c @node Bad administrative files
12083: @appendixsec Bad administrative files
12084: 
12085: @c -- Give hints on how to fix them
12086: @end ignore
12087: 
12088: @node Error messages
12089: @appendixsec エラーメッセージの部分的一覧
12090: 
12091: これは @sc{cvs} で起こるかもしれないエラー・メッセージの部分的な一覧で
12092: す。完全な一覧ではありません---@sc{cvs} はたくさん、たくさんのエラー・
12093: メッセージを印字する能力があり、しばしば一部分はオペレーティング・シス
12094: テムにより提供されます。しかし、ここでの意図はよくあるもの、混乱する可
12095: 能性のあるエラー・メッセージの、両方もしくはどちらかにあてはまるものの
12096: 一覧を挙げることです。
12097: 
12098: メッセージはアルファベット順ですが、@samp{cvs update: } のような前置き
12099: の文章は順番にするときには省かれています。
12100: 
12101: この一覧は古いバージョンの @sc{cvs} で印字されるメッセージがある場合も
12102: あります (使用者は特定の時にどのバージョンの @sc{cvs} を使用しているか
12103: を必ずしも知らないというのが理由の一つです)。
12104: @c If we want to start retiring messages, perhaps we
12105: @c should pick a cutoff version (for example, no more
12106: @c messages which are specific to versions before 1.9)
12107: @c and then move the old messages to an "old messages"
12108: @c node rather than deleting them completely.
12109: 
12110: @table @code
12111: @c FIXME: What is the correct way to format a multiline
12112: @c error message here?  Maybe @table is the wrong
12113: @c choice?  Texinfo gurus?
12114: @item cvs @var{command}: authorization failed: server @var{host} rejected access
12115: これは pserver のサーバに接続しようとして、それが特定の理由を教えるこ
12116: となく認証を拒否することを選んだときの一般的な反応です。指定された使用
12117: 者名とパスワードが正しいことと、指定された @code{CVSROOT} が 
12118: @file{inetd.conf} の @samp{--allow-root} で使用可になっているこを確認
12119: してください。
12120: 
12121: @item @var{file}:@var{line}: Assertion '@var{text}' failed
12122: システムによってこのメッセージの正確な形式は異なります。これは 
12123: @sc{cvs} のバグを示し、@ref{BUGS} で説明されているように扱うことができ
12124: ます。
12125: 
12126: @item cvs @var{command}: conflict: removed @var{file} was modified by second party
12127: このメッセージは、あなたがファイルを消去し、誰か別の人がそれを修正した
12128: ということを示します。衝突を解消するために、まず @samp{cvs add
12129: @var{file}} を実行します。それが望まれていれば、他の人々の修正を見てま
12130: だそれを消したいかどうかを決定します。消したくなければ、ここで止めます。
12131: 消去したければ、 @samp{cvs remove @var{file}} を実行して、削除を格納し
12132: ます。
12133: @c Tests conflicts2-142b* in sanity.sh test for this.
12134: 
12135: @item cannot change permissions on temporary directory
12136: @example
12137: Operation not permitted
12138: @end example
12139: このメッセージは、Red Hat Linux 3.0.3 と 4.1 でクライアント/サーバのテ
12140: スト一式を実行しているときいに、再現不可能な方法でときどき発生しました。
12141: 我々は何がそれを起こしたのか、また linux (もしくは、このマシンそのもの!) 
12142: に特有かどうかも分かりません。他の unix でも問題が発生した場合は、おそ
12143: らく @samp{Operation not permitted} は @samp{Not owner} や当のシステム
12144: が unix の @code{EPERM} エラーで使用している他のものになっているでしょ
12145: う。追加の情報があれば、@ref{BUGS} で説明されているように我々に知らせ
12146: てください。もし @sc{cvs} を使用していてこのエラーを経験したときは、そ
12147: れを発生させた操作をもう一度繰り返すとちゃんと動作するでしょう。
12148: 
12149: @item cvs [server aborted]: Cannot check out files into the repository itself
12150: このメッセージの明らかな原因は (特にクライアント/サーバでない @sc{cvs} 
12151: のときは)、@sc{cvs} のルートが例えば @file{/usr/local/cvsroot} で、
12152: @file{/usr/local/cvsroot/test} のようなサブディレクトリにファイルを取
12153: り出そうとしたことです。しかしながら、サーバの一時ディレクトリがルート
12154: のサブディレクトリに設定されている (これも許可されていません) というよ
12155: り微妙な場合もあります。これが問題の原因であるなら、一時ディレクトリを
12156: 別のところに設定してください。例えば、@file{/var/tmp} に。一時ディレク
12157: トリの設定のしかたは、@ref{Environment variables} の @code{TMPDIR} を
12158: 参照してください。
12159: 
12160: @c This has been seen in a variety of tests, including
12161: @c multibranch-2, multibranch-5, and basic1-24-rm-rm,
12162: @c so it doesn't seem particularly specific to any one
12163: @c test.
12164: 
12165: @c For one example see basica-1a10 in the testsuite
12166: @c For another example, "cvs co ." on NT; see comment
12167: @c at windows-NT/filesubr.c (expand_wild).
12168: @c For another example, "cvs co foo/bar" where foo exists.
12169: @item cannot open CVS/Entries for reading: No such file or directory
12170: これは一般的に @sc{cvs} の内部エラーを示し、他の @sc{cvs} のバグと同様
12171: に扱うことがきます (@pxref{BUGS})。たいていの場合、対策があります---正
12172: 確な方法は状況に依りますが、おそらく見付け出すことができるでしょう。
12173: 
12174: @c This is more obscure than it might sound; it only
12175: @c happens if you run "cvs init" from a directory which
12176: @c contains a CVS/Root file at the start.
12177: @item cvs [init aborted]: cannot open CVS/Root: No such file or directory
12178: このメッセージは無害です。もし他のエラーと一緒にでなければ、操作は成功
12179: しています。現在のバージョンの @sc{cvs} では出ないはずですが、@sc{cvs}
12180: 1.9 以前のために説明されています。
12181: 
12182: @item cvs [checkout aborted]: cannot rename file @var{file} to CVS/,,@var{file}: Invalid argument
12183: このメッセージは Solaris 2.5 上での CVS 1.9 でときどき発生することが報
12184: 告されています。原因は不明です。原因についてさらに知っていれば、
12185: @ref{BUGS} で説明されているように我々に知らせてください。
12186: 
12187: @item cvs [@var{command} aborted]: cannot start server via rcmd
12188: この残念ながらあまり詳しくないメッセージは、@sc{cvs} のクライアントを
12189: 実行していてサーバとの接続に問題があったときに @sc{cvs} 1.9 が印字しま
12190: す。現在のバージョンの @sc{cvs} はもっと詳しいエラーメッセージを印字す
12191: るようになっています。クライアントを実行しようとはしていないのにこのメッ
12192: セージが出たときは、おそらく @ref{Repository} で説明されている方法で 
12193: @code{:local:} を指定することを忘れたのでしょう。
12194: 
12195: @item ci: @var{file},v: bad diff output line: Binary files - and /tmp/T2a22651 differ
12196: CVS 1.9 以前は @sc{rcs} が正しくインストールされていないときにバイナリ
12197: ファイルを格納しようとしたときにこのメッセージを印字します。@sc{rcs} 
12198: の配布とともに取得している指示をもう一度読んで、@sc{cvs} 配布の 
12199: @sc{install} ファイルを読んでください。代替法として、@sc{rcs} を経由し
12200: ないで自分自身でファイルを格納する現在のバージョンの @sc{cvs} に変更す
12201: ることもできます。
12202: 
12203: @item cvs checkout: could not check out @var{file}
12204: CVS 1.9 では、これは @code{co} プログラム (@sc{rcs} プログラムの一部で
12205: す) が失敗の値を返したということです。他のエラーメッセージがその前にあ
12206: るはずですが、別のエラーメッセージなしに発生することも確認されており、
12207: 原因はよくわかっていません。現在のバージョンの CVS は @code{co} を実行
12208: しないので、このメッセージが別のエラーメッセージとともに現れなければ、
12209: それは間違いなく CVS のバグです (@pxref{BUGS})。
12210: @c My current suspicion is that the RCS in the rcs (not
12211: @c cvs/winnt/rcs57nt.zip) directory on the _Practical_
12212: @c CD is bad (remains to be confirmed).
12213: @c There is also a report of something which looks
12214: @c very similar on SGI, Irix 5.2, so I dunno.
12215: 
12216: @item cvs [update aborted]: unexpected EOF reading @var{file},v
12217: @samp{EOF in key in RCS file} を参照。
12218: 
12219: @item cvs [login aborted]: could not find out home directory
12220: これはホームデレクトリの位置を特定するために CVS が使用する環境変数を
12221: 設定する必要があるということです。@ref{Environment variables} の 
12222: @code{HOME}, @code{HOMEDRIVE}, @code{HOMEPATH} の議論を参照してくださ
12223: い。
12224: 
12225: @item cvs update: could not merge revision @var{rev} of @var{file}: No such file or directory
12226: CVS 1.9 以前は @code{rcsmerge} プログラムを見つけるときに問題が発生し
12227: たときにこのメッセージを印字します。それが @code{PATH} にあることを確
12228: 認するか、外部 @code{rcsmerge} プログラムを必要としない現在のバージョ
12229: ンの CVS に更新してください。
12230: 
12231: @item cvs [update aborted]: could not patch @var{file}: No such file or directory
12232: これは @code{patch} プログラムの探索に問題があったということです。それ
12233: が @code{PATH} 上にあるとを確認してください。メッセージの外観とは違っ
12234: て、@var{file} を見つけるかどうかについて言っているのでは@emph{ない}こ
12235: とに注意してください。クライアントとサーバが現在のバージョンの 
12236: @sc{cvs} を実行しているなら、外部 patch プログラムは必要ではなく、この
12237: メッセージを見ることはないでしょう。しかし、クライアントかサーバが 
12238: @sc{cvs} 1.9 を実行していれば、@code{patch} が必要です。
12239: 
12240: @item cvs update: could not patch @var{file}; will refetch
12241: これは、何らかの理由により、クライアントはサーバが送った patch を適用
12242: できなかったということです。メッセージは心配するようなものではありませ
12243: ん。これは、patch の適用ができなかったというのはちょっと作業を遅らせる
12244: だけで、@sc{cvs} が実行することには影響しないからです。
12245: @c xref to update output.  Or File status?
12246: @c Or some place else that
12247: @c explains this whole "patch"/P/Needs Patch thing?
12248: 
12249: @item dying gasps from @var{server} unexpected
12250: @sc{cvs} 1.9.18 以前のサーバにはこれを発生する既知のバグがあります。私
12251: は、@samp{-t} 広域オプションを使用しているときに再現可能です。もし興味
12252: があれば、それは Andy Piper の1997年11月4日の src/filesubr.c への変更
12253: で修正されました。このメッセージが出たときは、おそらく失敗した操作をた
12254: だもう一度試すことができます。また、この原因に関して情報を発見したなら、
12255: @ref{BUGS} に書かれているように我々に知らせてください。
12256: 
12257: @item end of file from server (consult above messages if any)
12258: このメッセージの一番多い原因は、外部 @code{rsh} プログラムを使用してい
12259: て、それがエラーを出して終了するというものです。この場合 @code{rsh}
12260: プログラムは、上のメッセージの前にメッセージを印字しているはずです。
12261: @sc{cvs} のクライアントとサーバの設定の情報は @ref{Remote
12262: repositories} を参照してください。
12263: 
12264: @cindex mkmodules
12265: @item cvs commit: Executing 'mkmodules'
12266: これはリポジトリが @sc{cvs} 1.8 より前のバージョンの @sc{cvs} で設定さ
12267: れているということです。@sc{cvs} 1.8 以降を使っていると、上記のメッセー
12268: ジの前に以下のものがでます。
12269: 
12270: @example
12271: cvs commit: Rebuilding administrative file database
12272: @end example
12273: 
12274: 両方のメッセージが表示されれば、データベースは2回再構築されていて、こ
12275: れは不必要ですが、無害です。重複を避けたくて、@sc{cvs} 1.7 以前を使っ
12276: ていないなら、@code{modules} ファイルにある全ての @code{-i mkmodules}
12277: を消してください。@code{modules} ファイルの情報は @ref{modules} を参照
12278: してください。
12279: 
12280: @c This messsage comes from "co", and I believe is
12281: @c possible only with older versions of CVS which call
12282: @c co.  The problem with being able to create the bogus
12283: @c RCS file still exists, though (and I think maybe
12284: @c there is a different symptom(s) now).
12285: @c FIXME: Would be nice to have a more exact wording
12286: @c for this message.
12287: @item missing author
12288: 普通これは使用者名が空の RCS ファイルを作成したときに発生します。CVS
12289: は、間違って author 部分に値のない不正な RCS ファイルを作成します。解
12290: 決策は、使用者名が空でないことを確認して、RCS フィルを再作成することで
12291: す。
12292: @c "make sure your username is set" is complicated in
12293: @c and of itself, as there are the environment
12294: @c variables the system login name, &c, and it depends
12295: @c on the version of CVS.
12296: 
12297: @item *PANIC* administration files missing
12298: これは普通は CVS という名前のディレクトリがあるけれど、CVS が CVS ディ
12299: レクトリに置く管理ファイルがないということです。もし問題が CVS 以外の
12300: 何らかの機構で CVS ディレクトリを作ったというものであれば、CVS 以外の
12301: 名前を使ってください。もしそうでなければ、それは CVS のバグを示してい
12302: ます (@pxref{BUGS})。
12303: 
12304: @item rcs error: Unknown option: -x,v/
12305: このメッセージの後には @sc{rcs} の使用法のメッセージが続きます。それは
12306: 古いバージョンの @sc{rcs} (おそらくオペレーティングシステムと共に提供
12307: されたものでしょう) があるということです。CVS は @sc{rcs} バージョン 5
12308: 以降でのみ動作します。
12309: @c For more information on installing @sc{cvs}, see
12310: @c (FIXME: where?  it depends on whether you are
12311: @c getting binaries or sources or what).
12312: @c The message can also say "ci error" or something
12313: @c instead of "rcs error", I suspect.
12314: 
12315: @item cvs [server aborted]: received broken pipe signal
12316: これは、@sc{cvs} かそれが実行されているシステムの追跡が困難なバグ (良
12317: く判っていません---我々はまだ追いかけていません!) により発生するようで
12318: す。@sc{cvs} コマンドが完了した後でのみ発生するようで、メッセージは無
12319: 視できます。しかしながら、その原因に関する情報を発見したなら、
12320: @ref{BUGS} で説明されているように我々に知らせてください。
12321: 
12322: @item Too many arguments!
12323: このメッセージは普通は @sc{cvs} のソース配布の @file{contrib} ディレク
12324: トリにある @file{log.pl} スクリプトにより印字されます。@sc{cvs} のバー
12325: ジョンには、@file{log.pl} が既定の @sc{cvs} インストールに含まれている
12326: ものもあります。@file{log.pl} スクリプトは @file{loginfo} 管理ファイル
12327: から呼ばれます。@file{loginfo} で渡されている引数があなたのバージョン
12328: の @file{log.pl} が期待するものとあっているか調べてください。特に、
12329: @sc{cvs} 1.3 以前の @file{log.pl} はログファイルを引数として期待します
12330: が、@sc{cvs} 1.5 以降の @file{log.pl} はログファイルは @samp{-f} オプ
12331: ションで指定されることを期待します。もちろん、@file{log.pl} が必要でな
12332: ければ、@file{loginfo} 中で註釈にして、使用しないようにすることができ
12333: ます。
12334: 
12335: @item cvs [login aborted]: unrecognized auth response from @var{server}
12336: このメッセージは普通はサーバが適切に設定されていないことを意味します。
12337: 例えば、@file{inetd.conf} が存在しない cvs 実行ファイルを指していると
12338: きです。これをデバッグするためには、inetd が書くログファイル
12339: (@file{/var/log/messages} やあなたのシステムの inetd が使うその他のも
12340: の) を見つけてください。詳細は @ref{Connection} と @ref{Password
12341: authentication server} 参照。
12342: 
12343: @item cvs commit: Up-to-date check failed for `@var{file}'
12344: これはあなたが最後に @code{cvs update} を実行した後に誰かが変更を格納
12345: したということです。ですから、@code{cvs commit} を継続する前に 
12346: @code{cvs update} をする必要があります。CVS はあなたのした変更と他の人
12347: がした変更をマージします。衝突が発見されなれば、@samp{M cacErrCodes.h} 
12348: のように報告され、@code{cvs commit} を実行する準備が整っています。もし
12349: 衝突が発見されれば、その由を印字し、@samp{C cacErrCodes.h} と報告され、
12350: 手で衝突を解消する必要があります。この過程の詳細は @ref{Conflicts
12351: example} を参照してください。
12352: 
12353: @item Usage:	diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
12354: @example
12355: Only one of [exEX3] allowed
12356: @end example
12357: これは @code{diff3} と @code{rcsmerge} のインストールに問題があること
12358: を示しています。特に @code{rcsmerge} は GNU diff3 を探すようにコンパイ
12359: ルされているけれど、代わりに unix の diff3 が使われています。一番簡単
12360: な解決法は外部の @code{rcsmerge} や @code{diff3} プログラムに頼らない
12361: 現在のバージョンの @sc{cvs} に更新することです。
12362: 
12363: @item warning: unrecognized response `@var{text}' from cvs server
12364: もし @var{text} が有効な応答 (@samp{ok} のようなもの) で、続きに余分な
12365: キャリッジリターンがあると (多くのシステムではこれはメッセージの2番目
12366: の部分が1番目の部分を上書きします)、おそらく、既定では透過的なデータス
12367: トリームを提供しない、多くの unix でない rsh のバージョンで 
12368: @samp{:ext:} 接続方法を使用としているのでしょう。その様な場合はたぶん 
12369: @samp{:ext:} の代わりに @samp{:server:} を試みるのが良いでしょう。
12370: @var{text} が何か他のものなら、CVS サーバに問題があることを表します。
12371: CVS サーバを設定するための指示を見てインストールを再度確認してください。
12372: 
12373: @item cvs commit: [@var{time}] waiting for @var{user}'s lock in @var{directory}
12374: これは普通のメッセージであり、エラーではありません。詳細は
12375: @ref{Concurrency} 参照。
12376: 
12377: @item cvs commit: warning: editor session failed
12378: @cindex Exit status, of editor
12379: これは @sc{cvs} が使用しているエディタが非零の値で終了したということで
12380: す。vi のバージョンにはファイルの編集に問題がなかったときでさえそうす
12381: るものがあります。もしそうなら、環境変数 @code{CVSEDITOR} を以下のよう
12382: な小さなスクリプトを指すようにしてください:
12383: 
12384: @example
12385: #!/bin/sh
12386: vi $*
12387: exit 0
12388: @end example
12389: 
12390: @c "warning: foo was lost" and "no longer pertinent" (both normal).
12391: @c Would be nice to write these up--they are
12392: @c potentially confusing for the new user.
12393: @end table
12394: 
12395: @node Connection
12396: @appendixsec CVS サーバに接続をしようとするときの問題
12397: 
12398: この章は @sc{cvs} サーバに接続しようとしたときに問題が起こったときに何
12399: をすれば良いかということを書いています。 Windows で @sc{cvs} コマンド
12400: ライン・クライアントを実行しているなら、まず @sc{cvs} 1.9.12 以降に更
12401: 新してください。以前のバージョンのエラー報告は、問題がどうであったかに
12402: ついて、ほとんど情報を提供しません。クライアントが Windows でなければ、
12403: @sc{cvs} 1.9 は問題ありません。
12404: 
12405: 問題を追いかけるためにエラー・メッセージが十分でなければ、次の手段は使
12406: 用している接続方法によってかなり異なります。
12407: 
12408: @table @code
12409: @cindex :ext:, troubleshooting
12410: @item :ext:
12411: コマンド行からの rsh プログラムの実行を試してください。例えば: "rsh
12412: servername cvs -v" は @sc{cvs} のバージョン情報を印字します。もしこれ
12413: が動作しなければ、@sc{cvs} の問題を気にする前にそれを修正する必要があ
12414: ります。
12415: 
12416: @cindex :server:, troubleshooting
12417: @item :server:
12418: この接続方法を使用するためにコマンド行の rsh プログラムは必要ではあり
12419: ませんが、rsh プログラムがあれば、デバッグ道具として役に立つでしょう。:
12420: ext: のところの指示に従ってください。
12421: 
12422: @cindex :pserver:, troubleshooting
12423: @item :pserver:
12424: 良いデバッグ道具は "telnet servername 2401" です。接続後、任意のテキス
12425: ト (例えば、"foo" リターン)。@sc{cvs} が正しく動作していれば、以下のよ
12426: うに反応するはずです。
12427: 
12428: @example
12429: cvs [pserver aborted]: bad auth protocol start: foo
12430: @end example
12431: 
12432: これの動作に失敗すれば、inetd が正しく動作しているか確認してください。
12433: @file{inetd.conf} での起動を cvs の代わりに echo プログラムに変更して
12434: ください。例えば:
12435: 
12436: @example
12437: 2401  stream  tcp  nowait  root /bin/echo echo hello
12438: @end example
12439: 
12440: その変更をして、inetd に設定ファイルを再読み込みするように指示した後で
12441: は、"telnet servername 2401" はテキスト hello を表示して、サーバが接続
12442: を切るはずです。これが動作しなければ、@sc{cvs} の問題を気にする前にそ
12443: れを修正してください。
12444: 
12445: AIX システムでは、システムにポート 2401 を使おうとするプログラムがあり
12446: ます。これは、ポート 2401 は @sc{cvs} での使用に登録されているという点
12447: で AIX の問題です。この問題を解決するために AIX のパッチがあるというこ
12448: とを聞いたことがあります。
12449: 
12450: 他の良いデバッグツールは inetd に @samp{-d} (debugging) オプションを付
12451: けることです。詳しい情報はシステムの説明文書を調べてください。
12452: 
12453: 接続はできているようですが、次のようなエラーが出る場合は:
12454: 
12455: @example
12456: cvs server: cannot open /root/.cvsignore: Permission denied
12457: cvs [server aborted]: can't chdir(/root): Permission denied
12458: @end example
12459: 
12460: @file{inetd.conf} で @samp{-f} を指定しなかったか、inetd により実行さ
12461: れているプログラムの @code{HOME} 環境変数をシステムが設定しているとい
12462: うことです。後者の場合は、 inetd に @code{HOME} を未設定にして 
12463: @sc{cvs} を実行するシェルスクリプトを実行させるようにするか、@sc{cvs}
12464: を純粋な環境で実行するために @code{env} を使うことができます。
12465: @end table
12466: 
12467: @node Other problems
12468: @appendixsec 他のよくある問題
12469: 
12470: これは上の分類には合わない問題の一覧です。順番には特に意味はありません。
12471: 
12472: @itemize @bullet
12473: @item
12474: Windows で、@sc{cvs} コマンドを実行したときに30秒くらいの遅れがあると
12475: きは、ホームディレクトリが例えば @file{C:/} に設定されているということ
12476: かもしれません (@ref{Environment variables}の @code{HOMEDRIVE} と
12477: @code{HOMEPATH} 参照)。 CVS はホームディレクトリがスラッシュで終わらな
12478: いことを期待しています。例えば、@file{C:} や @file{C:\cvcs} です。
12479: @c FIXCVS: CVS should at least detect this and print an
12480: @c error, presumably.
12481: 
12482: @item
12483: @sc{cvs} 1.9.18 以前を実行していて、@ref{Conflicts example} で説明され
12484: ているように、@code{cvs update} が衝突を発見し、マージを試みたけれど、
12485: 衝突があることを報告しなかったら、@sc{rcs} の古いバージョンが存在しま
12486: す。一番簡単な解決は、おそらく外部 @sc{rcs} プログラムを使用しない現在
12487: のバージョンの @sc{cvs} に変更することです。
12488: @end itemize
12489: 
12490: @c ---------------------------------------------------------------------
12491: @node Credits
12492: @appendix Credits
12493: 
12494: @cindex Contributors (manual)
12495: @cindex Credits (manual)
12496: 当時 Cygnus Support にいた Roland Pesch <@t{roland@@wrs.com}> 
12497: は @sc{cvs} 1.3 とともに頒布されたマニュアルを書きました。
12498: 記述の多くは、彼の文章から受け継いでいます。
12499: また彼にこのマニュアルの初期の草稿を読んでもらい、
12500: 多くのアイディアと訂正を頂きました。
12501: 
12502: メーリング・リスト @code{info-cvs} も時には有益でした。
12503: 私は以下の人物が行なった投稿による情報を含めました:
12504: David G. Grubbs <@t{dgg@@think.com}>.
12505: 
12506: @sc{rcs} の man からいくつか文章を引用しています。
12507: 
12508: David G. Grubbs 氏による @sc{cvs} @sc{faq} は、
12509: 有用な素地を与えてくれました。
12510: @sc{faq} はもうメンテナンスされていませんが、
12511: このマニュアルが (少くとも @sc{cvs} の使用方法の文書化に関して)、
12512: その後継に最も近いものでしょう。
12513: 
12514: また、次に挙げる人物が、私の誤りを訂正してくれました:
12515: 
12516: @display
12517: Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
12518: Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
12519: Karl Pingle <@t{pingle@@acuson.com}>,
12520: Thomas A Peterson <@t{tap@@src.honeywell.com}>,
12521: Inge Wallin <@t{ingwa@@signum.se}>,
12522: Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>,
12523: Michael Brown <@t{brown@@wi.extrel.com}>.
12524: @end display
12525: 
12526: ここの貢献者の一覧は包括的なものであはありません。このマニュアルへの貢
12527: 献者のより完全な一覧は @sc{cvs} のソース配布のファイル 
12528: @file{doc/ChangeLog} を見てください。
12529: 
12530: @c ---------------------------------------------------------------------
12531: @node BUGS
12532: @appendix CVS かこのマニュアルのバグに対処する
12533: 
12534: @cindex Bugs in this manual or CVS
12535: @sc{cvs} もこのマニュアルも完璧ではなく、また永遠にそうならないでしょ
12536: う。@sc{cvs} を使用していて問題にぶつかったり、バグを見つけたと思った
12537: りしたときは、いろいろな方法があります。また、マニュアルにはっきりしな
12538: いところがあれば、マニュアルのバグと考えられますので、これらの問題も 
12539: @sc{cvs} 自身の問題と同様に行動をするに値します。
12540: 
12541: @cindex Reporting bugs
12542: @cindex Bugs, reporting
12543: @cindex Errors, reporting
12544: @itemize @bullet
12545: @item
12546: 報告したバグを誰かに修正して欲しい場合は、代金と交換にしてくれる会社が
12547: あります。そのような会社は2つあります:
12548: 
12549: @cindex Signum Support
12550: @cindex Cyclic Software
12551: @cindex Support, getting CVS support
12552: @example
12553: Signum Support AB
12554: Box 2044
12555: S-580 02  Linkoping
12556: Sweden
12557: Email: info@@signum.se
12558: Phone: +46 (0)13 - 21 46 00
12559: Fax:   +46 (0)13 - 21 47 00
12560: http://www.signum.se/
12561: 
12562: Cyclic Software
12563: United States of America
12564: http://www.cyclic.com/
12565: info@@cyclic.com
12566: @end example
12567: 
12568: @item
12569: @sc{cvs} をオペレーティング・システムのベンダーやフリーウェアの 
12570: @sc{cd-rom} のベンダーのような配布者から取得していれば、配布者がサポー
12571: トを提供しているかどうかを知りたいでしょう。しばしば、サポートしなかっ
12572: たり、最小限のサポートしか提供しないかもしれませんが、それは配布者によっ
12573: て異なります。
12574: 
12575: @item
12576: もし十分な技能と時間があれば、バグを自分自身で修正しようと思うでしょう。
12577: その修正を将来の @sc{cvs} のリリース含めたいときは、@sc{cvs} のソース
12578: 配布にあるファイル @sc{hacking} を見てください。修正の提出方法に関する
12579: たくさんの情報があります。
12580: 
12581: @item
12582: ネット上に助けになるリソースがあるかもしれません。以下の2つは開始する
12583: 良い場所です:
12584: 
12585: @example
12586: http://www.cyclic.com
12587: http://www.loria.fr/~molli/cvs-index.html
12588: @end example
12589: 
12590: もし非常にやる気になれば、ネット上での情報を増やすと感謝される可能性が
12591: 高いでしょう。例えば、標準の @sc{cvs} 配布が Windows 95 について作業を
12592: する前に、@sc{cvs} を Windows 95 で実行するための説明とパッチのあるウェ
12593: ブページがあり、色々な人がその題がメーリングリストやニュースグループで
12594: 出る度にそのページを知らせることで手助けをしていました。
12595: 
12596: 訳註: 日本語のウェブページは以下のものが良いでしょう。
12597: 
12598: @example
12599: http://www.cyclic.com/cvs/lang-jp.html
12600: http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
12601: @end example
12602: 
12603: @item
12604: バグを @code{bug-cvs} に報告することもできます。誰かがあなたのバグ報告
12605: に対して何かをしようと思うかもしれないし、思わないかもしれない、という
12606: ことに注意してください---もし解決策が必要なら、上の方法のどれかを考慮
12607: してください。ですが、おそらく人々は特に大変な結果になるバグと、簡単に
12608: 修正できるバグの両方、もしくはどちらかに該当するもに関心があるでしょう。
12609: また、バグの本質と他の関係する情報を明確にすることで可能性を高めるこが
12610: できます。バグを報告するためには @code{bug-cvs@@gnu.org} に email を送
12611: ります。@code{bug-cvs} へ送ったものは @sc{gnu} Public License の条件の
12612: 下で配布されるかもしれないことに注意してください。もしこれを好まなけれ
12613: ば、送らないでください。普通は、メールを @code{bug-cvs} ではなく、
12614: @sc{cvs} の管理者に直接送ることの正当性はありません。そのようなバグ報
12615: 告に関心のある管理者は @code{bug-cvs} を読んできます。また、バグ報告を
12616: 他のメーリングリストやニュースグループに送ることは @code{bug-cvs} へ送
12617: る代わりには@emph{ならない}ということにも注意してださい。@sc{cvs} のバ
12618: グをどの場所でも好きなところで議論するのは良いことですが、
12619: @code{bug-cvs} 以外に送られたバグ報告を管理者の誰かが読んでいるとは限
12620: りません。
12621: @end itemize
12622: 
12623: @cindex Known bugs in this manual or CVS
12624: 結構頻繁に、既知のバグの一覧や特定のバグが知られたものかどうかの一覧が
12625: あるかどうかを尋ねられます。@sc{cvs} のソース配布の @sc{bugs} ファイル
12626: は既知のバグのリストの一つですが、必ずしも包括的なものであろうとはして
12627: いません。おそらく、既知のバグの包括的な、詳細な一覧は存在することはな
12628: いでしょう。
12629: 
12630: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
12631: @node Translation
12632: @appendix 日本語訳について
12633: 
12634: この @sc{cvs} のマニュアルは、
12635: @sc{cvs} @value{CVSVN} に付属していた、
12636: @file{cvs.texinfo} を日本語訳したものです。
12637: 文書の構造やノード名等は(この節を除いて)そのまま使用しており、
12638: 文章は自分に可能な限り忠実に訳しています。
12639: 修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。
12640: 
12641: @flushright
12642: 廣保 誠 <@t{hiroyasu@@iedc.mke.mei.co.jp}>
12643: @end flushright
12644: 
12645: @unnumberedsubsec 訳者からの謝辞
12646: 
12647: 大阪大学の西田圭介さんが、引地夫妻に問い合わせてこの文書の
12648: 配布条件の推奨訳を入手したり、一部の下訳を送ってくれたりしました。
12649: また @sc{cvs} について日本語で情報交換するためのメーリング・
12650: リストを立ち上げました。現在このメーリング・リストは
12651: 京都工芸繊維大学の西本卓也さんが引き継いでいます。
12652: 詳細は @file{http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html} 
12653: を参照して下さい。@sc{cvs} 1.9 から @sc{cvs} @value{CVSVN} への更新は
12654: 林芳樹 <t90553@@mail.ecc.u-tokyo.ac.jp> が行いました。
12655: 
12656: @unnumberedsubsec 日本語訳の配布条件
12657: 
12658: この文書を修正・再配布する場合には、
12659: 原英文の配布条件に従って下さい。
12660: 以下に許諾文の参考訳を付けます。
12661: 
12662: Copyright @copyright{} 1992, 1993 Signum Support AB
12663: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
12664: 
12665: 上記の著作権表示と本許可告知が
12666: すべての写しに前もって載せられている場合にのみ、
12667: 本マニュアルをそのまま複写し配布することを許可します。
12668: 
12669: @ignore
12670: TeX による処理結果に本複写許可告知と同一のものが載せられている場合にのみ、
12671: 本マニュアルのファイルを TeX により出力することを許可します。
12672: (ただし、本段落は TeX の処理結果には表れませんので、
12673: 実際の出力物に本段落は削除されることを除きます。)
12674: 
12675: @end ignore
12676: 本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件の
12677: もとに配布される場合にのみ許可します。
12678: 
12679: 本マニュアルの外国語 (英語以外の言語) への翻訳版の複写と配布は、
12680: 上記の修正版の場合に準じますが、
12681: 本許可告知は Free Software Foundation の許可を得た
12682: 翻訳でなければなりません。
12683: 
12684: @c ---------------------------------------------------------------------
12685: @node Index
12686: @unnumbered Index
12687: @cindex Index
12688: 
12689: @printindex cp
12690: 
12691: @summarycontents
12692: 
12693: @contents
12694: 
12695: @bye
12696: 
12697: Local Variables:
12698: fill-column: 70
12699: End:

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>