File:  [Local Repository] / gnujdoc / cvs-1.10 / cvs-ja.texinfo
Revision 1.5: download - view: text, annotated - select for diffs
Wed Jun 9 11:00:16 1999 UTC (21 years, 6 months ago) by hayashi
Branches: MAIN
CVS tags: HEAD
Fix typo

    1: \input texinfo  @c -*-texinfo-*-
    2: @comment Documentation for CVS.
    3: @comment Copyright (C) 1992, 1993 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 1, 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 (according to
   33: @c an internet draft by Jacob Palme).
   34: 
   35: @c This document seems to get overfull hboxes with some
   36: @c frequency (probably because the tendency is to
   37: @c sanity-check it with "make info" and run TeX less
   38: @c often).  The big ugly boxes just seem to add insult
   39: @c to injury, and I'm not aware of them helping to fix
   40: @c the overfull hboxes at all.
   41: @finalout
   42: 
   43: @setfilename cvs-ja.info
   44: @include CVSvn.texi
   45: @settitle CVS---Concurrent Versions System (in Japanese)
   46: @setchapternewpage odd
   47: @iftex
   48: @documentlanguage ja
   49: @documentencoding EUC-JP
   50: @end iftex
   51: @c FIXJA
   52: 
   53: @c -- TODO list:
   54: @c -- Fix all lines that match "^@c -- "
   55: @c -- Also places marked with FIXME should be manual
   56: @c problems (as opposed to FIXCVS for CVS problems).
   57: 
   58: @ifinfo
   59: @format
   60: START-INFO-DIR-ENTRY
   61: * CVS-JA: (cvs-ja).        Concurrent Versions System (Japanese)
   62: END-INFO-DIR-ENTRY
   63: @end format
   64: @end ifinfo
   65: 
   66: @ifinfo
   67: Copyright @copyright{} 1992, 1993 Signum Support AB
   68: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
   69: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
   70: Copyright @copyright{} 1999 Yoshiki Hayashi
   71: 
   72: Permission is granted to make and distribute verbatim copies of
   73: this manual provided the copyright notice and this permission notice
   74: are preserved on all copies.
   75: 
   76: @ignore
   77: Permission is granted to process this file through Tex and print the
   78: results, provided the printed document carries copying permission
   79: notice identical to this one except for the removal of this paragraph
   80: (this paragraph not being relevant to the printed manual).
   81: 
   82: @end ignore
   83: Permission is granted to copy and distribute modified versions of this
   84: manual under the conditions for verbatim copying, provided also that the
   85: entire resulting derived work is distributed under the terms of a
   86: permission notice identical to this one.
   87: 
   88: Permission is granted to copy and distribute translations of this manual
   89: into another language, under the above conditions for modified versions,
   90: except that this permission notice may be stated in a translation
   91: approved by the Free Software Foundation.
   92: @end ifinfo
   93: 
   94: @comment The titlepage section does not appear in the Info file.
   95: @titlepage
   96: @sp 4
   97: @comment The title is printed in a large font.
   98: @center @titlefont{CVSによるバージョン管理}
   99: @sp 2
  100: @center Version Management with CVS
  101: @center for @sc{cvs} @value{CVSVN}
  102: @center Per Cederqvist et al
  103: @sp 25
  104: @center 日本語訳 : 廣保 誠, 林 芳樹
  105: 
  106: @comment  The following two commands start the copyright page
  107: @comment  for the printed manual.  This will not appear in the Info file.
  108: @page
  109: @vskip 0pt plus 1filll
  110: Copyright @copyright{} 1992, 1993 Signum Support AB
  111: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
  112: Copyright @copyright{} 1999 Yoshiki Hayashi
  113: 
  114: Permission is granted to make and distribute verbatim copies of
  115: this manual provided the copyright notice and this permission notice
  116: are preserved on all copies.
  117: 
  118: Permission is granted to copy and distribute modified versions of this
  119: manual under the conditions for verbatim copying, provided also that the
  120: entire resulting derived work is distributed under the terms of a
  121: permission notice identical to this one.
  122: 
  123: Permission is granted to copy and distribute translations of this manual
  124: into another language, under the above conditions for modified versions,
  125: except that this permission notice may be stated in a translation
  126: approved by the Free Software Foundation.
  127: @end titlepage
  128: 
  129: @comment ================================================================
  130: @comment                   The real text starts here
  131: @comment ================================================================
  132: 
  133: @ifinfo
  134: @c ---------------------------------------------------------------------
  135: @node    Top
  136: @top CVS 1.10 Japanese Manual
  137: @c Note: there is a space after that @top command.
  138: @c The texinfo-format-buffer Emacs function and
  139: @c the makeinfo shell command disagree on what arguments
  140: @c @top takes; @top followed by a single space is
  141: @c something they can both cope with.
  142: 
  143: この info manual は、
  144: @sc{cvs} version @value{CVSVN}
  145: の使用方法と管理方法について記述します。
  146: @end ifinfo
  147: 
  148: @c This menu is pretty long.  Not sure how easily that
  149: @c can be fixed (no brilliant ideas right away)...
  150: @menu
  151: * Overview::                    CVS への導入
  152: * Repository::                  全てのソースが保存される場所
  153: * Starting a new project::      CVS でプロジェクトを始める
  154: * Revisions::                   リビジョンの数値とシンボルの名前
  155: * Branching and merging::       開発の枝の多様化/再一本化
  156: * Recursive behavior::          CVS はディレクトリを降りていく
  157: * Adding and removing::         ファイル/ディレクトリを加える/取り除
  158:                                 く/名前を変える
  159: * History browsing::            ファイルの履歴をいろいろな方法で閲覧する
  160: 
  161: CVS と現実の世界
  162: -----------------------
  163: * Binary files::                CVS はバイナリ・ファイルを扱うことができる
  164: * Multiple developers::         CVS の開発者グループの援助の仕方
  165: * Revision management::         リビジョン管理のポリシーへの質問
  166: * Keyword substitution::        CVS はファイルの中にリビジョンを含むこ
  167:                                 とができる
  168: * Tracking sources::            サード・パーティーソースの追っかけ
  169: * Builds::                      CVS とコンパイルに関する問題
  170: * Special Files::		デバイス、リンクと他の普通でないファイ
  171:   172: 
  173: リファレンス
  174: -----------
  175: * CVS commands::                CVS の命令は同じものを使う
  176: * Invoking CVS::                CVS の命令の quick reference
  177: * Administrative files::        管理ファイルへのリファレンスマニュアル
  178: * Environment variables::       CVS に影響する全ての環境変数
  179: * Compatibility::               CVS のバージョンを上げる
  180: * Troubleshooting::             動作しないときのいくらかのこつ
  181: * Credits::                     このマニュアルへの貢献者達
  182: * BUGS::                        CVS かこのマニュアルのバグの対処
  183: * 翻訳者より:Translation.       日本語訳について
  184: * Index::                       索引
  185: @end menu
  186: 
  187: @c ---------------------------------------------------------------------
  188: @node Overview
  189: @chapter 概観
  190: @cindex Overview
  191: 
  192: この章は @sc{cvs} を一度も使ったことが無く、おそらく以前にバージョン管
  193: 理ソフトを使ったことの無い人のためのものです。
  194: 
  195: 既に @sc{cvs} に親しんでいて、特定の機能を学んだり、特定の命令を覚えよ
  196: うとしているときは、ここは全て飛ばしてください。
  197: 
  198: @menu
  199: * What is CVS?::                @sc{cvs} で何が出きるか
  200: * What is CVS not?::            @sc{cvs} が解決しようとしない問題
  201: * A sample session::            基本的な @sc{cvs} の利用のツアー
  202: @end menu
  203: 
  204: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  205: @node What is CVS?
  206: @section CVS とは?
  207: @cindex What is CVS?
  208: @cindex Introduction to CVS
  209: @cindex CVS, introduction to
  210: 
  211: @sc{cvs} はバージョン管理システムであり、
  212: あなたのソース・ファイルの変遷を記録するのに使用します。
  213: 
  214: @c -- ///
  215: @c -- ///Those who cannot remember the past are condemned to repeat it.
  216: @c -- ///               -- George Santayana
  217: @c -- //////
  218: 
  219: @c -- Insert history  quote here!
  220: 例えば、ソフトウェアの修正に伴なってバグが入り込み、
  221: 発見されるまでに長い時間がかかったとします。
  222: @sc{cvs} を使っていれば、古いバージョンを簡単に復元し、
  223: バグの原因となった変更点を正確に調べることができます。
  224: この特徴に救われる時が必ずあります。
  225: 
  226: 全てのバージョンの全てのファイルを保存しておくこともできますが、
  227: ディスク容量の無駄使いでしかありません。
  228: @sc{cvs} は、バージョン間の差分のみを保存する方法により、
  229: 各ファイルの全バージョンを一つのファイルに記録します。
  230: 
  231: @sc{cvs} は、複数の開発者が同じソフトウェアに
  232: 取り組む場合に、真価を発揮します。
  233: このような場合にはよほど気を付けていないと、
  234: 他の人が変更したファイルを上書きしてしまいます。
  235: @sc{gnu} Emacs のようなエディタを使えば、
  236: 複数の人が同時に同じファイルを編集することはありません。
  237: しかし不幸なことに、全員が同じエディタを使うとは限りません。
  238: @sc{cvs} は開発者を互いに隔離することにより、この問題を解決しました。
  239: 全ての開発者は自分のディレクトリで作業し、
  240: その仕事を @sc{cvs} が組み合わせます。
  241: 
  242: @cindex History of CVS
  243: @cindex CVS, history of
  244: @cindex Credits (CVS program)
  245: @cindex Contributors (CVS program)
  246: @sc{cvs} は Dick Grune が作成し、
  247: 1986年 12 月に @code{comp.sources.unix} の volume 6 に投稿した、
  248: シェル・スクリプトから始まりました。
  249: 現在の @sc{cvs} は、
  250: これらのシェル・スクリプトのコードを全く含みませんが、
  251: 衝突解決のアルゴリズムの大部分を受け継いでいます。
  252: 
  253: 1989年 4 月に Brian Berliner が @sc{cvs} を設計し、コーディングしました。
  254: その後、Jeff Polk が @sc{cvs} の ベンダー枝とモジュールの設計を助けました。
  255: 
  256: @cindex Source, getting CVS source
  257: @sc{cvs} をインターネットからの自由なダウンロードなど、いろいろな方法
  258: で取得することができます。 @sc{cvs} のダウンロードや、他の @sc{cvs} の
  259: 話題の情報は、以下のところを参照してください。
  260: 
  261: @example
  262: http://www.cyclic.com/
  263: http://www.loria.fr/~molli/cvs-index.html
  264: @end example
  265: 
  266: @cindex Mailing list
  267: @cindex List, mailing list
  268: @cindex Newsgroups
  269: @w{@code{info-cvs}} という @sc{cvs} 専門のメーリング・リストがあります。
  270: @c このメーリング・リストに
  271: 参加、又は脱退したい場合には、
  272: @w{@code{info-cvs-request@@gnu.org}} にメールを出して下さい。
  273: Usenet グループの方を好むのであれば、正しいグループは
  274: @code{comp.software.config-mgmt} で、@sc{cvs} の議論を
  275: するために適した場所です (他の構成管理システムと一緒で
  276: すが)。 将来は @code{comp.software.config-mgmt.cvs} を
  277: 作ることも可能かもしれませんが、おそらく
  278: @code{comp.software.config-mgmt} に十分な流量があるよう
  279: になったときだけでしょう。
  280: @c Other random data is that past attempts to create a
  281: @c gnu.* group have failed (the relevant authorities
  282: @c say they'll do it, but don't), and that tale was very
  283: @c skeptical of comp.software.config-mgmt.cvs when the
  284: @c subject came up around 1995 or so (for one
  285: @c thing, because creating it would be a "reorg" which
  286: @c would need to take a more comprehensive look at the
  287: @c whole comp.software.config-mgmt.* hierarchy).
  288: 
  289: @ref{BUGS} でより詳細に説明されている bug-cvs メーリン
  290: グリストを講読するともできます。講読するためには、
  291: bug-cvs-request@@gnu.org にメールを送ってください。
  292: 
  293: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  294: @node What is CVS not?
  295: @section CVS は何ではない?
  296: @cindex What is CVS not?
  297: 
  298: @sc{cvs} は多くのことができますが、全ての人に全てのことを
  299: するようにはなっていません。
  300: 
  301: @table @asis
  302: @item @sc{cvs} は構築システムではありません。
  303: 
  304: リポジトリと modules ファイルの構造と構築システム (例. 
  305: @file{Makefile}) とは相互作用するかもしれませんが、本質的
  306: に独立したものです。
  307: 
  308: @sc{cvs} は、何かの作り方を指示したりはしません。
  309: @sc{cvs} はあなたの意思に従って、
  310: ツリー構造から望むファイルを取り出すだけです。
  311: 
  312: @sc{cvs} は、@code{checkout} 先の作業ディレクトリのディスク容量の使用
  313: 法について指示したりはしません。あなたが @file{Makefile} やスクリプトを
  314: 全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
  315: るとすると、リポジトリ全てを取り出す必要が生じます。
  316: 
  317: あなたが仕事をモジュール化し、(@file{Makefile} に link,
  318: mount, @code{VPATH}等を使用して、)ファイルを共有するよ
  319: うな構築システムを構成すれば、好きな様にディスクの利用
  320: 法を決めることが出来ます。
  321: 
  322: しかしこれら@emph{全ての}システムは、
  323: 構築と維持に多大な労力が必要なことに、
  324: 気を付けなければいけません。
  325: @sc{cvs} は、このような問題に関して考慮しません。
  326: 
  327: もちろん、これらの構築システムを支援するための道具
  328: (スクリプト, @file{Makefile} 等) は、
  329: @sc{cvs} の管理下に置くと良いでしょう。
  330: 
  331: 何らかの変更があった際に、再構築が必要なファイルを調べるのは、
  332: やはり @sc{cvs} の守備外です。
  333: 伝統的な手法の一例をあげると、
  334: 構築には @code{make} を用い、
  335: @code{make} に必要な依存関係は自動化されたツールを用いて生成します。
  336: 
  337: @sc{cvs} と結合して構築を行うための情報は @ref{Builds}
  338: を参照してください。
  339: 
  340: @item @sc{cvs} は管理者代理ではありません。
  341: 
  342: あなたの管理者や上司は、期日に従っているかどうかや、 
  343: マージ点、枝の名前、リリースの日時等について、
  344: あなたと度々話しあうことを求められています。
  345: 彼等がそうしないなら、@sc{cvs} は役に立ちません。
  346: 
  347: @sc{cvs} は、あなたの調律に従ってソースを踊らせる楽器の
  348: ようなものです。あなたは楽器奏者もしくは作曲者のような
  349: ものです。どんな楽器も勝手に演奏をしたりしないし、音楽
  350: が勝手に書かれたりもしません。
  351: 
  352: @item @sc{cvs} は開発者同士の意志疎通の代用にはなりません。
  353: 
  354: あるファイルに衝突が起きた場合に、
  355: ほとんどの開発者はそれほど苦労せずに解決します。
  356: しかし、@dfn{衝突} (@dfn{conflict})のより一般的な定義には、
  357: 開発者同士の意志疎通なしには解決できない
  358: 困難な問題も含まれます。
  359: 
  360: 同じファイル (もしくはファイルの集合) に、
  361: 同時に加えられた変更に論理的な衝突があっても、
  362: @sc{cvs} には分りません。
  363: @dfn{衝突}という概念は単に文字列の比較によるもので、
  364: 同じファイルを基に加えられた二つの変更が、
  365: @code{merge} コマンド (つまり @code{diff3}) を驚かせるのに
  366: 十分なほど近接している場合にのみ生じます。
  367: 
  368: @sc{cvs} は、
  369: プログラムの論理に、文字列でない衝突や、散らばった衝突
  370: があったとしても、警告を表示しません。
  371: 
  372: 例: 
  373: あなたは @file{A} で定義された関数 @code{X} の引数を変更したとします。
  374: 同じ時に、誰かが @file{B} を編集して、
  375: 古い引数を使って @code{X} を呼び出したとします。
  376: これは @sc{cvs} の能力の範囲外です。
  377: 
  378: 仕様書を読み、同僚と話し合う習慣を付けましょう。
  379: 
  380: 
  381: @item @sc{cvs} は変更管理をしません。
  382: 
  383: 変更管理という言葉は様々な意味を持ちます。
  384: まず@dfn{バグ追跡}と解釈すれば、バグ報告と各バグの状態
  385: (修正されたか? どのリリースか? 報告者は修正を確認したか? )
  386: についてのデータベース管理を意味します。
  387: @sc{cvs} とバグ追跡システムとの連携については、
  388: @file{rcsinfo} と @file{editinfo} ファイルを見て下さい 
  389: (@pxref{Administrative files})。
  390: 
  391: 論理的には一つと考えられる変更のため、
  392: 複数のファイルが同時に変更されたことを覚えておくことも、
  393: 変更管理と呼ばれます。
  394: 複数のファイルの変更を一つの @code{cvs commit} により格納した場合、
  395: @sc{cvs} はそれらのファイルが同時に格納されたことを忘れてしまいます。
  396: そして、それらのファイルを結ぶ事柄は、
  397: 同じログ・メッセージを持つことだけになるのです。
  398: @sc{gnu} 形式の @file{ChangeLog} を用いれば何らかの助けになるでしょう。
  399: @c FIXME: should have an xref to a section which talks
  400: @c more about keeping ChangeLog's with CVS, but that
  401: @c section hasn't been written yet.
  402: 
  403: 各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
  404: 開発者によって加えられた変更もあれば、
  405: 他の開発者によって追試中の変更もあるとか、そういったことです。
  406: 一般的に @sc{cvs} でこのようなことをするには、
  407: (@code{cvs diff} や @code{diff} を用いて) 差分を生成し、
  408: @code{patch} を当てる人物にメールとして送ります。
  409: これは非常に融通のきく方法ですが、
  410: @sc{cvs} 以外の機構に依存しているので、
  411: 問題が無いことを保証できません。
  412: 
  413: @item @sc{cvs} は自動検査プログラムではありません。
  414: 
  415: @code{commitinfo} ファイルを使えば、
  416: 強制的に必須の項目を検査することは可能だと思います。
  417: しかし、
  418: そんなことをしようとしたプロジェクトのことは聞いたことがありません。
  419: 
  420: @item @sc{cvs} は手順規範を備えていません。
  421: 
  422: 変更やリリースに必要とされる色々な手順や多くの承認を、
  423: 確実に行なう方法を備えたシステムもあります。
  424: @sc{cvs} を用いてこれを達成することも可能ですが、
  425: ちょっと面倒だと思います。
  426: 場合によっては、
  427: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{verifymsg} 
  428: 等のファイルを用いて、変更点を格納する前に、
  429: 必要な手順を確実に踏むように設定できるでしょう。
  430: また枝やタグといった機構を用いて、
  431: 開発用の枝で仕事を実行し、
  432: 安定性が証明された確実な変更だけを
  433: 安定化指向の枝に統合することも考えられます。
  434: @end table
  435: 
  436: @c ---------------------------------------------------------------------
  437: @node A sample session
  438: @section 作業例
  439: @cindex Example of a work-session
  440: @cindex Getting started
  441: @cindex Work-session, example of
  442: @cindex tc, Trivial Compiler (example)
  443: @cindex Trivial Compiler (example)
  444: 
  445: @c I think an example is a pretty good way to start.  But
  446: @c somewhere in here, maybe after the sample session,
  447: @c we need something which is kind of
  448: @c a "roadmap" which is more directed at sketching out
  449: @c the functionality of CVS and pointing people to
  450: @c various other parts of the manual.  As it stands now
  451: @c people who read in order get dumped right into all
  452: @c manner of hair regarding remote repositories,
  453: @c creating a repository, etc.
  454: @c
  455: @c The following was in the old Basic concepts node.  I don't
  456: @c know how good a job it does at introducing modules,
  457: @c or whether they need to be introduced so soon, but
  458: @c something of this sort might go into some
  459: @c introductory material somewhere.
  460: @ignore
  461: @cindex Modules (intro)
  462: リポジトリはディレクトリやファイルを含み、
  463: 任意の場所に設定できます。
  464: 複数のディレクトリやファイルから成る単位を、
  465: @dfn{モジュール} (@dfn{modules}) として一括して管理できます 
  466: (@pxref{modules})。
  467: 各モジュールは、
  468: プロジェクト毎に定義するのが普通です。
  469: @end ignore
  470: 
  471: @sc{cvs} を紹介する方法として、@sc{cvs} を使って典型的な仕事をしてみま
  472: す。最初に理解すべきことは @sc{cvs} は全てのファイルを中央に集められた 
  473: @dfn{リポジトリ} (@dfn{repository}) (@pxref{Repository}) に保存すると
  474: いうことです。この節ではリポジトリは準備されていると仮定します。
  475: @c I'm not sure that the sentence concerning the
  476: @c repository quite tells the user what they need to
  477: @c know at this point.  Might need to expand on "centralized"
  478: @c slightly (maybe not here, maybe further down in the example?)
  479: 
  480: あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語
  481: で書かれたファイルでできていて、@file{Makefile} を含んでいるとします。
  482: このコンパイラを @samp{tc} (Trivial Compiler) と呼ぶことにします。そし
  483: て @samp{tc} というモジュール名でリポジトリに登録されています。
  484: 
  485: @menu
  486: * Getting the source::          作業場所の作成
  487: * Committing your changes::     あなたの仕事を他の人が利用可能にする
  488: * Cleaning up::                 お掃除
  489: * Viewing differences::         差分を見る
  490: @end menu
  491: 
  492: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  493: @node Getting the source
  494: @subsection ソースの取得
  495: @cindex Getting the source
  496: @cindex Checking out source
  497: @cindex Fetching source
  498: @cindex Source, getting from CVS
  499: @cindex Checkout, example
  500: 
  501: まず、@samp{tc} のソースの作業コピーを取ってくることから始めましょう。
  502: これには @code{checkout} コマンドを使用します:
  503: 
  504: @example
  505: $ cvs checkout tc
  506: @end example
  507: 
  508: @noindent
  509: とすると @file{tc} という新しい作業ディレクトリが作られ、
  510: その中にソース・ファイルがコピーされます。
  511: 
  512: @example
  513: $ cd tc
  514: $ ls
  515: CVS         Makefile    backend.c   driver.c    frontend.c  parser.c
  516: @end example
  517: 
  518: @file{CVS} というディレクトリは @sc{cvs} が内部的に使用
  519: します。普通はその中にあるどんなファイルでも修正したり
  520: 削除してはいけません。
  521: 
  522: で、あなたの好きなエディタを用いて @file{backend.c} をハックして、
  523: 数時間後にコンパイラの最適化経路を加えたとします。
  524: @sc{rcs} と @sc{sccs} の利用者への注意: 編集したいファ
  525: イルをロックする必要はありません。その説明は、 @xref{Multiple
  526: developers}.
  527: 
  528: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  529: @node Committing your changes
  530: @subsection 変更の格納
  531: @cindex Committing changes
  532: @cindex Log message entry
  533: @cindex CVSEDITOR, environment variable
  534: @cindex EDITOR, environment variable
  535: 
  536: あなたはコンパイラが相変わらずコンパイル可能であることを確認し、
  537: @file{backend.c} の新しいバージョンとすることに決めました。これは新し
  538: い @file{backend.c} をリポジトリに格納し、同じリポジトリを使っている他
  539: の人が使用できるようにします。
  540: 
  541: @example
  542: $ cvs commit backend.c
  543: @end example
  544: 
  545: @noindent
  546: @sc{cvs} はログ・メッセージを記すためにエディタを開きます。
  547: そこで ``Added an optimization pass.'' などと入力し、
  548: 一時ファイルに保存し、エディタを終了します。
  549: 
  550: どのエディタが開かれるかは環境変数 @code{$CVSEDITOR} により決定されま
  551: す。@code{$CVSEDITOR} が設定されておらず、環境変数 @code{$EDITOR} が設
  552: 定されていれば、これを使用します。@code{$CVSEDITOR} と @code{$EDITOR} 
  553: の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
  554: フォルトが使われます。例えば、unix では @code{vi}で、Windows NT/95 で
  555: は @code{notepad} です。
  556: 
  557: @c This probably should go into some new node
  558: @c containing detailed info on the editor, rather than
  559: @c the intro.  In fact, perhaps some of the stuff with
  560: @c CVSEDITOR and -m and so on should too.
  561: @sc{cvs} がエディタを開始したときは、修正されたファイルのリストを含ん
  562: でいます。@sc{cvs} のクライアントでは、このリストはファイルの修正時刻
  563: を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
  564: ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
  565: いないというときも、修正されたものとして表示されます。これに対する最も
  566: 簡単な対処法は単純に気にしないことです---それを commitすると、@sc{cvs} 
  567: は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
  568: す。次の @code{update}はファイルが無修正であるという事実に基づき、将来
  569: のセッションでファイルが表示されないように、タイムスタンプを保存されて
  570: いるものに設定し直します。
  571: @c FIXCVS: Might be nice if "commit" and other commands
  572: @c would reset that timestamp too, but currently commit
  573: @c doesn't.
  574: @c FIXME: Need to talk more about the process of
  575: @c prompting for the log message.  Like show an example
  576: @c of what it pops up in the editor, for example.  Also
  577: @c a discussion of how to get the "a)bort, c)ontinue,
  578: @c e)dit" prompt and what to do with it.  Might also
  579: @c work in the suggestion that if you want a diff, you
  580: @c should make it before running commit (someone
  581: @c suggested that the diff pop up in the editor.  I'm
  582: @c not sure that is better than telling people to run
  583: @c "cvs diff" first if that is what they want, but if
  584: @c we want to tell people that, the manual possibly
  585: @c should say it).
  586: 
  587: わざわざエディタを開くのが嫌ならば、代わりにコマンド行の @samp{-m} フ
  588: ラグを使うことでログメッセージを以下のように指定することができます:
  589: 
  590: @example
  591: $ cvs commit -m "Added an optimization pass" backend.c
  592: @end example
  593: 
  594: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  595: @node Cleaning up
  596: @subsection お掃除
  597: @cindex Cleaning up
  598: @cindex Working copy, removing
  599: @cindex Removing your working copy
  600: @cindex Releasing your working copy
  601: 
  602: 他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も
  603: ちろん、次のようにしても可能です
  604: 
  605: @example
  606: $ cd ..
  607: $ rm -r tc
  608: @end example
  609: 
  610: @noindent
  611: しかし、@code{release} コマンドを使用するほうが良いでしょう 
  612: (@pxref{release}):
  613: 
  614: @example
  615: $ cd ..
  616: $ cvs release -d tc
  617: M driver.c
  618: ? tc
  619: You have [1] altered files in this repository.
  620: Are you sure you want to release (and delete) module `tc': n
  621: ** `release' aborted by user choice.
  622: @end example
  623: 
  624: @code{release} コマンドは、あなたの修正が格納されているかどうか確認し
  625: ます。ログを記録する設定ならば、ファイル @file{history} にメモします。 
  626: @xref{history file}.
  627: 
  628: @code{release} コマンドに @samp{-d} フラグを使用すると、
  629: 確認と同時に作業コピーを削除します。
  630: 
  631: 上の例では、@code{release} コマンドが何行か出力しています。
  632: @samp{? tc} は @sc{cvs} が @file{tc} というファイルを知らないという意味です。
  633: モジュール @samp{tc} のことではなく、
  634: 生成したコンパイラ @file{tc} を指しており、
  635: これはリポジトリに格納しなくて良いので無視して構いません。
  636: この警告を消すための情報は @ref{cvsignore} 参照。
  637: @code{release} の出力の詳細な説明は @ref{release output} 参照。
  638: 
  639: @samp{M driver.c} の方は重要です。
  640: これは、@file{driver.c} というファイルに加えた修正が、
  641: 格納されていないことを指摘しています。
  642: 
  643: @code{release} コマンドは、常に作業コピーの
  644: 修正が加えられたファイルの数を報告した後、
  645: ファイルを削除したり履歴ファイルにメモする前に、
  646: その確認を求めてきます。
  647: 
  648: ここでは大事を取って、最後に @code{release} が確認を求めたときに 
  649: @kbd{n @key{RET}} を入力しました。
  650: 
  651: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  652: @node Viewing differences
  653: @subsection 差分を見る
  654: @cindex Viewing differences
  655: @cindex Diff
  656: 
  657: あなたは @file{driver.c} に加えた修正を覚えていなかったので、
  658: 何をしたのか調べる必要があります。
  659: 
  660: @example
  661: $ cd tc
  662: $ cvs diff driver.c
  663: @end example
  664: 
  665: このコマンドは @code{diff} を実行して、取り出した時と、あなたの作業コ
  666: ピーの @file{driver.c} のバージョンを比較します。その出力を見て、最適
  667: 化経路を有効にするオプションを、コマンド行で指定できるようにしたことを
  668: 思い出しました。その変更を格納して、このモジュールに対する作業を終了し
  669: ます。
  670: @c FIXME: we haven't yet defined the term "check in".
  671: 
  672: @example
  673: $ cvs commit -m "Added an optimization pass" driver.c
  674: Checking in driver.c;
  675: /usr/local/cvsroot/tc/driver.c,v  <--  driver.c
  676: new revision: 1.2; previous revision: 1.1
  677: done
  678: $ cd ..
  679: $ cvs release -d tc
  680: ? tc
  681: You have [0] altered files in this repository.
  682: Are you sure you want to release (and delete) module `tc': y
  683: @end example
  684: 
  685: @c ---------------------------------------------------------------------
  686: @node Repository
  687: @chapter リポジトリ
  688: @cindex Repository (intro)
  689: @cindex Repository, example
  690: @cindex Layout of repository
  691: @cindex Typical repository
  692: @cindex /usr/local/cvsroot, as example repository
  693: @cindex cvsroot
  694: 
  695: @sc{cvs} の@dfn{リポジトリ} (@dfn{repository}) は、
  696: バージョン管理の対象となる全てのファイルとディレクトリの、
  697: 完全なコピーを保管します。
  698: 
  699: 通常、リポジトリ中のファイルを直接利用することはありません。
  700: その代わりに @sc{cvs} コマンドを使用して、
  701: 作業者自身のファイルのコピーを @dfn{作業ディレクトリ}
  702: に取り出し、そのコピーを用いて作業します。
  703: 
  704: そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も
  705: しくは @dfn{格納} します (@dfn{commit}))。リポジトリは、変更を加えたも
  706: のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され
  707: ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ
  708: とに注意してください。別の位置にあるべきです。
  709: @c Need some example, e.g. repository
  710: @c /usr/local/cvsroot; working directory
  711: @c /home/joe/sources.  But this node is too long
  712: @c as it is; need a little reorganization...
  713: 
  714: @cindex :local:
  715: @sc{cvs} は様々な方法でリポジトリを利用することができます。
  716: リポジトリは、使用中のコンピュータ内であってもいいし、
  717: 別の部屋のコンピュータや、別の国のコンピュータであっても構いません。
  718: リポジトリに接続する方法を区別するために、
  719: リポジトリの名前の最初に@dfn{接続経路} (@dfn{access
  720: method}) を加えることがあります。例えば @code{:local:} は、リポジトリ
  721: であるディレクトリを利用することを意味します。つまり 
  722: @code{:local:/usr/local/cvsroot} で表されるリポジトリは、@sc{cvs} を実
  723: 行したコンピュータの @file{/usr/local/cvsroot} というリポジトリを意味
  724: します。他の接続経路については @ref{Remote repositories} 参照。
  725: 
  726: @c Can se say this more concisely?  Like by passing
  727: @c more of the buck to the Remote repositories node?
  728: 接続経路の指定が省略され、リポジトリに @samp{:} が含まれない場合には、
  729: @code{:local:} が仮定されます。
  730: @samp{:} が含まれていた場合には、
  731: @code{:ext:} か @code{:server:} が仮定されます。
  732: 例えばリポジトリ @file{/usr/local/cvsroot} が同じコンピュータ内にある場合、
  733: @code{:local:/usr/local/cvsroot} を省略して
  734: @code{/usr/local/cvsroot} と記述しても構いません。
  735: しかし(Windows NT などで)、
  736: リポジトリが @file{c:\src\cvsroot} にある場合、 
  737: @code{:local:c:\src\cvsroot} として、
  738: 接続経路を明示する必要があります。
  739: 
  740: @c This might appear to go in Repository storage, but
  741: @c actually it is describing something which is quite
  742: @c user-visible, when you do a "cvs co CVSROOT".  This
  743: @c isn't necessary the perfect place for that, though.
  744: リポジトリは二つの要素から構成されます。
  745: @file{$CVSROOT/CVSROOT} には @sc{cvs} の管理用ファイルが置かれます。
  746: その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。
  747: 
  748: @menu
  749: * Specifying a repository::     どのリポジトリを使うか CVS に教える
  750: * Repository storage::          リポジトリの構造
  751: * Working directory storage::   作業ディレクトリの構造
  752: * Intro administrative files::  モジュールの定義
  753: * Multiple repositories::       複数のリポジトリ
  754: * Creating a repository::       リポジトリの作成
  755: * Backing up::                  リポジトリのバックアップ
  756: * Moving a repository::         リポジトリの移動
  757: * Remote repositories::         別のマシンのリポジトリを利用する
  758: * Read-only access::            リポジトリの読み込みのみの利用を許可する
  759: * Server temporary directory::  サーバは一時ディレクトリを作成する
  760: @end menu
  761: 
  762: @node Specifying a repository
  763: @section CVS にリポジトリの場所を教える
  764: 
  765: @sc{cvs} にリポジトリの場所を教えるには、
  766: いくつか方法があります。
  767: 一つ目はコマンド行で、
  768: @code{-d} ("directory" を示します) オプションを用いて
  769: 指定する方法です:
  770: 
  771: @example
  772: cvs -d /usr/local/cvsroot checkout yoyodyne/tc
  773: @end example
  774: 
  775: @cindex .profile, setting CVSROOT in
  776: @cindex .cshrc, setting CVSROOT in
  777: @cindex .tcshrc, setting CVSROOT in
  778: @cindex .bashrc, setting CVSROOT in
  779: @cindex CVSROOT, environment variable
  780: 二つ目は、環境変数 @code{$CVSROOT} に、
  781: 絶対パスでリポジトリを指定する方法です。
  782: 例では @file{/usr/local/cvsroot}です。
  783: @code{csh} や @code{tcsh} のユーザは各々
  784: @file{.cshrc} や @file{.tcshrc} に次の行を加えて下さい:
  785: 
  786: @example
  787: setenv CVSROOT /usr/local/cvsroot
  788: @end example
  789: 
  790: @noindent
  791: @code{sh} や @code{bash} のユーザは各々 
  792: @file{.profile} や @file{.bashrc} に次の行を加えて下さい:
  793: 
  794: @example
  795: CVSROOT=/usr/local/cvsroot
  796: export CVSROOT
  797: @end example
  798: 
  799: @cindex Root file, in CVS directory
  800: @cindex CVS/Root file
  801: @code{-d} によるリポジトリの指定は、
  802: 環境変数 @code{$CVSROOT} よりも優先されます。
  803: 一旦リポジトリから作業コピーを取得すれば、
  804: リポジトリの場所が記憶されます
  805: (この情報は、作業ディレクトリ内の 
  806: @file{CVS/Root} に記録されます)。
  807: 
  808: オプション @code{-d} とファイル @file{CVS/Root} は、
  809: どちらも環境変数 @code{$CVSROOT} よりも優先されます。
  810: また、@file{-d} と @file{CVS/Root} が一致しない場合は、
  811: 前者が使用されます
  812: (@code{-d} の指定により @file{CVS/Root} が上書きされます)。
  813: もちろん、
  814: 二つともが同じリポジトリを参照するのが、まともなやり方です。
  815: 
  816: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  817: @node Repository storage
  818: @section リポジトリでのデータの保存方法
  819: @cindex Repository, how data is stored
  820: 
  821: @sc{cvs} がリポジトリに情報を保存する@emph{方法}を知っていても、
  822: たいてい何の役にも立ちません。
  823: 実際、過去に書式が変更されましたし、
  824: 将来変更されることもあるでしょう。
  825: ほとんど全ての場合、
  826: @sc{cvs} コマンドを通してリポジトリを利用しますから、
  827: 書式を変更しても混乱は起きません。
  828: 
  829: しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え
  830: ば @sc{cvs} のロック解除が必要な場合 (@pxref{Concurrency}) や、リポジ
  831: トリのファイルの許可属性を適切に設定する必要がある場合などです。
  832: 
  833: @menu
  834: * Repository files::            リポジトリに保管されるファイル
  835: * File permissions::            ファイル使用許可
  836: * Windows permissions::         Windows 特有の問題
  837: * Attic::                       Attic に保存されるファイルもある
  838: * CVS in repository::           CVS ディレクトリの追加情報
  839: * Locks::                       CVS ロックは並列接続を制御する
  840: * CVSROOT storage::             CVSROOT の少しの違い
  841: @end menu
  842: 
  843: @node Repository files
  844: @subsection リポジトリのどこにファイルを保存するか
  845: 
  846: @c @cindex filenames, legal
  847: @c @cindex legal filenames
  848: @c Somewhere we need to say something about legitimate
  849: @c characters in filenames in working directory and
  850: @c repository.  Not "/" (not even on non-unix).  And
  851: @c here is a specific set of issues:
  852: @c 	Files starting with a - are handled inconsistently. They can not
  853: @c   be added to a repository with an add command, because it they are
  854: @c   interpreted as a switch. They can appear in a repository if they are
  855: @c   part of a tree that is imported. They can not be removed from the tree
  856: @c   once they are there.
  857: @c Note that "--" *is* supported (as a
  858: @c consequence of using GNU getopt).  Should document
  859: @c this somewhere ("Common options"?).  The other usual technique,
  860: @c "./-foo", isn't as effective, at least for "cvs add"
  861: @c which doesn't support pathnames containing "/".
  862: 
  863: リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい
  864: ます。例えば、リポジトリが
  865: 
  866: @example
  867: /usr/local/cvsroot
  868: @end example
  869: 
  870: @noindent
  871: にあれば、次のようなディレクトリの木構造になります (ディレクトリだけを
  872: 表示しています):
  873: 
  874: @example
  875: @t{/usr}
  876:  |
  877:  +--@t{local}
  878:  |   |
  879:  |   +--@t{cvsroot}
  880:  |   |    | 
  881:  |   |    +--@t{CVSROOT}
  882:           |      (管理用ファイル)
  883:           | 
  884:           +--@t{gnu}
  885:           |   | 
  886:           |   +--@t{diff}
  887:           |   |   (@sc{gnu} diff のソース)
  888:           |   | 
  889:           |   +--@t{rcs}
  890:           |   |   (@sc{rcs} のソース)
  891:           |   | 
  892:           |   +--@t{cvs}
  893:           |       (@sc{cvs} のソース)
  894:           | 
  895:           +--@t{yoyodyne}
  896:               | 
  897:               +--@t{tc}
  898:               |    |
  899:               |    +--@t{man}
  900:               |    |
  901:               |    +--@t{testing}
  902:               | 
  903:               +--(その他の Yoyodyne のソフトウェア)
  904: @end example                              
  905: 
  906: ディレクトリの中身は、管理下にあるファイルの@dfn{履歴ファイル} 
  907: (@dfn{history files}) です。
  908: 履歴ファイルの名前は、各ファイル名の最後に @samp{,v} を付加したものです。
  909: 次に、ディレクトリ @file{yoyodyne/tc} のリポジトリ構造を示します:
  910: @c FIXME: Should also mention CVS (CVSREP)
  911: @c FIXME? Should we introduce Attic with an xref to
  912: @c Attic?  Not sure whether that is a good idea or not.
  913: @example
  914:   @code{$CVSROOT}
  915:     |
  916:     +--@t{yoyodyne}
  917:     |   |
  918:     |   +--@t{tc}
  919:     |   |   |
  920:             +--@t{Makefile,v}
  921:             +--@t{backend.c,v}
  922:             +--@t{driver.c,v}
  923:             +--@t{frontend.c,v}
  924:             +--@t{parser.c,v}
  925:             +--@t{man}
  926:             |    |
  927:             |    +--@t{tc.1,v}
  928:             |
  929:             +--@t{testing}
  930:                  |
  931:                  +--@t{testpgm.t,v}
  932:                  +--@t{test2.t,v}
  933: @end example
  934: 
  935: @cindex History files
  936: @cindex RCS history files
  937: @c The first sentence, about what history files
  938: @c contain, is kind of redundant with our intro to what the
  939: @c repository does in node Repository....
  940: 履歴ファイルは、
  941: どのリビジョンのファイルでも再構築できる情報を持ち、
  942: また変更内容が格納された時のログ・メッセージと、
  943: その時のユーザの名前も記録しています。
  944: ファイルをこのような書式で保管した最初のプログラムが、
  945: @sc{rcs} というバージョン管理システムであったために、
  946: 履歴ファイルは @dfn{RCS ファイル} と呼ばれます。
  947: ファイル書式の完全な記述は、@sc{rcs} の配布セットにある
  948: @cite{rcsfile(5)} の @code{man} ページか、@sc{cvs} のソー
  949: ス配布のファイル @file{doc/RCSFILES} を参照してください。
  950: このファイル書式は非常に一般的なので、
  951: @sc{cvs} や @sc{rcs} 以外のシステムでも、
  952: 少くとも理解をすることができます。
  953: @c FIXME: Think about including documentation for this
  954: @c rather than citing it?  In the long run, getting
  955: @c this to be a standard (not sure if we can cope with
  956: @c a standards process as formal as IEEE/ANSI/ISO/etc,
  957: @c though...) is the way to go, so maybe citing is
  958: @c better.
  959: 
  960: @sc{cvs} で使用されている @sc{rcs} ファイルは標準の書式と少し違います。
  961: 最大の違いは魔法の枝です。詳細は @ref{Magic branch numbers} を参照して
  962: ください。@sc{cvs} では、有効なタグ名は @sc{rcs} で使用できるもののサ
  963: ブセットになっています。@sc{cvs} の規則は @ref{Tags} を参照してくださ
  964: い。
  965: 
  966: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  967: @node File permissions
  968: @subsection ファイル使用許可
  969: @c -- Move this to @node Creating a repository or similar
  970: @cindex Security
  971: @cindex File permissions, general
  972: @cindex permissions, general
  973: @c FIXME: we need to somehow reflect "permissions in
  974: @c repository" versus "permissions in working
  975: @c directory" in the index entries.
  976: @cindex Group
  977: @cindex read-only files, in repository
  978: 全ての @samp{,v} ファイルは読み込み専用であり、
  979: この使用許可を変えるべきではありません。
  980: これに対し、リポジトリ中のディレクトリは、
  981: ファイルの修正を行なう人物に対して、
  982: 書き込みを許可しなくてはいけません。
  983: これはつまり、
  984: ファイルの修正を行なう人物からなるグループを作って 
  985: (@cite{group(5)}参照)、
  986: そのディレクトリの所有グループとすることを意味しています。
  987: @c See also comment in commitinfo node regarding cases
  988: @c which are really awkward with unix groups.
  989: 
  990: 従って、
  991: ディレクトリ単位でしかファイルのアクセス権を
  992: 管理することができません。
  993: 
  994: @sc{cvs} はロック・ファイルを作成する必要があるため 
  995: (@pxref{Concurrency})、ファイルを取り出す使用者にも、書き込み許可が必
  996: 要であることに注意して下さい。
  997: 
  998: @c CVS seems to use CVSUMASK in picking permissions for
  999: @c val-tags, but maybe we should say more about this.
 1000: @c Like val-tags gets created by someone who doesn't
 1001: @c have CVSUMASK set right?
 1002: 利用者は @file{CVSROOT/val-tags} ファイルに書き込み許可が必要なことも
 1003: 注意してください。@sc{cvs} はそれをどのタグが有効かを記録するために使
 1004: います (作成時と、ときどきタグが使用されたときに更新されます)。
 1005: 
 1006: それぞれの @sc{rcs} ファイルは最後に書き込んだ利用者に所有されます。こ
 1007: れはあまり重要ではありません。重要なのは誰がディレクトリを所有している
 1008: かです。
 1009: 
 1010: @cindex CVSUMASK, environment variable
 1011: @cindex umask, for repository files
 1012: 木の中に新しいディレクトリを加える場合、
 1013: @sc{cvs} はできるだけ適当な使用許可を与える努力をします。
 1014: しかし新しいディレクトリの使用許可が、
 1015: 親ディレクトリのものと異なる必要がある場合には、
 1016: 手動で変更する必要があります。
 1017: 環境変数 @code{CVSUMASK} を設定すれば、
 1018: リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。
 1019: @code{CVSUMASK} は、作業ディレクトリのファイル使用許可には影響しません。
 1020: 作業コピーの使用許可は、
 1021: 新たに作成したファイルに通常与えられるものと同じです。
 1022: 但し、@sc{cvs} が読み込みだけを許可することがあります
 1023: (監視時 @ref{Setting a watch}, -r 使用時 @ref{Global options},
 1024: CVSREAD 設定時 @ref{Environment variables} を各々参照)。
 1025: @c FIXME: Need more discussion of which
 1026: @c group should own the file in the repository.
 1027: @c Include a somewhat detailed example of the usual
 1028: @c case where CVSUMASK is 007, the developers are all
 1029: @c in a group, and that group owns stuff in the
 1030: @c repository.  Need to talk about group ownership of
 1031: @c newly-created directories/files (on some unices,
 1032: @c such as SunOS4, setting the setgid bit on the
 1033: @c directories will make files inherit the directory's
 1034: @c group.  On other unices, your mileage may vary.  I
 1035: @c can't remember what POSIX says about this, if
 1036: @c anything).
 1037: 
 1038: クライアント/サーバ @sc{cvs} を使用すると (@pxref{Remote
 1039: repositories})、@code{CVSUMASK} を設定する良い方法はありません。クライ
 1040: アントマシンでの設定は効果がありません。@code{rsh} で接続しているなら、
 1041: オペーレーティングシステムの説明に書いてあるように、@file{.bashrc} や
 1042: @file{.cshrc} で @code{CVSUMASK} を設定することができます。この振る舞
 1043: いは将来のバージョンの @sc{cvs} では変更されるかもしれません。クライア
 1044: ントの @code{CVSUMASK} の設定には頼らず、それは無効になるでしょう。
 1045: @c FIXME: need to explain what a umask is or cite
 1046: @c someplace which does.
 1047: @c
 1048: @c There is also a larger (largely separate) issue
 1049: @c about the meaning of CVSUMASK in a non-unix context.
 1050: @c For example, whether there is
 1051: @c an equivalent which fits better into other
 1052: @c protection schemes like POSIX.6, VMS, &c.
 1053: @c
 1054: @c FIXME: Need one place which discusses this
 1055: @c read-only files thing.  Why would one use -r or
 1056: @c CVSREAD?  Why would one use watches?  How do they
 1057: @c interact?
 1058: @c
 1059: @c FIXME: We need to state
 1060: @c whether using CVSUMASK removes the need for manually
 1061: @c fixing permissions (in fact, if we are going to mention
 1062: @c manually fixing permission, we better document a lot
 1063: @c better just what we mean by "fix").
 1064: 
 1065: pserver を使う場合は、一般的に、 @sc{cvsroot} ディレクトリと木構造でそ
 1066: れより上のディレクトリには厳しい使用許可が必要です。@ref{Password
 1067: authentication security} を参照してください。
 1068: 
 1069: @cindex setuid
 1070: @cindex setgid
 1071: @cindex security, setuid
 1072: @cindex installed images (VMS)
 1073: オペレーティングシステムには特定のプログラムが、プログラムの呼び手には
 1074: できないような動作をする能力とともに実行される機能があるものがあります。
 1075: 例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や
 1076: VMS の installed image 機能です。CVS はそのような機能を使用するように
 1077: 書かれていませんので、そのような方法で CVS をインストールすると事故の
 1078: 過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして
 1079: いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使
 1080: 用許可を得るかもしれません。代わりに pserver を使用することを考えるか
 1081: もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ
 1082: キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供
 1083: する可能性がありますので、このオプションを考えているなら、pserver の説
 1084: 明文書を注意深く読んでください。(@ref{Password authentication
 1085: security})。
 1086: 
 1087: @node Windows permissions
 1088: @subsection Windows に特有なファイルの使用許可問題
 1089: @cindex Windows, and permissions
 1090: @cindex File permissions, Windows-specific
 1091: @cindex permissions, Windows-specific
 1092: 
 1093: ファイルの使用許可には Windows オペレーティングシステムに特有の問題も
 1094: あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ
 1095: ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、
 1096: 確かではありません)。
 1097: 
 1098: ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ
 1099: トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる
 1100: ことがあることが報告されています。Samba の設定で WRITE=YES にすると修
 1101: 正される/何とかなると言われています。
 1102: 責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調
 1103: 査をしていません。加えて、問題を避けるために CVS が違ったようにするこ
 1104: とができるかどうかも調べていません。何か発見したなら、@ref{BUGS} に書
 1105: かれているように我々に報せてください。
 1106: 
 1107: @node Attic
 1108: @subsection The attic
 1109: @cindex attic
 1110: 
 1111: ときどき @sc{cvs} は @sc{rcs} ファイルを @code{Attic} に保存することが
 1112: あることに気付くでしょう。例えば、@sc{cvsroot} が 
 1113: @file{/usr/local/cvsroot} でディレクトリ @file{yoyodyne/tc} のファイル
 1114: @file{backend.c} について話をしているとき、普通はファイルは以下のとこ
 1115: ろにあります
 1116: 
 1117: @example
 1118: /usr/local/cvsroot/yoyodyne/tc/backend.c,v
 1119: @end example
 1120: 
 1121: しかし、attic に行けば、代わりに
 1122: 
 1123: @example
 1124: /usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
 1125: @end example
 1126: 
 1127: @cindex dead state
 1128: になります。利用者にとってはファイルが attic にあるかどうかは関係あり
 1129: ません。@sc{cvs} はこれを記録し、必要なときは attic を調べます。詳細を
 1130: 知りたい人のために書くと、幹の先頭リビジョンが @code{dead} の状態であ
 1131: るまさにそのときだけ、ファイルは attic に保存されます。@code{dead} の
 1132: 状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが
 1133: ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは
 1134: @code{dead} の状態になり枝のリビジョンは @code{dead} ではない状態にな
 1135: ります。
 1136: @c Probably should have some more concrete examples
 1137: @c here, or somewhere (not sure exactly how we should
 1138: @c arrange the discussion of the dead state, versus
 1139: @c discussion of the attic).
 1140: 
 1141: @node CVS in repository
 1142: 
 1143: @subsection リポジトリの CVS ディレクトリ
 1144: @cindex CVS directory, in repository
 1145: 
 1146: それぞれのリポジトリのディレクトリの @file{CVS} ディレクトリはファイル
 1147: 属性などの情報が収められています (@file{CVS/fileattr} というファイルで
 1148: す。詳しい情報は CVS のソース配布の fileattr.h を見てください)。将来は
 1149: このディレクトリには他のファイルが加えられる可能性がありますから、実装
 1150: は追加のファイルを静かに無視するのが良いでしょう。
 1151: 
 1152: この動作は @sc{cvs} 1.7 とその後のものだけで実装されています。詳細は
 1153: @ref{Watches Compatibility} を参照してください。
 1154: 
 1155: @node Locks
 1156: @subsection リポジトリの CVS ロック
 1157: 
 1158: @cindex #cvs.rfl, technical details
 1159: @cindex #cvs.wfl, technical details
 1160: @cindex #cvs.lock, technical details
 1161: @cindex locks, cvs, technical details
 1162: 利用者から見える部分の CVS のロックに焦点をあてた紹介は 
 1163: @ref{Concurrency} を参照してください。次の部分は同じリポジトリをアクセ
 1164: スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう
 1165: なツールを書きたい人を対象にしています。@dfn{読み込みロック}
 1166: (@dfn{read lock}), @dfn{書き込みロック} (@dfn{write lock}), @dfn{デッ
 1167: ドロック} (@dfn{deadlock}) のような概念がよくわからなかったら、オペレー
 1168: ティングシステムやデータベースの文献を参照すると良いかもしれません。
 1169: 
 1170: @cindex #cvs.tfl
 1171: リポジトリ中の @file{#cvs.rfl} で始まる全てのファイルは読み込みロック
 1172: です。リポジトリ中の @file{#cvs.wfl} で始まる全てのファイルは書き込み
 1173: ロックです。古いバージョンの CVS (CVS 1.5 以前) は @file{#cvs.tfl} で
 1174: 始まる名前のファイルも作成していましたが、ここではそれらは議論しません。
 1175: ディレクトリ @file{#cvs.lock} はマスターロックとして働きます。すなわち、
 1176: 他のロックを取得する前に、まずこのロックを取得しなければならない、とい
 1177: うことです。
 1178: 
 1179: 書き込みロックを取得するためには、まず @file{#cvs.lock} ディレクトリを
 1180: 作成します。この操作は原子的操作でなければなりません (これはたいていの
 1181: オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた
 1182: めに失敗すれば、しばらく待ってもう一度試します。@file{#cvs.lock} ロッ
 1183: クを取得した後、@file{#cvs.rfl} の後に選択した情報 (例えば、ホスト名と
 1184: プロセス番号) が続いた名前のファイルを作成します。それからマスターロッ
 1185: クを解放するために @file{#cvs.lock} ディレクトリを消去します。それから
 1186: リポジトリを読んで続行します。終った後、読み込みロックを解放するために
 1187: @file{#cvs.rfl} ファイルを消去します。
 1188: 
 1189: 書き込みロックを取得するためには、読み込みロックと同様にまず 
 1190: @file{#cvs.lock} ディレクトリを作成します。それから @file{#cvs.rfl} で
 1191: 始まるファイルが無いかどうかを調べます。もしあれば、@file{#cvs.lock} 
 1192: を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、
 1193: @file{#cvs.wfl} の後に選択した情報を続けた名前のファイルを作成します 
 1194: (例えば、ホスト名とプロセス番号)。ロック @file{#cvs.lock} を続けます。
 1195: リポジトリへの書き込みを実行します。それが終わると、まず 
 1196: @file{#cvs.wfl} ファイルを消去し、それから @file{#cvs.lock} ディレクト
 1197: リを消去します。@file{#cvs.rfl} ファイルと違って、@file{#cvs.wfl} ファ
 1198: イルは情報提供のためだけにあることに注意してください。@file{#cvs.lock} 
 1199: そのもののロックを続ける以上のロック操作の効果はありません。
 1200: 
 1201: それぞれのロック (書き込みロック及び読み込みロック) は @file{Attic} と
 1202: @file{CVS} を含んだリポジトリの単独のディレクトリのみをロックしますが、
 1203: バージョン管理下の他のディレクトリは含まないことに注意してください。木
 1204: 全体をロックするためには、それぞれのディレクトリをロックする必要があり
 1205: ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため
 1206: に再挑戦の前に木全体を解放しなければならないことに注意してください)。
 1207: 
 1208: @sc{cvs} は個々の @file{foo,v} ファイルへのアクセス制御のために書き込
 1209: みロックを期待するということにも注意してください。@sc{rcs} には 
 1210: @file{,foo,} ファイルがロックとして働く機構がありますが、@sc{cvs} はそ
 1211: れを実装しておらず、@sc{cvs} の書き込みロックを取り出すことが推奨され
 1212: ています。さらなる議論/合理性は @sc{cvs} のソースコードの 
 1213: rcs_internal_lockfile のところのコメントを読んでください。
 1214: 
 1215: @node CVSROOT storage
 1216: @subsection CVSROOT ディレクトリでファイルが保管される方法
 1217: @cindex CVSROOT, storage of files
 1218: 
 1219: @file{$CVSROOT/CVSROOT} ディレクトリにはいろいろな管理ファイルがありま
 1220: す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て
 1221: います。そこにはファイル名が @samp{,v} で終わる多くの @sc{rcs} ファイ
 1222: ルがあり、多くの @sc{cvs} コマンドは同じ方法でそれを操作します。しかし、
 1223: 少しの違いはあります。
 1224: 
 1225: それぞれの管理ファイルには、@sc{rcs} ファイルに加えて、ファイルの取り
 1226: 出された版のコピーがあります。例えば、@sc{rcs} ファイル 
 1227: @file{loginfo,v} とそれの最新リビジョンであるファイル @file{loginfo}
 1228: があります。管理ファイルを格納したときは、@sc{cvs} は
 1229: 
 1230: @example
 1231: cvs commit: Rebuilding administrative file database
 1232: @end example
 1233: 
 1234: @noindent
 1235: @cindex checkoutlist
 1236: を印字し、@file{$CVSROOT/CVSROOT} の取り出された版のコピーを更新するよ
 1237: うになっています。もしそうならなければ、何かがおかしくなっています 
 1238: (@pxref{BUGS})。自分自身のファイルをこのように更新されるファイル群に追
 1239: 加するために、それらを管理ファイル @file{checkoutlist} に追加できます。
 1240: 
 1241: @cindex modules.db
 1242: @cindex modules.pag
 1243: @cindex modules.dir
 1244: 初期設定では @file{modules} ファイルは上で説明されているように振舞いま
 1245: す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし
 1246: て保存しているとモジュールの探索が遅くなるかもしれません (@sc{cvs} が
 1247: 最初にこの機能を追加したときほど関心があるかどうかは定かではありません。
 1248: ベンチマークは見ていませんので)。ですから、@sc{cvs} ソースコードに適切
 1249: な修正を加えるとおで、modules ファイルを Berkeley db や GDBM のような 
 1250: @code{ndbm} インターフェースを実装したデータベースで保存することができ
 1251: ます。このオプションが使用されると、modules データベースは
 1252: @file{module.db}, @file{modules} と/もしくは @file{modules.dir} に保存
 1253: されます。
 1254: @c I think fileattr also will use the database stuff.
 1255: @c Anything else?
 1256: 
 1257: いろいろな管理ファイルの意味に関する情報は @ref{Administrative files}
 1258: を参照してください。
 1259: 
 1260: @node Working directory storage
 1261: @section リポジトリでのデータの保存方法
 1262: 
 1263: @c FIXME: Somewhere we should discuss timestamps (test
 1264: @c case "stamps" in sanity.sh).  But not here.  Maybe
 1265: @c in some kind of "working directory" chapter which
 1266: @c would encompass the "Builds" one?  But I'm not sure
 1267: @c whether that is a good organization (is it based on
 1268: @c what the user wants to do?).
 1269: 
 1270: @cindex CVS directory, in working directory
 1271: しばしば表面に現れてくるかもしれない @sc{cvs} の内部についての話をして
 1272: いる間に、@sc{cvs} が作業ディレクトリの @file{CVS} ディレクトリに何を
 1273: 入れるかも話した方が良いでしょう。リポジトリと同様に、@sc{cvs} がこの
 1274: 情報を扱い、普通は @sc{cvs} のコマンドを通してだけそれを使用します。で
 1275: も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター
 1276: フェース の @code{jCVS} や emacs のための @code{VC} パッケージなどの他
 1277: のプログラムがそれを見る必要があるかもしれません。そのようなプログラム
 1278: は、上で書いたプログラムやコマンド行 @sc{cvs} クライアントの将来のバー
 1279: ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望
 1280: むなら、この節の推奨規格に従う必要があります。
 1281: 
 1282: @file{CVS} ディレクトリには複数のファイルがあります。このディレクトリ
 1283: を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在
 1284: するけれどここで説明されていないファイルは静かに無視するのが望ましいで
 1285: す。
 1286: 
 1287: @table @file
 1288: @item Root
 1289: このファイルは @ref{Specifying a repository} で説明されているように、
 1290: 現在の @sc{cvs} のルートを保持しています。
 1291: 
 1292: @cindex Repository file, in CVS directory
 1293: @cindex CVS/Repository file
 1294: @item Repository
 1295: このファイルは現在のディレクトリが対応するリポジトリでのディレクトリを
 1296: 保持しています。指定は絶対パス名と相対パス名のどちらでも可能です。
 1297: @sc{cvs} は少なくともバージョン 1.3 くらいから両方の形式を読み込む能力
 1298: を備えています。相対パスはルートからの相対位置で、より賢い方法ですが、
 1299: 絶対パス名は非常によく使われており、実装は両方を受け付けることが望まれ
 1300: ます。例えば、以下のコマンドの後で
 1301: 
 1302: @example
 1303: cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
 1304: @end example
 1305: 
 1306: @file{Root} は以下のようになり
 1307: 
 1308: @example
 1309: :local:/usr/local/cvsroot
 1310: @end example
 1311: 
 1312: @file{Repository} は
 1313: 
 1314: @example
 1315: /usr/local/cvsroot/yoyodyne/tc
 1316: @end example
 1317: 
 1318: @noindent
 1319:  1320: 
 1321: @example
 1322: yoyodyne/tc
 1323: @end example
 1324: 
 1325: @noindent
 1326: のどちらかになります。
 1327: 
 1328: @cindex Entries file, in CVS directory
 1329: @cindex CVS/Entries file
 1330: @item Entries
 1331: このファイルは作業ディレクトリ中のファイルとディレクトリの一覧を挙げて
 1332: います。使っているオペレーティング・システムに応じたテキスト・ファイル
 1333: になっています。
 1334: @c Using OS text file conventions makes it impossible (it
 1335: @c would seem) to share a working directory via a
 1336: @c networked file system between systems with diverse
 1337: @c text file conventions.  But that might be correct,
 1338: @c because the text files under CVS control are subject
 1339: @c to the same problem.  It is also the status quo.
 1340: 各行の最初の文字はそれがどんな行かを示します。将来の拡張ができるように、
 1341: 文字を認識できない場合は、ファイルを読み込んでいるファイルは暗黙にその
 1342: 行を飛ばすことが望まれます。
 1343: 
 1344: 最初の文字が @samp{/} であれば、様式は:
 1345: 
 1346: @example
 1347: /@var{name}/@var{revision}/@var{timestamp}[+@var{conflict}]/@var{options}/@var{tagdate}
 1348: @end example
 1349: 
 1350: で、@samp{[} と @samp{]} は登録の一部ではありませんが、その代わりに 
 1351: @samp{+} と衝突の印は省略任意であることを示しています。@var{name} はディ
 1352: レクトリ中のファイルの名前です。@var{revision} は作業中のファイルの元
 1353: のリビジョンで、@samp{0} の場合は追加されたファイル、@samp{-} の後にリ
 1354: ビジョンは削除されたファイルです。@var{timestamp} は @sc{cvs} がファイ
 1355: ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の
 1356: 修正時刻と違えば、ファイルは修正されたということです。それは Universal
 1357: Time (UT) で、ISO c astime() 関数で使われる様式で保存されます (例えば、
 1358: @samp{Sun Apr 7 01:29:26 1996})。ファイルが常に修正されていると見なさ
 1359: れるように、例えば、@samp{Result of merge} のようにその様式とは違う文
 1360: 字列を書くかもしれません。これは特別な場合ではありません。ファイルが修
 1361: 正されたかどうかを調べるために、プログラムはファイルのタイムスタンプを
 1362: 単純に @var{timestamp} と文字列比較をするべきです。@var{conflict} は衝
 1363: 突があったことを示します。もしそれが実際の修正時刻と同じであるなら、ユー
 1364: ザは明かに衝突を解消していません。@var{options} は貼り付けられたオプショ
 1365: ンを保持しています (例えば、バイナリ・ファイルのための @samp{-kbd})。
 1366: @var{tagdate} は @samp{T} の後にタグ名が続いているか、日付 (date) の 
 1367: @samp{D} で、貼り付けられたタグか日付がつづいているかのどちらかを保持
 1368: しています。@var{timestamp} が単独のタイムスタンプではなく、スペースで
 1369: 分離されたタイムスタンプの対であるなら、@sc{cvs} 1.5 より前のバージョ
 1370: ンの @sc{cvs} を扱っているということに注意してください (ここでは説明さ
 1371: れていません)。
 1372: 
 1373: @file{Entries} の行の最初の文字が @samp{D} であると、それはサブディレ
 1374: クトリを現しています。行が @samp{D} だけのときは、 @file{Entries} ファ
 1375: イルを書いたプログラムはサブディレクトリを記録したということを現します 
 1376: (ですから、そのような行があって、他に @samp{D} で始まる行がなければ、
 1377: サブディレクトリがないことがわかります)。そうでなければ、行は次のよう
 1378: になっています:
 1379: 
 1380: @example
 1381: D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
 1382: @end example
 1383: 
 1384: ここで @var{name} はサブディレクトリの名前であり、将来の拡張のために、
 1385: 全ての @var{filler} 部分は暗黙の内に無視されるべきです。@code{Entries} 
 1386: を修正するプログラムはこれらの部分を保存するのが望まれています。
 1387: 
 1388: @cindex Entries.Log file, in CVS directory
 1389: @cindex CVS/Entries.Log file
 1390: @item Entries.Log
 1391: このファイルは @file{Entries} に無いさらなる情報を記録することはありま
 1392: せんが、@file{Entries} ファイル全体を再書き込みすることなく、情報を更
 1393: 新するための方法をもたらし、その中には @file{Entries} と 
 1394: @file{Entries.Log} を書いているプログラムが不意に異常終了しても情報を
 1395: 保護する機能もあります。@file{Entries} ファイルを読み込むプログラムは
 1396: @file{Entries.Log} も調べるべきです。後者が存在すれば、@file{Entries} 
 1397: を読み込んで、@file{Entries.Log} にある変更を適用すべきです。変更を適
 1398: 用した後で、@file{Entries} を再度書き込んで、@file{Entries} を消去する
 1399: 習慣が推奨されています。@file{Entries.Log} の行の様式は、単独文字コマ
 1400: ンドがあり、その後にスペースが続き、その後は @file{Entries} の行に指定
 1401: された様式になります。単独文字コマンドは登録が追加されたことを示す
 1402: @samp{A} と登録が消去されたことを示す @samp{R} か、@file{Entries} の登
 1403: 録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2
 1404: 番目の文字が @file{Entries.Log} の行の2番目の文字がスペースでないと、
 1405: それは @sc{cvs} の古いバージョンで書かれています (ここでは説明されてい
 1406: ません)。
 1407: 
 1408: @cindex Entries.Backup file, in CVS directory
 1409: @cindex CVS/Entries.Backup file
 1410: @item Entries.Backup
 1411: これは一時ファイルです。推奨された使用法は、新しい Entriy ファイルを 
 1412: @file{Entries.Backup} に書き、それから @file{Entries} に改名する (もし
 1413: 可能なら原子的操作で) ことです。
 1414: 
 1415: @cindex Entries.Static file, in CVS directory
 1416: @cindex CVS/Entries.Static file
 1417: @item Entries.Static
 1418: このファイルが関連する唯一のことはそれが存在するか否か、ということです。
 1419: もし存在すると、ディレクトリの一部分だけが取得されていて、@sc{cvs} は
 1420: そのディレクトリに追加のファイルを作成しないということです。それを消去
 1421: するためには、@code{update} コマンドを @samp{-d} オプションとともに使っ
 1422: てください。そうすれば、追加のファイルを取得して、
 1423: @file{Entries.Static} を消去します。
 1424: @c FIXME: This needs to be better documented, in places
 1425: @c other than Working Directory Storage.
 1426: @c FIXCVS: The fact that this setting exists needs to
 1427: @c be more visible to the user.  For example "cvs
 1428: @c status foo", in the case where the file would be
 1429: @c gotten except for Entries.Static, might say
 1430: @c something to distinguish this from other cases.
 1431: @c One thing that periodically gets suggested is to
 1432: @c have "cvs update" print something when it skips
 1433: @c files due to Entries.Static, but IMHO that kind of
 1434: @c noise pretty much makes the Entries.Static feature
 1435: @c useless.
 1436: 
 1437: @cindex Tag file, in CVS directory
 1438: @cindex CVS/Tag file
 1439: @cindex Sticky tags/dates, per-directory
 1440: @cindex Per-directory sticky tags/dates
 1441: @item Tag
 1442: このファイルはディレクトリごとの貼り付いたタグを保持します。最初の文字
 1443: は枝のタグには @samp{T}、枝でないタグは @samp{N}、日付は @samp{D} にな
 1444: り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ
 1445: の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付
 1446: は新規に追加されたファイルに適用されること等に使用されることに注意して
 1447: ください。貼り付きタグと日付に関する一般的な情報は @ref{Sticky tags} 
 1448: を参照してください。
 1449: @c FIXME: This needs to be much better documented,
 1450: @c preferably not in the context of "working directory
 1451: @c storage".
 1452: @c FIXME: The Sticky tags node needs to discuss, or xref to
 1453: @c someplace which discusses, per-directory sticky
 1454: @c tags and the distinction with per-file sticky tags.
 1455: 
 1456: @cindex Checkin.prog file, in CVS directory
 1457: @cindex CVS/Checkin.prog file
 1458: @cindex Update.prog file, in CVS directory
 1459: @cindex CVS/Update.prog file
 1460: @item Checkin.prog
 1461: @itemx Update.prog
 1462: これらのファイルはそれぞれ modules ファイルの @samp{-i} と @samp{-u}
 1463: オプションで指定されたプログラムを保存します。
 1464: 
 1465: @cindex Notify file, in CVS directory
 1466: @cindex CVS/Notify file
 1467: @item Notify
 1468: このファイルはまだサーバに送信されていない通知 (例えば、@code{edit} や 
 1469: @code{unedit} のため) を保存します。書式はまだここでは説明されていませ
 1470: ん。
 1471: 
 1472: @cindex Notify.tmp file, in CVS directory
 1473: @cindex CVS/Notify.tmp file
 1474: @item Notify.tmp
 1475: このファイルと @file{Notify} の関係は @file{Entries.Backup} と 
 1476: @file{Entries} の関係と同じです。即ち、@file{Notify} を書くためにはま
 1477: ず新しい内容を @file{Notify.tmp} に書き、それから (可能であれば自動的
 1478: に) それを @file{Notify} に改名します。
 1479: 
 1480: @cindex Base directory, in CVS directory
 1481: @cindex CVS/Base directory
 1482: @item Base
 1483: 監視を使用していると、@code{edit} コマンドはファイルの元のコピーを 
 1484: @file{Base} ディレクトリに保存します。これで、サーバと通信できないとき
 1485: でさえ @code{unedit} コマンドが実行できるようになります。
 1486: 
 1487: @cindex Baserev file, in CVS directory
 1488: @cindex CVS/Baserev file
 1489: @item Baserev
 1490: このファイルは @file{Base} ディレクトリのそれぞれのファイルのリビジョ
 1491: ンを一覧にします。書式は:
 1492: 
 1493: @example
 1494: B@var{name}/@var{rev}/@var{expansion}
 1495: @end example
 1496: 
 1497: で、@var{expansion} は将来の拡張のために、無視されるべきものです。
 1498: 
 1499: @cindex Baserev.tmp file, in CVS directory
 1500: @cindex CVS/Baserev.tmp file
 1501: @item Baserev.tmp
 1502: このファイルと @file{Baserev} の関係は @file{Entries.Backup} と
 1503: @file{Entries} との関係と同じです。即ち、@file{Baserev} に書くために、
 1504: まず新しい内容を @file{Baserev.tmp} に書き、それから (もし可能なら自動
 1505: 的に) それを @file{Baserev} に改名します。
 1506: 
 1507: @cindex Template file, in CVS directory
 1508: @cindex CVS/Template file
 1509: @item Template
 1510: このファイルには @file{rcsinfo} ファイルで指定された雛型が入っています
 1511: (@pxref{rcsinfo})。それはクライアントだけに使われます。非クライアント/
 1512: サーバ型 @sc{cvs} は直接 @file{rcsinfo} ファイルを調べます。
 1513: @end table
 1514: 
 1515: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1516: @node Intro administrative files
 1517: @section 管理用ファイルの紹介
 1518: @cindex Administrative files (intro)
 1519: @cindex Modules file
 1520: @cindex CVSROOT, module name
 1521: @cindex Defining modules (intro)
 1522: 
 1523: @c FIXME: this node should be reorganized into "general
 1524: @c information about admin files" and put the "editing
 1525: @c admin files" stuff up front rather than jumping into
 1526: @c the details of modules right away.  Then the
 1527: @c Administrative files node can go away, the information
 1528: @c on each admin file distributed to a place appropriate
 1529: @c to its function, and this node can contain a table
 1530: @c listing each file and a @ref to its detailed description.
 1531: 
 1532: @file{$CVSROOT/CVSROOT} には、いくつか @dfn{管理用ファイル} 
 1533: (@dfn{administrative files}) があります。完全な説明は 
 1534: @xref{Administrative files}. これらのファイルが無く
 1535: ても @sc{cvs} を使用することができます。しかし、少なくとも 
 1536: @file{modules} というファイルが適切に設定してあれば @sc{cvs} のコマン
 1537: ドはうまく働きます。
 1538: 
 1539: 管理用ファイルの中で、
 1540: 最も重要なファイルは @file{modules} です。
 1541: これはリポジトリの中の全てのモジュールを定義しています。
 1542: @file{modules} ファイルの例を次に示します。
 1543: 
 1544: @c FIXME: The CVSROOT line is a goofy example now that
 1545: @c mkmodules doesn't exist.
 1546: @example
 1547: CVSROOT         CVSROOT
 1548: modules         CVSROOT modules
 1549: cvs             gnu/cvs
 1550: rcs             gnu/rcs
 1551: diff            gnu/diff
 1552: tc              yoyodyne/tc
 1553: @end example
 1554: 
 1555: @file{modules} ファイルは行ごとに意味を持つファイルです。
 1556: @file{modules} ファイルの各行はそれぞれ、
 1557: モジュール名, 空白, モジュールのあるディレクトリ名
 1558: という書式で記述されます。
 1559: モジュールのあるディレクトリ名は、
 1560: @code{$CVSROOT} からの相対パスです。
 1561: @file{modules} ファイルの各行はそれぞれ、
 1562: モジュール名, 空白, モジュールのあるディレクトリ名
 1563: という書式で記述されます。
 1564: モジュールのあるディレクトリ名は、
 1565: @code{$CVSROOT} からの相対パスです。
 1566: 上の例の最後の4行はそのような行の例です。
 1567: 
 1568: @c FIXME: might want to introduce the concept of options in modules file
 1569: @c (the old example which was here, -i mkmodules, is obsolete).
 1570: 
 1571: モジュール @samp{modules} を定義する行については、
 1572: ここでは説明しません。
 1573: より詳しい説明は @ref{modules} 参照。
 1574: 
 1575: @c FIXME: subsection without node is bogus
 1576: @subsection 管理用ファイルの編集
 1577: @cindex Editing administrative files
 1578: @cindex Administrative files, editing them
 1579: 
 1580: 管理用ファイルは、
 1581: 他のモジュールと同じ方法で編集します。
 1582: @samp{cvs checkout CVSROOT} を用いて作業コピーを取り出して、
 1583: 編集し、通常通り変更内容を格納します。
 1584: 
 1585: 間違いのある管理用ファイルを格納することも可能です。
 1586: このような場合には、間違いを正して新たなリビジョンを登録します。
 1587: しかし管理用ファイルに深刻な間違いがあれば、
 1588: 新たなリビジョンの登録さえも不可能になります。
 1589: @c @xref{Bad administrative files} for a hint
 1590: @c about how to solve such situations.
 1591: @c -- administrative file checking--
 1592: 
 1593: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1594: @node Multiple repositories
 1595: @section 複数のリポジトリ
 1596: @cindex Multiple repositories
 1597: @cindex Repositories, multiple
 1598: @cindex Many repositories
 1599: @cindex Parallel repositories
 1600: @cindex Disjoint repositories
 1601: @cindex CVSROOT, multiple repositories
 1602: 
 1603: 特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ
 1604: のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ
 1605: ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変
 1606: 数 @code{$CVSROOT} で設定するか、@sc{cvs} のオプション @samp{-d} に指
 1607: 定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に @sc{cvs} 
 1608: に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ
 1609: けです。
 1610: 
 1611: 複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。
 1612: しかし、別々のリポジトリで管理されるディレクトリに対して、
 1613: 一つの @sc{cvs} コマンドが再帰的に動作しない、という大きな欠点がありま
 1614: す。また一般的に、同じマシンに複数のリポジトリを作るのならば、
 1615: 同じリポジトリに複数のディレクトリを作るほうが良いと思います。
 1616: @c FIXCVS: the thing about recursing into diverse roots
 1617: @c would be nice to fix.  But it gets hairy if they are
 1618: @c on diverse servers--it isn't clear this is really
 1619: @c all that useful.
 1620: @c FIXME: Does the FAQ have more about this?  I have a
 1621: @c dim recollection, but I'm too lazy to check right now.
 1622: 
 1623: この文書では、
 1624: 複数のリポジトリを使用した例はありません。
 1625: 
 1626: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1627: @node Creating a repository
 1628: @section リポジトリの作成
 1629: 
 1630: @cindex Repository, setting up
 1631: @cindex Creating a repository
 1632: @cindex Setting up a repository
 1633: 
 1634: @sc{cvs} リポジトリを設定するために、まずソースファイルのリビジョン履
 1635: 歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも
 1636: のですので、たいていのマシンは十分なはずです。詳細は @ref{Server
 1637: requirements} を参照してください。
 1638: @c Possible that we should be providing a quick rule of
 1639: @c thumb, like the 32M memory for the server.  That
 1640: @c might increase the number of people who are happy
 1641: @c with the answer, without following the xref.
 1642: 
 1643: ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを
 1644: 移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、
 1645: バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ
 1646: ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに
 1647: なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは
 1648: ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同
 1649: じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、
 1650: 全体の木かそれの一部分のどちらかになります)。
 1651: 
 1652: リポジトリはサーバ経由からか直接 @sc{cvs} を使う全てのマシンからか、
 1653: (直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に
 1654: する必要があります。クライアントのマシンは @sc{cvs} プロトコル経由以外
 1655: でそれにアクセス可能である必要はありません。@sc{cvs} は、リポジトリに
 1656: ロック・ファイルを作成する必要があるため (@pxref{Concurrency})、利用者
 1657: が読み込み許可しか持たないリポジトリを、@sc{cvs} から使うことはできま
 1658: せん。
 1659: 
 1660: @cindex init (subcommand)
 1661: リポジトリを作成するときには、@code{cvs init} コマンドを実行して下さい。
 1662: 通常の方法で指定された @sc{cvs} のルート (@pxref{Repository}) 以下の、
 1663: 空のリポジトリを利用できるように整えます。例えば次のようにします。
 1664: 
 1665: @example
 1666: cvs -d /usr/local/cvsroot init
 1667: @end example
 1668: 
 1669: @code{cvs init} は注意深いので、リポジトリに存在するファイルを上書きし
 1670: ません。従って既に利用できる状態のリポジトリに対して @code{cvs init} 
 1671: を実行しても、何の不都合もありません。
 1672: 
 1673: @code{cvs init} は、操作履歴を記録するように設定します。
 1674: もしこれを望まないのであれば、@code{cvs init} を実行した後に、
 1675: @file{history} ファイルを削除して下さい。@xref{history file}.
 1676: 
 1677: @node Backing up
 1678: @section リポジトリのバックアップ
 1679: @cindex Repository, backing up
 1680: @cindex Backing up, repository
 1681: 
 1682: リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん
 1683: どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき
 1684: 点も幾つかあります。
 1685: 
 1686: @cindex locks, cvs, and backups
 1687: @cindex #cvs.rfl, and backups
 1688: 最初の点は偏執的で、バックアップ中には @sc{cvs} を使用しないか、バック
 1689: アップ中はバックアッププログラムに @sc{cvs} をロックさせる必要がありま
 1690: す。@sc{cvs} を使わないために、リポジトリを操作できるマシンへのログイ
 1691: ンを禁止したり、@sc{cvs} サーバを停止したり、同様な機構を利用するかも
 1692: しれません。詳細はあなたのオペレーティングシステムと、@sc{cvs} を設定
 1693: した方法に依存します。@sc{cvs} をロックするためには、@file{#cvs.rfl} 
 1694: ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう
 1695: に言ってきましたが、これらの事前注意をせずにただバックアップを行なって
 1696: も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元
 1697: すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること
 1698: が非常に難しいということは無いでしょう。
 1699: 
 1700: リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時
 1701: から変更されていると仮定すると、失敗に影響を受けあかったディレクトリは
 1702: 今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし
 1703: れません。そのようなディレクトリで @sc{cvs} を実行しようとすると、普通
 1704: はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す
 1705: 方法の一つに以下のようなものがあります:
 1706: 
 1707: @itemize @bullet
 1708: @item
 1709: 新しい作業ディレクトリを取得します。
 1710: 
 1711: @item
 1712: 失敗前に作業ディレクトリからファイルをコピーします (もちろん、
 1713: @file{CVS} ディレクトリの内容をコピーしないでください)。
 1714: 
 1715: @item
 1716: 新しい作業ディレクトリで作業をし、@code{cvs update} や @code{cvs diff} 
 1717: のようなコマンドを使って何が変更されたかを見つけ、準備がでいたなら、変
 1718: 更をリポジトリに格納します。
 1719: @end itemize
 1720: 
 1721: @node Moving a repository
 1722: @section リポジトリの移動
 1723: @cindex repository, moving
 1724: @cindex moving a repository
 1725: @cindex copying a repository
 1726: 
 1727: リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く
 1728: 似ているように、リポジトリを別の場所に移動する必要があるときも、それは
 1729: 他のファイルの集合を移動するのと非常に良く似ています。
 1730: 
 1731: 主に考慮することは、作業ディレクトリがリポジトリを指しているか、という
 1732: ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し
 1733: い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ
 1734: クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような
 1735: 何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作
 1736: 業ディレクトリを再利用したいなら、@file{CVS/Repository} ファイルを手で
 1737: 手術することで可能です。@file{CVS/Repository}  と @file{CVS/Root} ファ
 1738: イルの情報は @ref{Working  directory storage} で参照することができます
 1739: が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。
 1740: @c FIXME: This should be made unnecessary by:
 1741: @c 1) a new -d should affect CVS/Root files throughout
 1742: @c the tree, not just at the top level.
 1743: @c 2) the RELATIVE_REPOS code should be fixed and made the
 1744: @c default.  I think that CVS already reads
 1745: @c CVS/Repository files which are absolute or
 1746: @c relative.  FIXME: needs more investigation and
 1747: @c documentation in "Working directory storage".
 1748: 
 1749: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1750: @node Remote repositories
 1751: @section 別のマシンのリポジトリ
 1752: @cindex Repositories, remote
 1753: @cindex Remote repositories
 1754: @cindex Client/Server Operation
 1755: @cindex server, CVS
 1756: 
 1757: ソースの作業コピーはリポジトリと別のマシンに存在することができます。
 1758: @sc{cvs} をこの方法で使うことは @dfn{クライアント/サーバ}
 1759: (@dfn{client/server}) 操作として知られています。@dfn{クライアント} と
 1760: して、@sc{cvs} を作業ディレクトリを mount できるマシンで @sc{cvs} を実
 1761: 行し、@dfn{サーバ} となる、リポジトリを mount できるマシンと通信するよ
 1762: うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式
 1763: が以下のようになることを除き、ローカルのものを使うのと同じです:
 1764: 
 1765: @example
 1766: :@var{method}:@var{user}@@@var{hostname}:/path/to/repository
 1767: @end example
 1768: 
 1769: どれが本当に設定する必要があるかは、サーバに接続している方法に依って変
 1770: わります。
 1771: 
 1772: @var{method} が指定されず、リポジトリ名に @samp{:} が含まれる場合には、
 1773: 使用するオペレーティングシステムに依って @code{ext} か @code{server} 
 1774: が既定値とされます。詳しくは @ref{Connecting via rsh} 参照。
 1775: @c Should we try to explain which platforms are which?
 1776: @c Platforms like unix and VMS, which only allow
 1777: @c privileged programs to bind to sockets <1024 lose on
 1778: @c :server:
 1779: @c Platforms like Mac and VMS, whose rsh program is
 1780: @c unusable or nonexistent, lose on :ext:
 1781: @c Platforms like OS/2 and NT probably could plausibly
 1782: @c default either way (modulo -b troubles).
 1783: 
 1784: @c FIXME: We need to have a better way of explaining
 1785: @c what method to use.  This presentation totally
 1786: @c obscures the fact that :ext: and CVS_RSH is the way to
 1787: @c use SSH, for example.  Plus it incorrectly implies
 1788: @c that you need an @code{rsh} binary on the client to use
 1789: @c :server:.
 1790: @c Also note that rsh not pserver is the right choice if you want
 1791: @c users to be able to create their own repositories
 1792: @c (because of the --allow-root related issues).
 1793: @menu
 1794: * Server requirements::         サーバのためのメモリと他の資源
 1795: * Connecting via rsh::          接続に @code{rsh} プログラムを利用する
 1796: * Password authenticated::      パスワードを利用して直接接続する
 1797: * GSSAPI authenticated::        GSSAPI を利用して直接接続する
 1798: * Kerberos authenticated::      ケルベロスを利用して直接接続する
 1799: @end menu
 1800: 
 1801: @node Server requirements
 1802: @subsection サーバの要求
 1803: 
 1804: サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は
 1805: こじんまりとしたものであるということです---32M のメモリやそれ以下のサー
 1806: バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。
 1807: @c Say something about CPU speed too?  I'm even less sure
 1808: @c what to say on that subject...
 1809: 
 1810: もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の
 1811: 見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分
 1812: が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで
 1813: ないものがあれば、この説明文書を更新できるように、@ref{BUGS} に書かれ
 1814: ているように、我々に知らせてください)。
 1815: 
 1816: 大量のメモリ消費をする最初の部分は、@sc{cvs} サーバを使っているときの
 1817: 大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための
 1818: 2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ
 1819: ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー
 1820: ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな
 1821: るか、2メガバイトほどかどちらか大きいものになることが予想されています。
 1822: @c "two megabytes" of course is SERVER_HI_WATER.  But
 1823: @c we don't mention that here because we are
 1824: @c documenting the default configuration of CVS.  If it
 1825: @c is a "standard" thing to change that value, it
 1826: @c should be some kind of run-time configuration.
 1827: @c
 1828: @c See cvsclient.texi for more on the design decision
 1829: @c to not have locks in place while waiting for the
 1830: @c client, which is what results in memory consumption
 1831: @c as high as this.
 1832: 
 1833: それぞれの @sc{cvs} サーバの大きさを予想上の一度に活動するサーバ数で掛
 1834: けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい
 1835: ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ
 1836: リでしょう。
 1837: @c Has anyone verified that notion about swap space?
 1838: @c I say it based pretty much on guessing that the
 1839: @c ->text of the struct buffer_data only gets accessed
 1840: @c in a first in, first out fashion, but I haven't
 1841: @c looked very closely.
 1842: 
 1843: @c What about disk usage in /tmp on the server?  I think that
 1844: @c it can be substantial, but I haven't looked at this
 1845: @c again and tried to figure it out ("cvs import" is
 1846: @c probably the worst case...).
 1847: 
 1848: 大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの
 1849: @code{diff} です。これはバイナリ・ファイルでさえも必要です。大体の目安
 1850: は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が
 1851: 適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を
 1852: するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ 
 1853: でなければ、@sc{cvs} を実行しているマシン) に100メガバイトのメモリがあ
 1854: るのが良いです。これは物理メモリでなく、スワップであるかもしれません。
 1855: メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ
 1856: れるときのためのメモリを準備する必要は特にありません。
 1857: @c The 5-10 times rule of thumb is from Paul Eggert for
 1858: @c GNU diff.  I don't think it is in the GNU diff
 1859: @c manual or anyplace like that.
 1860: @c
 1861: @c Probably we could be saying more about
 1862: @c non-client/server CVS.
 1863: @c I would guess for non-client/server CVS in an NFS
 1864: @c environment the biggest issues are the network and
 1865: @c the NFS server.
 1866: 
 1867: クライアントの資源消費はさらに少ないです---オペレーティングシステムを
 1868: 動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。
 1869: @c Is that true?  I think the client still wants to
 1870: @c (bogusly) store entire files in memory at times.
 1871: 
 1872: ディスク容量に対する要求の情報は、@ref{Creating a repository} を参照し
 1873: てください。
 1874: 
 1875: @node Connecting via rsh
 1876: @subsection rsh で接続する
 1877: 
 1878: @cindex rsh
 1879: CVS はこれらの操作を実行するために @file{rsh} プロトコルを用いますので、
 1880: 遠隔側の使用者のホストはローカルの使用者の接続を許可する
 1881: @file{.rhosts} を持つ必要があります。
 1882: 
 1883: 例えば、あなたがローカルマシン @file{toe.grunge.com} の利用者
 1884: @file{mozart} であり、サーバマシンは @file{chainsaw.yard.com} であると
 1885: しましょう。chainsaw では、以下の行を @file{bach} のホームディレクトリ
 1886: の @file{.rhosts} ファイルに書いてください:
 1887: 
 1888: @example
 1889: toe.grunge.com  mozart
 1890: @end example
 1891: 
 1892: そして、@code{rsh} の動作を次の行で確認します。
 1893: 
 1894: @example
 1895: rsh -l bach chainsaw.yard.com 'echo $PATH'
 1896: @end example
 1897: 
 1898: @cindex CVS_SERVER, environment variable
 1899: 次に @code{rsh} が、
 1900: サーバを発見できるかどうか確認する必要があります。
 1901: 上記の例で @code{rsh} が表示したパスの中に、
 1902: サーバである @code{cvs} のあるディレクトリが
 1903: 含まれているかどうか確認して下さい。
 1904: @file{.login} や @file{.profile} でなく、
 1905: @file{.bashrc}, @file{.cshrc} 等に
 1906: パスを設定する必要があります。
 1907: 代わりに、クライアント側で環境変数 @code{CVS_SERVER} に、
 1908: @file{/usr/local/bin/cvs-1.6} などと、
 1909: 使用したいサーバ名を設定できます。
 1910: @c FIXME: there should be a way to specify the
 1911: @c program in CVSROOT, not CVS_SERVER, so that one can use
 1912: @c different ones for different roots.  e.g. ":server;cvs=cvs-1.6:"
 1913: @c instead of ":server:".
 1914: 
 1915: @file{inetd.conf} を編集したり、
 1916: @sc{cvs} のサーバ・デーモンを走らせる必要はありません。
 1917: 
 1918: @cindex :server:, setting up
 1919: @cindex :ext:, setting up
 1920: @code{rsh} 経由で @code{$CVSROOT} を利用するときに
 1921: 指定できる接続経路は二つあります。
 1922: @code{:server:} を指定した場合、
 1923: @sc{cvs} が内部実装した @code{rsh} のクライアントが用いられますが、
 1924: 移植版では利用できないものもあります。
 1925: @code{:ext:} を指定した場合、外部の @code{rsh} プログラムが用いられます。
 1926: @code{rsh} が既定となっていますが、
 1927: サーバを利用できる他のプログラムを呼び出す場合は、
 1928: 環境変数 @code{CVS_RSH} に設定して下さい 
 1929: (例えば HP-UX 9 では、
 1930: @code{rsh} は何か別のものなので @code{remsh} を用いて下さい)。
 1931: 指定するプログラムは、データを変更しないで送受信できなくてはいけません。
 1932: 例えば Windows NT の @code{rsh} は、
 1933: 既定では @t{CRLF} を @t{LF} に換えるので不適当です。
 1934: @sc{cvs} の OS/2 版はこれを回避するため、
 1935: @code{rsh} に @samp{-b} を渡して切り抜けていますが、
 1936: 標準的な @code{rsh} でないプログラムを黙認する形になるので、
 1937: 将来は別のやり方になるでしょう。
 1938: @code{CVS_RSH} に @code{SSH} 等の @code{rsh} の代替物を設定した場合、
 1939: この節の残りの @file{.rhosts} の使用説明などは、
 1940: おそらく不適当でしょうから、
 1941: 各 @code{rsh} の代替物の文書資料を参照して下さい。
 1942: @c FIXME: there should be a way to specify the
 1943: @c program in CVSROOT, not CVS_RSH, so that one can use
 1944: @c different ones for different roots.  e.g. ":ext;rsh=remsh:"
 1945: @c instead of ":ext:".
 1946: @c See also the comment in src/client.c for rationale
 1947: @c concerning "rsh" being the default and never
 1948: @c "remsh".
 1949: 
 1950: 例を続けます。仮に @file{chainsaw.brickyard.com} の
 1951: リポジトリ @file{/usr/local/cvsroot/} 中の
 1952: モジュール @file{foo} を利用したい場合には、
 1953: もう準備はできています:
 1954: 
 1955: @example
 1956: cvs -d :ext:bach@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
 1957: @end example
 1958: 
 1959: (クライアント側とサーバ側で、使用者名が同じ場合には、
 1960: @file{bach@@} を省略することが出来ます。)
 1961: 
 1962: @c Should we mention "rsh host echo hi" and "rsh host
 1963: @c cat" (the latter followed by typing text and ^D)
 1964: @c as troubleshooting techniques?  Probably yes
 1965: @c (people tend to have trouble setting this up),
 1966: @c but this kind of thing can be hard to spell out.
 1967: 
 1968: @node Password authenticated
 1969: @subsection パスワード認証による直接接続
 1970: 
 1971: @sc{cvs} のクライアントは、
 1972: パスワード・プロトコルを用いて、
 1973: サーバと接続することもできます。
 1974: この方法は、
 1975: @code{rsh} の使用が可能でなく 
 1976: (例えばサーバが防火壁の向こうにある場合)、
 1977: またケルベロスも利用できない場合に特に有効です。
 1978: 
 1979: この方法を使用するために、
 1980: サーバとクライアント双方での調整が必要になります。
 1981: 
 1982: @menu
 1983: * Password authentication server::     サーバ側の設定
 1984: * Password authentication client::     クライアントの使用
 1985: * Password authentication security::   この方法が何をして何をしないか
 1986: @end menu
 1987: 
 1988: @node Password authentication server
 1989: @subsubsection パスワード認証のためのサーバの設定
 1990: 
 1991: まず最初に、@file{$CVSROOT} と @file{$CVSROOT/CVSROOT} ディレクトリの
 1992: 使用許可をきつくすることを考えるでしょう。詳細は @ref{Password
 1993: authentication security} を参照してください。
 1994: 
 1995: @cindex Pserver (subcommand)
 1996: @cindex password server, setting up
 1997: @cindex authenticating server, setting up
 1998: @c FIXME: this isn't quite right regarding port
 1999: @c numbers; CVS looks up "cvspserver" in
 2000: @c /etc/services (on unix, but what about non-unix?).
 2001: サーバ側では @file{/etc/inetd.conf} を編集する必要があります。
 2002: 正しいポートに接続を受けた時、
 2003: @code{inetd} がコマンド @code{cvs pserver} を実行する様に変更します。
 2004: ポート番号の既定値は 2401 ですが、
 2005: クライアントをコンパイルした時に、
 2006: @code{CVS_AUTH_PORT} に他の値を定義した場合には異なります。
 2007: 
 2008: あなたの使用する @code{inetd} が、
 2009: ポート番号を素のまま @file{/etc/inetd.conf} に書いて良いならば、
 2010: 次の記述で十分でしょう 
 2011: (@file{inetd.conf} には一行で記述して下さい):
 2012: 
 2013: @example
 2014: 2401  stream  tcp  nowait  root  /usr/local/bin/cvs
 2015: cvs --allow-root=/usr/cvsroot pserver
 2016: @end example
 2017: 
 2018: @samp{-T} オプションで一時ファイルを作成するディレクトリも指定できます。
 2019: 
 2020: @samp{--allow-root} オプションは使用可能な @sc{cvsroot} ディレクトリを
 2021: 指定します。違う @sc{cvsroot} ディレクトリの使用を試みるクライアントは
 2022: 接続できません。許可したい @sc{cvsroot} ディレクトリが2つ以上あるなら、
 2023: オプションを繰り返してください。
 2024: 
 2025: あなたの使用する @code{inetd} が、
 2026: 素のポート番号ではなく、サービス名を要求するならば、
 2027: @file{/etc/services} に次の行を追加して下さい:
 2028: 
 2029: @example
 2030: cvspserver      2401/tcp
 2031: @end example
 2032: 
 2033: そして @file{inetd.conf} には、
 2034: @code{2401} ではなく @code{cvspserver} と記述して下さい。
 2035: 
 2036: 以上を注意して行なった後、
 2037: @code{inetd} を再起動するか、
 2038: 初期設定ファイルを再読させるのに必要な処置を取って下さい。
 2039: 
 2040: @c FIXME: should be documenting how to troubleshoot
 2041: @c this.  One strange situation I ran into recently
 2042: @c was that if inetd.conf specifies a non-existent
 2043: @c cvs (e.g. /usr/local/bin/cvs doesn't exist in
 2044: @c the above example), the client says
 2045: @c   cvs-1.8 [login aborted]: unrecognized auth response from harvey:
 2046: @c which is a very unhelpful response (can it be
 2047: @c improved?  does inetd log somewhere?)
 2048: 
 2049: @cindex CVS passwd file
 2050: @cindex passwd (admin file)
 2051: クライアントはパスワードを平文のまま保存または伝送します 
 2052: (ほぼそのように---詳細は @ref{Password authentication security})。
 2053: 従って、リポジトリを利用する時に、
 2054: 正規のパスワードを危険に曝さないために、
 2055: @sc{cvs} では別のパスワードファイルを使用します。
 2056: このファイルは @file{$CVSROOT/CVSROOT/passwd} です。
 2057: その書式は、使用者名、パスワード、サーバが使用する任意に省略可能な使用
 2058: 者名という二つか三つの欄しかない事を除けば、
 2059: @file{/etc/passwd} と同様です。
 2060: 次に例示します:
 2061: 
 2062: @example
 2063: bach:ULtgRLXo7NRxs
 2064: cwang:1sOp854gDF3DY
 2065: @end example
 2066: 
 2067: パスワードは、標準 Unix の関数 @code{crypt()} によって暗号化されます。
 2068: 従って、標準 Unix の @file{passwd} から直接コピーすることも可能です。
 2069: 
 2070: パスワード認証では、まずサーバが、
 2071: @sc{cvs} の @file{passwd} ファイル中の、使用者のエントリを確認します。
 2072: 使用者のエントリがあれば、入力されたパスワードと比較されます。
 2073: 使用者のエントリが無いか、
 2074: あるいは @sc{cvs} の @file{passwd} ファイルが存在しない場合には、
 2075: システムが使用者の調査機構に使用するパスワードと一致するか試されます
 2076: (cofig ファイルで @code{SystemAuth=no} を設定することで、システムの使
 2077: 用者調査機構を使用不能にすることができます)。
 2078: サーバはエントリの三番目の欄にある使用者の権限で実行されます。
 2079: 三番目の欄が無い場合には、最初の欄にある使用者の権限が使用されます 
 2080: (つまり @sc{cvs} の @file{passwd} ファイルに、
 2081: システムで有効な使用者を併せて記述すれば、
 2082: 架空の使用者名を使用できます)。
 2083: どちらの場合でも、
 2084: (有効な) 使用者が持たない特権は付与されません。
 2085: 
 2086: @cindex user aliases
 2087: @file{$CVSROOT/CVSROOT/passwd} ファイルのパスワードの後にコロンとシス
 2088: テムの使用者名を追加することで、CVS 専用の使用者名をシステムの使用者名
 2089: に ``マップ'' することが可能です。(例えば、システムのログイン名に)。例
 2090: えば:
 2091: 
 2092: @example
 2093: cvs:ULtgRLXo7NRxs:kfogel
 2094: generic:1sOp854gDF3DY:spwang
 2095: anyone:1sOp854gDF3DY:spwang
 2096: @end example
 2097: 
 2098: こうやって、次のコマンド:
 2099: 
 2100: @example
 2101: cvs -d :pserver:cvs@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
 2102: @end example
 2103: 
 2104: で @file{chainsaw.yard.com} のリポジトリに遠隔接続する人は、認証に成功
 2105: すると、システムの kfogel としてサーバを実行することになります。しかし、
 2106: 遠隔使用者は、 @file{$CVSROOT/CVSROOT/passwd} ファイルに @sc{cvs} のみ
 2107: が使用する違ったパスワードがあるかもしれませんので、kfogel のシステム
 2108: パスワードが必ず必要なわけではありません。そして、上記の例で示されてい
 2109: るように、複数の cvs 利用者名を単一のシステムの利用者名にマップするこ
 2110: とができます。
 2111: 
 2112: この機能はリポジトリへの接続をシステムへの完全な接続を行うことなく (特
 2113: に、@ref{Read-only access} を参照してください) 可能にするために設計さ
 2114: れています。しかし、@ref{Password authentication security} も参照して
 2115: ください。どんな種類のリポジトリ接続でも、ある程度の総合的なシステム接
 2116: 続も含んでいる可能性が高いのです。
 2117: 
 2118: 現在、
 2119: @sc{cvs} の @file{passwd} ファイルにパスワードを加えるには、
 2120: 他のどこかからコピーするしか方法がありません。
 2121: いつの日か @code{cvs passwd} コマンドができることでしょう。
 2122: @c We might also suggest using the @code{htpasswd} command
 2123: @c from freely available web servers as well, but that
 2124: @c would open up a can of worms in that the users next
 2125: @c questions are likely to be "where do I get it?" and
 2126: @c "how do I use it?"
 2127: @c Also note that htpasswd, at least the version I had,
 2128: @c likes to clobber the third field.
 2129: 
 2130: @node Password authentication client
 2131: @subsubsection パスワード認証によるクライアントの使用
 2132: @cindex Login (subcommand)
 2133: @cindex password client, using
 2134: @cindex authenticated client, using
 2135: @cindex :pserver:, setting up
 2136: サーバに接続する前に、
 2137: 使用者はコマンド @code{cvs login} を用いて
 2138: @dfn{ログイン}する必要があります。
 2139: サーバのパスワード確認と同時に、
 2140: 後のサーバとの処理のためにパスワードを保存します。
 2141: コマンド @code{cvs login} は、
 2142: 使用者名, サーバのホスト名, リポジトリへのフルパス等の情報が必要で、
 2143: リポジトリの引数もしくは環境変数 @code{CVSROOT} から取得します。
 2144: 
 2145: @code{cvs login} は対話的です---それはパスワード入力を促します:
 2146: 
 2147: @example
 2148: cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot login
 2149: CVS password:
 2150: @end example
 2151: 
 2152: サーバによりパスワードが照合され、
 2153: 正しければ @code{login} が成功しますが、
 2154: 誤りであれば失敗して、パスワードが正しく無いと文句を言います。
 2155: 
 2156: 一度ログインに成功すると、@sc{cvs} に保存されたパスワードを
 2157: 使って認証し、直接サーバに接続するようにさせられます:
 2158: 
 2159: @example
 2160: cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
 2161: @end example
 2162: 
 2163: @sc{cvs} がサーバに接続する際、
 2164: @code{:pserver:} が無ければ、
 2165: @code{rsh} が用いられます (@pxref{Connecting via rsh})。
 2166: 従って、必ず @code{:pserver:} を付加して下さい。
 2167: (一旦作業コピーを取り出した後、
 2168: 作業ディレクトリ中で @sc{cvs} を実行する場合には、
 2169: もう明示的にリポジトリの指定をする必要はありません。
 2170: @sc{cvs} は作業コピーのサブディレクトリ @file{CVS} に、
 2171: 引数のリポジトリを記録しているためです。)
 2172: 
 2173: パスワードは、既定ではファイル @file{$HOME/.cvspass} に保存されます。
 2174: ファイルは人が読める書式で書かれていますが、
 2175: 十分な知識無しに編集してはいけません。
 2176: パスワードは平文ではなく、
 2177: "悪気無く"見られる事 (つまり、システム管理者が偶然そのファイルを見付け、
 2178: 不注意に見るといった事) を防ぐために、
 2179: 簡単な符号化がなされています。
 2180: 
 2181: @c FIXME: seems to me this needs somewhat more
 2182: @c explanation.
 2183: @cindex Logout (subcommand)
 2184: 現在選ばれている遠隔リポジトリのパスワードは @code{cvs logout} コマン
 2185: ドを使用すると CVS_PASSFILE から消去できます。
 2186: 
 2187: 環境変数 @code{CVS_PASSFILE} は、この既定値に優先します。
 2188: この変数を使用するのであれば、
 2189: @code{cvs login} を実行する@emph{前に}設定しなければいけません。
 2190: @code{cvs login} を実行した後に設定した場合、
 2191: その後の @sc{cvs} コマンドは、
 2192: サーバに送るパスワードを見付けられません。
 2193: 
 2194: @node Password authentication security
 2195: @subsubsection パスワード認証における安全性の考察
 2196: 
 2197: @cindex security, of pserver
 2198: パスワードは、
 2199: 平文を簡単に符号化してクライアント側に保存されており、
 2200: 送信の際も同じ符号化が用いられます。
 2201: この符号化は、パスワードが偶然見られること (すなわちシステム管理者が
 2202: 不注意に見てしまう事) を防ぐためのもので、
 2203: 素人の攻撃からパスワードの取得を防ぐことさえ出来ません。
 2204: 
 2205: @c FIXME: The bit about "access to the repository
 2206: @c implies general access to the system is *not* specific
 2207: @c to pserver; it applies to kerberos and SSH and
 2208: @c everything else too.  Should reorganize the
 2209: @c documentation to make this clear.
 2210: @sc{cvs} 独自のパスワードファイルにより 
 2211: (@pxref{Password authentication server})、
 2212: リポジトリを利用する時には、
 2213: システムにログインする時とは別のパスワードが使用できます。
 2214: しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、
 2215: 多様な方法により、サーバ上でプログラムが実行可能になります。
 2216: つまりリポジトリの利用は、
 2217: かなり広範囲にシステムが利用できる事を暗示しています。
 2218: これを防止するように @sc{cvs} を修正する事は可能でしょうが、
 2219: これを書いている時点までには誰もやっていません。
 2220: @c OpenBSD uses chroot() and copies the repository to
 2221: @c provide anonymous read-only access (for details see
 2222: @c http://www.openbsd.org/anoncvs.shar).  While this
 2223: @c closes the most obvious holes, I'm not sure it
 2224: @c closes enough holes to recommend it (plus it is
 2225: @c *very* easy to accidentally screw up a setup of this
 2226: @c type).
 2227: さらに @sc{cvs} を利用して、
 2228: システムに対するより一般的な権限を獲得する別の方法が存在するでしょう。
 2229: しかし誰も徹底した審査を行っていません。
 2230: 
 2231: @file{$CVSROOT/CVSROOT} ディレクトリには @file{passwd} と他のセキュリ
 2232: ティを調べるために使われるファイルがあるので、このディレクトリの使用許
 2233: 可をを @file{/etc} と同じくらいきつくしなければならないことに注意して
 2234: ください。同じことが @file{$CVSROOT} ディレクトリそのものと、木のそれ
 2235: より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ
 2236: クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが
 2237: できます。これらの使用許可は普通は pserver を使っていないときに使用す
 2238: るものよりもきついものであることに注意してください。
 2239: @c TODO: Would be really nice to document/implement a
 2240: @c scheme where the CVS server can run as some non-root
 2241: @c user, e.g. "cvs".  CVSROOT/passwd would contain a
 2242: @c bunch of entries of the form foo:xxx:cvs (or the "cvs"
 2243: @c would be implicit).  This would greatly reduce
 2244: @c security risks such as those hinted at in the
 2245: @c previous paragraph.  I think minor changes to CVS
 2246: @c might be required but mostly this would just need
 2247: @c someone who wants to play with it, document it, &c.
 2248: 
 2249: 要約すると、
 2250: パスワードを得た人物は誰でもリポジトリを利用でき、
 2251: またある程度通常のシステム利用も可能になります。
 2252: ネットワークのパケットを漁ったり、
 2253: 保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、
 2254: 全ての人物がパスワードを入手可能です。
 2255: あなたが本物の安全を望むのならば、ケルベロスにしましょう。
 2256: 
 2257: @node GSSAPI authenticated
 2258: @subsection GSSAPI による直接接続
 2259: 
 2260: @cindex GSSAPI
 2261: @cindex security, GSSAPI
 2262: @cindex :gserver:, setting up
 2263: GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般
 2264: 的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、
 2265: @sc{cvs} を GSSAPI で認証して、直接 @sc{tcp} 接続を通して接続すること
 2266: ができます。
 2267: 
 2268: これをするためには、@sc{cvs} が GSSAPI サポート付きでコンパイルされて
 2269: いる必要があります。@sc{cvs} を configure しているときに、ケルベロス 
 2270: version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま
 2271: す。構築するために @file{--with-gssapi} も使用できます。
 2272: 
 2273: 接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認
 2274: 証@emph{されません}。ストリームの認証を要求するためには、広域オプショ
 2275: ン @code{-a} を使用する必要があります。
 2276: 
 2277: 既定状態では、データ転送は暗号化@emph{されません}。
 2278: クライアントとサーバ双方を、
 2279: 暗号化を有効にしてコンパイルしておく必要があります。
 2280: 構築時に @file{--enable-encryption} オプションを付加して、
 2281: 暗号化機能を有効にして下さい。
 2282: また暗号化を要求するために、
 2283: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2284: 
 2285: GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ
 2286: れます。@ref{Password authentication server} 参照。ケルベロスのような
 2287: 強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ
 2288: る認証を使用不能にしたいと思うかもしれません。そのためには、空の 
 2289: @file{CVSROOT/passwd} パスワードファイルを作成して、config ファイルで 
 2290: @code{SystemAuth=no} を設定します (@pxref{config})。
 2291: 
 2292: GSSAPI サーバは cvs/@var{hostname} の主な名前を使い、@var{hostname} は
 2293: サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ
 2294: うにこれを設定しなければなりません。
 2295: 
 2296: GSSAPI を使用して接続するには、@samp{:gserver:} を使用します。例えば、
 2297: 以下のようになります。
 2298: 
 2299: @example
 2300: cvs -d :gserver:chainsaw.yard.com:/usr/local/cvsroot checkout foo
 2301: @end example
 2302: 
 2303: @node Kerberos authenticated
 2304: @subsection ケルベロスによる直接接続
 2305: 
 2306: @cindex kerberos
 2307: @cindex security, kerberos
 2308: @cindex :kserver:, setting up
 2309: ケルベロスを使う一番簡単な方法は @ref{Connecting via rsh} で説明されて
 2310: いるようにケルベロスの @code{rsh} を使用することです。
 2311: rsh を利用する際の主な欠点は、
 2312: 全てのデータが他のプログラムを経由する必要があるため、
 2313: 時間がかかるかもしれない事です。
 2314: もしケルベロスが導入されているならば、
 2315: ケルベロスの認証により、直接 @sc{tcp} 接続する事が可能です
 2316: 
 2317: この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関
 2318: するものです。ケルベロス バージョン5は前節で説明されているように、
 2319: GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ
 2320: うになっています。
 2321: 
 2322: このためには、
 2323: ケルベロスの支援を受けるように @sc{cvs} をコンパイルする必要があります。
 2324: @sc{cvs} は configre 時に
 2325: ケルベロスが利用できるかどうかを検出しようとしますが、
 2326: 駄目ならフラグ @file{--with-krb4} を用いて強制させることも可能です。
 2327: 
 2328: 既定状態では、データ転送は暗号化され@emph{ません}。
 2329: クライアントとサーバ双方を、
 2330: 暗号化を有効にしてコンパイルしておく必要があります。
 2331: 構築時に @file{--enable-encryption} オプションを付加して、
 2332: 暗号化機能を有効にして下さい。
 2333: また暗号化を要求するために、
 2334: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2335: 
 2336: @cindex CVS_CLIENT_PORT
 2337: サーバの @file{inetd.conf} を編集する必要があります。
 2338: クライアントが使用する既定のポート番号は 1999 です。
 2339: 他のポートを使用したい場合には、
 2340: クライアントの環境変数 @code{CVS_CLIENT_PORT} で指定して下さい。
 2341: 
 2342: @cindex kinit
 2343: @sc{cvs} を利用する前に、
 2344: 通常の方法で切符を取得して下さい (一般的には @code{kinit} です)。
 2345: この切符でサーバへのログインが許可されるはずです。
 2346: これで準備ができました:
 2347: 
 2348: @example
 2349: cvs -d :kserver:chainsaw.yard.com:/usr/local/cvsroot checkout foo
 2350: @end example
 2351: 
 2352: ここで接続に失敗した場合、
 2353: 以前のバージョンの @sc{cvs} は rsh で再接続を試みましたが、
 2354: このバージョンでは再試行されません。
 2355: 
 2356: @c ---------------------------------------------------------------------
 2357: @node Read-only access
 2358: @section 読み込み専用リポジトリ接続
 2359: @cindex read-only repository access
 2360: @cindex readers (admin file)
 2361: @cindex writers (admin file)
 2362: 
 2363: パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める
 2364: ことができます (@pxref{Password authenticated})。 (他の接続方法は全て
 2365: リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用
 2366: 許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助
 2367: はありません。)
 2368: 
 2369: 読み込み専用接続の使用者は、特定の ``管理'' ファイル (ロックファイルや
 2370: 履歴ファイル) を除いて、リポジトリを変更しない @sc{cvs} の操作のみを実
 2371: 行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ
 2372: う (@pxref{Password authentication server})。
 2373: 
 2374: 以前のバージョンの @sc{cvs} と違って、読み込み専用使用者はリポジトリを
 2375: 読むことができるだけで、サーバのプログラムを実行できないようになってい
 2376: るはずです。そうしないと、予期しないレベルの接続を得ることができてしま
 2377: います。もしくは、より正確に言うと、@emph{既知の}穴は塞がれました。こ
 2378: の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ
 2379: リティへの関心に従って、どのような程度の注意も払うべきというのは正当の
 2380: ようです。
 2381: 
 2382: 使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除
 2383: です。
 2384: 
 2385: "包含" は、使用者を特別に @file{$CVSROOT/CVSROOT/readers} ファイルに一
 2386: 覧表示するということで、それは単純な改行で分離された利用者の一覧です。
 2387: これは @file{readers} ファイルの例です:
 2388: 
 2389: @example
 2390: melissa
 2391: splotnik
 2392: jrandom
 2393: @end example
 2394: 
 2395: (最後の使用者の後の改行を忘れないでください。)
 2396: 
 2397: "排除" は @emph{書き込み} 接続のできる人を全て明示的に一覧表示するとい
 2398: うことです---もしファイル
 2399: 
 2400: @example
 2401: $CVSROOT/CVSROOT/writers
 2402: @end example
 2403: 
 2404: @noindent
 2405: が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その
 2406: 他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相
 2407: 変らず @sc{cvs} @file{passwd} ファイルに挙げられている必要があります。)
 2408: @file{writers} ファイル は @file{readers} ファイルと同じ書式です。
 2409: 
 2410: 注意: @sc{cvs} @file{passwd} ファイルが cvs の使用者をシステムの使用者
 2411: にマップしているときは、@emph{cvs} の使用者名を使って書き込み専用接続
 2412: を拒否したり認めたりしていて、システムの使用者名を使っていないことを確
 2413: 認してください。すなわち、@file{readers} と @file{writers} ファイルに
 2414: cvs の使用者名があるということで、それはシステムの使用者名と同じかもし
 2415: れませんし、違うかもしれません。
 2416: 
 2417: これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ
 2418: の振舞いの完全な説明です。
 2419: 
 2420: @file{readers} が存在して、この使用者がそこに挙げられていれば、読み込
 2421: み専用接続になります。もしくは、@file{writers} が存在していて、使用者
 2422: がそこに挙げられていなければ読み込み専用接続になります (@file{readers}
 2423: が存在するけれど、そこには挙げられていないというときにもそのようになり
 2424: ます)。その他の場合では、完全な読み込み書き込み接続になります。
 2425: 
 2426: もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。
 2427: これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより
 2428: 多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな
 2429: ります。
 2430: 
 2431: @node Server temporary directory
 2432: @section サーバの一時ディレクトリ
 2433: @cindex temporary directories, and server
 2434: @cindex server, temporary directories
 2435: 
 2436: @sc{cvs} サーバは実行中に一時ディレクトリを作成します。それは
 2437: 
 2438: @example
 2439: cvs-serv@var{pid}
 2440: @end example
 2441: 
 2442: @noindent
 2443: のような名前で、@var{pid} はサーバのプロセス番号です。それらは環境変数
 2444: @samp{TMPDIR} (@pxref{Environment variables})、@samp{-T} 広域オプショ
 2445: ン (@pxref{Global options})、で指定されるディレクトリもしくは、それら
 2446: がないと @file{/tmp} に置かれます。
 2447: 
 2448: ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時
 2449: ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな
 2450: い場合がいくつかあります。例えば:
 2451: 
 2452: @itemize @bullet
 2453: @item
 2454: サーバがサーバの内部エラーで異常終了すると、デバッグを助けるためにディ
 2455: レクトリを保存するかもしれません。
 2456: 
 2457: @item
 2458: サーバが後始末をできない方法で kill されたとき (主にほとんど unix での 
 2459: @samp{kill -KILL})。
 2460: 
 2461: @item
 2462: システムが、サーバに後始末をするように告げる通常のシャットダウンをする
 2463: ことなくシャットダウンしたとき。
 2464: @end itemize
 2465: 
 2466: このような場合は、手で @file{cvs-serv@var{pid}} ディレクトリを消去する
 2467: 必要があります。プロセス番号 @var{pid} で動いているサーバが無ければ、
 2468: その行為は安全です。
 2469: 
 2470: @c ---------------------------------------------------------------------
 2471: @node Starting a new project
 2472: @chapter CVS でプロジェクトを始める
 2473: @cindex Starting a project with CVS
 2474: @cindex Creating a project
 2475: 
 2476: @comment --moduledb--
 2477: ファイルの改名とディレクトリ間の移動はうまくできないので、
 2478: 新しいプロジェクトを始めるときには、
 2479: 最初にファイルの構成をよく考えておく必要があります。
 2480: ファイルの改名や移動は、
 2481: 不可能ではありませんが非常にやっかいです。
 2482: 特にディレクトリの改名に関して、
 2483: @sc{cvs} は癖のある動作をします 
 2484: (@pxref{Moving files})。
 2485: 
 2486: 次に何をするかは、始める状況に依ります。
 2487: 
 2488: @menu
 2489: * Setting up the files::        ファイルをリポジトリに加える
 2490: * Defining the module::         ファイルからモジュールを作る
 2491: @end menu
 2492: @c -- File permissions!
 2493: 
 2494: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2495: @node Setting up the files
 2496: @section ファイルの準備
 2497: 
 2498: 始めの一歩は、リポジトリ中にファイルを生成することです。
 2499: これには幾つか異なる方法があります。
 2500: 
 2501: @c -- The contributed scripts
 2502: @menu
 2503: * From files::                  既存のプロジェクトに便利な方法
 2504:                                 (既にファイルが存在する場合)
 2505: * From other version control systems::  古いプロジェクトの、他の
 2506:                                         システムでの履歴を保存する
 2507: * From scratch::                ゼロからディレクトリを作成する
 2508: @end menu
 2509: 
 2510: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2511: @node From files
 2512: @subsection 存在するファイルからディレクトリを生成する
 2513: @cindex Importing files
 2514: 
 2515: @sc{cvs} を使い始める場合に、
 2516: おそらく @sc{cvs} を使用できるプロジェクトが
 2517: 既に幾つかあるでしょう。
 2518: この場合 @code{import} コマンドを使用するのが最も簡単です。
 2519: 例を挙げて説明します。
 2520: @sc{cvs} に組み込みたいファイルが @file{@var{wdir}} にあり、
 2521: それを @file{$CVSROOT/yoyodyne/@var{rdir}} に置きたい時、
 2522: 次のようにします。
 2523: 
 2524: @example
 2525: $ cd @var{wdir}
 2526: $ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
 2527: v@end example
 2528: 
 2529: @samp{-m} フラグでログ・メッセージを与えなかった場合、@sc{cvs} により
 2530: エディタが開かれ、メッセージの入力が促されます。文字列 @samp{yoyo} は 
 2531: @dfn{ベンダー・タグ}と呼ばれるものであり、
 2532: @samp{start} は@dfn{リリース・タグ}と呼ばれるもの
 2533: です。この文脈では意味をなさないかもしれませんが、@sc{cvs} はそれらの
 2534: 存在を要求します。詳しくは @xref{Tracking sources}.
 2535: 
 2536: では実際に動作したことを確かめた後、元のソースディレクトリを削除します。
 2537: @c FIXME: Need to say more about "verify that it
 2538: @c worked".  What should the user look for in the output
 2539: @c from "diff -r"?
 2540: 
 2541: @example
 2542: $ cd ..
 2543: $ mv @var{dir} @var{dir}.orig
 2544: $ cvs checkout yoyodyne/@var{dir}       # @r{下で説明}
 2545: $ diff -r @var{dir}.orig yoyodyne/@var{dir}
 2546: $ rm -r @var{dir}.orig
 2547: @end example
 2548: 
 2549: @noindent
 2550: 誤って @sc{cvs} を通さないで編集してしまわないように、下のソースを削除
 2551: すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るの
 2552: が賢明です。
 2553: 
 2554: @code{checkout} コマンドはモジュールの名前 (以前の全ての例のように)、
 2555: または @code{$CVSROOT} からの相対パス (上の例のように) を引数に取りま
 2556: す。
 2557: 
 2558: @sc{cvs} が @samp{$CVSROOT} 中のディレクトリに設定した
 2559: 使用許可とグループ属性が、
 2560: 適切かどうか調べると良いでしょう。@xref{File permissions}.
 2561: 
 2562: 取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、
 2563: wrapper 機能を用いて、どのファイルがバイナリなのか
 2564: 明示するとよいでしょう。@xref{Wrappers}.
 2565: 
 2566: @c The node name is too long, but I am having trouble
 2567: @c thinking of something more concise.
 2568: @node From other version control systems
 2569: @subsection 他のバージョン管理システムからファイルを作成する
 2570: @cindex Importing files, from other version control systems
 2571: 
 2572: @sc{rcs} 等の、
 2573: 他のバージョン管理システムで保守されてきたプロジェクトがあり、
 2574: そのプロジェクトのファイルを @sc{cvs} に移管する場合、
 2575: 各ファイルの修正履歴の維持を望むでしょう。
 2576: 
 2577: @table @asis
 2578: @cindex RCS, importing files from
 2579: @item RCS から
 2580: @sc{rcs} を使用してきた場合、@sc{rcs} ファイルを見付けて下さい---
 2581: 通常 @file{foo.c} という名前のファイルには、
 2582: @file{RCS/foo.c,v} という @sc{rcs} ファイルが対応します 
 2583: (他の場所にあるかもしれませんので、
 2584: 詳細は @sc{rcs} の文書を調べて下さい)。
 2585: 次に、@sc{cvs} リポジトリに適当なディレクトリを作成して下さい。
 2586: そして @sc{cvs} リポジトリの当該ディレクトリに、
 2587: ファイルをコピーして下さい 
 2588: (リポジトリ中のファイル名は、
 2589: ソース・ファイルに @samp{,v} が付加されたものでなくてはならず、
 2590: またファイルは @file{RCS} サブディレクトリではなく、
 2591: 当該ディレクトリに直接置いて下さい)。
 2592: この例のように、@sc{cvs} コマンドを利用せず、
 2593: @sc{cvs} リポジトリを直接利用するほうが適当な場合が稀にあります。
 2594: 以上で作業コピーを新たに取り出す準備ができました。
 2595: @c Someday there probably should be a "cvs import -t
 2596: @c rcs" or some such.  It could even create magic
 2597: @c branches.  It could also do something about the case
 2598: @c where the RCS file had a (non-magic) "0" branch.
 2599: 
 2600: @sc{rcs} ファイルを @sc{cvs} に移動するときに、
 2601: ロックされていてはいけません。
 2602: ロックされている場合には、@sc{cvs} での操作に支障を来します。
 2603: @c What is the easiest way to unlock your files if you
 2604: @c have them locked?  Especially if you have a lot of them?
 2605: @c This is a CVS bug/misfeature; importing RCS files
 2606: @c should ignore whether they are locked and leave them in
 2607: @c an unlocked state.  Yet another reason for a separate
 2608: @c "import RCS file" command.
 2609: 
 2610: @c How many is "many"? Or do they just import RCS files?
 2611: @item 他のバージョン管理システムから
 2612: 多くのバージョン管理システムは、
 2613: 標準形式の @sc{rcs} ファイルを出力する機能を持っています。
 2614: これが可能ならば、@sc{rcs} ファイルを出力して、
 2615: 前項の説明に従って下さい。
 2616: 
 2617: それが駄目なら、おそらく一番良いのは他のシステムのコマンド行のインター
 2618: フェースを使って一回に一つのリビジョンを取り出し、それを @sc{cvs} に格
 2619: 納するスクリプトを書くことでしょう。下の @file{sccs2rs} スクリプトはそ
 2620: のために役に立つ例でしょう。
 2621: 
 2622: @cindex SCCS, importing files from
 2623: @item From SCCS
 2624: @item SCCS から
 2625: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2626: @file{sccs2rcs} という名前のスクリプトがあります。
 2627: これを用いて @sc{sccs} ファイルを @sc{rcs} ファイルに変換できます。
 2628: 注意: @sc{sccs} と @sc{rcs} の両方を持つマシンで実行する必要があり、
 2629: また @file{contrib} 内の他の全てと同様に動作保証はされません 
 2630: (使用者によって評価は異なるでしょう)。
 2631: 
 2632: @cindex PVCS, importing files from
 2633: @item From PVCS
 2634: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2635: @file{pvcs_to_rcs} という名前のスクリプトがあります。
 2636: これを用いて @sc{pvcs} アーカイブを @sc{rcs} ファイルに変換できます。
 2637: @sc{pvcs} と @sc{rcs} のあるマシンで実行する必要があり、
 2638: また @file{contrib} 内の他の全てと同様に動作保証はされません
 2639: (使用者によって評価は異なるでしょう)。
 2640: 詳細はスクリプト中のコメントを読んでください。
 2641: @end table
 2642: @c CMZ and/or PATCHY were systems that were used in the
 2643: @c high energy physics community (especially for
 2644: @c CERNLIB).  CERN has replaced them with CVS, but the
 2645: @c CAR format seems to live on as a way to submit
 2646: @c changes.  There is a program car2cvs which converts
 2647: @c but I'm not sure where one gets a copy.
 2648: @c Not sure it is worth mentioning here, since it would
 2649: @c appear to affect only one particular community.
 2650: @c Best page for more information is:
 2651: @c http://wwwcn1.cern.ch/asd/cvs/index.html
 2652: @c See also:
 2653: @c http://ecponion.cern.ch/ecpsa/cernlib.html
 2654: 
 2655: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2656: @node From scratch
 2657: @subsection ゼロからディレクトリを作る
 2658: 
 2659: @c Also/instead should be documenting
 2660: @c $ cvs co -l .
 2661: @c $ mkdir tc
 2662: @c $ cvs add tc
 2663: @c $ cd tc
 2664: @c $ mkdir man
 2665: @c $ cvs add man
 2666: @c etc.
 2667: @c Using import to create the directories only is
 2668: @c probably a somewhat confusing concept.
 2669: 新しいプロジェクトを始める場合、
 2670: まず次のように空のディレクトリを作ります。
 2671: 
 2672: @example
 2673: $ mkdir tc
 2674: $ mkdir tc/man
 2675: $ mkdir tc/testing
 2676: @end example
 2677: 
 2678: その後 @code{import} コマンドを使って、
 2679: リポジトリに各々の (空の) ディレクトリを登録(作成)します:
 2680: 
 2681: @example
 2682: $ cd tc
 2683: $ cvs import -m "Created directory structure" yoyodyne/@var{dir} yoyo start
 2684: @end example
 2685: 
 2686: そして @code{add} コマンドで、
 2687: ファイル (と新しいディレクトリ) を加えていきます。
 2688: 
 2689: その時、 @samp{$CVSROOT} の中のファイルの使用許可が、
 2690: 正しいものかどうかを確認すると良いでしょう。
 2691: 
 2692: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2693: @node Defining the module
 2694: @section モジュールの定義
 2695: @cindex Defining a module
 2696: @cindex Editing the modules file
 2697: @cindex Module, defining
 2698: @cindex Modules file, changing
 2699: 
 2700: 二歩目は @file{modules} ファイルにモジュールの定義をする事です。
 2701: 必ずしも必要ではありませんが、
 2702: 関連するファイルやディレクトリをグループ化するのに便利です。
 2703: 
 2704: モジュールを定義する簡単な手順を示します。
 2705: 
 2706: @enumerate
 2707: @item
 2708: ファイル modules の作業コピーを取ってきます。
 2709: 
 2710: @example
 2711: $ cvs checkout CVSROOT/modules
 2712: $ cd CVSROOT
 2713: @end example
 2714: 
 2715: @item
 2716: ファイルを編集し、モジュールの定義を加えます。
 2717: 導入は @xref{Intro administrative files}.
 2718: 詳細な記述は @ref{modules} 参照。
 2719: モジュール @samp{tc} を定義するには次の行を加えます:
 2720: 
 2721: @example
 2722: tc   yoyodyne/tc
 2723: @end example
 2724: 
 2725: @item
 2726: modules ファイルに変更を格納します。
 2727: 
 2728: @example
 2729: $ cvs commit -m "Added the tc module." modules
 2730: @end example
 2731: 
 2732: @item
 2733: モジュール modules をリリースします。
 2734: 
 2735: @example
 2736: $ cd ..
 2737: $ cvs release -d CVSROOT
 2738: @end example
 2739: @end enumerate
 2740: 
 2741: @c ---------------------------------------------------------------------
 2742: @node Revisions
 2743: @chapter リビジョン
 2744: 
 2745: @sc{cvs} の多くの利用ではあまりリビジョン番号について心配する必要はあ
 2746: りません。@sc{cvs} は @code{1.1}, @code{1.2} などのような番号を割当て、
 2747: それだけが皆が知る必要のあることです。しかし、@sc{cvs} がリビジョン番
 2748: 号を割当てる方法に関してより知識を持ち、より制御したい人もいます。
 2749: 
 2750: どのリビジョンが特定のリリースになったか、などの 1 つより多くのファイ
 2751: ルを含むリビジョンの組を追いかけたいときは、@dfn{タグ} を使います。そ
 2752: れはそれぞれのファイルの数字リビジョンに割当てることのできるリビジョン
 2753: 名です。
 2754: 
 2755: @menu
 2756: * Revision numbers::            リビジョン番号の意味
 2757: * Versions revisions releases::  このマニュアルでの用語
 2758: * Assigning revisions::         リビジョンの割当て
 2759: * Tags::                        タグ--文字によるリビジョン
 2760: * Sticky tags::                 貼り付いたタグ
 2761: @end menu
 2762: 
 2763: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2764: @node Revision numbers
 2765: @section リビジョン番号
 2766: @cindex Revision numbers
 2767: @cindex Revision tree
 2768: @cindex Linear development
 2769: @cindex Number, revision-
 2770: @cindex Decimal revision number
 2771: @cindex Branch number
 2772: @cindex Number, branch
 2773: 
 2774: 各バージョンのファイルはそれぞれ一意な@dfn{リビジョン番号} 
 2775: (@dfn{revision number}) を持ちます。
 2776: @samp{1.1}, @samp{1.2} とか @samp{1.3.2.2} とか 
 2777: @samp{1.3.2.2.4.5} なんてのもあります。
 2778: リビジョン番号はピリオドで分けられた偶数個の十進整数です。
 2779: 初期設定ではファイルの最初のリビジョンは 1.1 で、
 2780: リビジョンが新しくなると一番右の番号が1つ増えます。
 2781: 次の絵は、新しいリビジョンを右にして少しリビジョンを図示しています。
 2782: 
 2783: @example
 2784:        +-----+    +-----+    +-----+    +-----+    +-----+
 2785:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 2786:        +-----+    +-----+    +-----+    +-----+    +-----+
 2787: @end example
 2788: 
 2789: 2 つ以上のピリオドを含む番号になることもあります。例えば、
 2790: @samp{1.3.2.2} です。そのようなリビジョンは枝のリビジョンを表します 
 2791: (@pxref{Branching and merging})。そのようなリビジョン番号は 
 2792: @ref{Branching and merging} で詳しく説明されています。
 2793: 
 2794: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2795: @node Versions revisions releases
 2796: @section バージョン、リビジョン、リリース
 2797: @cindex Revisions, versions and releases
 2798: @cindex Versions, revisions and releases
 2799: @cindex Releases, revisions and versions
 2800: 
 2801: 上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト
 2802: ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ
 2803: く @samp{4.1.1} のようなバージョン番号を付けられます。
 2804: 
 2805: バージョンには二つの意味があり、
 2806: 最初のものはこの文書で@dfn{リビジョン}と呼ばれるものです。
 2807: 二番目は@dfn{リリース}と呼ばれるものです。
 2808: 混乱を避けるために、
 2809: この文書ではなるべく@dfn{バージョン}という単語は使わないようにします。
 2810: 
 2811: @node Assigning revisions
 2812: @section リビジョンの割当て
 2813: 
 2814: @c We avoid the "major revision" terminology.  It seems
 2815: @c like jargon.  Hopefully "first number" is clear enough.
 2816: 初期設定では、@sc{cvs} は最初の番号を同じにして 2番目の番号を増加させ
 2817: ることにより数字リビジョンを割当てます。例えば、@code{1.1},
 2818: @code{1.2}, @code{1.3} のように。
 2819: 
 2820: 新しいファイルを加えるときは、2番目の番号は常に 1 で、最初の番号はその
 2821: ディレクトリの中のファイルの最初の番号の一番大きいものと等しくなります。
 2822: 例えば、現在のディレクトリの一番大きい番号が @code{1.7}, @code{3.1},
 2823: @code{4.12} であると、追加されたファイルの数字リビジョンは @code{4.1}
 2824: になります。
 2825: 
 2826: @c This is sort of redundant with something we said a
 2827: @c while ago.  Somewhere we need a better way of
 2828: @c introducing how the first number can be anything
 2829: @c except "1", perhaps.  Also I don't think this
 2830: @c presentation is clear on why we are discussing releases
 2831: @c and first numbers of numeric revisions in the same
 2832: @c breath.
 2833: 普通はリビジョン番号を気にかける必要はありません---それを @sc{cvs} が
 2834: 維持している内部番号のように扱う方が簡単で、タグは製品リリース 1 とリ
 2835: リース 2 のような間を区別するより良い手段です (@pxref{Tags})。 しかし、
 2836: 数字リビジョンを設定したいのであれば、@code{cvs commit} の @samp{-r}
 2837: オプションですることができます。@samp{-r} オプションは @samp{-f} オプ
 2838: ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
 2839: ということになります。
 2840: 
 2841: 例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな
 2842: いものも含めて)、次のように実行するかもしれません:
 2843: 
 2844: @example
 2845: $ cvs commit -r 3.0
 2846: @end example
 2847: 
 2848: @samp{-r} で指定する番号は存在するリビジョン番号より大きくなければなら
 2849: ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、
 2850: @samp{cvs commit -r 1.3} とはできないということです。複数のリリースを
 2851: 並行して維持したいときは、枝を使う必要があります (@pxref{Branching and
 2852: merging}).
 2853: 
 2854: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2855: @node Tags
 2856: @section タグ--文字によるリビジョン
 2857: @cindex Tags
 2858: 
 2859: リビジョン番号は開発に従って徐々に増えていきますが、
 2860: ソフトウェア製品のリリース番号とは全く何の関係もありません。
 2861: @sc{cvs} の使い方にもよりますが、
 2862: 異なる二つのリリースにおけるリビジョン番号は異なっているでしょう。
 2863: 例えば @sc{rcs} 5.6 を作るソース・ファイルは、
 2864: 次のようなリビジョン番号を持ちます:
 2865: @cindex RCS revision numbers
 2866: 
 2867: @example
 2868: ci.c            5.21
 2869: co.c            5.9
 2870: ident.c         5.3
 2871: rcs.c           5.12
 2872: rcsbase.h       5.11
 2873: rcsdiff.c       5.10
 2874: rcsedit.c       5.11
 2875: rcsfcmp.c       5.9
 2876: rcsgen.c        5.10
 2877: rcslex.c        5.11
 2878: rcsmap.c        5.2
 2879: rcsutil.c       5.10
 2880: @end example
 2881: 
 2882: @cindex tag, command, introduction
 2883: @cindex Tag, symbolic name
 2884: @cindex Symbolic name (tag)
 2885: @cindex Name, symbolic (tag)
 2886: @cindex HEAD, as reserved tag name
 2887: @cindex BASE, as reserved tag name
 2888: @code{tag} コマンドを使えば、
 2889: 特定のリビジョンに名前 (タグ名) を付けることができます。
 2890: 各ファイルに付けられた全てのタグと
 2891: 対応するリビジョン番号を調べたい場合は、
 2892: @code{status} コマンドに @samp{-v} フラグを付けて下さい。
 2893: タグには、大文字と小文字で始まる必要があり、大文字, 小文字, 数字,
 2894: @samp{-}, @samp{_} が使用可能です。
 2895: @code{BASE} と @code{HEAD} の二つのタグ名は、
 2896: @sc{cvs} が使用するために予約されています。
 2897: 将来使われる @sc{cvs} にとって特別な名前は、実際のタグ名との衝突を避け
 2898: るために @code{BASE} や @code{HEAD} などのような名前ではなく、例えば 
 2899: @samp{.} で始まるような特別な方法で命名されることが望まれています。
 2900: @c Including a character such as % or = has also been
 2901: @c suggested as the naming convention for future
 2902: @c special tag names.  Starting with . is nice because
 2903: @c that is not a legal tag name as far as RCS is concerned.
 2904: @c FIXME: CVS actually accepts quite a few characters
 2905: @c in tag names, not just the ones documented above
 2906: @c (see RCS_check_tag).  RCS
 2907: @c defines legitimate tag names by listing illegal
 2908: @c characters rather than legal ones.  CVS is said to lose its
 2909: @c mind if you try to use "/" (try making such a tag sticky
 2910: @c and using "cvs status" client/server--see remote
 2911: @c protocol format for entries line for probable cause).
 2912: @c TODO: The testsuite
 2913: @c should test for whatever are documented above as
 2914: @c officially-OK tag names, and CVS should at least reject
 2915: @c characters that won't work, like "/".
 2916: 
 2917: タグの命名にプログラムの名前とリリースのバージョン番号のような情報に基
 2918: いた何らかの習慣を選びたいでしょう。例えば、CVS 1.9 が @code{cvs1-9} 
 2919: という名前でタグ付けされるように、まずプログラムの名前を使い、その直後
 2920: にバージョン番号の @samp{.} を @samp{-} に変更したものを続けるかもしれ
 2921: ません。同じ習慣を続ければ、常にタグが @code{cvs-1-9} や @code{cvs1_9}
 2922: や他のものであったかを推測する必要はなくなります。taginfo ファイルでそ
 2923: の習慣を強制することさえ考えるかもしれません (@pxref{user-defined
 2924: logging}).
 2925: @c Might be nice to say more about using taginfo this
 2926: @c way, like giving an example, or pointing out any particular
 2927: @c issues which arise.
 2928: 
 2929: @cindex Adding a tag
 2930: @cindex tag, example
 2931: 次の例は、ファイルにタグを付ける方法を示したものです。
 2932: コマンドはあなたの作業ディレクトリで実行して下さい。
 2933: すなわち、@file{backend.c} があるディレクトリでコマンドを実行すべきで
 2934: ある、ということです。
 2935: 
 2936: @example
 2937: $ cvs tag rel-0-4 backend.c
 2938: T backend.c
 2939: $ cvs status -v backend.c
 2940: ===================================================================
 2941: File: backend.c         Status: Up-to-date
 2942: 
 2943:     Version:            1.4     Tue Dec  1 14:39:01 1992
 2944:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 2945:     Sticky Tag:         (none)
 2946:     Sticky Date:        (none)
 2947:     Sticky Options:     (none)
 2948: 
 2949:     Existing Tags:
 2950:         rel-0-4                     (revision: 1.4)
 2951: 
 2952: @end example
 2953: 
 2954: 単独のファイルにタグを付けるべき理由はほとんどありません。
 2955: タグの主な使い途は、
 2956: モジュールを構成する全てのファイルに同じタグを付け、
 2957: 開発の流れの重要点 (リリース時等) を示すことです。
 2958: 
 2959: @example
 2960: $ cvs tag rel-1-0 .
 2961: cvs tag: Tagging .
 2962: T Makefile
 2963: T backend.c
 2964: T driver.c
 2965: T frontend.c
 2966: T parser.c
 2967: @end example
 2968: 
 2969: (@sc{cvs} に対する引数にディレクトリを指定した場合は、
 2970: そのディレクトリに含まれる全てのファイルにタグが付けられます。
 2971: そのディレクトリ以下の全てのサブディレクトリに対しても
 2972: (再帰的に) 動作します。@xref{Recursive behavior}.)
 2973: 
 2974: @cindex Retrieving an old revision using tags
 2975: @cindex Tag, retrieving old revisions
 2976: @code{checkout} コマンドの @samp{-r} フラグに、
 2977: モジュールから取り出すリビジョンを指定します。
 2978: このフラグを用いて、
 2979: モジュール @samp{ tc} のリリース 1.0 を作るソースを、
 2980: 将来のいつでも簡単に復元することができます:
 2981: 
 2982: @example
 2983: $ cvs checkout -r rel-1-0 tc
 2984: @end example
 2985: 
 2986: @noindent
 2987: リリース時にタグを付けるようにしておけば、
 2988: 過去のリリースにバグが発見されたが最新版には無い、
 2989: という場合などに非常に便利です。
 2990: 
 2991: 任意の時間を指定してモジュールを復元することもできます。 
 2992: @xref{checkout options}.
 2993: 
 2994: 複数のファイルに同じタグを付けるという事を、
 2995: 「ファイル名とリビジョン番号の行列の中に線を引く」
 2996: と考えると良いでしょう。
 2997: 以下のリビジョンの五つのファイルがあるとしましょう:
 2998: 
 2999: @example
 3000: @group
 3001:         file1   file2   file3   file4   file5
 3002: 
 3003:         1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
 3004:         1.2*-   1.2     1.2    -1.2*-
 3005:         1.3  \- 1.3*-   1.3   / 1.3
 3006:         1.4          \  1.4  /  1.4
 3007:                       \-1.5*-   1.5
 3008:                         1.6
 3009: @end group
 3010: @end example
 3011: 
 3012: 過去の何らかの時点で、
 3013: @code{*} の付けられたバージョンにタグが付けられています。
 3014: 上図では @samp{*} の付いたリビジョンにタグが付けられています。
 3015: 仮にタグ名を「タグ付きリビジョンを結んだ紐」と考えると、
 3016: @code{checkout} の @samp{-r} は
 3017: 「紐を引くとタグ付きリビジョン全てが釣れる」などと解釈できるでしょう。
 3018: あるいはタグ付きリビジョンを水平に並べた方が、分り易いかも知れません:
 3019: 
 3020: @example
 3021: @group
 3022:         file1   file2   file3   file4   file5
 3023: 
 3024:                         1.1
 3025:                         1.2
 3026:                 1.1     1.3                       _
 3027:         1.1     1.2     1.4     1.1              /
 3028:         1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- ここを見る
 3029:         1.3             1.6     1.3              \_
 3030:         1.4                     1.4
 3031:                                 1.5
 3032: @end group
 3033: @end example
 3034: 
 3035: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3036: @node Sticky tags
 3037: @section 貼り付いたタグ
 3038: @cindex Sticky tags
 3039: @cindex Tags, sticky
 3040: 
 3041: @c A somewhat related issue is per-directory sticky
 3042: @c tags (see comment at CVS/Tag in node Working
 3043: @c directory storage); we probably want to say
 3044: @c something like "you can set a sticky tag for only
 3045: @c some files, but you don't want to" or some such.
 3046: 
 3047: 作業コピーのリビジョンには関連した追加のデータがあることがあります。例
 3048: えば、枝であったり (@pxref{Branching and merging})、@samp{checkout -D}
 3049: か @samp{update -D} によって特定の日時より前のバージョンに制限されてい
 3050: るかもしれません。このデータは永続しますので -- すなわち、作業コピーの
 3051: 残りのコマンドに適用されます -- 我々はそれを @dfn{貼り付けられた} と表
 3052: 現しました。
 3053: 
 3054: たいていの場合、貼り付きは考える必要のない @sc{cvs} の隠れた側面です。
 3055: しかし、この機能を使いたくないとしても、貼り付けられたタグに関して 
 3056: @emph{何か} 知る必要があるかもしれません (例えば、それを避ける方法!).
 3057: 
 3058: @dfn{貼り付いたタグ} (@dfn{sticky tag}) や日付を調べるには、
 3059: @code{status} コマンドを使用します:
 3060: 
 3061: @example
 3062: $ cvs status driver.c
 3063: ===================================================================
 3064: File: driver.c          Status: Up-to-date
 3065: 
 3066:     Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
 3067:     RCS Version:        1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
 3068:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3069:     Sticky Date:        (none)
 3070:     Sticky Options:     (none)
 3071: 
 3072: @end example
 3073: 
 3074: @cindex Resetting sticky tags
 3075: @cindex Sticky tags, resetting
 3076: @cindex Deleting sticky tags
 3077: 作業ファイルに貼り付いたタグは、
 3078: @samp{cvs update -A} を使って削除するまで残ります。
 3079: オプション @samp{-A} は、ファイルを幹の先頭のバージョンに戻し、
 3080: 貼り付いたタグ, 日付, オプションを全て剥します。
 3081: 
 3082: @cindex sticky date
 3083: 貼り付けられたタグの一番普通の使用法は、@ref{Accessing branches} で説
 3084: 明されているようにどの枝で作業しているかを確認することです。しかし、枝
 3085: でない貼り付きタグにも利用法はあります。
 3086: ここでは、他人の変更が安定しているかどうか分らないので、
 3087: 作業ディレクトリを更新したくない場合を例に挙げて考えます。
 3088: もちろんこの場合、@code{cvs update} の実行を控えれば済みます。
 3089: しかし、更新したくないのが大きなツリー構造の一部分だけならば、
 3090: そこにリビジョンを貼り付ければ良いのです。
 3091: ソースを取り出す際に (1.4 などと) リビジョンを指定すれば、
 3092: そのリビジョンを貼り付けることができます。
 3093: 以後、@samp{cvs update -A} によってタグを剥がすまで、
 3094: @code{cvs update} を実行しても
 3095: 最新リビジョンに更新されることはありません。
 3096: 同様にオプション @samp{-D} を @code{update} や @code{checkout} に使うと、
 3097: @dfn{貼り付いた日付} (@dfn{sticky date}) が設定され、
 3098: これ以降のコマンドにその日付が与えられます。
 3099: 
 3100: @cindex Restoring old version of removed file
 3101: @cindex Resurrecting old version of dead file
 3102: 古いバージョンのファイルを取り出す際に、
 3103: タグを貼り付けたくない場合も多いと思います。
 3104: @code{checkout} や @code{update} にオプション @samp{-p} を付けると、
 3105: ファイルの内容が標準出力に送られるので、これを利用します。
 3106: 例えば、リビジョン 1.1 のファイル @file{file1} を削除したとします 
 3107: (そうすると、死んだリビジョン 1.2 が加えられます)。
 3108: その後、以前と同じ内容で、再度このファイルを加えることになりました。
 3109: この場合の手順を以下に示します:
 3110: 
 3111: @example
 3112: $ cvs update -p -r 1.1 file1 >file1
 3113: ===================================================================
 3114: Checking out file1
 3115: RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
 3116: VERS: 1.1
 3117: ***************
 3118: $ cvs add file1
 3119: cvs add: re-adding file file1 (in place of dead revision 1.2)
 3120: cvs add: use 'cvs commit' to add this file permanently
 3121: $ cvs commit -m test
 3122: Checking in file1;
 3123: /tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
 3124: new revision: 1.3; previous revision: 1.2
 3125: done
 3126: $
 3127: @end example
 3128: 
 3129: @c ---------------------------------------------------------------------
 3130: @node Branching and merging
 3131: @chapter 枝とマージ
 3132: @cindex Branching
 3133: @cindex Merging
 3134: @cindex Copying changes
 3135: @cindex Main trunk and branches
 3136: @cindex Revision tree, making branches
 3137: @cindex Branches, copying changes between
 3138: @cindex Changes, copying between branches
 3139: @cindex Modifications, copying between branches
 3140: 
 3141: CVS では変更を @dfn{枝} (@dfn{branch}) として知られる別の開発ラインに
 3142: 分けることができます。枝のファイルを変更しても、その変更は幹や他の枝に
 3143: は現れません。
 3144: 
 3145: 後程、@dfn{マージ} (@dfn{merging}) によって変更をある枝から別の枝 (も
 3146: しくは幹) に移動することができます。マージはまず @code{cvs update -j}
 3147: を実行して、変更を作業ディレクトリに混ぜることから始まります。それから
 3148: そのリビジョンを格納することができ、こうして効果的に変更を別の枝にコピー
 3149: することができます。
 3150: 
 3151: @menu
 3152: * Branches motivation::         枝は何の役に立つか
 3153: * Creating a branch::           枝の作成
 3154: * Accessing branches::          枝の更新と取り出し
 3155: * Branches and revisions::      枝はリビジョン番号に反映される
 3156: * Magic branch numbers::        魔法の枝番号
 3157: * Merging a branch::            枝全体をマージする
 3158: * Merging more than once::      枝から何度もマージする
 3159: * Merging two revisions::       二つのリビジョン間の差分をマージする
 3160: * Merging adds and removals::   ファイルが追加/削除された場合はどうか?
 3161: @end menu
 3162: 
 3163: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3164: @node Branches motivation
 3165: @section 枝は何の役に立つか
 3166: @cindex Branches motivation
 3167: @cindex What branches are good for
 3168: @cindex Motivation for branches
 3169: 
 3170: @c FIXME: this node mentions one way to use branches,
 3171: @c but it is by no means the only way.  For example,
 3172: @c the technique of committing a new feature on a branch,
 3173: @c until it is ready for the main trunk.  The whole
 3174: @c thing is generally speaking more akin to the
 3175: @c "Revision management" node although it isn't clear to
 3176: @c me whether policy matters should be centralized or
 3177: @c distributed throughout the relevant sections.
 3178: tc のリリース 1.0 ができたとしましょう。tc の開発を継続していて、数ヶ
 3179: 月の間にリリース 1.1 を作成する計画を立てています。しばらくして、顧客
 3180: が致命的なバグについて文句を言ってくるようになりました。リリース 1.0を
 3181: 取り出し (@pxref{Tags})、バグを見つけました (結局些細な修正に終わりま
 3182: した)。しかし、ソースの現在のリビジョンは流動的で、少くとも1ヶ月は安定
 3183: しない状態です。最新のソースに基づくバグ修正リリースはとても作成できま
 3184: せん。
 3185: 
 3186: この様な状況でするべきことは tc のリリース 1.0 の全てのファイルのリビ
 3187: ジョンツリーに基づく @dfn{枝} (@dfn{branch}) を作成することです。そう
 3188: すれば幹の邪魔をすることなく枝に修正を加えることができます。修正が終わっ
 3189: たときに、幹に取り込むか、枝に残しておくかを選択することができます。
 3190: 
 3191: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3192: @node Creating a branch
 3193: @section 枝の作成
 3194: @cindex Creating a branch
 3195: @cindex Branch, creating a
 3196: @cindex tag, creating a branch using
 3197: @cindex rtag, creating a branch using
 3198: 
 3199: @code{tag -b} で枝を作成することができます。例えば、作業コピーのところ
 3200: にいるとしましょう:
 3201: 
 3202: @example
 3203: $ cvs tag -b rel-1-0-patches
 3204: @end example
 3205: 
 3206: @c FIXME: we should be more explicit about the value of
 3207: @c having a tag on the branchpoint.  For example
 3208: @c "cvs tag rel-1-0-patches-branchpoint" before
 3209: @c the "cvs tag -b".  This points out that
 3210: @c rel-1-0-patches is a pretty awkward name for
 3211: @c this example (more so than for the rtag example
 3212: @c below).
 3213: 
 3214: これは作業コピーの現在のリビジョンに基づいた枝を別に作成し、その枝に名
 3215: 前 @samp{rel-1-0-patches} を割当てます。
 3216: 
 3217: 枝はリポジトリに作成されているのであって、作業コピーに作成されているの
 3218: ではないということを理解することは重要です。上記の例の様に、現在のリビ
 3219: ジョンに基づいた枝を作成することは、自動的に作業コピーを新しい枝に切り
 3220: 換えることは @emph{しません}。それをする方法に関する情報は 
 3221: @ref{Accessing branches} を参照してください。
 3222: 
 3223: @code{rtag} を使って、作業コピーへの参照無しに枝を作ることもできます:
 3224: 
 3225: @example
 3226: $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
 3227: @end example
 3228: 
 3229: @samp{-r rel-1-0} はこの枝がタグ @samp{rel-1-0} に対応するリビジョンを
 3230: 根とするということを指定します。最新のリビジョンである必要はありません 
 3231: -- 古いリビジョンから枝を生やすことが役に立つことがしばしばあります
 3232: (例えば、他の部分は安定していることが知られている過去のリリースのバグ
 3233: を修正するとき)。
 3234: 
 3235: @samp{tag} と同様に @samp{-b} フラグは @code{rtag} に枝を作成するよう
 3236: に指示します (単なるリビジョン名ではなく)。@samp{rel-1-0} に対応する数
 3237: 字リビジョン番号はファイル毎に違うことを注意してください。
 3238: 
 3239: ですから、命令の完全な効果は新しい枝を作成することです -- モジュール 
 3240: @samp{tc} で、@samp{rel-1-0} でタグ付けされたリビジョンツリーを根元と
 3241: する -- @samp{rel-1-0-patches} という名前のものを。
 3242: 
 3243: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3244: @node Accessing branches
 3245: @section 枝のアクセス
 3246: @cindex Check out a branch
 3247: @cindex Retrieve a branch
 3248: @cindex Access a branch
 3249: @cindex Identifying a branch
 3250: @cindex Branch, check out
 3251: @cindex Branch, retrieving
 3252: @cindex Branch, accessing
 3253: @cindex Branch, identifying
 3254: 
 3255: 2 つの方法のどちらかで枝を取得することができます: リポジトリから新しく
 3256: 取り出すか、存在する作業コピーをその枝に切り換える方法です。
 3257: 
 3258: リポジトリから枝を取り出すには @samp{checkout} をフラグ @samp{-r} と、
 3259: その後に枝のタグ名を続けて起動します (@pxref{Creating a branch})。
 3260: 
 3261: @example
 3262: $ cvs checkout -r rel-1-0-patches tc
 3263: @end example
 3264: 
 3265: もしくは、既に作業コピーを持っていれば、@samp{update -r} で任意の枝に
 3266: 切り換えることができます:
 3267: 
 3268: @example
 3269: $ cvs update -r rel-1-0-patches tc
 3270: @end example
 3271: 
 3272: もしくは、それと等価な:
 3273: 
 3274: @example
 3275: $ cd tc
 3276: $ cvs update -r rel-1-0-patches
 3277: @end example
 3278: 
 3279: 作業コピーが元々幹にあったか他の枝にあったかは関係ありません -- 上のコ
 3280: マンドはそれを指定された名前の枝に切り換えます。普通の @samp{update}
 3281: コマンドと同様に、@samp{update -r} は全ての変更をマージし、衝突がどこ
 3282: で起こったかを知らせます。
 3283: 
 3284: 一度特定の枝に結び付けられた作業コピーを手に入れると、指示しない限りそ
 3285: こに残り続けます。これは、作業コピーから格納された変更はその枝に新しい
 3286: リビジョンを加えますが、幹と他の枝には影響を及ぼさないということです。
 3287: 
 3288: @cindex Branches, sticky
 3289: 作業コピーがどの枝であるかを知るために、コマンド @samp{status} を使う
 3290: ことができます。その出力で、@samp{Sticky tag} という名前の場所を探して
 3291: ください (@pxref{Sticky tags}) -- それは現在の作業ファイルに、もし枝が
 3292: あれば、それを教える @sc{cvs} の方法です:
 3293: 
 3294: @example
 3295: $ cvs status -v driver.c backend.c
 3296: ===================================================================
 3297: File: driver.c          Status: Up-to-date
 3298: 
 3299:     Version:            1.7     Sat Dec  5 18:25:54 1992
 3300:     RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
 3301:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3302:     Sticky Date:        (none)
 3303:     Sticky Options:     (none)
 3304: 
 3305:     Existing Tags:
 3306:         rel-1-0-patches             (branch: 1.7.2)
 3307:         rel-1-0                     (revision: 1.7)
 3308: 
 3309: ===================================================================
 3310: File: backend.c         Status: Up-to-date
 3311: 
 3312:     Version:            1.4     Tue Dec  1 14:39:01 1992
 3313:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 3314:     Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
 3315:     Sticky Date:        (none)
 3316:     Sticky Options:     (none)
 3317: 
 3318:     Existing Tags:
 3319:         rel-1-0-patches             (branch: 1.4.2)
 3320:         rel-1-0                     (revision: 1.4)
 3321:         rel-0-4                     (revision: 1.4)
 3322: 
 3323: @end example
 3324: 
 3325: それぞれのファイルの枝番号が違うという事実に混乱しないでください 
 3326: (それぞれ @samp{1.7.1} と @samp{1.4.2} です)。枝タグは同じ 
 3327: @samp{rel-1-0-patches} で、ファイルは実際に同じ枝にあります。番号は単
 3328: に枝が作られたときのそれぞれのファイルのリビジョン履歴を反映しています。
 3329: 上の例では、この枝が作成される前に、@samp{driver.c} が 
 3330: @samp{backend.c} よりも多くの変更が成されたということを導き出すことが
 3331: できます。
 3332: 
 3333: 枝番号が作成される方法の詳細は @ref{Branches and revisions} を参照して
 3334: ください。
 3335: 
 3336: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3337: @node Branches and revisions
 3338: @section 枝とリビジョン
 3339: @cindex Branch number
 3340: @cindex Number, branch
 3341: @cindex Revision numbers (branches)
 3342: 
 3343: 普通はファイルのリビジョン履歴は線形増加です (@pxref{Revision
 3344: numbers}):
 3345: 
 3346: @example
 3347:        +-----+    +-----+    +-----+    +-----+    +-----+
 3348:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 3349:        +-----+    +-----+    +-----+    +-----+    +-----+
 3350: @end example
 3351: 
 3352: しかし、@sc{cvs} は線形の開発に限られているわけではありません。@dfn{リ
 3353: ビジョン・ツリー} は @dfn{枝} に分割することができ、それぞれの枝は別に
 3354: 維持された開発ラインです。枝になされた変更は簡単に幹に戻すことができま
 3355: す。
 3356: 
 3357: それぞれの枝には @dfn{枝番号} があり、ピリオドで分けられた奇数個の10進
 3358: 整数から成ります。枝番号は枝が分岐した元の枝に対応するリビジョン番号に
 3359: 整数を追加することによって作成されます。枝番号により、特定のリビジョン
 3360: から 1 つ以上の枝を枝分かれすることができます。
 3361: 
 3362: @need 3500
 3363: 枝の全てのリビジョンは枝番号に普通の数字を追加することで形成されます。
 3364: 下図に、前述の例から枝が発展した例を示します。
 3365: 
 3366: @example
 3367: @group
 3368:                                       +-------------+
 3369:            Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
 3370:                                     / +-------------+
 3371:                                    /
 3372:                                   /
 3373:                  +---------+    +---------+    +---------+
 3374: Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3375:                / +---------+    +---------+    +---------+
 3376:               /
 3377:              /
 3378: +-----+    +-----+    +-----+    +-----+    +-----+
 3379: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
 3380: +-----+    +-----+    +-----+    +-----+    +-----+
 3381:                 !
 3382:                 !
 3383:                 !   +---------+    +---------+    +---------+
 3384: Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
 3385:                     +---------+    +---------+    +---------+
 3386: 
 3387: @end group
 3388: @end example
 3389: 
 3390: @c --   However, at least for me the figure is not enough.  I suggest more
 3391: @c --   text to accompany it.  "A picture is worth a thousand words", so you
 3392: @c --   have to make sure the reader notices the couple of hundred words
 3393: @c --   *you* had in mind more than the others!
 3394: 
 3395: @c --   Why an even number of segments?  This section implies that this is
 3396: @c --   how the main trunk is distinguished from branch roots, but you never
 3397: @c --   explicitly say that this is the purpose of the [by itself rather
 3398: @c --   surprising] restriction to an even number of segments.
 3399: 
 3400: 枝番号が作成される厳密な詳細は普通は気にしなくて良いのですが、以下が動
 3401: 作の方法です: @sc{cvs} が枝番号を作成するときは、2 から始まる最初の未
 3402: 使用の偶数を選びます。ですから、リビジョン 6.4 から枝を作成したいとき
 3403: は、それは 6.4.2 という番号になるでしょう。零で終わる全ての枝番号 
 3404: (6.4.0 のように) は @sc{cvs} の内部で使用されます (@pxref{Magic branch
 3405: numbers})。枝 1.1.1 は特別な意味を持ちます。@xref{Tracking sources}.
 3406: 
 3407: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3408: @node Magic branch numbers
 3409: @section 魔法の枝番号
 3410: 
 3411: @c Want xref to here from "log"?
 3412: 
 3413: この部分は @dfn{魔法の枝} (@dfn{magic brandh}) と呼ばれる @sc{cvs} の
 3414: 機能を説明します。たいていの目的のためには魔法の枝を心配する必要はあり
 3415: ません。@sc{cvs} が代わりに扱ってくれます。しかし、特定の状況ではそれ
 3416: が見えていることもありますので、いくらか動作の仕方を知っていると役に立
 3417: つかもしれません。
 3418: 
 3419: 表面的には、枝番号はドットで分けられた奇数個の10進の整数です。 
 3420: @xref{Revision numbers}.  しかし、これは真実の姿ではありません。
 3421: @sc{cvs} は能率のために、余分な 0 を右から2番目の位置に挿入することが
 3422: あります(1.2.3 は 1.2.0.3 となり、8.9.10.11.12 は 8.9.10.11.0.12 にな
 3423: ります)。
 3424: 
 3425: この魔法の枝と呼ばれるものを、@sc{cvs} はうまく隠しています。しかし、
 3426: 完璧に隠し切れていないところも数ヶ所あります。
 3427: 
 3428: @itemize @bullet
 3429: @ignore
 3430: @c This is in ignore as I'm taking their word for it,
 3431: @c that this was fixed
 3432: @c a long time ago.  But before deleting this
 3433: @c entirely, I'd rather verify it (and add a test
 3434: @c case to the testsuite).
 3435: @item
 3436: @sc{cvs} 1.3 で、
 3437: 魔法の枝番号が @code{cvs status} の出力に現われてしまう。
 3438: これは @sc{cvs} 1.3-s2 では修復されました。
 3439: 
 3440: @end ignore
 3441: @item
 3442: 魔法の枝番号が @code{cvs log} の出力に現われてしまう。
 3443: @c What output should appear instead?
 3444: 
 3445: @item
 3446: @code{cvs admin} で枝のタグ名が指定できない。
 3447: 
 3448: @end itemize
 3449: 
 3450: @c Can CVS do this automatically the first time
 3451: @c you check something in to that branch?  Should
 3452: @c it?
 3453: @code{admin} コマンドを使用して、
 3454: @sc{rcs} が枝のタグ名を理解できるように再設定する方法があります。
 3455: @code{R4patches} というタグ名が、
 3456: ファイル @file{number.c} の枝 1.4.2 に付けられている場合
 3457: (魔法の枝番号は 1.4.0.2 です)、
 3458: 次のようにします:
 3459: 
 3460: @example
 3461: $ cvs admin -NR4patches:1.4.2 numbers.c
 3462: @end example
 3463: 
 3464: この方法を用いる場合は、1つ以上のリビジョンが、
 3465: 既に枝に格納されている必要があります。
 3466: タグに間違った番号を設定しないように、注意しなくてはいけません。
 3467: (実行以前にタグがどう設定されていたかを調べる方法はありません)。
 3468: 
 3469: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3470: @node Merging a branch
 3471: @section 枝全体をマージする
 3472: @cindex Merging a branch
 3473: @cindex -j (merging branches)
 3474: 
 3475: @code{update} コマンドに @samp{-j @var{branch}} フラグを付けると、
 3476: 枝に加えられた変更を作業コピーに反映することができます。
 3477: @samp{-j @var{branch}} オプションが1つだけだと、
 3478: 枝の分岐点と枝の最新リビジョン間の違いを 
 3479: (あなたの作業コピーに) マージします。
 3480: 
 3481: @cindex Join
 3482: @samp{-j} は、``join'' の略です。
 3483: 
 3484: @cindex Branch merge example
 3485: @cindex Example, branch merge
 3486: @cindex Merge, branch example
 3487: 次のリビジョン・ツリーを考えます。
 3488: 
 3489: @example
 3490: +-----+    +-----+    +-----+    +-----+
 3491: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
 3492: +-----+    +-----+    +-----+    +-----+
 3493:                 !
 3494:                 !
 3495:                 !   +---------+    +---------+
 3496: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3497:                     +---------+    +---------+
 3498: @end example
 3499: 
 3500: @noindent
 3501: 枝 1.2.2 には @samp{R1fix} というタグ (文字列) が付けられています。次
 3502: は @file{m.c} というファイル1つを含むモジュール @samp{mod} の例です。
 3503: 
 3504: @example
 3505: $ cvs checkout mod               # @r{最新のリビジョン 1.4 を取り出す}
 3506: 
 3507: $ cvs update -j R1fix m.c        # @r{枝で行なわれた変更(リビジョン 1.2}
 3508:                                  # @r{と 1.2.2.2 の差分)を作業コピーに追加}
 3509: 
 3510: $ cvs commit -m "Included R1fix" # @r{リビジョン 1.5 を作成}
 3511: @end example
 3512: 
 3513: マージ作業で衝突が起きることもありますが、衝突が起きた場合は、それを解
 3514: 決してから新しいリビジョンを格納して下さい。 @xref{Conflicts example}.
 3515: 
 3516: @code{checkout} コマンドでもフラグ @samp{-j @var{branch}} を使用できます。
 3517: 以下の様にして上記と同じ効果を得ることができます:
 3518: 
 3519: @example
 3520: $ cvs checkout -j R1fix mod
 3521: $ cvs commit -m "Included R1fix"
 3522: @end example
 3523: 
 3524: @node Merging more than once
 3525: @section 枝から何度もマージする
 3526: 
 3527: 前節の例を続けると、
 3528: 現在のリビジョン・ツリーは次の様になっています:
 3529: 
 3530: @example
 3531: +-----+    +-----+    +-----+    +-----+    +-----+
 3532: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3533: +-----+    +-----+    +-----+    +-----+    +-----+
 3534:                 !                           *
 3535:                 !                          *
 3536:                 !   +---------+    +---------+
 3537: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3538:                     +---------+    +---------+
 3539: @end example
 3540: 
 3541: 前節で枝 @samp{R1fix} を幹にマージした事を、ここでは星線で表します。
 3542: 
 3543: 次に、枝 @samp{R1fix} で開発が続けられたと仮定します:
 3544: 
 3545: @example
 3546: +-----+    +-----+    +-----+    +-----+    +-----+
 3547: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3548: +-----+    +-----+    +-----+    +-----+    +-----+
 3549:                 !                           *
 3550:                 !                          *
 3551:                 !   +---------+    +---------+    +---------+
 3552: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3553:                     +---------+    +---------+    +---------+
 3554: @end example
 3555: 
 3556: そしてこの新しい変更を幹にマージしたくなりました。
 3557: ここで再び @code{cvs update -j R1fix m.c} コマンドを用いた場合、
 3558: @sc{cvs} は既にマージされた変更点を重ねてマージしようとして、
 3559: 望ましくない結果をもたらします。
 3560: 
 3561: そこで、
 3562: 未だ幹にマージされてない変更点だけマージしたい旨を、
 3563: 明示する必要があります。
 3564: これには、@samp{-j} オプションで二つのリビジョンを指定します。
 3565: @sc{cvs} は、
 3566: 最初のリビジョンから次のリビジョンまでの変更をマージします。
 3567: 例えば、この場合、最も簡単な方法は次の様になります。
 3568: 
 3569: @example
 3570: cvs update -j 1.2.2.2 -j R1fix m.c    # @r{1.2.2.2 から、枝 R1fix の}
 3571:                                       # @r{先頭までの変更をマージする}
 3572: @end example
 3573: 
 3574: この方法の問題点は、リビジョン 1.2.2.2 を自分で指定する必要がある事です。
 3575: 最後にマージが行われた日時を使用する方が、少しましでしょう:
 3576: 
 3577: @example
 3578: cvs update -j R1fix:yesterday -j R1fix m.c
 3579: @end example
 3580: 
 3581: さらに良いのは、
 3582: 変更点を幹にマージする度に、
 3583: 枝 @samp{R1fix} にタグを振っておき、
 3584: 後でマージする時にそのタグを用いる方法です:
 3585: 
 3586: @example
 3587: cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
 3588: @end example
 3589: 
 3590: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3591: @node Merging two revisions
 3592: @section 二つのリビジョン間の差分をマージする
 3593: @cindex Merging two revisions
 3594: @cindex Revisions, merging differences between
 3595: @cindex Differences, merging
 3596: 
 3597: @code{update} (と @code{checkout}) コマンドに @samp{-j @var{revision}} 
 3598: フラグを二つ付けることで、任意の二つのリビジョン間の違いをあなたの作業
 3599: コピーに加えることができます。
 3600: 
 3601: @cindex Undoing a change
 3602: @cindex Removing a change
 3603: @example
 3604: $ cvs update -j 1.5 -j 1.3 backend.c
 3605: @end example
 3606: 
 3607: @noindent
 3608: このようにするとリビジョン 1.3 と 1.5 間の変更を
 3609: 全て@emph{取り除く}ことになります。
 3610: リビジョンを指定する順序に十分注意して下さい!
 3611: 
 3612: 複数のファイルに対してこのオプションを指定する場合は、
 3613: モジュールを構成するファイルごとに
 3614: リビジョン番号が全く異なるであろうことを思い出して下さい。
 3615: 複数のファイルを操作する場合には、
 3616: リビジョン番号ではなく、
 3617: 必ずタグ名を用いるようにして下さい。
 3618: 
 3619: @node Merging adds and removals
 3620: @section ファイルの追加や削除もマージできる
 3621: 
 3622: マージする変更点に、ファイルの削除や追加が伴なう場合でも、
 3623: @code{update -j} は削除や追加を反映します。
 3624: 
 3625: @c FIXME: This example needs a lot more explanation.
 3626: @c We also need other examples for some of the other
 3627: @c cases (not all--there are too many--as long as we present a
 3628: @c coherent general principle).
 3629: 実行例:
 3630: @example
 3631: cvs update -A
 3632: touch a b c
 3633: cvs add a b c ; cvs ci -m "added" a b c
 3634: cvs tag -b branchtag
 3635: cvs update -r branchtag
 3636: touch d ; cvs add d
 3637: rm a ; cvs rm a
 3638: cvs ci -m "added d, removed a"
 3639: cvs update -A
 3640: cvs update -jbranchtag
 3641: @end example
 3642: 
 3643: これらのコマンドが実行され、@samp{cvs commit} がなされた後、幹ではファ
 3644: イル @file{a} は削除され、ファイル@file{d} は追加されます
 3645: @c (which was determined by trying it)
 3646: 
 3647: @c ---------------------------------------------------------------------
 3648: @node Recursive behavior
 3649: @chapter 再帰的動作
 3650: @cindex Recursive (directory descending)
 3651: @cindex Directory, descending
 3652: @cindex Descending directories
 3653: @cindex Subdirectories
 3654: 
 3655: ほとんど全ての @sc{cvs} のコマンドは、
 3656: ディレクトリを引数に取ったときに再帰的に動作します。
 3657: 例えば、次のディレクトリ構造を考えます。
 3658: 
 3659: @example
 3660:       @code{$HOME}
 3661:         |
 3662:         +--@t{tc}
 3663:         |   |
 3664:             +--@t{CVS}
 3665:             |      (内部 @sc{cvs} ファイル)
 3666:             +--@t{Makefile}
 3667:             +--@t{backend.c}
 3668:             +--@t{driver.c}
 3669:             +--@t{frontend.c}
 3670:             +--@t{parser.c}
 3671:             +--@t{man}
 3672:             |    |
 3673:             |    +--@t{CVS}
 3674:             |    |  (内部 @sc{cvs} ファイル)
 3675:             |    +--@t{tc.1}
 3676:             |
 3677:             +--@t{testing}
 3678:                  |
 3679:                  +--@t{CVS}
 3680:                  |  (内部 @sc{cvs} ファイル)
 3681:                  +--@t{testpgm.t}
 3682:                  +--@t{test2.t}
 3683: @end example
 3684: 
 3685: @noindent
 3686: 現在のディレクトリが @samp{tc} であれば、
 3687: 以下が成立します:
 3688: 
 3689: @itemize @bullet
 3690: @item
 3691: @samp{cvs update testing} は
 3692: 
 3693: @example
 3694: cvs update testing/testpgm.t testing/test2.t
 3695: @end example
 3696: と等価です。
 3697: 
 3698: @item
 3699: @samp{cvs update testing man} は
 3700: サブディレクトリ中の全てのファイルを更新します。
 3701: 
 3702: @item
 3703: @samp{cvs update .} 又は @samp{cvs update} は、
 3704: モジュール @code{tc} 中の全てのファイルを更新します。
 3705: @end itemize
 3706: 
 3707: 引数を付けない @code{update} コマンドは現在の作業ディレクトリと全ての
 3708: サブディレクトリを更新します。言い替えると、@file{.} は @code{update} 
 3709: の既定引数です。これは @code{update} コマンドだけではなく、たいていの 
 3710: @sc{cvs} のコマンドにも当てはまります。
 3711: 
 3712: @samp{-l} オプションを付けることによって、
 3713: @sc{cvs} の再帰的な動作を抑止することができます。
 3714: 逆に、@samp{-R} オプションは @file{~/.cvsrc} で @samp{-l} が指定されて
 3715: いるときに再帰的動作を強制するために使うことができます
 3716: (@pxref{~/.cvsrc})。
 3717: 
 3718: @example
 3719: $ cvs update -l         # @r{サブディレクトリのファイルは更新しない。}
 3720: @end example
 3721: 
 3722: @c ---------------------------------------------------------------------
 3723: @node Adding and removing
 3724: @chapter ファイルとディレクトリの追加、削除、改名
 3725: 
 3726: プロジェクトの最中では、よく新しいファイルを追加します。削除や改名、も
 3727: しくはディレクトリも同様です。心に留めておく総合的な概念は、元に戻せな
 3728: い変更をする代わりに、存在するファイルの修正のように、@sc{cvs} に変更
 3729: が発生したという事実を記録させたい、ということです。@sc{cvs} でこれを
 3730: する厳密な機構は状況に依り異ります。
 3731: 
 3732: @menu
 3733: * Adding files::                ファイルの追加
 3734: * Removing files::              ファイルの削除
 3735: * Removing directories::        ディレクトリの削除
 3736: * Moving files::                ファイルの移動と改名
 3737: * Moving directories::          ディレクトリの移動と改名
 3738: @end menu
 3739: 
 3740: @node Adding files
 3741: @section ディレクトリにファイルを加える
 3742: @cindex Adding files
 3743: 
 3744: ディレクトリにファイルを加える手順を説明します。
 3745: 
 3746: @itemize @bullet
 3747: @item
 3748: ディレクトリの作業コピーが必要です。@xref{Getting the source}.
 3749: 
 3750: @item
 3751: ディレクトリの作業コピーの中に、
 3752: 新しいファイルを作ります。
 3753: 
 3754: @item
 3755: @samp{cvs add @var{filename}} を用いて、
 3756: バージョン管理に加えたいファイルを @sc{cvs} に伝えます。
 3757: ファイルがバイナリ・データを含んでいる場合には、
 3758: @samp{-kb} を指定して下さい (@pxref{Binary files})。
 3759: 
 3760: @item
 3761: @samp{cvs commit @var{filename}} を用いて、
 3762: 実際にリポジトリにファイルを格納します。
 3763: この手順を行なうまでは、他の開発者はファイルを見ることができません。
 3764: @end itemize
 3765: 
 3766: @code{add} コマンドは、
 3767: 新しいディレクトリを加える場合にも使用します。
 3768: @c FIXCVS and/or FIXME: Adding a directory doesn't
 3769: @c require the commit step.  This probably can be
 3770: @c considered a CVS bug, but it is possible we should
 3771: @c warn people since this behavior probably won't be
 3772: @c changing right away.
 3773: 
 3774: 他のほとんどのコマンドと異なり、
 3775: @code{add} コマンドは再帰的に動作しません。
 3776: @samp{cvs add foo/bar} とタイプすることさえできません。
 3777: 代りに、
 3778: 次のようにする必要があります。
 3779: @c FIXCVS: This is, of course, not a feature.  It is
 3780: @c just that no one has gotten around to fixing "cvs add
 3781: @c foo/bar".
 3782: 
 3783: @example
 3784: $ cd foo
 3785: $ cvs add bar
 3786: @end example
 3787: 
 3788: @cindex add (subcommand)
 3789: @deffn コマンド {cvs add} [@code{-k} kflag] [@code{-m} message] files @dots{}
 3790: 
 3791: @var{files} が加えられた事をリポジトリに伝えます。
 3792: @code{add} で指定するファイルやディレクトリは、
 3793: 現在のディレクトリに存在している必要があります。
 3794: 新しいディレクトリ階層の全てをリポジトリに加える場合は 
 3795: (例えばサード・パーティーからのファイル等)、
 3796: 代りに @code{import} コマンドを使用した方が良いでしょう。@xref{import}.
 3797: 
 3798: 内容を @code{commit} で格納するまで、
 3799: ここで加えたファイルは実際にはリポジトリに置かれません。
 3800: @code{remove} コマンドで削除されたファイルに対して、
 3801: @code{commit} を発行する前に @code{add} を実行した場合、
 3802: @code{remove} が無効になります。
 3803: 例は @xref{Removing files}.
 3804: 
 3805: オプション @samp{-k} には、
 3806: このファイルを取り出すときの置換モードを指定します。
 3807: 詳細は @ref{Substitution modes} 参照。
 3808: 
 3809: @c As noted in BUGS, -m is broken client/server (Nov
 3810: @c 96).  Also see testsuite log2-* tests.
 3811: @samp{-m} オプションには、ファイルの説明文を記述します。
 3812: (ログ情報を記録する設定ならば)この説明文が
 3813: ファイル @file{history} に記録されます (@pxref{history file})。
 3814: またファイルを格納する際、リポジトリの履歴ファイルにも記録されます。
 3815: この説明文は @code{log} コマンドの出力で確認できます。
 3816: 変更するには @samp{admin -t} を用います。@xref{admin}.
 3817: フラグ @samp{-m @var{description}} を省略した場合、
 3818: 空の文字列が使用され、説明を記述するように促されることはありません。
 3819: @end deffn
 3820: 
 3821: 例えば、以下のコマンドでファイル @file{backend.c} が
 3822: リポジトリに加えられます:
 3823: 
 3824: @c This example used to specify
 3825: @c     -m "Optimizer and code generation passes."
 3826: @c to the cvs add command, but that doesn't work
 3827: @c client/server (see log2 in sanity.sh).  Should fix CVS,
 3828: @c but also seems strange to document things which
 3829: @c don't work...
 3830: @example
 3831: $ cvs add backend.c
 3832: $ cvs commit -m "Early version. Not yet compilable." backend.c
 3833: @end example
 3834: 
 3835: 加えたファイルは、作業中の枝だけに加えられます 
 3836: (@pxref{Branching and merging})。
 3837: 他の枝にも加えたい場合は、後でマージすることができます 
 3838: (@pxref{Merging adds and removals})。
 3839: @c Should we mention that earlier versions of CVS
 3840: @c lacked this feature (1.3) or implemented it in a buggy
 3841: @c way (well, 1.8 had many bugs in cvs update -j)?
 3842: @c Should we mention the bug/limitation regarding a
 3843: @c file being a regular file on one branch and a directory
 3844: @c on another?
 3845: @c FIXME: This needs an example, or several, here or
 3846: @c elsewhere, for it to make much sense.
 3847: @c Somewhere we need to discuss the aspects of death
 3848: @c support which don't involve branching, I guess.
 3849: @c Like the ability to re-create a release from a tag.
 3850: 
 3851: @c ---------------------------------------------------------------------
 3852: @node Removing files
 3853: @section ファイルを削除する
 3854: @cindex Removing files
 3855: @cindex Deleting files
 3856: 
 3857: @c FIXME: this node wants to be split into several
 3858: @c smaller nodes.  Could make these children of
 3859: @c "Adding and removing", probably (death support could
 3860: @c be its own section, for example, as could the
 3861: @c various bits about undoing mistakes in adding and
 3862: @c removing).
 3863: モジュールは変わります。
 3864: 新しいファイルが加えられ、古いファイルが削除されます。
 3865: しかし、モジュールの古いバージョンの、
 3866: 正確なコピーを復元できるようにしておきたいと思うでしょう。
 3867: 
 3868: ここでは、モジュールからファイルを削除した後も、
 3869: 古いバージョンの復元を可能にする手順を説明します:
 3870: 
 3871: @itemize @bullet
 3872: @c FIXME: should probably be saying something about
 3873: @c having a working directory in the first place.
 3874: @item
 3875: 未格納の修正がファイルに残ってないことを確認する必要があります。
 3876: 確認方法は @xref{Viewing differences}.
 3877: また @code{status} や @code{update} といった
 3878: コマンドを使用しても確認できます。
 3879: 修正を格納せずにファイルを消した場合、
 3880: 当然ですが以前の状態に復元することはできません。
 3881: 
 3882: @item
 3883: モジュールの作業コピーからファイルを削除します。
 3884: 例えば、@code{rm} などを使っても良いでしょう。
 3885: 
 3886: @item
 3887: ファイルを本当に削除するという意思を @sc{cvs} に伝えるために、
 3888: @samp{cvs remove @var{filename}} を使います。
 3889: 
 3890: @item
 3891: リポジトリからファイルを実際に削除するために、
 3892: @samp{cvs commit @var{filename}} を使います。
 3893: @end itemize
 3894: 
 3895: @c FIXME: Somehow this should be linked in with a more
 3896: @c general discussion of death support.  I don't know
 3897: @c whether we want to use the term "death support" or
 3898: @c not (we can perhaps get by without it), but we do
 3899: @c need to discuss the "dead" state in "cvs log" and
 3900: @c related subjects.  The current discussion is
 3901: @c scattered around, and not xref'd to each other.
 3902: @c FIXME: I think this paragraph wants to be moved
 3903: @c later down, at least after the first example.
 3904: ファイルの削除を格納する場合、@sc{cvs} は、
 3905: ファイルがもう無いという事実を記録します。
 3906: ファイルが他の枝に存在していても良いし、
 3907: 後で別のファイルを同じ名前で加えても構いません。
 3908: @code{checkout} や @code{update} に指定する
 3909: オプション @samp{-r} や @samp{-D} に応じて、
 3910: @sc{cvs} が正しくファイルを作成したり、しなかったりします。
 3911: 
 3912: @c FIXME: This style seems to clash with how we
 3913: @c document things in general.
 3914: @cindex Remove (subcommand)
 3915: @deffn コマンド {cvs remove} [options] files @dots{}
 3916: 
 3917: ファイルが削除された事実をリポジトリに伝えます 
 3918: (作業ディレクトリから未削除のファイルは処理されません)。
 3919: このコマンドを実行しても、リポジトリのファイルは、
 3920: 削除が格納されるまで実際には削除されません。
 3921: オプションの完全な一覧は @ref{Invoking CVS} を参照してください。
 3922: @end deffn
 3923: 
 3924: 以下に、幾つかファイルを削除する例を挙げます:
 3925: 
 3926: @example
 3927: $ cd test
 3928: $ rm *.c
 3929: $ cvs remove
 3930: cvs remove: Removing .
 3931: cvs remove: scheduling a.c for removal
 3932: cvs remove: scheduling b.c for removal
 3933: cvs remove: use 'cvs commit' to remove these files permanently
 3934: $ cvs ci -m "Removed unneeded files"
 3935: cvs commit: Examining .
 3936: cvs commit: Committing .
 3937: @end example
 3938: 
 3939: 利便性のために、@samp{-f} オプションを指定することでファイルの削除と 
 3940: @code{cvs remove} を一度に行うことができます。例えば、上の例はこのよう
 3941: にすることもできます:
 3942: 
 3943: @example
 3944: $ cd test
 3945: $ cvs remove -f *.c
 3946: cvs remove: scheduling a.c for removal
 3947: cvs remove: scheduling b.c for removal
 3948: cvs remove: use 'cvs commit' to remove these files permanently
 3949: $ cvs ci -m "Removed unneeded files"
 3950: cvs commit: Examining .
 3951: cvs commit: Committing .
 3952: @end example
 3953: 
 3954: ファイルに @code{remove} を実行したけれど、
 3955: 格納前に気が変わったのなら、@code{add} コマンドを用いて、
 3956: 簡単にファイルを復活させることができます。
 3957: @ignore
 3958: @c is this worth saying or not?  Somehow it seems
 3959: @c confusing to me.
 3960: もちろん、作業ディレクトリからファイルのコピーを削除しましたので、
 3961: @sc{cvs} は必ずしも @code{remove} を実行する前のファイルの内容に戻すわ
 3962: けではありません。代わりにリポジトリからもう一度ファイルを取得します。
 3963: @end ignore
 3964: 
 3965: @c FIXME: what if you change your mind after you commit
 3966: @c it?  (answer is also "cvs add" but we don't say that...).
 3967: @c We need some index entries for thinks like "undoing
 3968: @c removal" too.
 3969: 
 3970: @example
 3971: $ ls
 3972: CVS   ja.h  oj.c
 3973: $ rm oj.c
 3974: $ cvs remove oj.c
 3975: cvs remove: scheduling oj.c for removal
 3976: cvs remove: use 'cvs commit' to remove this file permanently
 3977: $ cvs add oj.c
 3978: U oj.c
 3979: cvs add: oj.c, version 1.1.1.1, resurrected
 3980: @end example
 3981: 
 3982: @code{remove} コマンドを実行する前に失敗に気付いた場合、
 3983: @code{update} コマンドを用いてファイルを復活できます:
 3984: 
 3985: @example
 3986: $ rm oj.c
 3987: $ cvs update oj.c
 3988: cvs update: warning: oj.c was lost
 3989: U oj.c
 3990: @end example
 3991: 
 3992: 削除したファイルは、作業中の枝だけから削除されます 
 3993: (@pxref{Branching and merging})。
 3994: 他の枝からも削除したい場合は、後でマージすることができます 
 3995: (@pxref{Merging adds and removals})。
 3996: 
 3997: @node Removing directories
 3998: @section ディレクトリを削除する
 3999: @cindex removing directories
 4000: @cindex directories, removing
 4001: 
 4002: 概念上では、ディレクトリの削除はファイルの削除と似ています---現在の作
 4003: 業ディレクトリからそのディレクトリを消したいけれど、ディレクトリが存在
 4004: した古いリリースも取得できるようにしたい、と思うでしょう。
 4005: 
 4006: ディレクトリを削除する方法は、その中の全てのファイルを削除することです。
 4007: ディレクトリ自身は削除しません。そうする方法はありません。代わりに、
 4008: @code{cvs update}, @code{cvs checkout}, @code{cvs export} に @samp{-P} 
 4009: オプションを指定して、作業ディレクトリから空のディレクトリを削除するよ
 4010: うにします。おそらく最良の方法は常に @samp{-P} を指定することです。空
 4011: のディレクトリが欲しければ、削除されないように、ダミーファイルを作って
 4012: ください (例えば、 @file{.keepme})。
 4013: 
 4014: @c I'd try to give a rationale for this, but I'm not
 4015: @c sure there is a particularly convincing one.  What
 4016: @c we would _like_ is for CVS to do a better job of version
 4017: @c controlling whether directories exist, to eliminate the
 4018: @c need for -P and so that a file can be a directory in
 4019: @c one revision and a regular file in another.
 4020: @code{checkout} と @code{export} の @samp{-r} と @samp{-D} のオプショ
 4021: ンでは @samp{-P} が暗黙に含まれていることに注意してください。この方法
 4022: により @sc{cvs} は正しくディレクトリを作ることができ、又、取り出した特
 4023: 定のバージョンのそのディレクトリにファイルがあるかどうかに左右されなく
 4024: なります。
 4025: 
 4026: @c ---------------------------------------------------------------------
 4027: @node Moving files
 4028: @section ファイルの改名と移動
 4029: @cindex Moving files
 4030: @cindex Renaming files
 4031: @cindex Files, moving
 4032: 
 4033: ファイルを他のディレクトリに移動したり、改名したりするのは、
 4034: 難しくはありません。
 4035: しかし、難解な方法でこれを実現するものがあります。
 4036: (ディレクトリの移動と改名は、
 4037: より困難です。@xref{Moving directories}.)。
 4038: 
 4039: 以降の例では、
 4040: @var{old} というファイルを @var{new} に改名します。
 4041: 
 4042: @menu
 4043: * Outside::                     通常の改名方法
 4044: * Inside::                      小技を使った別の方法
 4045: * Rename by copying::           別の小技を使った方法
 4046: @end menu
 4047: 
 4048: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4049: @node Outside
 4050: @subsection 通常の改名方法
 4051: 
 4052: @c More rename issues.  Not sure whether these are
 4053: @c worth documenting; I'm putting them here because
 4054: @c it seems to be as good a place as any to try to
 4055: @c set down the issues.
 4056: @c * "cvs annotate" will annotate either the new
 4057: @c file or the old file; it cannot annotate _each
 4058: @c line_ based on whether it was last changed in the
 4059: @c new or old file.  Unlike "cvs log", where the
 4060: @c consequences of having to select either the new
 4061: @c or old name seem fairly benign, this may be a
 4062: @c real advantage to having CVS know about renames
 4063: @c other than as a deletion and an addition.
 4064: 
 4065: ファイルを移動する通常の方法は、
 4066: @var{old} を @var{new} にコピーして、
 4067: 普通の @sc{cvs} コマンドで @var{old} をリポジトリから削除し、
 4068: @var{new} を加えることです。
 4069: @c The following sentence is not true: one must cd into
 4070: @c the directory to run "cvs add".
 4071: @c  (Both @var{old} and @var{new} could
 4072: @c contain relative paths, for example @file{foo/bar.c}).
 4073: 
 4074: @example
 4075: $ mv @var{old} @var{new}
 4076: $ cvs remove @var{old}
 4077: $ cvs add @var{new}
 4078: $ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new}
 4079: @end example
 4080: 
 4081: これがファイルを移動する最も単純な方法であり、
 4082: 間違いがなく、この操作の履歴も記録されます。
 4083: このファイルの履歴を利用する際、
 4084: 古い名前か、新しい名前のどちらかを指定して、
 4085: 履歴のどの部分が欲しいのか知らせなくてはいけません。
 4086: 例えば、@code{cvs log @var{old}} を実行しても、
 4087: 改名が行なわれた時までのログ情報しか得られません。
 4088: 
 4089: @var{new} が格納される場合には、
 4090: リビジョン番号は普通は 1.1 から再び始まります。
 4091: それが嫌ならば、格納時にオプション @samp{-r rev}
 4092: を用いると良いでしょう。詳しい情報は @ref{Assigning revisions} を参照
 4093: してください。
 4094: 
 4095: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4096: @node Inside
 4097: @subsection 履歴ファイルを移動する
 4098: 
 4099: この方法は、リポジトリ中のファイルの移動を含むため、
 4100: さらに危険です。
 4101: この節を全部読んでから実行して下さい。
 4102: 
 4103: @example
 4104: $ cd $CVSROOT/@var{module}
 4105: $ mv @var{old},v @var{new},v
 4106: @end example
 4107: 
 4108: @noindent
 4109: 利点:
 4110: 
 4111: @itemize @bullet
 4112: @item
 4113: 変更の記録が完全に保たれる。
 4114: 
 4115: @item
 4116: リビジョン番号に影響がない。
 4117: @end itemize
 4118: 
 4119: @noindent
 4120: 欠点:
 4121: 
 4122: @itemize @bullet
 4123: @item
 4124: リポジトリから、モジュールの古いリリースを簡単に復元できない。
 4125: (改名される以前のリビジョンでもファイルの名前が @var{new} になる。)
 4126: 
 4127: @item
 4128: ファイルがいつ改名されたかの記録がない。
 4129: 
 4130: @item
 4131: ファイルの移動の最中に、
 4132: 誰かが履歴ファイルにアクセスした場合、酷いことが起きる。
 4133: あなたがファイルを移動させている間は、
 4134: 誰にも @sc{cvs} コマンドを発行させてはいけません。
 4135: @end itemize
 4136: 
 4137: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4138: @node Rename by copying
 4139: @subsection 履歴ファイルをコピーする
 4140: 
 4141: この方法も、リポジトリ中のファイルの移動を含みます。
 4142: 欠点が無い訳ではありませんが、安全です。
 4143: 
 4144: @example
 4145: # @r{リポジトリ中の @sc{rcs} ファイルをコピーする}
 4146: $ cd $CVSROOT/@var{module}
 4147: $ cp @var{old},v @var{new},v
 4148: # @r{以前のファイルを削除する}
 4149: $ cd ~/@var{module}
 4150: $ rm @var{old}
 4151: $ cvs remove @var{old}
 4152: $ cvs commit @var{old}
 4153: # @r{@var{new} の全てのタグを削除する}
 4154: $ cvs update @var{new}
 4155: $ cvs log @var{new}             # @r{枝でないタグ名を思い出す}
 4156: $ cvs tag -d @var{tag1} @var{new}
 4157: $ cvs tag -d @var{tag2} @var{new}
 4158: @dots{}
 4159: @end example
 4160: 
 4161: タグを削除することで、
 4162: モジュールの以前のリビジョンを復元することができます。
 4163: 
 4164: @noindent
 4165: 利点:
 4166: 
 4167: @itemize @bullet
 4168: @item
 4169: @c FIXME: Is this true about -D now that we have death
 4170: @c support?  See 5B.3 in the FAQ.
 4171: リビジョンの取得に @samp{-D@var{date}} を使わないで、
 4172: @samp{-r@var{tag}} を使う限り、以前のリビジョンのファイルを正しく復元
 4173: できる。
 4174: 
 4175: @item
 4176: 変更の記録を完全に維持できる。
 4177: 
 4178: @item
 4179: リビジョン番号に影響しない。
 4180: @end itemize
 4181: 
 4182: @noindent
 4183: 欠点:
 4184: 
 4185: @itemize @bullet
 4186: @item
 4187: 改名の前後で履歴を辿ることが困難である。
 4188: 
 4189: @ignore
 4190: @c Is this true?  I don't see how the revision numbers
 4191: @c _could_ start over, when new,v is just old,v with
 4192: @c the tags deleted.
 4193: @c If there is some need to reinstate this text,
 4194: @c it is "usually 1.1", not "1.0" and it needs an
 4195: @c xref to Assigning revisions
 4196: @item
 4197: @samp{-r rev} フラグを付けて @code{commit} しないと、
 4198: @var{new} のリビジョン番号はまた 1.0 から始まる
 4199: (@pxref{commit options})。
 4200: @end ignore
 4201: @end itemize
 4202: 
 4203: @c ---------------------------------------------------------------------
 4204: @node Moving directories
 4205: @section ディレクトリの改名と移動
 4206: @cindex Moving directories
 4207: @cindex Renaming directories
 4208: @cindex Directories, moving
 4209: 
 4210: ディレクトリの改名と移動の普通の方法は @ref{Outside} で説明されている
 4211: ようにその中のそれぞれのファイルを改名もしくは移動することです。それか
 4212: ら @ref{Removing directories} に説明されているように @samp{-P} オプショ
 4213: ンを付けて取り出します。
 4214: 
 4215: 本当にリポジトリの中身を変更してディレクトリを改名したり削除したければ、
 4216: 次のようにしてください:
 4217: 
 4218: @enumerate
 4219: @item
 4220: ディレクトリを改名する前に、
 4221: モジュールの作業コピーを持っている全ての人に、
 4222: その旨を知らせます。
 4223: 次のステップに進む前に、彼等全員が変更内容を格納し、
 4224: モジュールの作業コピーを削除しなければなりません。
 4225: 
 4226: @item
 4227: リポジトリ中のディレクトリを改名します。
 4228: 
 4229: @example
 4230: $ cd $CVSROOT/@var{module}
 4231: $ mv @var{old-dir} @var{new-dir}
 4232: @end example
 4233: 
 4234: @item
 4235: @sc{cvs} の管理用ファイルを修正します。
 4236: (例えばモジュール名を改名する場合等)。
 4237: 
 4238: @item
 4239: モジュールを取り出して作業を続けられることを、
 4240: 全員に知らせます。
 4241: 
 4242: @end enumerate
 4243: 
 4244: 誰かがモジュールの作業コピーを消さずに持っていた場合、
 4245: 彼がリポジトリから消されたディレクトリを削除するまで、
 4246: 彼の発行する @sc{cvs} コマンドは無視されます。
 4247: 
 4248: ディレクトリを移動させるよりは、
 4249: ディレクトリ中のファイルを移動させる方を推奨します。
 4250: ディレクトリを移動させれば、
 4251: ディレクトリ名に依存している古いリリースを正確に復元する事は、
 4252: ほとんど不可能になります。
 4253: 
 4254: @c ---------------------------------------------------------------------
 4255: @node History browsing
 4256: @chapter 履歴の閲覧
 4257: @cindex History browsing
 4258: @cindex Traceability
 4259: @cindex Isolation
 4260: 
 4261: @ignore
 4262: @c This is too long for an introduction (goal is
 4263: @c one 20x80 character screen), and also mixes up a
 4264: @c variety of issues (parallel development, history,
 4265: @c maybe even touches on process control).
 4266: 
 4267: @c -- @quote{To lose ones history is to lose ones soul.}
 4268: @c -- ///
 4269: @c -- ///Those who cannot remember the past are condemned to repeat it.
 4270: @c -- ///               -- George Santayana
 4271: @c -- ///
 4272: 
 4273: @sc{cvs} tries to make it easy for a group of people to work
 4274: together.  This is done in two ways:
 4275: 
 4276: @itemize @bullet
 4277: @item
 4278: Isolation---You have your own working copy of the
 4279: source.  You are not affected by modifications made by
 4280: others until you decide to incorporate those changes
 4281: (via the @code{update} command---@pxref{update}).
 4282: 
 4283: @item 
 4284: Traceability---When something has changed, you can
 4285: always see @emph{exactly} what changed.
 4286: @end itemize
 4287: 
 4288: There are several features of @sc{cvs} that together lead
 4289: to traceability:
 4290: 
 4291: @itemize @bullet
 4292: @item
 4293: Each revision of a file has an accompanying log
 4294: message.
 4295: 
 4296: @item
 4297: All commits are optionally logged to a central history
 4298: database.
 4299: 
 4300: @item
 4301: Logging information can be sent to a user-defined
 4302: program (@pxref{loginfo}).
 4303: @end itemize
 4304: 
 4305: @c -- More text here.
 4306: 
 4307: This chapter should talk about the history file, the
 4308: @code{log} command, the usefulness of ChangeLogs
 4309: even when you run @sc{cvs}, and things like that.
 4310: 
 4311: @end ignore
 4312: 
 4313: @c kind of lame, in a lot of ways the above text inside
 4314: @c the @ignore motivates this chapter better
 4315: 何時、誰が、どのように、どのファイルを変更したか、
 4316: といったバージョン管理の履歴を @sc{cvs} を使って保存してきたならば、
 4317: 様々な機構を用いてこの履歴を調べることができます。
 4318: 
 4319: @c FIXME: should also be talking about how you look at
 4320: @c old revisions (e.g. "cvs update -p -r 1.2 foo.c").
 4321: @menu
 4322: * log messages::                ログ・メッセージ
 4323: * history database::            履歴データベース
 4324: * user-defined logging::        ログ方法を使用者自身が設定する
 4325: * annotate::                    各行がどのリビジョンで変更されたか?
 4326: @end menu
 4327: 
 4328: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4329: @node log messages
 4330: @section ログ・メッセージ
 4331: 
 4332: @c FIXME: @xref to place where we talk about how to
 4333: @c specify message to commit.
 4334: ファイルを格納する時には、必ずログ・メッセージを記述します。
 4335: 
 4336: @c FIXME: bring the information here, and get rid of or
 4337: @c greatly shrink the "log" node.
 4338: 各リビジョンの格納時に記述されたログ・メッセージを調べる場合、
 4339: @code{cvs log} コマンドを使用します (@pxref{log})。
 4340: 
 4341: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4342: @node history database
 4343: @section 履歴データベース
 4344: 
 4345: @c FIXME: bring the information from the history file
 4346: @c and history nodes here.  Rewrite it to be motivated
 4347: @c better (start out by clearly explaining what gets
 4348: @c logged in history, for example).
 4349: 様々な @sc{cvs} の実行履歴を記録するために、
 4350: ファイル @file{history} が使用できます (@pxref{history file})。
 4351: ファイル @file{history} の情報を検索するには、
 4352: @code{cvs history} コマンドを使用して下さい (@pxref{history})。
 4353: @c
 4354: @c The history database has many problems:
 4355: @c * It is very unclear what field means what.  This
 4356: @c could be improved greatly by better documentation,
 4357: @c but there are still non-orthogonalities (for
 4358: @c example, tag does not record the "repository"
 4359: @c field but most records do).
 4360: @c * Confusion about files, directories, and modules.
 4361: @c Some commands record one, some record others.
 4362: @c * File removal is not logged.  There is an 'R'
 4363: @c record type documented, but CVS never uses it.
 4364: @c * Tags are only logged for the "cvs rtag" command,
 4365: @c not "cvs tag".  The fix for this is not completely
 4366: @c clear (see above about modules vs. files).
 4367: @c * Are there other cases of operations that are not
 4368: @c logged?  One would hope for all changes to the
 4369: @c repository to be logged somehow (particularly
 4370: @c operations like tagging, "cvs admin -k", and other
 4371: @c operations which do not record a history that one
 4372: @c can get with "cvs log").  Operations on the working
 4373: @c directory, like export, get, and release, are a
 4374: @c second category also covered by the current "cvs
 4375: @c history".
 4376: @c * The history file does not record the options given
 4377: @c to a command.  The most serious manifestation of
 4378: @c this is perhaps that it doesn't record whether a command
 4379: @c was recursive.  It is not clear to me whether one
 4380: @c wants to log at a level very close to the command
 4381: @c line, as a sort of way of logging each command
 4382: @c (more or less), or whether one wants
 4383: @c to log more at the level of what was changed (or
 4384: @c something in between), but either way the current
 4385: @c information has pretty big gaps.
 4386: @c * Further details about a tag--like whether it is a
 4387: @c branch tag or, if a non-branch tag, which branch it
 4388: @c is on.  One can find out this information about the
 4389: @c tag as it exists _now_, but if the tag has been
 4390: @c moved, one doesn't know what it was like at the time
 4391: @c the history record was written.
 4392: @c * Whether operating on a particular tag, date, or
 4393: @c options was implicit (sticky) or explicit.
 4394: @c
 4395: @c Another item, only somewhat related to the above, is a
 4396: @c way to control what is logged in the history file.
 4397: @c This is probably the only good way to handle
 4398: @c different people having different ideas about
 4399: @c information/space tradeoffs.
 4400: @c
 4401: @c It isn't really clear that it makes sense to try to
 4402: @c patch up the history file format as it exists now to
 4403: @c include all that stuff.  It might be better to
 4404: @c design a whole new CVSROOT/nhistory file and "cvs
 4405: @c nhistory" command, or some such, or in some other
 4406: @c way trying to come up with a clean break from the
 4407: @c past, which can address the above concerns.  Another
 4408: @c open question is how/whether this relates to
 4409: @c taginfo/loginfo/etc.
 4410: 
 4411: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4412: @node user-defined logging
 4413: @section ログ方法を使用者自身が設定する
 4414: 
 4415: @c FIXME: should probably also mention the fact the -l
 4416: @c global option can disable most of the mechanisms
 4417: @c discussed here (why?  What is the -l global option for?).
 4418: @c
 4419: @c FIXME: probably should centralize this information
 4420: @c here, at least to some extent.  Maybe by moving the
 4421: @c loginfo, etc., nodes here and replacing
 4422: @c the "user-defined logging" node with one node for
 4423: @c each method.
 4424: @sc{cvs} を用いた様々な作業の履歴は、
 4425: 利用者自身が選択する方法で記録されます。
 4426: @sc{cvs} は、様々な場面でスクリプトを実行し、
 4427: この機構を実現します。
 4428: これらのスクリプトには、
 4429: ログ・ファイルに情報を追記したり、
 4430: 開発者グループにメールを送ったり、
 4431: 特定のニュース・グループに記事を投稿したりするものがあります。
 4432: 格納時のログ方法は @file{loginfo} で設定します(@pxref{loginfo})。
 4433: @c FIXME: What is difference between doing it in the
 4434: @c modules file and using loginfo/taginfo?  Why should
 4435: @c user use one or the other?
 4436: commit, checkout, export, tag
 4437: 等を実行した時のログ方法は、
 4438: 各々オプション @samp{-i}, @samp{-o}, @samp{-e}, @samp{-t} を用いて、
 4439: modules ファイルに設定できます。
 4440: これらのスクリプトほどのものは必要としない使用者にも、
 4441: @code{cvs watch add} コマンドを使用して、
 4442: 様々な告知をする弾力的な方法を提供します(@pxref{Getting Notified})。
 4443: この方法は @code{cvs watch on} を使用していない場合でも利用できます。
 4444: 
 4445: @cindex taginfo
 4446: @cindex exit status, of taginfo
 4447: 誰かが @code{tag} か @code{rtag} コマンドを実行した時に
 4448: 実行されるプログラムを、@file{taginfo} ファイルに設定します。
 4449: 管理用ファイルの標準書式に従い(@pxref{Administrative files})、
 4450: @file{taginfo} の各行には、
 4451: 正規表現に続いて実行されるコマンドが記述されます。
 4452: コマンドに渡される引数を順に挙げると、
 4453: @var{タグ名}, @var{操作}(@code{tag} なら @code{add},
 4454: @code{tag -F} なら @code{mov}, @code{tag -d} なら @code{del}),
 4455: @var{リポジトリ}, 残りは全て @var{ファイル名} と @var{リビジョン} の組
 4456: です。
 4457: フィルタ・プログラムが非零で終了した場合は、
 4458: タグ処理が中止されます。
 4459: 
 4460: これは taginfo を使って tag と rtag コマンドのログを取る例です。
 4461: taginfo ファイルには以下のものを入れます:
 4462: 
 4463: @example
 4464: ALL /usr/local/cvsroot/CVSROOT/loggit
 4465: @end example
 4466: 
 4467: @file{/usr/local/cvsroot/CVSROOT/loggit} は以下のスクリプトになってい
 4468: ます:
 4469: 
 4470: @example
 4471: #!/bin/sh
 4472: echo "$@@" >>/home/kingdon/cvsroot/CVSROOT/taglog
 4473: @end example
 4474: 
 4475: @node annotate
 4476: @section コマンド annotate
 4477: @cindex annotate (subcommand)
 4478: 
 4479: @deffn コマンド {cvs annotate} [@code{-flR}] [@code{-r rev}|@code{-D date}] files @dots{}
 4480: 
 4481: @var{files} で指定された各ファイルについて、
 4482: 幹の先頭リビジョンの内容と、各行が最後に修正された時の情報を、
 4483: 併せて表示します。
 4484: 以下に例示します:
 4485: 
 4486: @example
 4487: $ cvs annotate ssfile
 4488: Annotations for ssfile
 4489: ***************
 4490: 1.1          (mary     27-Mar-96): ssfile line 1
 4491: 1.2          (joe      28-Mar-96): ssfile line 2
 4492: @end example
 4493: 
 4494: ファイル @file{ssfile} は現在 2行から成り、
 4495: @code{ssfile line 1} という行は 3月 27日に @code{mary} が格納しました。
 4496: そして 3月 28日に @code{joe} が、
 4497: @code{ssfile line 1} という行を修正せずに、
 4498: @code{ssfile line 2} という行を格納しました。
 4499: この報告では、削除されたり修正された行については何も分らないので、
 4500: @code{cvs diff} を用いる必要があるでしょう(@pxref{diff})。
 4501: 
 4502: @end deffn
 4503: 
 4504: @code{cvs annotate} へのオプションは @ref{Invoking CVS} で一覧にされて
 4505: ていて、annotate するファイルとリビジョンを選択するために使うことがで
 4506: きます。オプションは @ref{Common options} でより詳しく説明されています。
 4507: 
 4508: @c FIXME: maybe an example using the options?  Just
 4509: @c what it means to select a revision might be worth a
 4510: @c few words of explanation ("you want to see who
 4511: @c changed this line *before* 1.4"...).
 4512: 
 4513: @c ---------------------------------------------------------------------
 4514: @node Binary files
 4515: @chapter バイナリ・ファイルの扱い
 4516: @cindex Binary files
 4517: 
 4518: 最も普通の @sc{cvs} の使用はテキスト・ファイルの保管です。テキスト・ファ
 4519: イルでは、@sc{cvs} はリビジョンをマージしたり、リビジョン間の違いを人
 4520: 間が読める形式で表示したり、他の似たような操作をすることができます。し
 4521: かし、これらの中のいくつかの機能を諦めることで、@sc{cvs} はバイナリ・
 4522: ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ
 4523: 画像の両方からなるウェブサイトを @sc{cvs} で保管するかもしれません。
 4524: 
 4525: @menu
 4526: * Binary why::     バイナリ・ファイルの問題の詳細
 4527: * Binary howto::   保管方法
 4528: @end menu
 4529: 
 4530: @node Binary why
 4531: @section バイナリ・ファイルの問題
 4532: 
 4533: 普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必
 4534: 要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ
 4535: せます。
 4536: 
 4537: バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。
 4538: 例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して
 4539: いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ
 4540: イルには、@sc{cvs} は @code{cvs diff} コマンドでこの機能を提供します。
 4541: バイナリ・ファイルには、2つのリビジョンを取り出して、@sc{cvs} の外部に
 4542: あるプログラムで比較することができるでしょう (例えば、ワープロにはよく
 4543: そのような機能があります)。もしそのようなツールがなければ、人に良いロ
 4544: グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実
 4545: 際にした変更が本当にそうしたいと思っている変更そのものであることを期待
 4546: しなければなりません。
 4547: 
 4548: バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。
 4549: @sc{cvs} ではこれは2つの文脈で発生します。1つめは使用者が分離された作
 4550: 業ディレクトリで変更をしたときです (@pxref{Multiple developers})。2つ
 4551: 目は @samp{update -j} コマンドで明示的にマージしたときです 
 4552: (@pxref{Branching and merging})。
 4553: 
 4554: テキスト・ファイルの場合は、@sc{cvs} は独立になされた変更をマージでき、
 4555: 変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、
 4556: @sc{cvs} にできることは、せいぜい2つの違ったファイルのコピーを出して、
 4557: 使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー
 4558: を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール
 4559: があればそれを実行するかもしれません。使用者にマージをさせることは、主
 4560: に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して
 4561: おり、エラーが発生する可能性が高いということに注意してください。
 4562: 
 4563: この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別
 4564: の作業ディレクトリによるマージを避けるためには、@ref{Multiple
 4565: developers} の独占取得 (ファイル占有) の議論を参照してください。枝によ
 4566: るマージを避けるためには、枝の使用を制限してください。
 4567: 
 4568: @node Binary howto
 4569: @section バイナリ・ファイルを保管する方法
 4570: 
 4571: @sc{cvs} でバイナリ・ファイルを保管する際の問題点が二つあります。
 4572: 一つ目は、@sc{cvs} がファイルを取り出す際に、
 4573: リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、
 4574: クライアント側のオペレーティングシステムに適した形式に変換する事です 
 4575: (例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり
 4576: ます)。
 4577: 
 4578: 二つ目の問題点は、キーワードと同じデータが
 4579: 偶然バイナリ・ファイルに含まれる可能性がある事です 
 4580: (@pxref{Keyword substitution})。
 4581: そのためキーワード展開を無効にする必要があります。
 4582: 
 4583: @c FIXME: the third is that one can't do merges with
 4584: @c binary files.  xref to Multiple Developers and the
 4585: @c reserved checkout issues.
 4586: 
 4587: 幾つかの @sc{cvs} コマンドで @samp{-kb} オプションを用いれば、
 4588: 確実に行末変換とキーワード展開を止めることができます。
 4589: 
 4590: @samp{-kb} フラグを用いて新しいファイルを登録する方法を、
 4591: 以下に例示します:
 4592: 
 4593: @example
 4594: $ echo '$@asis{}Id$' > kotest
 4595: $ cvs add -kb -m"A test file" kotest
 4596: $ cvs ci -m"First checkin; contains a keyword" kotest
 4597: @end example
 4598: 
 4599: ふと油断して @samp{-kb} 無しでファイルを加えてしまった場合、
 4600: @code{cvs admin} コマンドを使用して正常な状態に戻す必要があります。
 4601: 以下に例示します:
 4602: 
 4603: @example
 4604: $ echo '$@asis{}Id$' > kotest
 4605: $ cvs add -m"A test file" kotest
 4606: $ cvs ci -m"First checkin; contains a keyword" kotest
 4607: $ cvs admin -kb kotest
 4608: $ cvs update -A kotest
 4609: # @r{For non-unix systems:}
 4610: # @r{Copy in a good copy of the file from outside CVS}
 4611: $ cvs commit -m "make it binary" kotest
 4612: @end example
 4613: 
 4614: @c Trying to describe this for both unix and non-unix
 4615: @c in the same description is very confusing.  Might
 4616: @c want to split the two, or just ditch the unix "shortcut"
 4617: @c (unixheads don't do much with binary files, anyway).
 4618: @c This used to say "(Try the above example, and do a
 4619: @c @code{cat kotest} after every command)".  But that
 4620: @c only really makes sense for the unix case.
 4621: ファイル @file{kotest} を格納した時はファイルはバイナリ・ファイルとし
 4622: ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ
 4623: たからです。
 4624: @samp{cvs admin -kb} コマンドでファイルの置換モードを設定しますが、
 4625: 既にある作業コピーは変更してくれません。
 4626: 行末を適切に処理する必要がある場合 (@sc{cvs} のクライアントとして 
 4627: unix 以外のシステムを使用している場合) は、
 4628: 上記の例に示した @code{cvs commit} コマンドのように、
 4629: 新たにファイルのコピーを格納する必要があります。
 4630: Unix では、@samp{cvs update -A} で十分です。
 4631: @c FIXME: should also describe what the *other users*
 4632: @c need to do, if they have checked out copies which
 4633: @c have been corrupted by lack of -kb.  I think maybe
 4634: @c "cvs update -kb" or "cvs
 4635: @c update -A" would suffice, although the user who
 4636: @c reported this suggested removing the file, manually
 4637: @c removing it from CVS/Entries, and then "cvs update"
 4638: 
 4639: ここで、@samp{cvs admin -k} を用いて置換モードを変更しても、
 4640: この置換モードはバージョン管理されないことを認識しておいて下さい。
 4641: これは例えば古いリリースにテキスト・ファイルがあり、
 4642: 新しいリリースに同じ名前のバイナリ・ファイルがあった場合、
 4643: バージョンによってテキストとバイナリを区別して取り出す方法を、
 4644: @sc{cvs} が備えていないことを意味しています。
 4645: この問題を解決する方法は今のところありません。
 4646: 
 4647: @code{cvs add} や @code{cvs import} を実行する際、
 4648: 既定でバイナリとして扱うかどうかを、
 4649: ファイルの名前によって判断するように設定もできます。
 4650: 例えば、ファイル名が @samp{.exe} で終わるファイルを
 4651: バイナリと判断するように設定できます。@xref{Wrappers}.
 4652: 現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ
 4653: ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの
 4654: 区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに
 4655: 応じてかなり異なるであろうということです。
 4656: @c For example, it would be good on MS-DOS-family OSes
 4657: @c for anything containing ^Z to be binary.  Having
 4658: @c characters with the 8th bit set imply binary is almost
 4659: @c surely a bad idea in the context of ISO-8859-* and
 4660: @c other such character sets.  On VMS or the Mac, we
 4661: @c could use the OS's file typing.  This is a
 4662: @c commonly-desired feature, and something of this sort
 4663: @c may make sense.  But there are a lot of pitfalls here.
 4664: @c
 4665: @c Another, probably better, way to tell is to read the
 4666: @c file in text mode, write it to a temp file in text
 4667: @c mode, and then do a binary mode compare of the two
 4668: @c files.  If they differ, it is a binary file.  This
 4669: @c might have problems on VMS (or some other system
 4670: @c with several different text modes), but in general
 4671: @c should be relatively portable.  The only other
 4672: @c downside I can think of is that it would be fairly
 4673: @c slow, but that is perhaps a small price to pay for
 4674: @c not having your files corrupted.  Another issue is
 4675: @c what happens if you import a text file with bare
 4676: @c linefeeds on Windows.  Such files will show up on
 4677: @c Windows sometimes (I think some native windows
 4678: @c programs even write them, on occasion).  Perhaps it
 4679: @c is reasonable to treat such files as binary; after
 4680: @c all it is something of a presumption to assume that
 4681: @c the user would want the linefeeds converted to CRLF.
 4682: 
 4683: @c ---------------------------------------------------------------------
 4684: @node Multiple developers
 4685: @chapter 複数の開発者
 4686: @cindex Multiple developers
 4687: @cindex Team of developers
 4688: @cindex File locking
 4689: @cindex Locking files
 4690: @cindex Working copy
 4691: @cindex reserved checkouts
 4692: @cindex unreserved checkouts
 4693: @cindex RCS-style locking
 4694: 
 4695: 複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。
 4696: 例えば二人の人物が、
 4697: 同じファイルを同時に編集しようとすることがよくあります。
 4698: 解決策の一つは、
 4699: @dfn{ファイル占有} (@dfn{file locking}) または @dfn{独占取得} 
 4700: (@dfn{reserved checkouts}) と呼ばれるもので、
 4701: 同時にファイルを編集できる人数を一人に制限するものです。
 4702: @sc{rcs} や @sc{sccs} 等の履歴管理システムでは、
 4703: これが唯一の方法です。
 4704: 現時点では @sc{cvs} で独占取得をする普通の方法は @code{cvs admin -l}
 4705: コマンドです (@pxref{admin options})。これは後述する監視機能のように 
 4706: @sc{cvs} によく実装されてはいませんが、独占取得を必要なほとんどの人は
 4707: 十分だと思うでしょう。
 4708: @c Or "find it better than worrying about implementing
 4709: @c nicely integrated reserved checkouts" or ...?
 4710: また後述する監視機構を適切な手順を踏んで用いることでも (ソフトウェアか
 4711: らは強制されません)、同時編集を避けることが可能でしょう。
 4712: 
 4713: @c Our unreserved checkout model might not
 4714: @c be quite the same as others.  For example, I
 4715: @c think that some systems will tend to create a branch
 4716: @c in the case where CVS prints "up-to-date check failed".
 4717: @c It isn't clear to me whether we should try to
 4718: @c explore these subtleties; it could easily just
 4719: @c confuse people.
 4720: @sc{cvs} の既定モデルは@dfn{無条件取得} 
 4721: (@dfn{unreserved checkouts}) と呼ばれるものです。
 4722: このモデルでは、
 4723: 開発者がそれぞれ自分の @dfn{作業コピー} 
 4724: (@dfn{working copy}) のファイルを同時に編集できます。
 4725: 最初に変更を格納した人物は、
 4726: 他の人物が編集を始めたことが自動的には分りません。
 4727: 二番目の人物が格納する時にはエラー表示を受けますから、
 4728: @sc{cvs} コマンドを用いて、
 4729: 自分の作業コピーをリポジトリのリビジョンの最新のものにする
 4730: 必要があります。
 4731: この手順はほぼ自動化されています。
 4732: 
 4733: @c FIXME? should probably use the word "watch" here, to
 4734: @c tie this into the text below and above.
 4735: @sc{cvs} は、独占取得がするような規則を強制することなく、
 4736: 種々の意志疎通を容易にする仕組みを用意しています。
 4737: 
 4738: この章の残りでは、色々なモデルの動作方法と、
 4739: 各モデルの選択に伴なう問題点について述べます。
 4740: 
 4741: @ignore
 4742: Here is a draft reserved checkout design or discussion
 4743: of the issues.  This seems like as good a place as any
 4744: for this.
 4745: 
 4746: Might want a cvs lock/cvs unlock--in which the names
 4747: differ from edit/unedit because the network must be up
 4748: for these to work.  unedit gives an error if there is a
 4749: reserved checkout in place (so that people don't
 4750: accidentally leave locks around); unlock gives an error
 4751: if one is not in place (this is more arguable; perhaps
 4752: it should act like unedit in that case).
 4753: 
 4754: On the other hand, might want it so that emacs,
 4755: scripts, etc., can get ready to edit a file without
 4756: having to know which model is in use.  In that case we
 4757: would have a "cvs watch lock" (or .cvsrc?) (that is,
 4758: three settings, "on", "off", and "lock").  Having cvs
 4759: watch lock set would cause a get to record in the CVS
 4760: directory which model is in use, and cause "cvs edit"
 4761: to change behaviors.  We'd want a way to query which
 4762: setting is in effect (this would be handy even if it is
 4763: only "on" or "off" as presently).  If lock is in
 4764: effect, then commit would require a lock before
 4765: allowing a checkin; chmod wouldn't suffice (might be
 4766: debatable--see chmod comment below, in watches--but it
 4767: is the way people expect RCS to work and I can't think
 4768: of any significant downside.  On the other hand, maybe
 4769: it isn't worth bothering, because people who are used
 4770: to RCS wouldn't think to use chmod anyway).
 4771: 
 4772: Implementation: use file attributes or use RCS
 4773: locking.  The former avoids more dependence on RCS
 4774: behaviors we will need to reimplement as we librarify
 4775: RCS, and makes it easier to import/export RCS files (in
 4776: that context, want to ignore the locker field).  But
 4777: note that RCS locks are per-branch, which is the
 4778: correct behavior (this is also an issue for the "watch
 4779: on" features; they should be per-branch too).
 4780: 
 4781: Here are a few more random notes about implementation
 4782: details, assuming "cvs watch lock" and
 4783: 
 4784: CVS/Watched file?  Or try to fit this into CVS/Entries somehow?
 4785: Cases: (1) file is checked out (unreserved or with watch on) by old
 4786: version of CVS, now we do something with new one, (2) file is checked
 4787: out by new version, now we do something with old one.
 4788: 
 4789: Remote protocol would have a "Watched" analogous to "Mode".  Of course
 4790: it would apply to all Updated-like requests.  How do we keep this
 4791: setting up to date?  I guess that there wants to be a Watched request,
 4792: and the server would send a new one if it isn't up to date? (Ugh--hard
 4793: to implement and slows down "cvs -q update"--is there an easier way?)
 4794: 
 4795: "cvs edit"--checks CVS/Watched, and if watch lock, then sends
 4796: "edit-lock" request.  Which comes back with a Checked-in with
 4797: appropriate Watched (off, on, lock, locked, or some such?), or error
 4798: message if already locked.
 4799: 
 4800: "cvs commit"--only will commit if off/on/locked.  lock is not OK.
 4801: 
 4802: Doc:
 4803: note that "cvs edit" must be connected to network if watch lock is in
 4804: effect.
 4805: 
 4806: Talk about what to do if someone has locked a file and you want to
 4807: edit that file.  (breaking locks, or lack thereof).
 4808: 
 4809: 
 4810: One other idea (which could work along with the
 4811: existing "cvs admin -l" reserved checkouts, as well as
 4812: the above):
 4813: 
 4814: "cvs editors" could show who has the file locked, if
 4815: someone does.
 4816: 
 4817: @end ignore
 4818: 
 4819: @menu
 4820: * File status::                 ファイルは幾つかの状態を取る
 4821: * Updating a file::             ファイルを最新にする
 4822: * Conflicts example::           有益な実行例
 4823: * Informing others::            協力のために他の人にお知らせする
 4824: * Concurrency::                 リポジトリの同時利用
 4825: * Watches::                     ファイル編集者の追跡機構
 4826: * Choosing a model::            独占取得か無条件取得か?
 4827: @end menu
 4828: 
 4829: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4830: @node File status
 4831: @section ファイル状態
 4832: @cindex File status
 4833: @cindex Status of a file
 4834: 
 4835: @c Shouldn't this start with an example or something,
 4836: @c introducing the unreserved checkout model?  Before we
 4837: @c dive into listing states?
 4838: 取り出した後にあなたが加えた操作や、
 4839: 他の人物がリポジトリに加えた操作によって、
 4840: ファイルを幾つかの状態に分類します。
 4841: @code{status} コマンドによって報告される状態を以下に挙げます:
 4842: 
 4843: @c The order of items is chosen to group logically
 4844: @c similar outputs together.
 4845: @c People who want alphabetical can use the index...
 4846: @table @asis
 4847: @cindex Up-to-date
 4848: @item Up-to-date
 4849: このファイルが、
 4850: 使用している枝の最新リビジョンと同じであることを示します。
 4851: @c FIXME: should we clarify "in use"?  The answer is
 4852: @c sticky tags, and trying to distinguish branch sticky
 4853: @c tags from non-branch sticky tags seems rather awkward
 4854: @c here.
 4855: @c FIXME: What happens with non-branch sticky tags?  Is
 4856: @c a stuck file "Up-to-date" or "Needs checkout" or what?
 4857: 
 4858: @item Locally Modified
 4859: @cindex Locally Modified
 4860: このファイルを修正したが、まだ変更内容を格納してないことを示します。
 4861: 
 4862: @item Locally Added
 4863: @cindex Locally Added
 4864: @code{add} コマンドによりファイルを加えたが、
 4865: まだその内容を格納してないことを示します。
 4866: @c There are many cases involving the file being
 4867: @c added/removed/modified in the working directory, and
 4868: @c added/removed/modified in the repository, which we
 4869: @c don't try to describe here.  I'm not sure that "cvs
 4870: @c status" produces a non-confusing output in most of
 4871: @c those cases.
 4872: 
 4873: @item Locally Removed
 4874: @cindex Locally Removed
 4875: @code{remove} コマンドによりファイルを削除したが、
 4876: まだその変更を格納してないことを示します。
 4877: 
 4878: @item Needs Checkout
 4879: @cindex Needs Checkout
 4880: 他の人物が新しいリビジョンをリポジトリに格納したことを示します。
 4881: この表示は少し紛らわしいのですが、
 4882: 新しいリビジョンを取り出す際には、@code{checkout} ではなく、
 4883: @code{update} を使用するのが普通です。
 4884: 
 4885: @item Needs Patch
 4886: @cindex Needs Patch
 4887: @c See also newb-123j0 in sanity.sh (although that case
 4888: @c should probably be changed rather than documented).
 4889: Needs Checkout と似たようなものですが、
 4890: @sc{cvs} のサーバは、ファイル全てではなく差分を送ります。
 4891: 差分を送る場合も、ファイル全てを送る場合と結果は同じです。
 4892: 
 4893: @item Needs Merge
 4894: @cindex Needs Merge
 4895: 他の人物が新しいリビジョンをリポジトリに格納したが、
 4896: 作業ファイルも修正されていたため、マージする必要があることを示します。
 4897: 
 4898: @item File had conflicts on merge
 4899: @cindex File had conflicts on merge
 4900: @c is it worth saying that this message was "Unresolved
 4901: @c Conflict" in CVS 1.9 and earlier?  I'm inclined to
 4902: @c think that is unnecessarily confusing to new users.
 4903: Locally Modified と似ていますが、先の @code{update} コマンドの結果、
 4904: 変更点の衝突が発見されたことを示します。
 4905: 衝突を解消する方法は @ref{Conflicts example} 参照。
 4906: 
 4907: @item Unknown
 4908: @cindex Unknown
 4909: このファイルについて @sc{cvs} が何も知らないことを示します。
 4910: 例えば新たなファイルを作成したが、@code{add} を実行していない場合などです。
 4911: @c
 4912: @c "Entry Invalid" and "Classify Error" are also in the
 4913: @c status.c.  The latter definitely indicates a CVS bug
 4914: @c (should it be worded more like "internal error" so
 4915: @c people submit bug reports if they see it?).  The former
 4916: @c I'm not as sure; I haven't tracked down whether/when it
 4917: @c appears in "cvs status" output.
 4918: 
 4919: @end table
 4920: 
 4921: @code{status} は、ファイル状態を分類する際の補助として、
 4922: 作業中のファイルの由来となるリビジョン
 4923: を示す @samp{Working revision} と、
 4924: 使用中の枝のリポジトリにおける最新リビジョン
 4925: を示す @samp{Repository revision} とも報告します。
 4926: @c FIXME: should we clarify "in use"?  The answer is
 4927: @c sticky tags, and trying to distinguish branch sticky
 4928: @c tags from non-branch sticky tags seems rather awkward
 4929: @c here.
 4930: @c FIXME: What happens with non-branch sticky tags?
 4931: @c What is the Repository Revision there?  See the
 4932: @c comment at vn_rcs in cvs.h, which is kind of
 4933: @c confused--we really need to document better what this
 4934: @c field contains.
 4935: @c Q: Should we document "New file!" and other such
 4936: @c outputs or are they self-explanatory?
 4937: @c FIXME: what about the date to the right of "Working
 4938: @c revision"?  It doesn't appear with client/server and
 4939: @c seems unnecessary (redundant with "ls -l") so
 4940: @c perhaps it should be removed for non-client/server too?
 4941: @c FIXME: Need some examples.
 4942: @c FIXME: Working revision can also be something like
 4943: @c "-1.3" for a locally removed file.  Not at all
 4944: @c self-explanatory (and it is possible that CVS should
 4945: @c be changed rather than documenting this).
 4946: 
 4947: @c Would be nice to have an @example showing output
 4948: @c from cvs status, with comments showing the xref
 4949: @c where each part of the output is described.  This
 4950: @c might fit in nicely if it is desirable to split this
 4951: @c node in two; one to introduce "cvs status" and one
 4952: @c to list each of the states.
 4953: @code{status} コマンドのオプションについての情報は、@ref{Invoking CVS}
 4954: 参照。
 4955: @samp{Sticky tag} と @samp{Sticky date} についての
 4956: 情報は、@ref{Sticky tags} 参照。
 4957: @samp{Sticky options} の情報は、@ref{update options} 
 4958: の @samp{-k} オプションを参照して下さい。
 4959: 
 4960: @code{status} と @code{update} コマンドは補完するようなものとして考え
 4961: ることができます。ファイルを最新にするためには @code{update} を使い、
 4962: @code{status} で @code{update} が何をするかをある程度知ることができま
 4963: す (もちろん、リポジトリの状態は実際に @code{update} を実行するまでに
 4964: 変化するかもしれません)。実際は、@code{status} コマンドで表示されるよ
 4965: り短い形式でコマンドに表示させたければ、次を実行することができます
 4966: 
 4967: @cindex update, to display file status
 4968: @example
 4969: $ cvs -n -q update
 4970: @end example
 4971: 
 4972: @samp{-n} オプションは実際に update をしないが、状態を表示するだけであ
 4973: る、ということです。@samp{-q} オプションはそれぞれのディレクトリ名の印
 4974: 字を避けます。@code{update} コマンドとこれらのオプションの情報は、
 4975: @ref{Invoking CVS} を参照してください。
 4976: 
 4977: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4978: @node Updating a file
 4979: @section ファイルを最新にする
 4980: @cindex Bringing a file up to date
 4981: @cindex Updating a file
 4982: @cindex Merging a file
 4983: @cindex update, introduction
 4984: 
 4985: ファイルを更新もしくはマージしたい場合には、
 4986: @code{update} コマンドを使用します。
 4987: これは最新でないファイルに対しては @code{checkout} コマンドとほとんど
 4988: 等価です。
 4989: つまり、最新リビジョンのファイルをリポジトリから取り出して、
 4990: 作業ディレクトリにコピーします。
 4991: 
 4992: @code{update} コマンドを使用しても、
 4993: あなたの修正が失なわれることはありません。
 4994: より新しいバージョンが無い場合には、@code{update} は何もしません。
 4995: 新しいバージョンが存在し、かつ作業ファイルが修正されている場合、
 4996: @sc{cvs} は全ての変更を作業コピーにマージします。
 4997: 
 4998: 例えばリビジョン 1.4 を取り出して、編集を始めたとします。
 4999: その合間に他の人物がバージョン 1.5 を格納し、
 5000: またすぐに 1.6 になったとします。
 5001: ここで @code{update} コマンドを使用した場合、
 5002: @sc{cvs} は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。
 5003: 
 5004: @cindex Overlap
 5005: 1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、
 5006: @dfn{重複} (@dfn{overlap}) が起きます。
 5007: そして警告が表示され、ファイルには重複した行が両方並記されて、
 5008: 特別なマークで囲まれます。
 5009: @code{update} コマンドの詳細は @xref{update}.
 5010: 
 5011: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5012: @node Conflicts example
 5013: @section 衝突の例
 5014: @cindex Merge, an example
 5015: @cindex Example of merge
 5016: @cindex driver.c (merge example)
 5017: 
 5018: リビジョン 1.4 の @file{drive.c} は次のような内容とします:
 5019: 
 5020: @example
 5021: #include <stdio.h>
 5022: 
 5023: void main()
 5024: @{
 5025:     parse();
 5026:     if (nerr == 0)
 5027:         gencode();
 5028:     else
 5029:         fprintf(stderr, "No code generated.\n");
 5030:     exit(nerr == 0 ? 0 : 1);
 5031: @}
 5032: @end example
 5033: 
 5034: @noindent
 5035: リビジョン 1.6 では @file{drive.c} は次のようになっています:
 5036: 
 5037: @example
 5038: #include <stdio.h>
 5039: 
 5040: int main(int argc,
 5041:          char **argv)
 5042: @{
 5043:     parse();
 5044:     if (argc != 1)
 5045:     @{
 5046:         fprintf(stderr, "tc: No args expected.\n");
 5047:         exit(1);
 5048:     @}
 5049:     if (nerr == 0)
 5050:         gencode();
 5051:     else
 5052:         fprintf(stderr, "No code generated.\n");
 5053:     exit(!!nerr);
 5054: @}
 5055: @end example
 5056: 
 5057: @noindent
 5058: リビジョン 1.4 を元にしたあなたの @file{driver.c} の作業コピーは、
 5059: @samp{cvs update} の前に次ようになっています:
 5060: @c -- Really include "cvs"?
 5061: 
 5062: @example
 5063: #include <stdlib.h>
 5064: #include <stdio.h>
 5065: 
 5066: void main()
 5067: @{
 5068:     init_scanner();
 5069:     parse();
 5070:     if (nerr == 0)
 5071:         gencode();
 5072:     else
 5073:         fprintf(stderr, "No code generated.\n");
 5074:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5075: @}
 5076: @end example
 5077: 
 5078: @noindent
 5079: この時 @samp{cvs update} を実行してみます:
 5080: @c -- Really include "cvs"?
 5081: 
 5082: @example
 5083: $ cvs update driver.c
 5084: RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
 5085: retrieving revision 1.4
 5086: retrieving revision 1.6
 5087: Merging differences between 1.4 and 1.6 into driver.c
 5088: rcsmerge warning: overlaps during merge
 5089: cvs update: conflicts found in driver.c
 5090: C driver.c
 5091: @end example
 5092: 
 5093: @noindent
 5094: @cindex Conflicts (merge example)
 5095: @sc{cvs} は上記のように、衝突が起きたことが報告します。
 5096: あなたが編集したオリジナルのファイルは、
 5097: 無修正で @file{.#driver.c.1.4} という名前で保存されます。
 5098: @file{driver.c} の新しいバージョンは次のようになります:
 5099: 
 5100: @example
 5101: #include <stdlib.h>
 5102: #include <stdio.h>
 5103: 
 5104: int main(int argc,
 5105:          char **argv)
 5106: @{
 5107:     init_scanner();
 5108:     parse();
 5109:     if (argc != 1)
 5110:     @{
 5111:         fprintf(stderr, "tc: No args expected.\n");
 5112:         exit(1);
 5113:     @}
 5114:     if (nerr == 0)
 5115:         gencode();
 5116:     else
 5117:         fprintf(stderr, "No code generated.\n");
 5118: @asis{}<<<<<<< driver.c
 5119:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5120: @asis{}=======
 5121:     exit(!!nerr);
 5122: @asis{}>>>>>>> 1.6
 5123: @}
 5124: @end example
 5125: 
 5126: @noindent
 5127: @cindex Markers, conflict
 5128: @cindex Conflict markers
 5129: @cindex <<<<<<<
 5130: @cindex >>>>>>>
 5131: @cindex =======
 5132: 
 5133: 重複しなかった修正がどの様に作業コピーに組み込まれているか注意して下さ
 5134: い。
 5135: 重複した部分は
 5136: @samp{<<<<<<<}, @samp{=======} 及び @samp{>>>>>>>} 
 5137: ではっきりと囲まれています。
 5138: 
 5139: @cindex Resolving a conflict
 5140: @cindex Conflict resolution
 5141: ファイルを編集して衝突が起きた部分を解決し、
 5142: マークと間違った行を消します。
 5143: 最終的に次のようになったとします:
 5144: @c -- Add xref to the pcl-cvs manual when it talks
 5145: @c -- about this.
 5146: @example
 5147: #include <stdlib.h>
 5148: #include <stdio.h>
 5149: 
 5150: int main(int argc,
 5151:          char **argv)
 5152: @{
 5153:     init_scanner();
 5154:     parse();
 5155:     if (argc != 1)
 5156:     @{
 5157:         fprintf(stderr, "tc: No args expected.\n");
 5158:         exit(1);
 5159:     @}
 5160:     if (nerr == 0)
 5161:         gencode();
 5162:     else
 5163:         fprintf(stderr, "No code generated.\n");
 5164:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5165: @}
 5166: @end example
 5167: 
 5168: @noindent
 5169: 今やこのファイルを格納してリビジョン 1.7 とすることができます。
 5170: 
 5171: @example
 5172: $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
 5173: Checking in driver.c;
 5174: /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
 5175: new revision: 1.7; previous revision: 1.6
 5176: done
 5177: @end example
 5178: 
 5179: 衝突が起きたが未解決であるファイルは、安全を考慮して、
 5180: @sc{cvs} が格納することを拒否します。
 5181: 衝突を解決するとき、ファイルの編集時間を変更する必要があります。
 5182: 前のバージョンの @sc{cvs} では、ファイルに衝突マークがないことを確認す
 5183: る必要もありました。ファイルには正しく衝突マークがあるかもしれませんの
 5184: で (すなわち、行頭にある @samp{>>>>>>> } は衝突の印ではありません)、現
 5185: 在のバージョンの @sc{cvs} は警告を印字してファイルの格納を実行します。
 5186: @c The old behavior was really icky; the only way out
 5187: @c was to start hacking on
 5188: @c the @code{CVS/Entries} file or other such workarounds.
 5189: @c
 5190: @c If the timestamp thing isn't considered nice enough,
 5191: @c maybe there should be a "cvs resolved" command
 5192: @c which clears the conflict indication.  For a nice user
 5193: @c interface, this should be invoked by an interactive
 5194: @c merge tool like emerge rather than by the user
 5195: @c directly--such a tool can verify that the user has
 5196: @c really dealt with each conflict.
 5197: 
 5198: @cindex emerge
 5199: もしあなたが pcl-cvs (@sc{gnu} Emacs 用 @sc{cvs} フロントエンド) の、
 5200: 1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに 
 5201: emerge という Emacs パッケージが利用できます。
 5202: pcl-cvs の文書を見て下さい。
 5203: 
 5204: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5205: @node Informing others
 5206: @section 格納したことを他の人に知らせる
 5207: @cindex Informing others
 5208: @cindex Spreading information
 5209: @cindex Mail, automatic mail on commit
 5210: 
 5211: 新しいリビジョンが格納されたときに、
 5212: それを開発者全員に通知するようにしておくと便利でしょう。
 5213: @file{moduels} か @file{loginfo} ファイルの 
 5214: @samp{-i} オプションにより、この手順を自動化することができます 
 5215: @xref{modules}. @xref{loginfo}.
 5216: この機構により、例えば全ての開発者にメールを出したり、
 5217: ニュースに記事を投稿したりすることができます。
 5218: @c -- More text would be nice here.
 5219: 
 5220: @node Concurrency
 5221: @section 同時に CVS の実行を試みる複数の開発者
 5222: 
 5223: @cindex locks, cvs, introduction
 5224: @c For a discussion of *why* CVS creates locks, see
 5225: @c the comment at the start of src/lock.c
 5226: 複数の開発者が同時に @sc{cvs} を実行しようとした場合、
 5227: 次のようなメッセージが表示されます:
 5228: 
 5229: @example
 5230: [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
 5231: @end example
 5232: 
 5233: @cindex #cvs.rfl, removing
 5234: @cindex #cvs.wfl, removing
 5235: @cindex #cvs.lock, removing
 5236: @sc{cvs} は 30秒毎に実行を試み、
 5237: まだ待つ必要があれば再度メッセージを表示し、
 5238: そうでなければ処理を続けます。
 5239: 不適当な程長く待ち続けているようならば、
 5240: ロックさせている人物を見付けて、
 5241: 実行中の cvs コマンドを訊いてみて下さい。
 5242: cvs コマンドが実行されてないのならば、メッセージで書かれているリポジト
 5243: リディレクトリを見て、彼等が所有している 
 5244: @file{#cvs.tfl}, @file{#cvs.rfl}, @file{#cvs.wfl} 
 5245: という名前で始まるファイルを捜して、削除して下さい。
 5246: 
 5247: このロックは @sc{cvs} の内部データ構造を保護するもので、
 5248: @sc{rcs} で使用される@dfn{ロック} (@dfn{lock}) 
 5249: という言葉とは全く何の関係もないことに注意してください。
 5250: @sc{rcs} のロックについては、
 5251: 独占取得についての記述を参照して下さい (@pxref{Multiple developers})。
 5252: 
 5253: 任意のリポジトリから何人でも、
 5254: 同時に読み出すことが可能です。
 5255: 誰かが書き込み中の場合にだけ、
 5256: 他の人の読み出しや書き込みが禁止されます。
 5257: 
 5258: @cindex Atomic transactions, lack of
 5259: @cindex Transactions, atomic, lack of
 5260: @c the following talks about what one might call commit/update
 5261: @c atomicity.
 5262: @c Probably also should say something about
 5263: @c commit/commit atomicity, that is, "An update will
 5264: @c not get partial versions of more than one commit".
 5265: @c CVS currently has this property and I guess we can
 5266: @c make it a documented feature.
 5267: @c For example one person commits
 5268: @c a/one.c and b/four.c and another commits a/two.c and
 5269: @c b/three.c.  Then an update cannot get the new a/one.c
 5270: @c and a/two.c and the old b/four.c and b/three.c.
 5271: 次に示すような動作を望む人がいるでしょう
 5272: 
 5273: @example
 5274: ある人物が一つの cvs コマンドで複数のファイルに対する変更点を
 5275: 格納した時、他の誰かが同時に update を実行すると、全てのファイルが
 5276: 更新されるか、全く更新されないかのどちらかである。
 5277: @end example
 5278: 
 5279: が、@sc{cvs} はこのように動作@emph{しません}。
 5280: 例えば以下のファイルがあるとして、
 5281: 
 5282: @example
 5283: a/one.c
 5284: a/two.c
 5285: b/three.c
 5286: b/four.c
 5287: @end example
 5288: 
 5289: ある人物が次のコマンドを実行した時、
 5290: 
 5291: @example
 5292: cvs ci a/two.c b/three.c
 5293: @end example
 5294: 
 5295: 同時に他の誰かが @code{cvs update} を実行した場合、
 5296: @code{update} を実行している人は @file{b/three.c} の変更点のみが更新さ
 5297: れ、
 5298: @file{a/two.c} の変更点は更新されないでしょう。
 5299: 
 5300: @node Watches
 5301: @section ファイル編集者の追跡機構
 5302: @cindex Watches
 5303: 
 5304: 多くのグループが @sc{cvs} を既定状態で使用していますが、
 5305: ほぼ完全に満足しているようです。
 5306: しかし時には、自分と他人の修正点が重複する事があり、
 5307: この重複を処理して再び格納しなくてはいけません。
 5308: あるグループでは、
 5309: 誰がどのファイルを編集中か分るようにしています。
 5310: 従って、二人で同じファイルを編集する場合、
 5311: 誰が何時何をするのか相談できるため、
 5312: 格納時に驚かされずに済みます。
 5313: この節では、
 5314: このような調整作業を行なう機能について説明しますが、
 5315: 二人の開発者が同時に同じファイルを編集する能力は維持されます。
 5316: 
 5317: @c Some people might ask why CVS does not enforce the
 5318: @c rule on chmod, by requiring a cvs edit before a cvs
 5319: @c commit.  The main reason is that it could always be
 5320: @c circumvented--one could edit the file, and
 5321: @c then when ready to check it in, do the cvs edit and put
 5322: @c in the new contents and do the cvs commit.  One
 5323: @c implementation note: if we _do_ want to have cvs commit
 5324: @c require a cvs edit, we should store the state on
 5325: @c whether the cvs edit has occurred in the working
 5326: @c directory, rather than having the server try to keep
 5327: @c track of what working directories exist.
 5328: @c FIXME: should the above discussion be part of the
 5329: @c manual proper, somewhere, not just in a comment?
 5330: 開発者は、
 5331: 編集するファイルを読み書き可能にする時に、
 5332: (@code{chmod} でなく) @code{cvs edit} を使用し、
 5333: もう使用しない作業ディレクトリを処分する時に、
 5334: (@code{rm} でなく) @code{cvs release} を使用することが推奨されます。
 5335: しかし、@sc{cvs} はこれらの手順を強制する事は出来ません。
 5336: 
 5337: @c I'm a little dissatisfied with this presentation,
 5338: @c because "watch on"/"edit"/"editors" are one set of
 5339: @c functionality, and "watch add"/"watchers" is another
 5340: @c which is somewhat orthogonal even though they interact in
 5341: @c various ways.  But I think it might be
 5342: @c confusing to describe them separately (e.g. "watch
 5343: @c add" with loginfo).  I don't know.
 5344: 
 5345: @menu
 5346: * Setting a watch::             監視するファイルを CVS に教える
 5347: * Getting Notified::            誰に通知するか CVS に教える
 5348: * Editing files::               監視下にあるファイルの編集方法
 5349: * Watch information::           誰が監視や編集をしているか
 5350: * Watches Compatibility::       監視は CVS 1.6 以前と上手く協調しない
 5351: @end menu
 5352: 
 5353: @node Setting a watch
 5354: @subsection 監視するファイルを CVS に教える
 5355: 
 5356: 監視機能を有効にするには、
 5357: まずそのファイルを監視するように指示する必要があります。
 5358: 
 5359: @cindex watch on (subcommand)
 5360: @deffn コマンド {cvs watch on} [@code{-lR}] files @dots{}
 5361: 
 5362: @cindex read-only files, and watches
 5363: この指定以降、@var{files} を編集しようとする開発者は 
 5364: @code{cvs edit} を実行する必要があります。
 5365: 開発者が編集前に @code{cvs edit} の実行を忘れない様に、
 5366: @sc{cvs} は @var{files} の読み込みだけを許可します。
 5367: 
 5368: @var{files} がディレクトリを含む場合、
 5369: リポジトリの対応するディレクトリ内の全てのファイルに加えて、
 5370: 将来ディレクトリに追加されるファイル全てが 
 5371: @sc{cvs} の監視対象になります。
 5372: この動作を利用して、ディレクトリ毎に通知方針を設定することができます。
 5373: またオプション @samp{-l} を指定しない場合、
 5374: ディレクトリ以下が再帰的に処理されます。
 5375: @code{-l} オプションが @file{~/.cvsrc} で設定されている場合は 
 5376: @code{-R} オプションを使って再帰を強制することができます 
 5377: (@pxref{~/.cvsrc})。
 5378: 
 5379: @var{files} を省略した場合、
 5380: 現在のディレクトリが指定されたと解釈します。
 5381: 
 5382: @cindex watch off (subcommand)
 5383: @end deffn
 5384: 
 5385: @deffn コマンド {cvs watch off} [@code{-lR}] files @dots{}
 5386: 
 5387: @var{files} が編集された時の通知を行ないません。
 5388: @sc{cvs} は @var{files} の作業コピーを読み書き可能にします。
 5389: 
 5390: @var{files} や引数指定時の振舞いは、
 5391: @code{cvs watch on} の場合と同じです。
 5392: 
 5393: @end deffn
 5394: 
 5395: @node Getting Notified
 5396: @subsection 誰に通知するか CVS に教える
 5397: 
 5398: あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、
 5399: その旨を @sc{cvs} に知らせます。
 5400: そのファイルに対して @code{cvs watch on} を用いなくても、
 5401: 通知の要求は可能です。
 5402: しかし、開発者がコマンド @code{cvs edit} を用いるとは限らないため、
 5403: 通常は @code{cvs watch on} を用いた方が良いでしょう。
 5404: 
 5405: @cindex watch add (subcommand)
 5406: @deffn コマンド {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{}
 5407: 
 5408: 現在の使用者を、 @var{files} に対して操作が行なわれた時に
 5409: 通知を受けとる人の一覧に追加します。
 5410: 
 5411: オプション @samp{-a} には、
 5412: 通知して欲しい操作の種類を指定します。
 5413: @var{action} は次のうちのどれかです:
 5414: 
 5415: @table @code
 5416: 
 5417: @item edit
 5418: あなた以外の人物が、
 5419: ファイルに対してコマンド @code{cvs edit} (後述) を適用した場合。
 5420: 
 5421: @item unedit
 5422: あなた以外の人物が、
 5423: ファイルに対してコマンド @code{cvs unedit} (後述) または 
 5424: @code{cvs release} を適用した場合。
 5425: また、ファイルが消されて @code{cvs update} により再度生成された場合。
 5426: 
 5427: @item commit
 5428: あなた以外の人物が、ファイルに対する変更を格納した場合。
 5429: 
 5430: @item all
 5431: 上記全て。
 5432: 
 5433: @item none
 5434: 上記以外。
 5435: (これは後述の @code{cvs edit} で使用すると便利です。)
 5436: 
 5437: @end table
 5438: 
 5439: オプション @samp{-a} は何度指定しても良いし、
 5440: 全く指定しなくても構いません。
 5441: 省略した場合には、@code{all} が指定されたと解釈します。
 5442: 
 5443: @var{files} や引数指定時の振舞いは、
 5444: @code{cvs watch on} の場合と同じです。
 5445: 
 5446: @end deffn
 5447: 
 5448: 
 5449: @cindex watch remove (subcommand)
 5450: @deffn コマンド {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{}
 5451: 
 5452: @code{cvs watch add} で設定した通知要求を取り下げます。
 5453: 引数は同じです。
 5454: オプション @samp{-a} を用いた場合、
 5455: 指定された事項に対する通知のみを停止します。
 5456: 
 5457: @end deffn
 5458: 
 5459: @cindex notify (admin file)
 5460: 通知すべき状態が発生した時、
 5461: @sc{cvs} は管理用ファイル @file{notify} を見ます。
 5462: @file{notify} は他の管理用ファイルと同じように編集して下さい。
 5463: (@pxref{Intro administrative files})。
 5464: 管理用ファイルの慣例に従って (@pxref{syntax})、このファイルの各行には、
 5465: 正規表現に続けて実行したいコマンドを記述します。
 5466: コマンドの引数には、(通知すべき使用者に置換される) 
 5467: @samp{%s} という文字列を一つだけ指定する必要があり、
 5468: 通知内容はコマンドの標準入力に与えられます。
 5469: ファイル @code{notify} に書く標準のものは次の一行です:
 5470: 
 5471: @example
 5472: ALL mail %s -s \"CVS notification\"
 5473: @end example
 5474: 
 5475: この記述により、使用者に電子メールで通知が行なわれます。
 5476: @c FIXME: should it be this hard to set up this
 5477: @c behavior (and the result when one fails to do so,
 5478: @c silent failure to notify, so non-obvious)?  Should
 5479: @c CVS give a warning if no line in notify matches (and
 5480: @c document the use of "DEFAULT :" for the case where
 5481: @c skipping the notification is indeed desired)?
 5482: 
 5483: @cindex users (admin file)
 5484: 上記の行をそのまま記述した場合、
 5485: 使用者はサーバ上で通知を受ける事に注意して下さい。
 5486: 他の場所に通知したい場合には、
 5487: もちろん @file{notify} に記述しても良いのですが、
 5488: @sc{cvs} ではもっと簡単に各使用者の通知先を設定できます。
 5489: @file{CVSROOT} に @file{users} というファイルを作成し、
 5490: @var{user}:@var{value} という書式で、
 5491: 各使用者について一行ずつ記述して下さい。
 5492: @sc{cvs} は、@file{notify} に記述された @var{user} の代りに、
 5493: @var{value} (通常は別のマシンのメールアドレス) に通知します。
 5494: 
 5495: @sc{Cvs} はあなた自身の変更は通知しません。現時点では、この照合は通知
 5496: を発生させる動作をしている人の使用者名が通知を受ける人の使用者名と合う
 5497: かどうかに基づいてなされています。実際のところ、一般的に、監視機構はそ
 5498: れぞれの使用者の一つの編集だけを追跡します。おそらく、監視がそれぞれの
 5499: 作業ディレクトリを別に追跡するとより便利なので、この振舞いは変更する
 5500: 価値があるでしょう。
 5501: @c "behavior might be worth changing" is an effort to
 5502: @c point to future directions while also not promising
 5503: @c that "they" (as in "why don't they fix CVS to....")
 5504: @c will do this.
 5505: @c one implementation issue is identifying whether a
 5506: @c working directory is same or different.  Comparing
 5507: @c pathnames/hostnames is hopeless, but having the server
 5508: @c supply a serial number which the client stores in the
 5509: @c CVS directory as a magic cookie should work.
 5510: 
 5511: @node Editing files
 5512: @subsection 監視下にあるファイルの編集方法
 5513: 
 5514: @cindex checkout, as term for getting ready to edit
 5515: 監視下にあるファイルを取り出した場合、
 5516: 読み込みだけが許可されるため、単純に編集はできません。
 5517: 読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、
 5518: @code{cvs edit} コマンドを使用して下さい。
 5519: 上記の作業を @dfn{checkout} と呼ぶシステムもありますが、
 5520: @sc{cvs} ではこの用語をソースのコピーを得る (@dfn{取り出す}) 
 5521: という意味で用います (@pxref{Getting the source})。
 5522: 他のシステムでは、この操作は @dfn{get} とか @dfn{fetch} と呼ばれます。
 5523: @c Issue to think about: should we transition CVS
 5524: @c towards the "get" terminology?  "cvs get" is already a
 5525: @c synonym for "cvs checkout" and that section of the
 5526: @c manual refers to "Getting the source".  If this is
 5527: @c done, needs to be done gingerly (for example, we should
 5528: @c still accept "checkout" in .cvsrc files indefinitely
 5529: @c even if the CVS's messages are changed from "cvs checkout: "
 5530: @c to "cvs get: ").
 5531: @c There is a concern about whether "get" is not as
 5532: @c good for novices because it is a more general term
 5533: @c than "checkout" (and thus arguably harder to assign
 5534: @c a technical meaning for).
 5535: 
 5536: @cindex edit (subcommand)
 5537: @deffn コマンド {cvs edit} [options] files @dots{}
 5538: 
 5539: 作業ファイル @var{files} を編集する準備をします。
 5540: @sc{cvs} は @var{files} の読み書きを許可し、
 5541: @var{files} に対する @code{edit} 通知を求める使用者に通知します。
 5542: 
 5543: @code{cvs edit} コマンドに、
 5544: @code{cvs watch add} コマンドと同じ @var{options} を使用すれば、
 5545: 一時的に @var{files} を監視することができます。
 5546: @sc{cvs} は、
 5547: @var{files} が @code{unedit} もしくは @code{commit} されたときに、
 5548: 監視を止めます。
 5549: 通知を受けたくない場合には、@samp{-a none} を指定して下さい。
 5550: 
 5551: @var{files} や引数指定時の振舞いは、
 5552: @code{cvs watch} の場合と同じです。
 5553: 
 5554: @strong{注意:} @code{PreservePermissions} オプションがリポジトリで使用
 5555: 可になっていると (@pxref{config})、CVS はどの @var{files} の使用許可も
 5556: 変更しません。この変更の理由は @samp{cvs edit} の使用が CVS リポジトリ
 5557: のファイル使用許可を保管する機能と干渉しないようにするということです。
 5558: 
 5559: @end deffn
 5560: 
 5561: 変更を全て終了したら、通常は @code{cvs commit} を用いて、
 5562: 監視下にあるファイルの変更点を格納し、
 5563: 読み込みだけが許可された状態に戻します。
 5564: しかし、途中で変更を止めたり、何も変更しないと決めた場合には、
 5565: @code{cvs unedit} コマンドを使用します。
 5566: 
 5567: @cindex unedit (subcommand)
 5568: @cindex abandoning work
 5569: @cindex reverting to repository version
 5570: @deffn コマンド {cvs unedit} [@code{-lR}] files @dots{}
 5571: 
 5572: 作業ファイル @var{files} に加えた変更を捨て、
 5573: 変更前のリポジトリのバージョンに戻します。
 5574: @var{files} に対して、@code{cvs watch on} による通知要求がある場合、
 5575: @sc{cvs} は @var{files} の読み込みだけを許可します。
 5576: また @var{files} に対する @code{unedit} 通知を求める使用者に通知します。
 5577: 
 5578: @var{files} や引数指定時の振舞いは、
 5579: @code{cvs watch} の場合と同じです。
 5580: 
 5581: ファイルが監視されてないときにはおそらく 
 5582: @code{unedit} コマンドが動作しないため、
 5583: リポジトリのバージョンに戻したい場合は、ファイルを削除してから 
 5584: @code{cvs update} で新たにコピーを取得して下さい。
 5585: これは厳密には同じ意味ではなく、削除して更新した場合には、
 5586: あなたが最後に更新した後にリポジトリに加えられた変更も付随します。
 5587: @c It would be a useful enhancement to CVS to make
 5588: @c unedit work in the non-watch case as well.
 5589: @end deffn
 5590: 
 5591: @sc{cvs} のクライアント/サーバを使用していて、
 5592: サーバとうまく接続できなかった場合でも、
 5593: @code{cvs edit} や @code{cvs unedit} コマンドが使用できます。
 5594: 次に @sc{cvs} コマンドが成功した時に、
 5595: 一緒に通知が行なわれます。
 5596: 
 5597: @node Watch information
 5598: @subsection 誰が監視や編集をしているか
 5599: 
 5600: @cindex watchers (subcommand)
 5601: @deffn コマンド {cvs watchers} [@code{-lR}] files @dots{}
 5602: 
 5603: 現在、@var{files} の変更を監視している人物の一覧を表示します。
 5604: 監視されているファイルと、各監視者のメールアドレスを報告します。
 5605: 
 5606: @var{files} や引数指定時の振舞いは、
 5607: @code{cvs watch} の場合と同じです。
 5608: 
 5609: @end deffn
 5610: 
 5611: 
 5612: @cindex editors (subcommand)
 5613: @deffn コマンド {cvs editors} [@code{-lR}] files @dots{}
 5614: 
 5615: 現在、@var{files} を編集している人物の一覧を表示します。
 5616: 各編集者のメールアドレス、編集作業を開始した時間、
 5617: ファイルが置かれた作業ディレクトリのパス名とホスト名を報告します。
 5618: 
 5619: @var{files} や引数指定時の振舞いは、
 5620: @code{cvs watch} の場合と同じです。
 5621: 
 5622: @end deffn
 5623: 
 5624: @node Watches Compatibility
 5625: @subsection 古いバージョンの CVS と監視機能
 5626: 
 5627: @cindex CVS 1.6, and watches
 5628: 監視機能を使用している場合、
 5629: リポジトリに @file{CVS} というディレクトリが作成され、
 5630: このディレクトリに監視情報が格納されます。
 5631: このリポジトリに対して @sc{cvs} 1.6 以前のものを使用した場合には、
 5632: 以下のエラー・メッセージが出力されます (全て一行にでます):
 5633: 
 5634: @example
 5635: cvs update: cannot open CVS/Entries for reading:
 5636: No such file or directory
 5637: @end example
 5638: 
 5639: そして、操作が途中で終了します。
 5640: 監視機能を使用するためには、
 5641: このリポジトリを利用するクライアント/サーバ両方で、
 5642: @sc{cvs} を新しいものと交換する必要があります。
 5643: もし新しいものと交換できない場合には、
 5644: @code{watch off} と @code{watch remove} コマンドを用いて
 5645: 監視を全て停止すれば、
 5646: リポジトリを @sc{cvs} 1.6 が利用できる状態に再構築できます。
 5647: 
 5648: @node Choosing a model
 5649: @section 独占取得と無条件取得の選択
 5650: @cindex choosing, reserved or unreserved checkouts
 5651: 
 5652: 独占取得、無条件取得それぞれに一長一短があります。
 5653: ここでは、この問題を簡単に説明しますが、
 5654: 残りの多くは個人的な見解の相違や、
 5655: 各グループの作業スタイルの相違だと思います。
 5656: 開発者チームを構成するには様々な方法があります。
 5657: @sc{cvs} は特定の構成を強制せず、
 5658: 各々を実現する機能を提供するだけです。
 5659: 
 5660: 独占取得には、非常に非生産的な部分があります。
 5661: 二人が同じファイルを編集する場合でも、編集部分が異なる場合には、
 5662: どちらか一方の編集を禁止する必要は全くありません。
 5663: また、ファイルを編集するためにロックした後、
 5664: ロック解除を忘れてしまうことが、普通に起こり得ます。
 5665: 
 5666: @c "many groups"?  specifics?  cites to papers on this?
 5667: @c some way to weasel-word it a bit more so we don't
 5668: @c need facts :-)?
 5669: 独占取得に特別な安心感を持つ人々は、
 5670: 無条件取得を用いた場合の衝突の多さや、
 5671: それを解決する困難さをよく訴えます。
 5672: しかし多くのグループの経験から言うと、
 5673: 衝突は稀であり、解決も普通は比較的簡単なものです。
 5674: 
 5675: 衝突は2人の開発者がコードの与えられた部分の適切な設計について
 5676: 意見が食い違っているときにのみ起こることを理解するまで、
 5677: 深刻な衝突の発生の少なさは驚きでしょう。
 5678: このような衝突は、そもそもチーム内での意思疎通が上手く行っていないこと
 5679: を示しています。
 5680: @emph{どのような}ソース管理方法を採るにしても、
 5681: 開発者が共同で作業する際には、
 5682: システム全体の設計方針に従わなければいけません。
 5683: きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。
 5684: 
 5685: 無条件取得が、全く不適当な場合があります。
 5686: 管理下にあるファイルの形式をマージする道具が無く 
 5687: (例えばワード・プロセッサによるファイルや、
 5688: CAD プログラムで編集されたファイル等)、
 5689: マージ可能なデータ書式を使用するようにプログラムを変更できない場合、
 5690: 悪夢のような衝突解決をするよりは、
 5691: 普通は独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。
 5692: 
 5693: 上の @ref{Watches} で記述された監視機構は、
 5694: 独占取得と無条件取得の中間的なものと考えられます。
 5695: ファイルを編集する前に、
 5696: 他の誰がファイルを編集中なのか調べることができます。
 5697: これは単純に双方の同時編集を禁止するのではなく、
 5698: 現況を報告し、それが問題かどうかは自分で判断してもらいます。
 5699: これを適切に使用すれば、
 5700: 独占取得と無条件取得の中でも最善の選択となるでしょう。
 5701: 
 5702: @c ---------------------------------------------------------------------
 5703: @node Revision management
 5704: @chapter リビジョン管理
 5705: @cindex Revision management
 5706: 
 5707: @c -- This chapter could be expanded a lot.
 5708: @c -- Experiences are very welcome!
 5709: 
 5710: ここまで読んだあなたは、
 5711: @sc{cvs} を使って何ができるかを、もう随分理解しているでしょう。
 5712: ここでは、あなたが決めるべき事柄について少し説明します。
 5713: 
 5714: あなたが一人で @sc{cvs} を使用して開発しているならば、
 5715: ここは読み飛ばして結構です。
 5716: 複数の人物が同じリポジトリを使って作業する場合に、
 5717: ここで説明する問題が重要になってきます。
 5718: 
 5719: @menu
 5720: * When to commit::              この問題の論議
 5721: @end menu
 5722: 
 5723: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5724: @node When to commit
 5725: @section いつ格納すべきか?
 5726: @cindex When to commit
 5727: @cindex Commit, when to
 5728: @cindex Policy
 5729: 
 5730: あなたのグループは、格納の時期に関して、
 5731: どのような方針を採るか決めておく必要があります。
 5732: 幾つかの方針が可能であり、@sc{cvs} での経験を重ねることによって、
 5733: 独自の方法を見付けることができるでしょう。
 5734: 
 5735: とにかく早く格納することにして、
 5736: コンパイルもせずに格納してしまったとします。
 5737: あなたの同僚が、作業ソースを更新して
 5738: あなたのバギーなファイルを取り込んだ場合、
 5739: 彼はコンパイルができません。
 5740: 逆にめったに格納しない場合、
 5741: 同僚はあなたがコードに加えた改良の利益を得ることができず、
 5742: 衝突がより多くなるでしょう。
 5743: 
 5744: コンパイルできるかどうか確認したファイルだけを
 5745: 格納する方法がよく採られます。
 5746: あるサイトでは、ファイルが検査に合格することを要求します。
 5747: @file{commitinfo} ファイルを使用して (@pxref{commitinfo})、
 5748: このような方針を強制できますが、その前によく考えなくてはいけません。
 5749: 十分過ぎる程管理された開発環境を作ると、
 5750: 厳格になり過ぎて、非生産的になり、
 5751: ソフトウェアを書くという目的が果たせなくなります。
 5752: 
 5753: @c ---------------------------------------------------------------------
 5754: @node Keyword substitution
 5755: @chapter キーワード置換
 5756: @cindex Keyword substitution
 5757: @cindex Keyword expansion
 5758: @cindex Identifying files
 5759: 
 5760: @comment   この章を編集する場合には十分注意して下さい。
 5761: @comment   このファイルはバージョン管理されており、
 5762: @comment   有効なキーワードが、文中に含まれないように
 5763: @comment   注意しなくてはいけません。
 5764: 
 5765: モジュールの作業ファイルを編集している間は、
 5766: @samp{cvs status} や @samp{cvs log} を使って
 5767: そのファイルの状態を調べることができます。
 5768: しかし開発環境から取り出した場合は、
 5769: 各ファイルのリビジョンを識別するのが難しくなります。
 5770: 
 5771: CVSは、@dfn{キーワード置換} (@dfn{keyword substitution}) 
 5772: (もしくは@dfn{キーワード展開} (@dfn{keyword expansion}))
 5773: と呼ばれる機構により、ファイルの識別を補助します。
 5774: ファイル中に @code{$@var{keyword}$}, 
 5775: @code{$@var{keyword}:@dots{}$} といった書式で
 5776: 埋め込まれた文字列を、ファイルを取り出すときに 
 5777: @code{$@var{keyword}:@var{value}$} といった書式の文字列に置き換えます。
 5778: 
 5779: @menu
 5780: * Keyword list::                キーワード
 5781: * Using keywords::              キーワードの使用
 5782: * Avoiding substitution::       置換を止めるには
 5783: * Substitution modes::          置換モード
 5784: * Log keyword::                 キーワード $@asis{}Log$ の問題点
 5785: @end menu
 5786: 
 5787: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5788: @node Keyword list
 5789: @section キーワード一覧
 5790: @cindex Keyword List
 5791: 
 5792: @c FIXME: need some kind of example here I think,
 5793: @c perhaps in a
 5794: @c "Keyword intro" node.  The intro in the "Keyword
 5795: @c substitution" node itself seems OK, but to launch
 5796: @c into a list of the keywords somehow seems too abrupt.
 5797: 
 5798: これはキーワードの利用の一覧です:
 5799: 
 5800: @table @code
 5801: @cindex Author keyword
 5802: @item $@asis{Author}$
 5803: そのリビジョンを格納したユーザのログイン名。
 5804: 
 5805: @cindex Date keyword
 5806: @item $@asis{Date}$
 5807: そのリビジョンを格納した日付と時間 (UTC)。
 5808: 
 5809: @cindex Header keyword
 5810: @item $@asis{Header}$
 5811: 標準のヘッダは、@sc{rcs} ファイルのフルパス名, 
 5812: リビジョン番号, 日付 (UTC), 最終変更者, ファイル状態, 
 5813: (ロックされているならば) ロックしている人物という情報で
 5814: 構成されます。
 5815: @sc{cvs} を使用する場合、普通ファイルはロックされません。
 5816: 
 5817: @cindex Id keyword
 5818: @item $@asis{Id}$
 5819: @sc{rcs} ファイル名がフルパスでないことを除けば、
 5820: @code{$@asis{Header}$} と同じです。
 5821: 
 5822: @cindex Name keyword
 5823: @item $@asis{Name}$
 5824: このファイルを取り出すときに使用したタグ名。
 5825: @c FIXME: should supply an example (e.g. "if you use
 5826: @c "cvs update -r foo" then Name expands to "foo").  Also
 5827: @c should add Name to testsuite (best way to ensure
 5828: @c that the example is correct!)
 5829: 
 5830: @cindex Locker keyword
 5831: @item $@asis{Locker}$
 5832: そのリビジョンをロックしている人物のログイン名。
 5833: (ロックされていなければ空です。
 5834: 従って @sc{cvs} を使用する限りは無意味です。)
 5835: 
 5836: @cindex Log keyword
 5837: @item $@asis{Log}$
 5838: @sc{rcs} ファイル名, リビジョン番号, 最終変更者, 
 5839: 日付 (UTC) から構成されるヘッダ行に続けて、
 5840: 格納時のログ・メッセージを挿入します。
 5841: 以前に挿入されたログ・メッセージを置き換えるのでは@emph{なく}、
 5842: 新しいメッセージを @code{$@asis{Log:@dots{}}$} の次の行に挿入します。
 5843: それぞれの新しい行には @code{$Log} キーワードの前にあるものと
 5844: 同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。
 5845: 
 5846: @example
 5847:   /* Here is what people have been up to:
 5848:    *
 5849:    * $@asis{}Log: frob.c,v $
 5850:    * Revision 1.1  1997/01/03 14:23:51  joe
 5851:    * Add the superfrobnicate option
 5852:    *
 5853:    */
 5854: @end example
 5855: 
 5856: @noindent
 5857: そうすると、@code{$Log} を展開するときに追加される行はその前に 
 5858: @samp{  * } が付きます。以前のバージョンの @sc{cvs}、@sc{rcs} と違って、
 5859: @sc{rcs} ファイル の @dfn{註釈符} (@dfn{comment leader}) は使用されま
 5860: せん。
 5861: @code{$Log} キーワードは、
 5862: ソース・ファイルに全てのログを残したい場合には便利ですが、
 5863: 問題点も幾つかあります (@pxref{Log keyword})。
 5864: 
 5865: @cindex RCSfile keyword
 5866: @item $@asis{RCSfile}$
 5867: パスを含まない @sc{rcs} ファイル名。
 5868: 
 5869: @cindex Revision keyword
 5870: @item $@asis{Revision}$
 5871: そのリビジョンを表わすリビジョン番号。
 5872: 
 5873: @cindex Source keyword
 5874: @item $@asis{Source}$
 5875: RCS ファイルのフルパス名。
 5876: 
 5877: @cindex State keyword
 5878: @item $@asis{State}$
 5879: そのリビジョンの状態。
 5880: 各リビジョンの状態は、@samp{cvs admin -s} で割り当てることができます---
 5881: @ref{admin options} 参照。
 5882: 
 5883: @end table
 5884: 
 5885: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5886: @node Using keywords
 5887: @section キーワードの使用
 5888: 
 5889: キーワードを使いたい場合は、@code{$@asis{Id}$} などの適当な文字列を
 5890: ファイルに記述してから格納するだけです。
 5891: @sc{cvs} は格納操作の一環として自動的に文字列を展開します。
 5892: 
 5893: @code{$@asis{}Id$} 文字列をソースファイルに入れて、生成されるファイル
 5894: にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
 5895: ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
 5896: れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために 
 5897: @code{#pragma ident} 命令が使用できるコンパイラもあります。もしくは、
 5898: 文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
 5899: れません。
 5900: 
 5901: @c Would be nice to give an example, but doing this in
 5902: @c portable C is not possible and the problem with
 5903: @c picking any one language (VMS HELP files, Ada,
 5904: @c troff, whatever) is that people use CVS for all
 5905: @c kinds of files.
 5906: 
 5907: @cindex Ident (shell command)
 5908: @code{ident} コマンド (@sc{rcs} パッケージの一部) を使用して、
 5909: ファイルからキーワードとその値を抜き出すことができます。
 5910: もちろんテキスト・ファイルにも使えますが、
 5911: バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。
 5912: 
 5913: @example
 5914: $ ident samp.c
 5915: samp.c:
 5916:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 5917: $ gcc samp.c
 5918: $ ident a.out
 5919: a.out:
 5920:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 5921: @end example
 5922: 
 5923: @cindex What (shell command)
 5924: 別のリビジョン管理システムとして有名なものに @sc{sccs} があります。
 5925: @sc{sccs} には、@code{ident} と非常によく似た
 5926: 同じ用途のコマンド @code{what} が含まれます。
 5927: @sc{rcs} を持たないサイトの多くは @sc{sccs} を使っています。
 5928: @code{what} コマンドは @code{@@(#)} という文字列を探すため、
 5929: 両方のコマンドに対応するキーワードを含めるのは簡単です。
 5930: @sc{rcs} のキーワードの前に、
 5931: 簡単な @sc{sccs} の魔法の呪文を唱えるだけで良いのです:
 5932: 
 5933: @example
 5934: static char *id="@@(#) $@asis{}Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
 5935: @end example
 5936: 
 5937: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5938: @node Avoiding substitution
 5939: @section 置換を止めるには
 5940: 
 5941: キーワード置換にも欠点があります。
 5942: ファイル中に表われる文字列 @samp{$@asis{}Author$} は、
 5943: @sc{rcs} によってキーワードと見倣されます。
 5944: この文字列を @samp{$@asis{}Author: ceder $} などと解釈させずに、
 5945: そのまま使いたい事があるでしょう。
 5946: 
 5947: 不幸なことに、選択的にキーワード置換を止めることはできません。
 5948: @samp{-ko} によって完全にキーワード置換を止めることができます 
 5949: (@pxref{Substitution modes})。
 5950: 
 5951: @sc{rcs} キーワードが最終製品に現われるとしても、
 5952: ソース・ファイル中には使いたくない場合が多くあります。
 5953: 例えばこのマニュアルのソースには @samp{$@asis{}Author$} ではなく、
 5954: @samp{$@@asis@{@}Author$} と記述しています。
 5955: @code{nroff} や @code{troff} であれば、
 5956: ヌル文字である @code{\&} をキーワード中に埋め込めば
 5957: 同様の効果を発揮します。
 5958: 
 5959: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5960: @node Substitution modes
 5961: @section 置換モード
 5962: @cindex -k (keyword substitution)
 5963: @cindex Kflag
 5964: 
 5965: @c FIXME: This could be made more coherent, by expanding it
 5966: @c with more examples or something.
 5967: 各ファイルには既定の置換モードが設定されており、
 5968: 作業ディレクトリの各ファイルの置換モードも別々に設定できます。
 5969: 前者は @code{cvs add} や @code{cvs admin} に
 5970: オプション @samp{-k} を付けて設定します。
 5971: 後者は @code{cvs checkout} や @code{cvs update} に
 5972: オプション @samp{-k} や @samp{-A} を付けて設定します。
 5973: @code{cvs diff} にも @samp{-k} オプションがあります。
 5974: 例が幾つかありますので、@ref{Binary files} 参照。
 5975: @c The fact that -A is overloaded to mean both reset
 5976: @c sticky options and reset sticky tags/dates is
 5977: @c somewhat questionable.  Perhaps there should be
 5978: @c separate options to reset sticky options (e.g. -k
 5979: @c A") and tags/dates (someone suggested -r HEAD could
 5980: @c do this instead of setting a sticky tag of "HEAD"
 5981: @c as in the status quo but I haven't thought much
 5982: @c about that idea.  Of course -r .reset or something
 5983: @c could be coined if this needs to be a new option).
 5984: @c On the other hand, having -A mean "get things back
 5985: @c into the state after a fresh checkout" has a certain
 5986: @c appeal, and maybe there is no sufficient reason for
 5987: @c creeping featurism in this area.
 5988: 
 5989: 利用できるモードを以下に示します:
 5990: 
 5991: @table @samp
 5992: @item -kkv
 5993: 既定形式でキーワード文字列を生成します。
 5994: 例えば、キーワード @code{Revision} に対して 
 5995: @code{$@asis{}Revision: 5.7 $} が生成されます。
 5996: 
 5997: @item -kkvl
 5998: @samp{-kkv} とほぼ同様ですが、
 5999: 指定されたリビジョンがロックされていれば、
 6000: ロックしている人物の名前を挿入します。
 6001: 普通 @sc{cvs} ではこのオプションを使いません。
 6002: 
 6003: @item -kk
 6004: キーワード文字列からキーワードのみを生成し、その値は省略されます。
 6005: 例えば、キーワード @code{Revision} に対して、
 6006: @code{$@asis{}Revision: 5.7 $} ではなく、
 6007: @code{$@asis{}Revision$} が生成されます。
 6008: このオプションは、リビジョン間の違いを比較する時、
 6009: キーワードによる違いを無視するのに便利です。
 6010: 
 6011: @item -ko
 6012: そのファイルが格納される前の、
 6013: 古いキーワード文字列を生成します。
 6014: 例えば、キーワード @code{Revision} に対して、
 6015: @code{$@asis{}Revision: 5.7 $} ではなく、
 6016: ファイルが格納された時の文字列である 
 6017: @code{$@asis{}Revision: 1.1 $} が生成されます。
 6018: 
 6019: @item -kb
 6020: @samp{-ko} と同様ですが、
 6021: リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、
 6022: クライアント側のオペレーティングシステムに適した形式へ変換しません。
 6023: 行端にラインフィードのみが使用されるシステム (unix 等) では、
 6024: このオプションは @samp{-ko} と同じです。
 6025: バイナリ・ファイルの詳細情報は @ref{Binary files} 参照。
 6026: 
 6027: @item -kv
 6028: キーワードの値のみを生成します。
 6029: 例えば、キーワード @code{Revision} に対して、
 6030: @code{$@asis{}Revision: 5.7 $} ではなく、
 6031: @code{5.7} が生成されます。
 6032: これは、@code{$@asis{}Revision: $} といった、
 6033: キーワード識別子を除くのが困難な
 6034: プログラミング言語のファイルを生成する時に便利です。
 6035: しかし、キーワード名が削除されてしまうために、
 6036: これ以後はキーワード置換を行うことができません。
 6037: 従って使用には注意が必要です。
 6038: 
 6039: オプション @samp{-kv} は、@code{cvs export} で使用される事が
 6040: 多くあります---@pxref{export}。
 6041: しかしモジュールがバイナリ・ファイルを含む場合は、
 6042: うまく処理できないので使用しない方が賢明です。
 6043: 
 6044: @end table
 6045: 
 6046: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6047: @node Log keyword
 6048: @section キーワード $@asis{}Log$ の問題点
 6049: 
 6050: キーワード @code{$@asis{}Log$} にはちょっと問題があります。
 6051: 開発環境で作業をしているならば、
 6052: キーワード @code{$@asis{}Log$} を使用しなくても、
 6053: @code{cvs log} を使えば同じ情報が簡単に手に入ります。
 6054: いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。
 6055: 
 6056: さらに重要な問題は、枝を幹にマージするときに、
 6057: @sc{rcs} が @code{$@asis{}Log$} の項目をうまく扱えないことです。
 6058: このマージ操作の結果、衝突が起きることがよくあります。
 6059: @c Might want to check whether the CVS implementation
 6060: @c of RCS_merge has this problem the same way rcsmerge
 6061: @c does.  I would assume so....
 6062: 
 6063: またファイル中のログ・メッセージは、@emph{修復}される傾向にあります。
 6064: (綴の間違いやほんとの間違い等)。
 6065: しかしこの結果、
 6066: @code{cvs log} の情報とファイルの中身が一致しないことになります。
 6067: これも問題といえば問題でしょう。
 6068: 
 6069: どうしてもキーワード @code{$@asis{}Log$} を使うのならば、
 6070: ファイルの先頭ではなく、
 6071: ファイルの @emph{最後} に挿入することを推奨します。
 6072: この方法ならば、
 6073: 長い変更メッセージを毎日眺めなくて済みます。
 6074: 
 6075: @c ---------------------------------------------------------------------
 6076: @node Tracking sources
 6077: @chapter サード・パーティーのソースの追っかけ
 6078: @cindex Third-party sources
 6079: @cindex Tracking sources
 6080: 
 6081: @c FIXME: Need discussion of added and removed files.
 6082: @c FIXME: This doesn't really adequately introduce the
 6083: @c concepts of "vendor" and "you".  They don't *have*
 6084: @c to be separate organizations or separate people.
 6085: @c We want a description which is somewhat more based on
 6086: @c the technical issues of which sources go where, but
 6087: @c also with enough examples of how this relates to
 6088: @c relationships like customer-supplier, developer-QA,
 6089: @c maintainer-contributor, or whatever, to make it
 6090: @c seem concrete.
 6091: あなたのサイトに合わせてプログラムを修正した場合、
 6092: そのプログラムの次のリリースにも同じ修正を加えたいでしょう。
 6093: @sc{cvs} を用いてこの作業を自動化することができます。
 6094: 
 6095: @cindex Vendor
 6096: @cindex Vendor branch
 6097: @cindex Branch, vendor-
 6098: @sc{cvs} の用語では、プログラムの開発元を@dfn{ベンダー} 
 6099: (@dfn{vendor}) と呼びます。
 6100: ベンダーの配布物は、
 6101: 修正を加えずに @dfn{ベンダー枝} (@dfn{vendor branch}) という枝に格納します。
 6102: @sc{cvs} はこの為に 1.1.1 という番号を予約しています。
 6103: 
 6104: あなたがソースを修正して格納した場合、
 6105: そのリビジョンは幹に入ります。
 6106: ベンダーから新しいリリースが届いたら、
 6107: それをベンダー枝に加えて、修正を幹にコピーします。
 6108: 
 6109: ベンダー枝を作り、更新するには、
 6110: @code{import} コマンドを使用します。
 6111: 新しいファイルを import すると、
 6112: ベンダー枝に `最初' のリビジョンが作られ、
 6113: @code{checkout} する人は誰でもそのリビジョンを取得します。
 6114: 格納されたローカルな修正は幹に置かれ、
 6115: `最初' のリビジョンが作られます。
 6116: 
 6117: @menu
 6118: * First import::                初めてモジュールを持ち込む
 6119: * Update imports::              import コマンドでモジュールを更新する
 6120: * Reverting local changes::     モジュールを最新のベンダーリリースに戻す
 6121: * Binary files in imports::     バイナリ・ファイルには特別な操作が必要
 6122: * Keywords in imports::         キーワード置換は望ましくない
 6123: * Multiple vendor branches::    複数の場所からソースを取得すると?
 6124: @end menu
 6125: 
 6126: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6127: @node First import
 6128: @section 初めてモジュールを持ち込む
 6129: @cindex Importing modules
 6130: 
 6131: @c Should mention naming conventions for vendor tags,
 6132: @c release tags, and perhaps directory names.
 6133: まず最初に、@code{import} コマンドを使ってソースを登録します。
 6134: @code{import} コマンドでサード・パーティーの追っかけをする場合には、
 6135: @dfn{ベンダー・タグ} (@dfn{vendor tag}) と
 6136: @dfn{リリース・タグ} (@dfn{release tag}) を用いると良いでしょう。
 6137: @dfn{ベンダー・タグ}は枝のタグ名です 
 6138: (@samp{-b @var{branch}} フラグを使用しなければ、
 6139: 枝のリビジョンは常に 1.1.1 です---@xref{Multiple vendor branches}.)。
 6140: @dfn{リリース・タグ}は特定のリリースを指すタグ名で、
 6141: ここでは @samp{FSF_0_04} とします。
 6142: 
 6143: @c I'm not completely sure this belongs here.  But
 6144: @c we need to say it _somewhere_ reasonably obvious; it
 6145: @c is a common misconception among people first learning CVS
 6146: @code{import} は起動されたディレクトリを変更 @emph{しない} ことに注意
 6147: してください。特に、そのディレクトリが @sc{cvs} の作業ディレクトリとし
 6148: て設定されることはありません。ソースに作業をしたいなら、まずそれを持ち
 6149: 込んで、それから違うディレクトリに取り出してください (@pxref{Getting
 6150: the source})。
 6151: 
 6152: @cindex Wdiff (import example)
 6153: ディレクトリ @file{wdiff-0.04} に @code{wdiff} というプログラムのソー
 6154: スがあるとします。将来に新しいリリースがなされたときでも適用したい個人
 6155: 的な修正を加えようとしています。まず、リポジトリに @code{wdiff} のソー
 6156: スを加えることから始めましょう:
 6157: 
 6158: @example
 6159: $ cd wdiff-0.04
 6160: $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
 6161: @end example
 6162: 
 6163: 上の例では、ベンダー・タグを @samp{FSF_DIST} とし、
 6164: 唯一のリリース・タグを @samp{WDIFF_0_04} としています。
 6165: @c FIXME: Need to say where fsf/wdiff comes from.
 6166: 
 6167: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6168: @node Update imports
 6169: @section import コマンドでモジュールを更新する
 6170: 
 6171: 新しいリリースのソースが届いたら、
 6172: それを最初と同じく @code{import} コマンドでリポジトリに加えます。
 6173: 違いは、最初と異なるリリース・タグを用いることだけです。
 6174: 
 6175: @example
 6176: $ tar xfz wdiff-0.05.tar.gz
 6177: $ cd wdiff-0.05
 6178: $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
 6179: @end example
 6180: 
 6181: ファイルがローカルな修正を受けてなければ、
 6182: 今加えたものが最初のリビジョンになります。
 6183: ローカルな変更を加えていれば、
 6184: @code{import} コマンドは変更を幹にマージするように警告を出し、
 6185: @samp{checkout -j} を使うように促します。
 6186: 
 6187: @c FIXME: why "wdiff" here and "fsf/wdiff" in the
 6188: @c "import"?  I think the assumption is that one has
 6189: @c "wdiff fsf/wdiff" or some such in modules, but it
 6190: @c would be better to not use modules in this example.
 6191: @example
 6192: $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
 6193: @end example
 6194: 
 6195: @noindent
 6196: このコマンドで @samp{wdiff} の最新のリビジョンが取り出され、
 6197: @samp{yesterday} 以降にベンダー枝 @samp{FSF_DIST} に加えられた変更を、
 6198: 作業コピーにマージします。
 6199: マージの過程で衝突が起きれば、通常の方法で解決して下さい 
 6200: (@pxref{Conflicts example})。
 6201: その後、変更したファイルを格納します。
 6202: 
 6203: 上記の実行例のように日時を使用する場合、
 6204: 一日に一つ以上のリリースを @code{import} しないと仮定しています。
 6205: この仮定に反するならば、次のようにして下さい:
 6206: 
 6207: @example
 6208: $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
 6209: @end example
 6210: 
 6211: @noindent
 6212: 今の例では、上の二つのコマンドは等価です。
 6213: 
 6214: @node Reverting local changes
 6215: @section 最新のベンダーリリースに戻す
 6216: 
 6217: 全てのファイルで `先頭' のリビジョンを変更してベンダー枝に戻すことで
 6218: ローカルの変更を完全に復旧し、最新のベンダーリリースに戻ることができま
 6219: す。例えば、ソースの取り出したコピーを @file{~/work.d/wdiff} に置いて
 6220: いて、そのディレクトリの全てのファイルをベンダーのバージョンに戻したい
 6221: のなら、次のように入力します:
 6222: 
 6223: @example
 6224: $ cd ~/work.d/wdiff
 6225: $ cvs admin -bWDIFF .
 6226: @end example
 6227: 
 6228: @noindent
 6229: @samp{-bWDIFF} は @samp{-b} の後空白を入れないで指定しなければなりませ
 6230: ん。@xref{admin options}.
 6231: 
 6232: @node Binary files in imports
 6233: @section cvs import でバイナリ・ファイルを扱う方法
 6234: 
 6235: @samp{-k} wrapper 機能オプションを使って、どのファイルがバイナリである
 6236: かを教えます。@xref{Wrappers}.
 6237: 
 6238: @node Keywords in imports
 6239: @section cvs import でキーワード置換を扱う方法
 6240: 
 6241: 持ち込んでいるソースにキーワードがある場合があります (@pxref{Keyword
 6242: substitution})。例えば、ベンダーは @sc{cvs} や他の似たキーワード展開構
 6243: 文を使うシステムを使っているかもしれません。既定の方法でファイルを持ち
 6244: 込んだだけでは、ベンダーのキーワード展開があなた自身の @sc{cvs} コピー
 6245: でも行われます。この情報はベンダーから持ち込んだソースの情報であること
 6246: がありますから、ベンダーの展開を維持した方がより便利でしょう。
 6247: 
 6248: ベンダーのキーワード展開を維持するためには、最初にファイルを持ち込むと
 6249: きに @code{cvs import} に @samp{-ko} オプションを付けます。こうすると、
 6250: そのファイルのキーワード展開を完全に止めます。もっと選択的な方法を望む
 6251: 場合は、@code{cvs update} や @code{cvs admin} に適切に @samp{-k} オプ
 6252: ションを使用します。
 6253: @c Supplying -ko to import if the file already existed
 6254: @c has no effect.  Not clear to me whether it should
 6255: @c or not.
 6256: 
 6257: @node Multiple vendor branches
 6258: @section 複数のベンダー枝
 6259: 
 6260: 今までの例はソースを取得しているベンダーは一つだけだと仮定しています。
 6261: いろいろな場所からソースを得るような場合もあります。例えば、多くの違っ
 6262: た人やチームがソフトウェアを修正しているプロジェクトに関係しているとし
 6263: ます。これを扱う方法はいろいろありますが、たくさんのソースツリーが散ら
 6264: ばっていて、とりあえずやりたいことはそれら全てを CVS に放り込んで少な
 6265: くとも一箇所にまとめることだ、ということがあります。
 6266: 
 6267: 複数のベンダーがある状況を扱うために、@code{cvs import} に @samp{-b}
 6268: オプションを指定できます。その引数は持ち込むベンダー枝です。既定値は
 6269: @samp{-b 1.1.1} です。
 6270: 
 6271: 例えば、赤チームと青チームの2つのチームがあり、あなたにソースを送って
 6272: くるとします。赤チームが努力したものを枝 1.1.1 に持ち込んで、ベンダー
 6273: タグ RED を使いたいと思っています。青チームが努力したものは枝 1.1.3 に
 6274: 持ち込んで、ベンダータグ BLUE を使おうとしています。使用するコマンドは
 6275: 以下のようになります。
 6276: 
 6277: @example
 6278: $ cvs import dir RED RED_1-0
 6279: $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
 6280: @end example
 6281: 
 6282: ベンダータグ が @samp{-b} オプションと合わなくても、CVS は発見しないこ
 6283: とに注意してください。例えば、
 6284: 
 6285: @example
 6286: $ cvs import -b 1.1.3 dir RED RED_1-0
 6287: @end example
 6288: 
 6289: @noindent
 6290: 慎重に; この種類の不適当な組合せは混乱や、よりひどいことへの種になりま
 6291: す。不釣合いを指定することでの便利な使用をここでは考え付きません。もし
 6292: そのような使用を発見しても、使わないでください。CVS は将来のリリースで
 6293: はそれをエラーにするでしょう。
 6294: 
 6295: @c Probably should say more about the semantics of
 6296: @c multiple branches.  What about the default branch?
 6297: @c What about joining (perhaps not as useful with
 6298: @c multiple branches, or perhaps it is.  Either way
 6299: @c should be mentioned).
 6300: 
 6301: @c I'm not sure about the best location for this.  In
 6302: @c one sense, it might belong right after we've introduced
 6303: @c CVS's basic version control model, because people need
 6304: @c to figure out builds right away.  The current location
 6305: @c is based on the theory that it kind of akin to the
 6306: @c "Revision management" section.
 6307: @node Builds
 6308: @chapter 構築システムと CVS の関係方法
 6309: @cindex builds
 6310: @cindex make
 6311: 
 6312: 紹介で書かれているように、@sc{cvs} にはソースコードからソフトウェアを
 6313: 構築するためのソフトウェアはありません。この部分は構築システムが
 6314: @sc{cvs} と協調するかもしれない種々の側面を説明します。
 6315: 
 6316: @c Is there a way to discuss this without reference to
 6317: @c tools other than CVS?  I'm not sure there is; I
 6318: @c wouldn't think that people who learn CVS first would
 6319: @c even have this concern.
 6320: @sc{rcs} に慣れている人からの特に多い、よくある質問は、どうすれば構築
 6321: 機構が最新のソースのコピーを手に入れることができるか、ということです。
 6322: @sc{cvs} では2重になります。まず最初に、@sc{cvs} はディレクトリを再帰
 6323: 的に辿ることができますので、各ファイルが最新であることを確認するために 
 6324: @file{Makefile} (もしくは、構築ツールが使う設定ファイルの名前) を修正
 6325: する必要はありません。その代わりに、まず @code{cvs -q update} として、
 6326: それから @code{make} や構築ツールを起動するコマンドを実行するという2つ
 6327: のコマンドだけを使います。2番目に、あなた自身の作業が終わるまで、誰か
 6328: の変更したコピーを取得@emph{したい} と思わないかもしれません。1つの方
 6329: 法はまずソースを更新して、それから実装、構築し、考えていた変更を試して
 6330: からソースを格納する (必要ならまず更新します) というものです。定期的に
 6331: (変更の合間に、さっき書いた方法で) 木全体を更新することで、ソースが十
 6332: 分に新しいことを保証できます。
 6333: 
 6334: @cindex bill of materials
 6335: よくある要求は、どのソースファイルのどのリビジョンが特定の構築に相当す
 6336: るかを記録することです。このような種類の機能は @dfn{bill of materials} 
 6337: などと呼ばれることがあります。@sc{cvs} で実現する最良の方法は 
 6338: @code{tag}コマンドがどのバージョンが与えられた構築に相当するかを記録す
 6339: ることです (@pxref{Tags})。
 6340: 
 6341: @sc{cvs} を一番素直な方法で使うと、それぞれの開発者は特定の構築に使わ
 6342: れるソースツリー全体のコピーを持っています。ソースツリーが小さかったり、
 6343: 開発者が地理的に離れたところにいるのなら、これが好ましい解決方法です。
 6344: 実のところ、大きなプロジェクトを遂行する手段の一つはプロジェクトを小さ
 6345: な分割してコンパイルされるサブシステムに分け、開発者に必要なことは主に
 6346: 作業しているサブシステムだけを取り出すだけにするように、内部でリリース
 6347: する方法を作ることです。
 6348: @c I say subsystem instead of module because they may or
 6349: @c may not use the modules file.
 6350: 
 6351: 別の手段は、開発者にいくつかのファイルのコピーだけの所有をして、他のファ
 6352: イルには中央管理下のソースファイルを見に行くことができるようにする機構
 6353: を設定することです。多くの人は、大部分のオペレーティング・システムにあ
 6354: るシンボリックリンクや、@code{make} の多くのバージョンにある 
 6355: @code{VPATH} 機能を使う様な解決法に到達しました。
 6356: @c two such people are paul@sander.cupertino.ca.us (for
 6357: @c a previous employer)
 6358: @c and gtornblo@senet.abb.se (spicm and related tools),
 6359: @c but as far as I know
 6360: @c no one has nicely packaged or released such a system (or
 6361: @c instructions for constructing one).
 6362: このような種類のものを助けるために設計された構築ツールに Odin というも
 6363: のがあります (@code{ftp://ftp.cs.colorado.edu/pub/distribs/odin} 参照)。
 6364: @c Should we be saying more about Odin?  Or how you use
 6365: @c it with CVS?  Also, the Prime Time Freeware for Unix
 6366: @c disk (see http://www.ptf.com/) has Odin (with a nice
 6367: @c paragraph summarizing it on the web), so that might be a
 6368: @c semi-"official" place to point people.
 6369: @c
 6370: @c Of course, many non-CVS systems have this kind of
 6371: @c functionality, for example OSF's ODE
 6372: @c (http://www.osf.org/ode/) or mk
 6373: @c (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
 6374: @c He has changed providers in the past; a search engine search
 6375: @c for "Peter Ziobrzynski" probably won't get too many
 6376: @c spurious hits :-).  A more stable URL might be
 6377: @c ftp://ftp.uu.net/pub/cmvc/mk).  But I'm not sure
 6378: @c there is any point in mentioning them here unless they
 6379: @c can work with CVS.
 6380: 
 6381: @c ---------------------------------------------------------------------
 6382: @node Special Files
 6383: @chapter 特別なファイル
 6384: 
 6385: @cindex special files
 6386: @cindex device nodes
 6387: @cindex ownership, saving in CVS
 6388: @cindex permissions, saving in CVS
 6389: @cindex hard links
 6390: @cindex symbolic links
 6391: 
 6392: 普通の環境では、CVS は普通のファイルでのみ動作します。プロジェクトの全
 6393: てのファイルは永続すると仮定されています。開き、読み込み、閉じるという
 6394: 操作などが可能でなければなりません。また、CVS はファイルの使用許可と所
 6395: 有権を無視します。そのような問題はインストール時に開発者によって解決さ
 6396: れる必要があります。言い換えれば、デバイスを "格納" することは不可能で
 6397: す。デバイスファイルを開けなければ、CVS はそれを扱うことを拒否します。
 6398: ファイルはリポジトリの取り扱い中にも所有権や使用許可を失います。
 6399: 
 6400: リポジトリで設定変数 @code{PreservePermissions} (@pxref{config}) が設
 6401: 定されていると、CVS は以下のファイルの特性をリポジトリに記録します:
 6402: 
 6403: @itemize @bullet
 6404: @item 使用者とグループの所有権
 6405: @item 使用許可
 6406: @item 主・副デバイス番号
 6407: @item シンボリックリンク
 6408: @item ハードリンク機構
 6409: @end itemize
 6410: 
 6411: @code{PreservePermissions} オプションを使うと CVS の振舞いにいくつか影
 6412: 響します。まず、CVS で使用可能になった新しい操作の中に、全ての使用者に
 6413: は使用可能でないものができます。特に、ファイルの所有権と特別なファイル
 6414: の特性とはスーパーユーザにだけ変更できるものでしょう。ですから、
 6415: @code{PreservePermissions} 設定変数が設定されていると、使用者は CVS の
 6416: 操作をうるために `root' になる必要があるでしょう。
 6417: 
 6418: @code{PreservePermissions} が使用されていると、CVS の操作の中には 
 6419: (@samp{cvs status} のように) ファイルのハードリンク構造を認識せず、合っ
 6420: ていないハードリンクに関して見せかけの警告を出力します。これは CVS の
 6421: 内部構造がハードリンクに必要なデータ全てを集めるのを難しくしており、そ
 6422: のために不正確なデータでファイルの衝突を調べるからです。
 6423: 
 6424: CVS はファイルの内容が変更されたときのみ、それが変更されたと考えること
 6425: による、より微妙な違いがあります (特に、作業ファイルの修正時刻がリポジ
 6426: トリのそのファイルと合わないとき)。ですから、使用許可、所有権、ハード
 6427: リンクが変わったり、デバイスの主、副番号が変わったとしても、CVS は報告
 6428: しません。そのような変更をリポジトリに格納するためには、@samp{cvs
 6429: commit -f} で格納を強制する必要があります。これは、ファイルの使用許可
 6430: が変わっていて、リポジトリのファイルが作業コピーより新しいと、
 6431: @samp{cvs update} の実行は、知らない間に作業コピーの使用許可を変更して
 6432: いるということでもあります。
 6433: 
 6434: CVS リポジトリでのハードリンクの変更は特に慎重な扱いが必要です。
 6435: @file{foo} がファイル @file{old} にリンクされていたけれど、後でファイ
 6436: ル @file{new} にリンクされ直したとしましょう。@file{foo}, @file{old},
 6437: @file{new} は全て中のリンクパターンは変更されているけれど、@file{foo} 
 6438: と @file{new} だけが修正されていて、そのために @file{old} は格納の候補
 6439: としてみなされない、という変な状況になることがあります。このような方法
 6440: により整合しない結果は非常に簡単に作られます。ですから、ハードリンクを
 6441: リポジトリに保存するのが重要なときは、賢明な動作方法は最後の格納からリ
 6442: ンクや状態が変わったファイル全てに @code{touch} することです。実際、複
 6443: 雑なハードリンク構造のディレクトリを格納する前には @code{touch *} をす
 6444: るのが賢いかもしれません。
 6445: 
 6446: おそらく明らかである理由により、普通のファイルだけがマージできるという
 6447: ことを書いておくのも意味のあることでしょう。もし @samp{cvs update} や 
 6448: @samp{cvs checkout -j} がシンボリックリンクを普通のファイルとマージし
 6449: ようとしたり、2つのデバイスファイルが違った種類のデバイスのためのもの
 6450: であったりすると、CVS は衝突を報告して、マージの実行を拒否します。また、
 6451: テキストがないファイル上でのテキスト比較は無意味なので、@samp{cvs
 6452: diff} はこれらのファイル間の相違を報告しません。
 6453: 
 6454: @code{PreservePermissions} 機能はクライアント/サーバの @sc{cvs} では動
 6455: 作しません。別の制限に、ハードリンクは同じディレクトリの他のファイルへ
 6456: のリンクでなければならない、というものがあります。ディレクトリをまたい
 6457: だハードリンクは使用できません。
 6458: 
 6459: @c ---------------------------------------------------------------------
 6460: @node CVS commands
 6461: @appendix CVS のコマンド便覧
 6462: 
 6463: この付録は @sc{cvs} コマンドの全体構造の説明をし、いくつかのコマンドは
 6464: 詳しく説明します (他のものは別のところで説明されています。@sc{cvs} コ
 6465: マンドの簡単な便覧は、@pxref{Invoking CVS})。
 6466: @c The idea is that we want to move the commands which
 6467: @c are described here into the main body of the manual,
 6468: @c in the process reorganizing the manual to be
 6469: @c organized around what the user wants to do, not
 6470: @c organized around CVS commands.
 6471: 
 6472: @menu
 6473: * Structure::                   CVS コマンド構造の全て
 6474: * Exit status::                 CVS の成功か失敗を示す
 6475: * ~/.cvsrc::                    既定オプションと ~/.cvsrc ファイル
 6476: * Global options::              cvs_command の左側に付けるオプション
 6477: * Common options::              cvs_command の右側に付けるオプション
 6478: * admin::                       管理
 6479: * checkout::                    編集の為にソースを取り出す
 6480: * commit::                      ファイルをリポジトリに格納する
 6481: * diff::                        リビジョン間の差分を見る
 6482: * export::                      CVS からソースを取り出す, checkout に類似
 6483: * history::                     ファイルと使用者の状態を表示
 6484: * import::                      CVS にソースを取り込む, ベンダー枝を使用
 6485: * log::                         ファイルのログ情報を表示
 6486: * rdiff::                       リリース間の `patch' 形式の差分
 6487: * release::                     モジュールの放棄を表明する
 6488: * rtag::                        モジュールにタグ名を付ける
 6489: * tag::                         取り出したバージョンにタグ名を付ける
 6490: * update::                      作業コピーをリポジトリと一致させる
 6491: @end menu
 6492: 
 6493: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6494: @node Structure
 6495: @appendixsec CVS コマンド構造の全て
 6496: @cindex Structure
 6497: @cindex CVS command structure
 6498: @cindex Command structure
 6499: @cindex Format of CVS commands
 6500: 
 6501: @sc{cvs} のコマンド全体の書式を示します:
 6502: 
 6503: @example
 6504: cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
 6505: @end example
 6506: 
 6507: @table @code
 6508: @item cvs
 6509: @sc{cvs} プログラムの名前です。
 6510: 
 6511: @item cvs_options
 6512: @sc{cvs} のサブコマンド全体に適用されるオプションです。以下で説明され
 6513: ています。
 6514: 
 6515: @item cvs_command
 6516: いくつかの違ったサブコマンドの一つです。
 6517: 幾つかのコマンドでは別名が使用できます。別名はそのコマンドの便覧マニュ
 6518: アルのところで書かれています。
 6519: 次の二つの場合にだけ @samp{cvs_command} を省略できます。
 6520: つまり @samp{cvs -H} として利用可能なコマンドのリストを得る場合か、
 6521: @samp{cvs -v} として @sc{cvs} 自身のバージョン情報を得る場合です。
 6522: 
 6523: @item command_options
 6524: コマンド固有のオプションです。
 6525: 
 6526: @item command_args
 6527: コマンドの引数です。
 6528: @end table
 6529: 
 6530: 不幸な事に、
 6531: @code{cvs_options} と @code{command_options} の間で幾つか混乱があります。
 6532: @samp{-l} は @code{cvs_option} として使われたときいくつかのコマンドに
 6533: 影響します。@code{command_option} として使されたときは、より多くのコマ
 6534: ンドで意味を持ちます。つまり、上の分類をあまり深刻に受けとめないでくだ
 6535: さい。代わりに文書を見るようにしましょう。
 6536: 
 6537: @node Exit status
 6538: @appendixsec CVS の終了状態
 6539: @cindex exit status, of CVS
 6540: 
 6541: CVS はそれ呼んだ環境に @dfn{終了状態} (@dfn{exit status}) を設定するこ
 6542: とで、成功したか失敗したかを示すことができます。
 6543: 終了状態を調べる正確な方法はオペレーティング・システムごとに異なります。
 6544: 例えば、unix のシェルスクリプトでは、最後のコマンドが成功終了状態を返
 6545: せば変数 @samp{$?} は0で、終了状態が失敗を示していれば、0より大きくな
 6546: ります。
 6547: 
 6548: CVS が成功した場合は、成功状態を返します。エラーがあれば、エラーメッセー
 6549: ジを印字して、失敗状態を返します。@code{cvs diff} コマンドはこの例外で
 6550: す。違いが見つからなければ成功状態を返し、違いが見つかるか、エラーが発
 6551: 生したときに失敗状態を返します。この振舞いはエラーの検知には良くないの
 6552: で、将来では @code{cvs diff} が他の @sc{cvs} コマンドと同じように振舞
 6553: うように変更される可能性があります。
 6554: @c It might seem like checking whether cvs -q diff
 6555: @c produces empty or non-empty output can tell whether
 6556: @c there were differences or not.  But it seems like
 6557: @c there are cases with output but no differences
 6558: @c (testsuite basica-8b).  It is not clear to me how
 6559: @c useful it is for a script to be able to check
 6560: @c whether there were differences.
 6561: @c FIXCVS? In previous versions of CVS, cvs diff
 6562: @c returned 0 for no differences, 1 for differences, or
 6563: @c 2 for errors.  Is this behavior worth trying to
 6564: @c bring back (but what does it mean for VMS?)?
 6565: 
 6566: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6567: @node ~/.cvsrc
 6568: @appendixsec 既定オプションと ~/.cvsrc ファイル
 6569: @cindex .cvsrc file
 6570: @cindex option defaults
 6571: 
 6572: よく使用する @code{command_option} が幾つかあり、
 6573: そのオプションを必ず指定するように設定したいことがあります。
 6574: 例えば (実際に .cvsrc を実装した要因の一つですが) 
 6575: 多くの人には @samp{diff} の既定出力は大変読みにくく、
 6576: context 形式か unidiff 形式のほうが遥かに分かりやすいでしょう。
 6577: 
 6578: シェル・スクリプトやエイリアスに頼らなくても、
 6579: @file{~/.cvsrc} ファイルを用いて @code{cvs_commands} 各々に
 6580: 既定のオプションを加えることができます。
 6581: 
 6582: @file{~/.cvsrc} の書式は簡単です。
 6583: 実行された @code{cvs_command} と同じ名前で始まる行が検索されます。
 6584: 一致した行を発見したら、行の残りの部分をオプションに分割し (空白のとこ
 6585: ろで)、
 6586: コマンド行からのオプションを与える@emph{前に}、
 6587: 得られたオプションをコマンドの引数として与えます。
 6588: コマンドが別名を持つ場合 (例えば、@code{checkout} と @code{co})、
 6589: コマンド行で使われるものとは限りませんが、公的な名前がファイルとの
 6590: 合致時に使用されます。
 6591: 例えば @file{~/.cvsrc} の内容が次の様であった場合:
 6592: 
 6593: @example
 6594: log -N
 6595: diff -u
 6596: update -P
 6597: checkout -P
 6598: @end example
 6599: 
 6600: @noindent
 6601: @samp{cvs co foo} も、コマンド @samp{cvs checkout foo} と同様に 
 6602: @samp{-P} が引数として与えられます。
 6603: 
 6604: 上記の例では @samp{cvs diff foobar} の出力は unidiff 形式になります。
 6605: @samp{cvs diff -c foobar} だと指定通り context 形式になります。
 6606: @samp{diff} には "古い" 形式で出力するためのオプションが無いため、
 6607: "古い" 形式を使いたい場合には少し面倒ですが 
 6608: @samp{cvs -f diff foobar} とする必要があります。
 6609: 
 6610: コマンド名の部分に @code{cvs} と記述すれば、
 6611: 広域オプションを指定することができます (@pxref{Global options})。
 6612: 例えば @file{.cvsrc} 中の以下の行は、
 6613: 
 6614: @example
 6615: cvs -z6
 6616: @end example
 6617: 
 6618: @sc{cvs} が圧縮レベル 6 を用いるように指定しています。
 6619: 
 6620: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6621: @node Global options
 6622: @appendixsec 広域オプション
 6623: @cindex Options, global
 6624: @cindex Global options
 6625: @cindex Left-hand options
 6626: 
 6627: @samp{cvs_options} (@samp{cvs_command} の左側に与えられる) 
 6628: として利用できるものを以下に示します:
 6629: 
 6630: @table @code
 6631: @item --allow-root=@var{rootdir}
 6632: 正しい @sc{cvsroot} ディレクトリを指定します。@ref{Password
 6633: authentication server} 参照。
 6634: 
 6635: @cindex authentication, stream
 6636: @cindex stream authentication
 6637: @item -a
 6638: クライアントとサーバの全ての通信を認証します。@sc{cvs} クライアントで
 6639: だけ意味をもちます。これを書いている時点では、GSSAPI 接続を行う場合だ
 6640: けに実装されています (@pxref{GSSAPI authenticated})。認証は流れている 
 6641: @sc{tcp} 接続のハイジャックというような攻撃から身を守ることができます。
 6642: 認証を使用しても暗号化は使用されません。
 6643: 
 6644: @cindex RCSBIN, overriding
 6645: @cindex Overriding RCSBIN
 6646: @item -b @var{bindir}
 6647: @sc{cvs} 1.9.18 以前では、これは @sc{rcs} プログラムが @var{bindir} ディ
 6648: レクトリにあることを指定していました。現在のバージョンの @sc{cvs} は 
 6649: @sc{rcs} プログラムを実行しません。互換性のためにこのオプションがあり
 6650: ますが、指定しても何もしません。
 6651: 
 6652: @cindex TMPDIR, overriding
 6653: @cindex Overriding TMPDIR
 6654: @item -T @var{tempdir}
 6655: 一時ファイルが置かれるディレクトリを @var{tempdir} とします。
 6656: 環境変数 @code{$TMPDIR} の設定や、
 6657: コンパイル時のディレクトリ設定よりも優先されます。
 6658: この値は絶対パス名で指定して下さい。
 6659: 
 6660: @cindex CVSROOT, overriding
 6661: @cindex Overriding CVSROOT
 6662: @item -d @var{cvs_root_directory}
 6663: リポジトリのルートディレクトリのパス名を @var{cvs_root_directory} とし
 6664: ます。
 6665: 環境変数 @code{$CVSROOT} よりも優先します。@xref{Repository}.
 6666: 
 6667: @cindex EDITOR, overriding
 6668: @cindex Overriding EDITOR
 6669: @item -e @var{editor}
 6670: リビジョンのログ情報の入力に @var{editor} を使用します。
 6671: 環境変数 @code{$CVSEDITOR} や @code{$EDITOR} よりも優先します。
 6672: 詳しい情報は @ref{Committing your changes} 参照。
 6673: 
 6674: @item -f
 6675: @file{~/.cvsrc} を読みません。
 6676: このオプションが最も良く使われるのは、
 6677: @sc{cvs} のオプション設定に直交性がない時です。
 6678: 例えば @samp{cvs log} のオプション @samp{-N} (タグの表示を抑制します)
 6679: に対応する表示を行なうオプションはありません。
 6680: 従って、@file{~/.cvsrc} の @samp{log} エントリに @samp{-N} があったとき、
 6681: タグを表示するには @samp{-f} を使用する他ありません。
 6682: 
 6683: @item -H
 6684: @itemx --help
 6685: 指定された @samp{cvs_command} の使用法を表示します 
 6686: (コマンドが実際に実行されることはありません)。
 6687: コマンド名を指定しない場合には、
 6688: @samp{cvs -H} は他のヘルプオプションの一覧などを含む、@sc{cvs} の全体
 6689: のヘルプを表示します。
 6690: @c It seems to me it is better to document it this way
 6691: @c rather than trying to update this documentation
 6692: @c every time that we add a --help-foo option.  But
 6693: @c perhaps that is confusing...
 6694: 
 6695: @item -l
 6696: @samp{cvs_command} をコマンド履歴に記録しません 
 6697: (しかしコマンドは実行されます)。
 6698: コマンド履歴の情報は @xref{history}.
 6699: 
 6700: @cindex Read-only mode
 6701: @item -n
 6702: ファイルを更新しません。
 6703: @samp{cvs_command} を実行した場合の表示だけが行なわれます。
 6704: 既存のファイルを削除, 更新, マージしたり、
 6705: 新しいファイルを作成することはありません。
 6706: 
 6707: @sc{cvs} は必ずしも @samp{-n} を付けなかったときと全く同じ出力をするわ
 6708: けではないことに注意してください。ときどき、出力が同じ場合がありますが、
 6709: 他の場合では、@sc{cvs} は正確に同じ出力をするために必要な実行を飛ばし
 6710: ます。
 6711: 
 6712: @item -Q
 6713: コマンドの出力が完全に抑止され、
 6714: 重大な問題が発生した場合にのみ出力が行なわれます。
 6715: 
 6716: @item -q
 6717: コマンドの出力を減らします。
 6718: 再帰的にサブディレクトリを辿る時の報告などの補助情報は抑止されます。
 6719: 
 6720: @cindex read-only files, and -r
 6721: @item -r
 6722: 新たな作業ファイルを読み込み専用にします。
 6723: 環境変数 @code{$CVSREAD} を設定するのと同じ効果があります 
 6724: (@pxref{Environment variables})。
 6725: 既定では、そのファイルが監視されてない限り作業ファイルへの書き込みが許
 6726: 可されます (@pxref{Watches})。
 6727: 
 6728: @item -s @var{variable}=@var{value}
 6729: ユーザ変数を設定します (@pxref{Variables})。
 6730: 
 6731: @cindex Trace
 6732: @item -t
 6733: プログラムの実行状態をトレースします。
 6734: @sc{cvs} が実行する各ステップの情報を表示します。
 6735: @samp{-n} オプションと共に使用し、
 6736: 不慣れなコマンドの潜在的な影響を調べるのに便利です。
 6737: 
 6738: @item -v
 6739: @item --version
 6740: @sc{cvs} のバージョンと著作権情報を表示します。
 6741: 
 6742: @cindex CVSREAD, overriding
 6743: @cindex Overriding CVSREAD
 6744: @item -w
 6745: 新しい作業ファイルを読み書き可能にします。
 6746: 環境変数 @code{$CVSREAD} の設定を無効にします。
 6747: @code{$CVSREAD} が設定されておらず、
 6748: @samp{-r} オプションも無い場合には、
 6749: 作成されるファイルは読み書き可能とされます。
 6750: @c Note that -w only overrides -r and CVSREAD; it has
 6751: @c no effect on files which are readonly because of
 6752: @c "cvs watch on".  My guess is that is the way it
 6753: @c should be (or should "cvs -w get" on a watched file
 6754: @c be the same as a get and a cvs edit?), but I'm not
 6755: @c completely sure whether to document it this way.
 6756: 
 6757: @cindex encryption
 6758: @item -x
 6759: クライアントとサーバ間の全ての通信を暗号化します。これは @sc{cvs} クラ
 6760: イアントでだけ意味を持ち、また現時点では GSSAPI 接続を用いる場合 
 6761: (@pxref{GSSAPI authenticated}) かケルベロス接続 (@pxref{Kerberos
 6762: authenticated}) を用いる場合にしか実装されていません。暗号化を使用する
 6763: ということは送信されるメッセージも認証されるということです。既定状態で
 6764: は暗号化機能は使用できません。特別に @file{--enable-encryption} を指定
 6765: して @sc{cvs} を構築する必要があります。
 6766: 
 6767: @item -z @var{gzip-level}
 6768: 圧縮レベルを設定します。
 6769: @sc{cvs} クライアントでだけ意味を持ちます。
 6770: 
 6771: @end table
 6772: 
 6773: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6774: @node Common options
 6775: @appendixsec 共通のコマンド・オプション
 6776: @cindex Common options
 6777: @cindex Right-hand options
 6778: 
 6779: ここでは、複数の @sc{cvs} コマンドで共通に使用できる 
 6780: @samp{command_options} について説明します。
 6781: これらのオプションは、
 6782: 必ず @samp{cvs_command} の右側に付けられます。
 6783: 以下に示すオプションは、全てのコマンドで使えるわけではありません。
 6784: 各オプションは、それが意味をなすコマンドにおいてのみ使用可能です。
 6785: しかし以下のオプションを持つコマンドがあるならば、
 6786: そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。
 6787: (各コマンドの固有オプションのほとんどは、
 6788: 他の @sc{cvs} コマンドのものとは異なる意味を持っています。)
 6789: 
 6790:  @strong{警告:} @samp{history} コマンドは例外です。このコマンドには、
 6791: ここに示す標準オプションと重複する固有オプションが多くあります。
 6792: 
 6793: @table @code
 6794: @cindex Dates
 6795: @cindex Time
 6796: @cindex Specifying dates
 6797: @item -D @var{date_spec}
 6798: @var{date_spec} 以前のリビジョンのうち、最新のものを使用します。
 6799: @var{date_spec} には、過去の日付を示すものを一つだけ指定します。
 6800: 
 6801: このオプションを用いて作業ファイルを取り出すと、
 6802: 指定した日付が@dfn{貼り付け}られます。
 6803: つまり @samp{-D} オプションの引数が記録され、
 6804: これ以後の @code{update} の際に同じ日付が用いられます 
 6805: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 6806: @samp{-D} は以下のコマンドで利用できます:
 6807: @code{checkout}, @code{diff}, @code{export}, @code{history},
 6808: @code{rdiff}, @code{rtag}, @code{update}.
 6809: (@code{history} コマンドはこのオプションを少し違った方法で使用します。
 6810: @pxref{history options}).
 6811: 
 6812: @c What other formats should we accept?  I don't want
 6813: @c to start accepting a whole mess of non-standard
 6814: @c new formats (there are a lot which are in wide use in
 6815: @c one context or another), but practicality does
 6816: @c dictate some level of flexibility.
 6817: @c * POSIX.2 (e.g. touch, ls output, date) and other
 6818: @c POSIX and/or de facto unix standards (e.g. at).  The
 6819: @c practice here is too inconsistent to be of any use.
 6820: @c * VMS dates.  This is not a formal standard, but
 6821: @c there is a published specification (see SYS$ASCTIM
 6822: @c and SYS$BINTIM in the _VMS System Services Reference
 6823: @c Manual_), it is implemented consistently in VMS
 6824: @c utilities, and VMS users will expect CVS running on
 6825: @c VMS to support this format (and if we're going to do
 6826: @c that, better to make CVS support it on all
 6827: @c platforms.  Maybe).
 6828: @c
 6829: @c NOTE: The tar manual has some documentation for
 6830: @c getdate.y (just for our info; we don't want to
 6831: @c attempt to document all the formats accepted by
 6832: @c getdate.y).
 6833: @c
 6834: @c One more note: In output, CVS should consistently
 6835: @c use one date format, and that format should be one that
 6836: @c it accepts in input as well.  The former isn't
 6837: @c really true (see survey below), and I'm not
 6838: @c sure that either of those formats is accepted in
 6839: @c input.
 6840: @c
 6841: @c cvs log
 6842: @c   current 1996/01/02 13:45:31
 6843: @c   Internet 02 Jan 1996 13:45:31 UT
 6844: @c   ISO 1996-01-02 13:45:31
 6845: @c cvs ann
 6846: @c   current 02-Jan-96
 6847: @c   Internet-like 02 Jan 96
 6848: @c   ISO 96-01-02
 6849: @c cvs status
 6850: @c   current Tue Jun 11 02:54:53 1996
 6851: @c   Internet [Tue,] 11 Jun 1996 02:54:53
 6852: @c   ISO 1996-06-11 02:54:53
 6853: @c   note: date possibly should be omitted entirely for
 6854: @c   other reasons.
 6855: @c cvs editors
 6856: @c   current Tue Jun 11 02:54:53 1996 GMT
 6857: @c cvs history
 6858: @c   current 06/11 02:54 +0000
 6859: @c any others?
 6860: @c There is a good chance the proper solution has to
 6861: @c involve at least some level of letting the user
 6862: @c decide which format (with the default being the
 6863: @c formats CVS has always used; changing these might be
 6864: @c _very_ disruptive since scripts may very well be
 6865: @c parsing them).
 6866: @c
 6867: @c Another random bit of prior art concerning dates is
 6868: @c the strptime function which takes templates such as
 6869: @c "%m/%d/%y", and apparent a variant of getdate()
 6870: @c which also honors them.  See
 6871: @c X/Open CAE Specification, System Interfaces and
 6872: @c Headers Issue 4, Version 2 (September 1994), in the
 6873: @c entry for getdate() on page 231
 6874: 
 6875: @cindex timezone, in input
 6876: @cindex zone, time, in input
 6877: @sc{cvs} では、様々な形式で日付を指定できます。
 6878: 最も標準的なものは (International Standards Organization による) 
 6879: ISO8601 と (RFC 822 で規定され、RFC1123 で修正された) Internet e-mail
 6880: の標準です。
 6881: 
 6882: @c Probably should be doing more to spell out just what
 6883: @c the rules are, rather than just giving examples.
 6884: @c But I want to keep this simple too.
 6885: @c So I don't know....
 6886: @c A few specific issues: (1) Maybe should reassure
 6887: @c people that years after 2000
 6888: @c work (they are in the testsuite, so they do indeed
 6889: @c work).  (2) What do two digit years
 6890: @c mean?  Where do we accept them?  (3) Local times can
 6891: @c be ambiguous or nonexistent if they fall during the
 6892: @c hour when daylight savings time goes into or out of
 6893: @c effect.  Pretty obscure, so I'm not at all sure we
 6894: @c should be documenting the behavior in that case.
 6895: ISO8601 はいろんな異種があります。すこし例を挙げます:
 6896: 
 6897: @example
 6898: 1972-09-24
 6899: 1972-09-24 20:05
 6900: @end example
 6901: @c I doubt we really accept all ISO8601 format dates
 6902: @c (for example, decimal hours like 1972-09-24 20,2)
 6903: @c I'm not sure we should, many of them are pretty
 6904: @c bizarre and it has lots of gratuitous multiple ways
 6905: @c to specify the same thing.
 6906: 
 6907: ISO8601 の日付の詳細は以下を参照してください:
 6908: 
 6909: @example
 6910: http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html
 6911: @end example
 6912: @c Perhaps we want to also cite other sources in
 6913: @c case that page goes away.  For example:
 6914: @c http://www.saqqara.demon.co.uk/datefmt.htm
 6915: 
 6916: Internet e-mail で使用が認められている日付に加えて、
 6917: @sc{cvs} では、いくつかのフィールドが省略されたものも使えます。
 6918: 例えば、以下のようなものです:
 6919: @c FIXME: Need to figure out better, and document,
 6920: @c what we want to allow the user to omit.
 6921: @c NOTE: "omit" does not imply "reorder".
 6922: @c FIXME: Need to cite a web page describing how to get
 6923: @c RFC's.
 6924: 
 6925: @example
 6926: 24 Sep 1972 20:05
 6927: 24 Sep
 6928: @end example
 6929: 
 6930: 特定の標準時が指定されていない場合は、日付はローカルの標準時として解釈
 6931: されます。
 6932: 
 6933: この2つの書式の使用が好まれます。しかし、@sc{cvs} は今は他の日付の書式
 6934: を幅広く受け付けます。それらはここでは故意に詳しくは説明されておらず、
 6935: @sc{cvs} の将来のバージョンはそれら全ては受け付けないかもしれません。
 6936: @c We should document and testsuite "now" and
 6937: @c "yesterday".  "now" is mentioned in the FAQ and
 6938: @c "yesterday" is mentioned in this document (and the
 6939: @c message from "cvs import" suggesting a merge
 6940: @c command).  What else?  Probably some/all of the "3
 6941: @c weeks ago" family.
 6942: @c
 6943: @c Maybe at
 6944: @c some point have CVS start give warnings on "unofficial"
 6945: @c formats (many of which might be typos or user
 6946: @c misunderstandings, and/or formats people never/rarely
 6947: @c use to specify dates)?
 6948: 
 6949: そのような書式の中に
 6950: @code{@var{月}/@var{日}/@var{年}}.  というものがあります。
 6951: これは月と日が逆の順番になっているものに慣れている人を混乱させます。
 6952: @samp{1/4/96} は1月4日であり、4月1日ではありません。
 6953: 
 6954: シェルは空白を引数の区切りにするので、
 6955: @samp{-D} の引数を引用符で囲むのを忘れてはいけません。
 6956: @samp{-D} オプションを付けたコマンド行は、次の様になるでしょう:
 6957: 
 6958: @example
 6959: $ cvs diff -D "1 hour ago" cvs.texinfo
 6960: @end example
 6961: 
 6962: @cindex Forcing a tag match
 6963: @item -f
 6964: 日付やタグ名を指定して @sc{cvs} コマンドを用いた場合、
 6965: そのタグ名を持たない (その時には存在しなかった) ファイルは、
 6966: 普通は無視されます。
 6967: タグでも日付でも引っ掛からなかったファイルを復元したい場合に、
 6968: @samp{-f} オプションを使用します 
 6969: (そのファイルの最新のリビジョンが取り出されます)。
 6970: 
 6971: @need 800
 6972: @samp{-f} は以下のコマンドで利用できます: 
 6973: @code{annotate}, @code{checkout}, 
 6974: @code{export}, @code{rdiff}, @code{rtag}, @code{update}.
 6975: 
 6976: @strong{警告:} @code{commit} と @code{remove} コマンドにも @samp{-f} 
 6977: オプションがありますが、異なる動作をします。@xref{commit options}, 
 6978: @ref{Removing files} 参照。
 6979: 
 6980: @item -k @var{kflag}
 6981: 既定のキーワード置換モードを変更します。
 6982: @var{kflag} の詳細は @ref{Substitution modes} 参照。
 6983: 
 6984: このオプションを用いて作業ファイルを取り出すと、
 6985: @var{kflag} が@dfn{貼り付け}られます。
 6986: つまり、このオプションを @code{checkout} や @code{update} コマンドに
 6987: 用いた場合、@sc{cvs} は指定した @var{kflag} をそのファイルに結合します。
 6988: これ以後、同ファイルに対する @code{update} コマンドには 
 6989: @var{kflag} が使用され続けます。
 6990: この効果は別の指定を行なうまで止みません。
 6991: 
 6992: @samp{-k} オプションは以下のコマンドで利用できます: @code{add}, 
 6993: @code{checkout}, @code{diff}, @code{import}, @code{update}.
 6994: 
 6995: @item -l
 6996: Local の頭文字です。再帰的にサブディレクトリを辿らず、
 6997: カレントディレクトリでのみコマンドを実行します。
 6998: 
 6999: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7000: @samp{cvs -l} と混同しないようにして下さい。
 7001: 
 7002: 以下のコマンドで利用できます: @code{annotate}, @code{checkout},
 7003: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7004: @code{export}, @code{log}, @code{rdiff}, @code{remove}, @code{rtag},
 7005: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7006: and @code{watchers}.
 7007: 
 7008: @cindex Editor, avoiding invocation of
 7009: @cindex Avoiding editor invocation
 7010: @item -m @var{message}
 7011: @item -m @var{message}
 7012: エディタを起動せず、ログ情報を @var{message} に記述します。
 7013: 
 7014: 以下のコマンドで利用できます: @code{add}, 
 7015: @code{commit}, @code{import}.
 7016: 
 7017: @item -n
 7018: @code{checkout}/@code{commit}/@code{rtag} コマンド実行時に、
 7019: 常には実行されるプログラムを実行しません。
 7020: 各コマンド実行時のプログラムは、
 7021: 管理用ファイル @file{modules} に記述されます 
 7022: (@pxref{modules})。
 7023: つまり、このオプションは @file{modules} の記述を無効にします。
 7024: 
 7025: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7026: @samp{cvs -n} と混同しないようにして下さい。
 7027: 
 7028: 以下のコマンドで利用できます:
 7029: @code{checkout}, @code{commit}, @code{export}, 
 7030: @code{rtag}.
 7031: 
 7032: @item -P
 7033: 空のディレクトリを削除 (prune) します。@ref{Removing directories} 参照。
 7034: 
 7035: @item -p
 7036: リポジトリから取得したファイルを、カレントディレクトリに置かず、
 7037: 標準出力に送り (pipe) ます。
 7038: 
 7039: 以下のコマンドで利用できます: @code{checkout}, @code{update}.
 7040: 
 7041: @item -R
 7042: 再帰的にディレクトリを辿って実行します。これは指定しなくても実行されま
 7043: す。
 7044: 
 7045: 以下のコマンドで使用可能です: @code{annotate}, @code{checkout},
 7046: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7047: @code{export}, @code{rdiff}, @code{remove}, @code{rtag},
 7048: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7049: @code{watchers}.
 7050: 
 7051: @item -r @var{tag}
 7052: @cindex HEAD, special tag
 7053: @cindex BASE, special tag
 7054: 既定の@dfn{先頭} (@dfn{head}) リビジョンの代りに、
 7055: 引数 @var{tag} で指定されたリビジョンを使用します。
 7056: @code{tag} か @code{rtag} コマンドで任意に定義されたタグの他に、
 7057: 二つの特別なタグ @samp{HEAD} と @samp{BASE} が常に利用できます。
 7058: @samp{HEAD} は、リポジトリにある最新のリビジョンを参照します。
 7059: @samp{BASE} は、作業コピーの由来となるリビジョンを参照します。
 7060: 
 7061: @c FIXME: What does HEAD really mean?  I believe that
 7062: @c the current answer is the head of the default branch
 7063: @c for all cvs commands except diff.  For diff, it
 7064: @c seems to be (a) the head of the trunk (or the default
 7065: @c branch?) if there is no sticky tag, (b) the head of the
 7066: @c branch for the sticky tag, if there is a sticky tag.
 7067: @c (b) is ugly as it differs
 7068: @c from what HEAD means for other commands, but people
 7069: @c and/or scripts are quite possibly used to it.
 7070: @c See "head" tests in sanity.sh.
 7071: @c Probably the best fix is to introduce two new
 7072: @c special tags, ".thead" for the head of the trunk,
 7073: @c and ".bhead" for the head of the current branch.
 7074: @c Then deprecate HEAD.  This has the advantage of
 7075: @c not suprising people with a change to HEAD, and a
 7076: @c side benefit of also phasing out the poorly-named
 7077: @c HEAD (see discussion of reserved tag names in node
 7078: @c "Tags").  Of course, .thead and .bhead should be
 7079: @c carefully implemented (with the implementation the
 7080: @c same for "diff" as for everyone else), test cases
 7081: @c written (similar to the ones in "head"), new tests
 7082: @c cases written for things like default branches, &c.
 7083: 
 7084: タグを指定して @code{checkout} や @code{update} コマンドを実行し、
 7085: 自分の作業ファイルを作った場合、そのタグは貼り付けられます。
 7086: つまりこのタグが記録され、以後他のものを指定するまで 
 7087: @code{update} に同じタグが使われ続けます 
 7088: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 7089: @var{tag} には、文字列と数字のどちらを指定しても構いません。
 7090: @xref{Tags}.
 7091: 
 7092: コマンド・オプション @samp{-r} と一緒に
 7093: 広域オプション @samp{-q} を指定すると、
 7094: @sc{rcs} ファイルが指定したタグを含まない場合に、
 7095: 警告出力が抑止されるので便利です。
 7096: 
 7097: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7098: @samp{cvs -r} と混同しないようにして下さい!
 7099: 
 7100: @samp{-r} は以下のコマンドで利用できます :@code{checkout},
 7101: @code{commit}, @code{diff}, @code{history}, @code{export},
 7102: @code{rdiff}, @code{rtag}, @code{update}.
 7103: 
 7104: @item -W
 7105: フィルタを適用したいファイルを指定します。
 7106: フィルタを適用したいファイルが複数あるときは、
 7107: このオプションを何個並べても構いません。
 7108: ファイル @file{.cvswrappers} での指定方法と同じ形式で指定します。
 7109: 
 7110: 以下のコマンドで利用できます: @code{import}, @code{update}.
 7111: 
 7112: @end table
 7113: 
 7114: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7115: @node admin
 7116: @appendixsec admin---管理
 7117: @cindex Admin (subcommand)
 7118: 
 7119: @itemize @bullet
 7120: @item
 7121: 必須: リポジトリ, 作業ディレクトリ
 7122: @item
 7123: 変更: リポジトリ
 7124: @item
 7125: 別名: rcs
 7126: @end itemize
 7127: 
 7128: これは雑多な管理機構への @sc{cvs} のインターフェースです。@sc{cvs} で
 7129: は役に立つか疑わしいようなものもありますが、歴史的な互換性の目的のため
 7130: に存在しています。このコマンドは@emph{必ず}再帰的に動作するため、使用
 7131: の際には細心の注意を払って下さい。
 7132: 
 7133: Unix ではグループ名 @code{cvsadmin} が存在する場合、
 7134: そのグループの一員だけが @code{cvs admin} を利用できます。
 7135: このグループはサーバ側か、非クライアント/サーバの @sc{cvs} を実行してい
 7136: る全てのシステムで存在している必要があります。
 7137: その名前で無人のグループを作成すれば、
 7138: @code{cvs admin} の使用を全面的に禁止できます。
 7139: NT では、@code{cvsadmin} 機能は存在せず、全ての使用者が @code{cvs
 7140: admin} を実行できます。
 7141: 
 7142: @menu
 7143: * admin options::               admin のオプション
 7144: @end menu
 7145: 
 7146: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7147: @node admin options
 7148: @appendixsubsec admin のオプション
 7149: 
 7150: これらのオプションの中には @sc{cvs} での有用性に疑問符が付くものもあり
 7151: ますが、歴史的な互換性のために存在しています。中には、効果を解除するま
 7152: で、@sc{cvs} を使えなくなるものもあります!
 7153: 
 7154: @table @code
 7155: @item -A@var{oldfile}
 7156: @sc{cvs} では使用されません。@var{oldfile} の利用者一覧を、
 7157: 指定した @sc{rcs} ファイルの利用者一覧に追加します。
 7158: 
 7159: @item -a@var{logins}
 7160: @sc{cvs} では使用されません。@sc{rcs} ファイルの利用者一覧に、
 7161: @var{logins} で指定された利用者を追加します。
 7162: @var{logins} はカンマで区切った利用者の一覧です。
 7163: 
 7164: @item -b[@var{rev}]
 7165: 既定の枝を @var{rev} に設定します。@sc{cvs} では、普通は既定の枝は操作
 7166: しません。貼り付いたタグ (@pxref{Sticky tags}) を使うのがどの枝で作業
 7167: をするかを決める良い方法です。@code{cvs admin -b} を実行する理由は一つ
 7168: だけあります: ベンダー枝を使用しているときに、ベンダーのバージョンに戻
 7169: すため、です (@pxref{Reverting local changes})。@samp{-b} と引数の間に
 7170: 空白があってはいけません。
 7171: @c Hmm, we don't document the usage where rev is
 7172: @c omitted.  Maybe that usage can/should be deprecated
 7173: @c (and replaced with -bHEAD or something?) (so we can toss
 7174: @c the optional argument).  Note that -bHEAD does not
 7175: @c work, as of 17 Sep 1997, but probably will once "cvs
 7176: @c admin" is internal to CVS.
 7177: 
 7178: @cindex comment leader
 7179: @item -c@var{string}
 7180: 註釈符を @var{string} にします。註釈符は現在のバージョンの @sc{cvs} で
 7181: も、@sc{rcs} 5.7 でも使用されていません。ですから、心配する必要は全く
 7182: ありません。@xref{Keyword substitution}.
 7183: 
 7184: @item -e[@var{logins}]
 7185: @sc{cvs} では使用されません。@var{logins} に含まれる利用者を、
 7186: @sc{rcs} ファイルの利用者一覧から削除します。
 7187: @var{logins} が省略された場合は、利用者一覧を全て削除します。
 7188: 
 7189: @item -I
 7190: 標準入力が端末でない場合でも対話的に動作します。
 7191: このオプションはクライアント/サーバの @sc{cvs} では動作せず、将来の
 7192: @sc{cvs} のリリースからは消えるでしょう。
 7193: 
 7194: @item -i
 7195: @sc{cvs} では無意味です。これはリビジョンを作成することなく、新しい 
 7196: @sc{rcs} ファイルを作成して、初期化します。@sc{cvs} では、@code{cvs
 7197: add} コマンドでファイルを加えてください (@pxref{Adding files})。
 7198: 
 7199: @item -k@var{subst}
 7200: 既定のキーワード置換モードを 
 7201: @var{subst} にします。@xref{Substitution modes}.
 7202: ここで既定とした方法よりも、
 7203: @code{cvs update}, @code{cvs export}, @code{cvs checkout}
 7204: での @samp{-k} オプションが優先されます。
 7205: 
 7206: @item -l[@var{rev}]
 7207: リビジョン @var{rev} をロックします。
 7208: 枝番号が与えられた場合、その枝の最新リビジョンをロックします。
 7209: @var{rev} が省略された場合は、
 7210: 既定の枝の最新リビジョンをロックします。
 7211: 引数 と @samp{-l} の間にスペースがあってはいけません。
 7212: 
 7213: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 7214: @file{rcslock.pl} という名前のスクリプトがあります。
 7215: これを用いて上記のロック状態を、
 7216: @sc{cvs} における独占取得 (一時に一人だけがファイル編集可能な状態) 
 7217: に置き換えることができます。
 7218: 詳細はスクリプトの註釈を参照して下さい 
 7219: (寄贈物の支援と権利の放棄声明文が書かれたファイル @file{README} 
 7220: も一読して下さい)。
 7221: その註釈によれば、厳格ロックモード (既定) に設定しておく必要があります。
 7222: 
 7223: @item -L
 7224: 厳格にロックを求める設定 (厳格ロックモード) にします。
 7225: 厳格ロックモードだと、@sc{rcs} ファイルの所有者であっても、
 7226: ロックしていないファイルは格納できません。
 7227: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7228: 上記 @samp{-l} オプションの説明も参照して下さい。
 7229: 
 7230: @cindex Changing a log message
 7231: @cindex Replacing a log message
 7232: @cindex Correcting a log message
 7233: @cindex Fixing a log message
 7234: @cindex Log message, correcting
 7235: @item -m@var{rev}:@var{msg}
 7236: リビジョン @var{rev} のログ・メッセージを @var{msg} に替えます。
 7237: 
 7238: @c The rcs -M option, to suppress sending mail, has never been
 7239: @c documented as a cvs admin option.
 7240: 
 7241: @item -N@var{name}[:[@var{rev}]]
 7242: これ以前の @var{name} の設定を無効にすることを除けば、
 7243: @samp{-n} と同じように働きます。
 7244: 魔法の枝での使用法は @ref{Magic branch numbers} を参照してください。
 7245: 
 7246: @item -n@var{name}[:[@var{rev}]]
 7247: 枝またはリビジョン @var{rev} にタグ名 @var{name} を付けます。
 7248: 通常は @samp{cvs tag} か @samp{cvs rtag} を代わりに用いると良いでしょう。
 7249: @samp{:} と @var{rev} の両方を省略すると、タグ名が削除されます。
 7250: また @var{name} が既に使用されていた場合は、
 7251: エラー・メッセージが出力されます。
 7252: @var{rev} がタグ名のときは、相当する番号に置換されます。
 7253: 枝番号の後に @samp{.} を付けて @var{rev} に指定した場合、
 7254: その枝の現時点での最新リビジョンになります。
 7255: @samp{:} だけで @var{rev} を指定しなかった場合、
 7256: 既定の枝 (通常は幹) の現時点での最新リビジョンになります。
 7257: 例えば @samp{cvs admin -n@var{name}: RCS/*} は、
 7258: 指定された全ての RCS ファイルの、
 7259: 現時点での最新リビジョンに @var{name} というタグ名を付けます。
 7260: 一方 @samp{cvs admin -n@var{name}:$ RCS/*} では、
 7261: 各作業ファイルのキーワード文字列に含まれる
 7262: リビジョンに @var{name} というタグ名を付けます。
 7263: 
 7264: @cindex Deleting revisions
 7265: @cindex Outdating revisions
 7266: @cindex Saving space
 7267: @item -o@var{range}
 7268: 
 7269: @var{range} の範囲のリビジョンを消去 (@dfn{過去のものにする}) します。
 7270: 
 7271: このコマンドは何をしているかを @emph{正確に} 知っていないと非常に危険
 7272: であることに注意してください (例えば、以下の @var{rev1:}@var{rev2} と
 7273: いう構文がいかに間違いやすいかという警告を読んでください)。
 7274: 
 7275: ディスクの容量が少ないなら、このオプションは役に立つかもしれません。し
 7276: かし、使う前によく考えてください---このコマンドを取り消すためには最後
 7277: のバックアップで復元するしかありません! 不注意や、(天が禁止している) 
 7278: CVS のバグによって、計画していたものと違うリビジョンを消してしまったら、
 7279: リビジョンが消去される前のエラーを修正する機会はありません。おそらく、
 7280: まずリポジトリのコピーで試すというのは良い考えでしょう。
 7281: 
 7282: 以下のどれかで @var{range} を指定します:
 7283: 
 7284: @table @code
 7285: @item @var{rev1}::@var{rev2}
 7286: CVS が rev1 から rev2 に関連付けられた差分だけを保存し、間の段階を保存
 7287: しないように、rev1 と rev2 間の全てのリビジョンを壊します。例えば、
 7288: @samp{-o 1.3::1.5} の後では、リビジョン 1.3, リビジョン 1.5, 1.3 から 
 7289: 1.5 の差分を取得することができますが、リビジョン 1.4 や 1.3 と 1.4 の
 7290: 差分を取得することはできません。他の例です: @samp{-o 1.3::1.4} と
 7291: @samp{-o 1.3::1.3} は間に消去するリビジョンが無いので、何の効果もあり
 7292: ません。
 7293: 
 7294: @item ::@var{rev}
 7295: @var{rev} のある枝と @var{rev} 自身の間のリビジョンを壊します。枝の始
 7296: 点と @var{rev} はそのまま残ります。例えば、@samp{-o ::1.3.2.6} はリビ
 7297: ジョン 1.3.2.1, リビジョン 1.3.2.5, とその間の全てのものを消去しますが、
 7298: 1.3 と 1.3.2.6 はそのまま残します。
 7299: 
 7300: @item @var{rev}::
 7301: @var{rev} と @var{rev} のある枝の最後との間のリビジョンを壊します。リ
 7302: ビジョン @var{rev} はそのまま残りますが、先頭のリビジョンは消去されま
 7303: す。
 7304: 
 7305: @item @var{rev}
 7306: リビジョン @var{rev} を消去します。例えば、@samp{-o 1.3} は @samp{-o
 7307: 1.2::1.4} と等価です。
 7308: 
 7309: @item @var{rev1}:@var{rev2}
 7310: 同じ枝の @var{rev1} から @var{rev2} のリビジョンを、それを含めて消去し
 7311: ます。@var{rev1} や @var{rev2} やその間の全てのリビジョンを取得するこ
 7312: とはできなくなります。例えば、コマンド @samp{cvs admin -oR_1_01:R_1_02
 7313: .} はほとんど役に立ちません。それは、タグ R_1_02 までのリビジョンを、
 7314: それを含めて消去するということです。でも注意してください! R_1_02 と 
 7315: R_1_03 で変更されていないファイルがあれば、そのファイルはタグ R_1_02 
 7316: と R_1_03 で@emph{同じ}数値リビジョン番号になっています。ですから、
 7317: R_1_02 を取得できなるだけではありません。R_1_03 もテープから復元しなけ
 7318: ればならなくなります! たいていの場合、代わりに @var{rev}::@var{rev2}
 7319: と指定しようと思うでしょう。
 7320: 
 7321: @item :@var{rev}
 7322: @var{rev} のある枝の最初から、@var{rev} までのリビジョンを、それを含め
 7323: て消去します。
 7324: 
 7325: @item @var{rev}:
 7326: @var{rev} のある枝の最後から、@var{rev} までのリビジョンを、それを含め
 7327: て消去します。
 7328: @end table
 7329: 
 7330: 消去されるべきリビジョンは全て枝やロックを持っていてはいけません。
 7331: 
 7332: 消去されるべきリビジョンにタグ名があり、@samp{::} 構文のどれかを指定
 7333: すると、@sc{cvs} はエラーを出して、どのリビジョンも消去されません。タ
 7334: グ名とリビジョンの両方を消去したいなら、まず @code{cvs tag -d} でタグ
 7335: 名を消去し、それから @code{cvs admin -o} を実行します。@samp{::} でな
 7336: い構文をいてい すると、@sc{cvs} はリビジョンを消去しますが、タグ名を存
 7337: 在しないリビジョン指すタグ名として残します。この振舞いは @sc{cvs} の以
 7338: 前のバージョンとの互換性のために残されています。しかし、これは便利では
 7339: ありませんので、将来は @samp{::} の場合と同様の振舞いに変更されるかも
 7340: しれません。
 7341: 
 7342: @sc{cvs} が枝を扱う方法のために、@var{rev} は、もし枝であれば名前で指
 7343: 定することはできません。説明は、@xref{Magic branch numbers}.
 7344: @c FIXME: is this still true?  I suspect not.
 7345: 
 7346: だれも壊したリビジョンのコピーを取り出していないことを確認してください。
 7347: 誰かがそれを編集して、格納し直そうとすると、変なことが起こります。この
 7348: ため、このオプションは無駄な格納を戻すためには良い方法ではありません。
 7349: 代わりにその変更を元に戻すための新しいリビジョンを格納してください 
 7350: (@pxref{Merging two revisions})。
 7351: 
 7352: @item -q
 7353: 簡素な (quiet) 表示、つまり実行時に診断情報を表示しません。
 7354: 
 7355: @item -s@var{state}[:@var{rev}]
 7356: @sc{cvs} でも使用します。
 7357: リビジョン @var{rev} の状態を識別する文字列を @var{state} にします。
 7358: @var{rev} が枝番号の場合、その枝の最新リビジョンの状態を変更します。
 7359: @var{rev} を省略すると、既定の枝の最新リビジョンを変更します。
 7360: @var{state} には、どのような文字列を用いても構いません。
 7361: 通常使用されるのは、@samp{Exp} (実験段階), @samp{Stab} (安定動作), 
 7362: @samp{Rel} (出荷済) といった組み合わせです。
 7363: 既定では、新しく作成されたリビジョンの状態は @samp{Exp} にされます。
 7364: 各リビジョンの状態は、@samp{cvs log} (@pxref{log}) の出力や、
 7365: キーワード @samp{$@asis{}Log$}, @samp{$@asis{}State$}
 7366: (@pxref{Keyword substitution}) の内容で確認できます。
 7367: ここで、@sc{cvs} が @code{dead} という状態を
 7368: 独自の目的で用いることに注意して下さい。
 7369: @code{dead} 状態を扱う際には、@code{cvs remove} 
 7370: や @code{cvs add} といったコマンドを使用し、
 7371: @samp{cvs admin -s} を使用してはいけません。
 7372: 
 7373: @item -t[@var{file}]
 7374: @sc{cvs} でも使用します。
 7375: @sc{rcs} ファイルの説明文を @var{file} の内容に書き換えます。
 7376: @var{file} のパス名は @samp{-} で始まってはいけません。
 7377: 各ファイルの説明文は @samp{cvs log} (@pxref{log}) の出力で確認できます。
 7378: @samp{-t} と引数の間に空白があってはいけません。
 7379: 
 7380: @var{file} が省略された場合、標準入力が用いられ、
 7381: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7382: 対話的動作が可能なら入力促進も可能です。@samp{-I} を参照してださい。
 7383: クライアント/サーバの @sc{cvs} では標準入力からの読み込みは動作せず、
 7384: 将来の @sc{cvs} のリリースでは変更されるかもしれません。
 7385: @c Changing it to doeditor() is the most obvious thing
 7386: @c (but with a different syntax, as we would like to
 7387: @c phase out optional arguments).  I don't know.  I'm
 7388: @c tempted to say the whole concept is unnecessary.
 7389: 
 7390: @item -t-@var{string}
 7391: @samp{-t@var{file}} と同様です。
 7392: @sc{rcs} ファイルの説明文を @var{string} に書き換えます。
 7393: @samp{-t} と引数の間に空白があってはいけません。
 7394: 
 7395: @c The rcs -T option, do not update last-mod time for
 7396: @c minor changes, has never been documented as a
 7397: @c cvs admin option.
 7398: 
 7399: @item -U
 7400: 厳格にはロックしない設定 (非厳格ロックモード) にします。
 7401: 非厳格ロックモードだと、@sc{rcs} ファイルの所有者ならば、
 7402: ロックしていないファイルも格納できます。
 7403: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7404: 上記 @samp{-l} オプションの説明も参照して下さい。
 7405: 
 7406: @item -u[@var{rev}]
 7407: このオプションを @sc{cvs} で使用する際の説明は、
 7408: 上記 @samp{-l} オプションを参照して下さい。
 7409: リビジョン @var{rev} のロックを解除します。
 7410: 枝を指定した場合、その枝の最新リビジョンのロックを解除します。
 7411: @var{rev} を省略すると、その人物が行なった最後のロックを解除します。
 7412: 通常は、ロックを掛けた人物だけがロックを解除できます。
 7413: 誰か他の人物がロックを解除した場合には、
 7414: ロックを掛けた人物にメールが送信されます。
 7415: このメールにはロックを解除した理由等が書き添えられます。
 7416: 連絡文はロックを解除した人物が入力し、
 7417: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7418: @samp{-u} とその引数の間に空白があってはいけません。
 7419: @c In the future "send mail" probably will go via the
 7420: @c CVSROOT/notify mechanism.  But for now it means
 7421: @c whatever it means to "rcs".
 7422: 
 7423: @item -V@var{n}
 7424: 前のバージョンの @sc{cvs} ではこのオプションはバージョン @var{n} の 
 7425: @sc{rcs} ファイルが認識できる @sc{rcs} ファイルを書くことを意味してい
 7426: ましたが、今は旧式となり、それを指定するとエラーを起こします。
 7427: @c Note that -V without an argument has never been
 7428: @c documented as a cvs admin option.
 7429: 
 7430: @item -x@var{suffixes}
 7431: 前のバージョンの @sc{cvs} では、これは @sc{rcs} ファイルの名前を指定す
 7432: るための方法として説明されていました。しかし、@sc{cvs} は常に @sc{cvs} 
 7433: で使用される @sc{rcs} ファイルは @samp{,v} で終わることを要求してきま
 7434: したので、このオプションは今まで役に立ったことはありません。
 7435: 
 7436: @c The rcs -z option, to specify the timezone, has
 7437: @c never been documented as a cvs admin option.
 7438: @end table
 7439: 
 7440: 
 7441: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7442: @node checkout
 7443: @appendixsec checkout---編集の為にソースを取り出す
 7444: @cindex Checkout (subcommand)
 7445: @cindex Co (subcommand)
 7446: 
 7447: @itemize @bullet
 7448: @item
 7449: 書式: checkout [options] modules@dots{}
 7450: @item
 7451: 必須: リポジトリ
 7452: @item
 7453: 変更: 作業ディレクトリ
 7454: @item
 7455: 別名: co, get
 7456: @end itemize
 7457: 
 7458: @var{modules} で指定されたモジュールの作業ディレクトリを作成、
 7459: もしくは更新し、
 7460: その中にソース・ファイルをコピーします。
 7461: @sc{cvs} のほとんどのコマンドは作業ディレクトリを扱うものなので、
 7462: まず @code{checkout} を実行しておく必要があります。
 7463: 
 7464: @var{modules} は、
 7465: リポジトリ中のディレクトリやファイルへの相対パスだけでなく、
 7466: ディレクトリやファイルの集合に対する別名でも構いません。
 7467: 別名は管理用ファイル @file{modules} で定義します 
 7468: @xref{modules}.
 7469: @c Needs an example, particularly of the non-"modules"
 7470: @c case but probably of both.
 7471: 
 7472: @c FIXME: this seems like a very odd place to introduce
 7473: @c people to how CVS works.  The bit about unreserved
 7474: @c checkouts is also misleading as it depends on how
 7475: @c things are set up.
 7476: 指定したモジュールにもよりますが、
 7477: @code{checkout} は再帰的にディレクトリを作成し、
 7478: そこに適切なソース・ファイルを入れていきます。
 7479: そして (他の開発者が各自のコピーを編集しているかどうかに関わらず)、
 7480: 好きなときに自分のソース・ファイルを編集し、
 7481: 他人の変更を取り入れるために更新したり、
 7482: 自分の変更をリポジトリに反映するために格納したりします。
 7483: 
 7484: @code{checkout} で作成されるディレクトリに注意して下さい。
 7485: 最上位のディレクトリは、
 7486: 必ず @code{checkout} を実行したディレクトリに追加され、
 7487: 通常は指定したモジュールと同じ名前になります。
 7488: モジュールに別名が定義されている場合、
 7489: サブディレクトリは違う名前になりますが心配は要りません。
 7490: @code{checkout} の処理中、各ファイルを作業領域に展開したと同時に
 7491: その相対パスが表示されますから、
 7492: この表示でサブディレクトリを確認して下さい 
 7493: (広域オプション @samp{-Q} を付けた場合は表示がありません)。
 7494: 
 7495: @sc{cvs} にオプション @samp{-r} が付けられた場合 
 7496: (@pxref{Global options})、
 7497: 環境変数 @code{CVSREAD} が設定されていた場合 
 7498: (@pxref{Environment variables})、
 7499: ファイルが監視されていた場合 
 7500: (@pxref{Watches}) を除いて、
 7501: @code{checkout} が作成するファイルは読み書き可能な状態になります。
 7502: 
 7503: @code{checkout} で作成したディレクトリの上で、
 7504: 再度 @code{checkout} を実行しても構わないということに注意してください。
 7505: これはリポジトリに作成された新しいディレクトリが作業領域に現れるという
 7506: 点で、@code{update} コマンドに @samp{-d} オプションを付けるのと同様の
 7507: 効果があります。しかし、@code{update} は引数にディレクトリ名を取ります
 7508: が、@code{checkout} は引数にモジュール名を取ります。@code{checkout} を
 7509: この様に使うためには、最上位のディレクトリから実行しなければなりません
 7510: ので (普段 @code{checkout} を実行する場所です)、存在するディレクトリを
 7511: 更新するために @code{checkout} を実行する前に、ディレクトリを最上位の
 7512: ディレクトリに変更することを忘れないでください。
 7513: 
 7514: @code{checkout} コマンドの出力は @ref{update output} を参照して下さい。
 7515: 
 7516: @menu
 7517: * checkout options::            checkout のオプション
 7518: * checkout examples::           checkout の使用例
 7519: @end menu
 7520: 
 7521: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7522: @node checkout options
 7523: @appendixsubsec checkout のオプション
 7524: 
 7525: @code{checkout} では、以下の標準オプションが利用できます 
 7526: (完全な記述は @pxref{Common options}):
 7527: 
 7528: @table @code
 7529: @item -D @var{date}
 7530: @var{date} 以前の最も新しいリビジョンを取り出します。
 7531: このオプションは貼り付けられ、
 7532: 勝手に @samp{-P} オプションも実行されます。
 7533: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 7534: 
 7535: @item -f
 7536: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 7537: 指定したリビジョンが見付からなかった場合、
 7538: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 7539: 
 7540: @item -k @var{kflag}
 7541: キーワード置換モードを @var{kflag} に指定します。
 7542: 詳細は @ref{Substitution modes} を参照。
 7543: このオプションは貼り付けられます。つまりこれ以後、
 7544: この作業ディレクトリでファイルが更新されるときには、
 7545: 同じ @var{kflag} が使用され続けます。
 7546: @code{status} コマンドを用いて
 7547: 貼り付いたオプションを見ることができます。
 7548: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 7549: 
 7550: @item -l
 7551: Local、つまり現在の作業ディレクトリでのみコマンドが
 7552: 実行されます。
 7553: 
 7554: @item -n
 7555: ファイルを取り出したとき、普段は実行されるプログラムを実行しません。
 7556: このプログラムは管理用ファイル @file{modules} の
 7557: オプション @samp{-o} で指定されます (@pxref{modules})。
 7558: 
 7559: @item -P
 7560: 空になったディレクトリを削除 (prune) します。@ref{Moving directories}
 7561: を参照してください。
 7562: 
 7563: @item -p
 7564: ファイルを標準出力に送り (pipe) ます。
 7565: 
 7566: @item -R
 7567: ディレクトリを再帰的に取り出します。このオプションは指定しなくても実行
 7568: されます。
 7569: 
 7570: @item -r @var{tag}
 7571: @var{tag} で指定されたリビジョンを取り出します。
 7572: このオプションは貼り付けられ、
 7573: @samp{-P} オプションも勝手に実行されます。
 7574: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 7575: @end table
 7576: 
 7577: さらに @code{checkout} では次の固有オプションも使用可能です:
 7578: 
 7579: @table @code
 7580: @item -A
 7581: 全ての貼り付いたタグや日付、
 7582: また @samp{-k} オプションの指定を剥がします。
 7583: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags} を参照してくだ
 7584: さい。
 7585: 
 7586: @item -c
 7587: 管理用ファイル @file{modules} の内容を、
 7588: アルファベット順に並べて標準出力に出します。
 7589: 作業ディレクトリは全く変更されません。
 7590: 
 7591: @item -d @var{dir}
 7592: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 7593: 一般的に、このフラグは @samp{mkdir @var{dir}; cd @var{dir}} の後に 
 7594: @samp{-d} フラグ無しで checkout コマンドを実行することと同じです。
 7595: 
 7596: しかし、重要な例外があります。単独の項目を取り出しているときには、出力
 7597: に間に空のディレクトリが無いディレクトリが現れた方がとても便利です。こ
 7598: の場合@emph{のみ}、CVS は空のディレクトリを避けるためにパス名を ``短く'' 
 7599: します。
 7600: 
 7601: 例えば、ファイル @samp{bar.c} がある @samp{foo} というモジュールがある
 7602: とすると、コマンド @samp{cvs co -d dir foo} はディレクトリ @samp{dir}
 7603: を作成し、中に @samp{bar.c} を置きます。同様に、サブディレクトリ 
 7604: @samp{baz} があり、その中に @samp{quux.c} のあるモジュール @samp{bar} 
 7605: があるとすると、コマンド @samp{cvs -d dir co bar/baz} はディレクトリ 
 7606: @samp{dir} 作成し、その中に @samp{quux.c} を置きます。
 7607: 
 7608: @samp{-N} フラグを使うと、この振舞いは抑制されます。上と同じモジュール
 7609: の定義で、@samp{cvs co -N -d dir foo} はディレクトリ @samp{dir/foo} を
 7610: 作成してその中に @samp{bar.c} を置き、@samp{cvs co -N -d dir bar/baz}
 7611: はディクトリ @samp{dir/bar/baz} を作成してその中に @samp{quux.c} を置
 7612: きます。
 7613: 
 7614: @item -j @var{tag}
 7615: @samp{-j} オプションを二つ指定した場合、
 7616: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 7617: 作業ディレクトリにマージします。
 7618: 
 7619: @samp{-j} オプションが一つの場合、
 7620: その分岐リビジョンから指定したリビジョンへの変更を、
 7621: 作業ディレクトリにマージします。
 7622: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 7623: @samp{-j} で指定したリビジョンとの共通の祖先です。
 7624: 
 7625: @samp{-j} オプションに枝を指定する場合、
 7626: 日付の指定を付加することができます。
 7627: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 7628: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 7629: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 7630: 
 7631: @xref{Branching and merging}.
 7632: 
 7633: @item -N
 7634: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 7635: このオプションを指定した場合、
 7636: 単独モジュールを取り出したときに、
 7637: 作業ディレクトリのモジュールパスを ``短く'' しません。例と説明は 
 7638: @samp{-d} フラグを参照してください。
 7639: 
 7640: @item -s
 7641: @samp{-c} と同様ですが、全てのモジュールの状態を
 7642: アルファベット順に並べて標準出力に出します。
 7643: モジュールの状態を設定するために管理用ファイル @file{modules} の中で使
 7644: われるオプション @samp{-s} の情報は、@xref{modules}.
 7645: @end table
 7646: 
 7647: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7648: @node checkout examples
 7649: @appendixsubsec checkout の使用例
 7650: 
 7651: モジュール @samp{tc} のコピーを取り出します:
 7652: 
 7653: @example
 7654: $ cvs checkout tc
 7655: @end example
 7656: 
 7657: モジュール @samp{tc} を昨日の状態で取り出します:
 7658: 
 7659: @example
 7660: $ cvs checkout -D yesterday tc
 7661: @end example
 7662: 
 7663: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7664: @node commit
 7665: @appendixsec commit---ファイルをリポジトリに格納する
 7666: @cindex Commit (subcommand)
 7667: 
 7668: @itemize @bullet
 7669: @item
 7670: 書式: commit [-lnRf] [-m 'log_message' |
 7671: -F file] [-r revision] [files@dots{}]
 7672: @item
 7673: 必須: 作業ディレクトリ, リポジトリ
 7674: @item
 7675: 変更: リポジトリ
 7676: @item
 7677: 別名: ci
 7678: @end itemize
 7679: 
 7680: @code{commit} は、作業ファイルに対する変更を
 7681: リポジトリに組み入れる際に使用します。
 7682: 
 7683: 格納するファイルを特に指定しなければ、
 7684: 現在の作業ディレクトリの全ファイルが調査され、
 7685: 変更が加えられたファイルだけがリポジトリに格納されます。
 7686: 既定 (もしくは明示的にオプション @samp{-R} が指定された場合) では、
 7687: サブディレクトリのファイルも調査され、変更されていれば格納されます。
 7688: オプション @samp{-l} を指定して、
 7689: @code{commit} の動作を現在のディレクトリだけに留めることも可能です。
 7690: 
 7691: @code{commit} は、選択されたファイルが
 7692: リポジトリの最新リビジョンであるかどうか確認します。
 7693: 指定されたファイルの中に @code{update} (@pxref{update}) 
 7694: が必要なものが一つでもあれば、その旨が表示され、
 7695: 格納せずに終了します。
 7696: @code{commit} はあえて @code{update} コマンドを呼び出さず、
 7697: 開発者自身に適切な時期を判断してもらいます。
 7698: 
 7699: 全てが正常ならば、ログ・メッセージを記すためにエディタが起動されます。
 7700: ログ・メッセージは幾つかの処理プログラムに送られると同時に 
 7701: (@ref{modules} と @ref{loginfo} を参照)、
 7702: リポジトリ中の @sc{rcs} ファイルにも記録されます。
 7703: このログ・メッセージを参照するには @code{log} コマンドを
 7704: 用いて下さい。@ref{log} 参照。
 7705: オプション @samp{-m @var{message}} で
 7706: コマンド行にログ・メッセージを記述したり、
 7707: オプション @samp{-F @var{file}} で
 7708: ログ・メッセージを記述したファイルを指定すれば、
 7709: エディタを起動しなくて済みます。
 7710: 
 7711: @menu
 7712: * commit options::              commit のオプション
 7713: * commit examples::             commit の使用例
 7714: @end menu
 7715: 
 7716: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7717: @node commit options
 7718: @appendixsubsec commit のオプション
 7719: 
 7720: @code{commit} では、以下の標準オプションが利用できます 
 7721: (完全な記述は @pxref{Common options}):
 7722: 
 7723: @table @code
 7724: @item -l
 7725: Local、つまり現在の作業ディレクトリでのみコマンドが
 7726: 実行されます。
 7727: 
 7728: @item -n
 7729: モジュールのプログラムを実行しません。
 7730: 
 7731: @item -R
 7732: ディレクトリを再帰的に格納します。
 7733: このオプションは指定しなくても実行されます。
 7734: 
 7735: @item -r @var{revision}
 7736: @var{revision} に格納します。
 7737: @var{revision} には、枝もしくは、
 7738: 既存の全てのリビジョン番号よりも大きい番号を持つ
 7739: 幹上のリビジョンを指定しなくてはいけません 
 7740: (@pxref{Assigning revisions})。
 7741: 枝上のリビジョンを指定して格納することはできません。
 7742: @c FIXME: Need xref for branch case.
 7743: @end table
 7744: 
 7745: さらに @code{commit} では以下のオプションも使用可能です:
 7746: 
 7747: @table @code
 7748: @item -F @var{file}
 7749: エディタを起動せず @var{file} からログ・メッセージを読み込みます。
 7750: 
 7751: @item -f
 7752: これは @ref{Common options} のオプション @samp{-f} に記述される
 7753: 標準的な動作とは異なることに注意して下さい。
 7754: 
 7755: 作業ファイルに何も変更を加えていない場合でも、
 7756: 無理矢理新しいリビジョンとして格納します。
 7757: 現在の @var{file} のリビジョンを 1.7 と仮定したとき、
 7758: 次の二つのコマンドの実行結果は同じになります:
 7759: 
 7760: @example
 7761: $ cvs commit -f @var{file}
 7762: $ cvs commit -r 1.8 @var{file}
 7763: @end example
 7764: 
 7765: @c This is odd, but it's how CVS has worked for some
 7766: @c time.
 7767: @samp{-f} オプションは再帰を使いません (すなわち、@samp{-l} を含んでい
 7768: ます)。全てのサブディレクトリの全てのファイルの新しいリビジョンの格納
 7769: を @sc{cvs} 強制するには、@samp{-f -R} を使用する必要があります。
 7770: 
 7771: @item -m @var{message}
 7772: エディタを起動せず、@var{message} をログ・メッセージとします。
 7773: @end table
 7774: 
 7775: @need 2000
 7776: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7777: @node commit examples
 7778: @appendixsubsec commit の使用例
 7779: 
 7780: @appendixsubsubsec 枝に対して格納する
 7781: 
 7782: オプション @samp{-r} を用いて、枝リビジョン (リビジョン番号が
 7783: 偶数個のドットを含むもの) に格納することができます。
 7784: 枝リビジョンは @code{rtag} か @code{tag} コマンドに
 7785: オプション @samp{-b} を指定して作成します 
 7786: (@pxref{tag} もしくは @pxref{rtag})。
 7787: そして @code{checkout} か @code{update} で、
 7788: 新しく作成した枝からソースを取り出します。
 7789: その結果、この作業ソースに対する変更を @code{commit} すると、
 7790: 全て自動的に枝リビジョンの方に追加され、
 7791: 幹の開発系統は全く影響を受けません。
 7792: 例えば、バージョン 1.2 の製品に対するパッチを作成する必要があるけれど、
 7793: 既にバージョン 2.0 の開発が始まっているような場合、
 7794: 以下のようにします:
 7795: 
 7796: @example
 7797: $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
 7798: $ cvs checkout -r FCS1_2_Patch product_module
 7799: $ cd product_module
 7800: [[ hack away ]]
 7801: $ cvs commit
 7802: @end example
 7803: 
 7804: @noindent
 7805: オプション @samp{-r} は作業ディレクトリに貼り付けられるため、
 7806: これを指定する必要はありません。
 7807: 
 7808: @appendixsubsubsec 編集後に枝を作成する
 7809: 
 7810: 例えば、先週取り出したリビジョンを元にして、
 7811: 極めて実験的な変更をソフトウェアに加えてきたとします。
 7812: ここで実験に他の開発者を加えたいけれど、
 7813: 幹の開発系統を妨げたくない場合は、
 7814: その変更点を新しい枝に格納すれば良いでしょう。
 7815: すると他の開発者も実験中のコードを取り出して、
 7816: @sc{cvs} の衝突解決の恩恵を全て受けることができます。
 7817: このシナリオは次のようになるでしょう:
 7818: 
 7819: @c FIXME: Should we be recommending tagging the branchpoint?
 7820: @example
 7821: [[ hacked sources are present ]]
 7822: $ cvs tag -b EXPR1
 7823: $ cvs update -r EXPR1
 7824: $ cvs commit
 7825: @end example
 7826: 
 7827: @code{update} コマンドで、全てのファイルに
 7828: オプション @samp{-r EXPR1} が貼り付けられます。
 7829: このとき、@code{update} コマンドでは
 7830: ファイルに対する変更が削除されないことに注意して下さい。
 7831: @samp{-r} が貼り付けられているため、
 7832: @code{commit} すれば自動的に正しい枝に変更が格納されます。
 7833: これは次の手順もあります:
 7834: 
 7835: @c FIXME: Should we be recommending tagging the branchpoint?
 7836: @example
 7837: [[ hacked sources are present ]]
 7838: $ cvs tag -b EXPR1
 7839: $ cvs commit -r EXPR1
 7840: @end example
 7841: 
 7842: @noindent
 7843: しかしこの場合、
 7844: 変更されていたファイルだけに @samp{-r EXPR1} が貼り付けられます。
 7845: 従って別のファイルを変更して、フラグ @samp{-r EXPR1} を付けずに
 7846: 格納した場合、誤って幹に格納されてしまいます。
 7847: 
 7848: 他の開発者が実験に参加する際には、
 7849: 単純に以下のようにして下さい:
 7850: 
 7851: @example
 7852: $ cvs checkout -r EXPR1 whatever_module
 7853: @end example
 7854: 
 7855: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7856: @node diff
 7857: @appendixsec diff---リビジョン間の差分の表示
 7858: @cindex Diff (subcommand)
 7859: 
 7860: @itemize @bullet
 7861: @item
 7862: 書式: diff [-lR] [format_options] [[-r rev1 | -D date1] [-r rev2 |  -D date2]] [files@dots{}]
 7863: @item
 7864: 必須: 作業ディレクトリ, リポジトリ
 7865: @item
 7866: 変更: なし
 7867: @end itemize
 7868: 
 7869: @code{diff} コマンドは、
 7870: 別々のリビジョン間の差異を比較するのに使用します。
 7871: 特にオプションを指定しない場合、
 7872: 作業ファイルをその由来となったリビジョンと比較し、
 7873: 検出された全ての差異を報告します。
 7874: 
 7875: ファイル名を指定した場合、そのファイルについてのみ比較します。
 7876: ディレクトリを指定した場合、その下の全てのファイルを比較します。
 7877: 
 7878: diff の終了状態は他の @sc{cvs} コマンドと違います。詳細は @ref{Exit
 7879: status} を参照してください。
 7880: 
 7881: @menu
 7882: * diff options::                diff のオプション
 7883: * diff examples::               diff の使用例
 7884: @end menu
 7885: 
 7886: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7887: @node diff options
 7888: @appendixsubsec diff のオプション
 7889: 
 7890: @code{diff} では、以下の標準オプションが利用できます 
 7891: (完全な記述は @pxref{Common options}):
 7892: 
 7893: @table @code
 7894: @item -D @var{date}
 7895: @var{date} 以前の最も新しいリビジョンを利用します。
 7896: このオプションを比較に用いた時の効果は @samp{-r} を参照して下さい。
 7897: 
 7898: @item -k @var{kflag}
 7899: @var{kfalg} に従ってキーワード置換を行います。@ref{Keyword
 7900: substitution}, 参照。
 7901: 
 7902: @item -l
 7903: Local、つまり現在の作業ディレクトリでのみコマンドが
 7904: 実行されます。
 7905: 
 7906: @item -R
 7907: ディレクトリを再帰的に調べます。
 7908: このオプションは指定しなくても実行されます。
 7909: 
 7910: @item -r @var{tag}
 7911: リビジョン @var{tag} と比較します。
 7912: オプション @samp{-r} は最大二つまで使用できます。
 7913: オプション @samp{-r} を指定しない場合、
 7914: 作業ファイルをその由来となったリビジョンと比較します。
 7915: オプション @samp{-r} を一つ指定した場合、
 7916: 指定したリビジョンと作業ファイルとを比較します。
 7917: オプション @samp{-r} を二つ指定した場合、
 7918: 指定した二つのリビジョンを比較します 
 7919: (作業ファイルが結果に影響を与えることはありません)。
 7920: @c We should be a lot more explicit, with examples,
 7921: @c about the difference between "cvs diff" and "cvs
 7922: @c diff -r HEAD".  This often confuses new users.
 7923: 
 7924: 一つもしくは両方のオプション @samp{-r} を、前述の
 7925: オプション @samp{-D @var{date}} と交換することができます。
 7926: @end table
 7927: 
 7928: @c Conceptually, this is a disaster.  There are 3
 7929: @c zillion diff formats that we support via the diff
 7930: @c library.  It is not obvious to me that we should
 7931: @c document them all.  Maybe just the most common ones
 7932: @c like -c and -u, and think about phasing out the
 7933: @c obscure ones.
 7934: @c FIXCVS: also should be a way to specify an external
 7935: @c diff program (which can be different for different
 7936: @c file types) and pass through
 7937: @c arbitrary options, so that the user can do
 7938: @c "--pass=-Z --pass=foo" or something even if CVS
 7939: @c doesn't know about the "-Z foo" option to diff.
 7940: @c This would fit nicely with deprecating/eliminating
 7941: @c the obscure options of the diff library, because it
 7942: @c would let people specify an external GNU diff if
 7943: @c they are into that sort of thing.
 7944: 以下のオプションは出力の書式を指定します。
 7945: 意味は GNU diff と同じです。
 7946: 
 7947: @example
 7948: -0 -1 -2 -3 -4 -5 -6 -7 -8 -9
 7949: --binary
 7950: --brief
 7951: --changed-group-format=@var{arg}
 7952: -c
 7953:   -C @var{nlines}
 7954:   --context[=@var{lines}]
 7955: -e --ed
 7956: -t --expand-tabs
 7957: -f --forward-ed
 7958: --horizon-lines=@var{arg}
 7959: --ifdef=@var{arg}
 7960: -w --ignore-all-space
 7961: -B --ignore-blank-lines
 7962: -i --ignore-case
 7963: -I @var{regexp}
 7964:    --ignore-matching-lines=@var{regexp}
 7965: -h
 7966: -b --ignore-space-change
 7967: -T --initial-tab
 7968: -L @var{label}
 7969:   --label=@var{label}
 7970: --left-column
 7971: -d --minimal
 7972: -N --new-file
 7973: --new-line-format=@var{arg}
 7974: --old-line-format=@var{arg}
 7975: --paginate
 7976: -n --rcs
 7977: -s --report-identical-files
 7978: -p
 7979: --show-c-function
 7980: -y --side-by-side
 7981: -F @var{regexp}
 7982: --show-function-line=@var{regexp}
 7983: -H --speed-large-files
 7984: --suppress-common-lines
 7985: -a --text
 7986: --unchanged-group-format=@var{arg}
 7987: -u
 7988:   -U @var{nlines}
 7989:   --unified[=@var{lines}]
 7990: @c FIXCVS: This option is accepted by src/diff.c but
 7991: @c not diff/diff.c; it would appear that any attempt to
 7992: @c use it would get an error.
 7993: -V @var{arg}
 7994: -W @var{columns}
 7995:   --width=@var{columns}
 7996: @end example
 7997: 
 7998: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7999: @node diff examples
 8000: @appendixsubsec diff の使用例
 8001: 
 8002: 次の実行例は、@file{backend.c} のリビジョン 1.14 と 1.19 間の差分を、
 8003: unidiff 形式 (フラグ @samp{-u}) で出力します。
 8004: またキーワード置換を止めるために @samp{-kk} を指定し、
 8005: キーワード置換による差分を無視します。
 8006: 
 8007: @example
 8008: $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
 8009: @end example
 8010: 
 8011: タグ RELEASE_1_0 が付けられたファイルの集合から、
 8012: 実験用の枝 EXPR1 が派生していると仮定します。
 8013: この枝に加えられた変更を見るには、次のようにします:
 8014: 
 8015: @example
 8016: $ cvs diff -r RELEASE_1_0 -r EXPR1
 8017: @end example
 8018: 
 8019: 次の実行例では、二つのリリース間の差分を context 形式で出力します:
 8020: 
 8021: @example
 8022: $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
 8023: @end example
 8024: 
 8025: ChangeLogs を運用している場合、
 8026: 変更を格納する前に次の行のようなコマンドを実行すると、
 8027: ChangeLogs の記載事項を入力するのに役立つでしょう。
 8028: 作業ファイルに加えた変更点のうち、格納していないもの全てを表示します。
 8029: 
 8030: @example
 8031: $ cvs diff -u | less
 8032: @end example
 8033: 
 8034: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8035: @node export
 8036: @appendixsec export---CVS からソースを取り出す, checkout に類似
 8037: @cindex Export (subcommand)
 8038: 
 8039: @itemize @bullet
 8040: @item
 8041: 書式: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
 8042: @item
 8043: 必須: リポジトリ
 8044: @item
 8045: 変更: 現在のディレクトリ
 8046: @end itemize
 8047: 
 8048: このコマンドは @code{checkout} の変形で、
 8049: @var{module} のソースのコピーを、
 8050: @sc{cvs} の管理用ディレクトリを除いた状態で取り出します。
 8051: 例えば出荷用のソースを準備するときなどに @code{export} を使います。
 8052: 出荷したソースを後で再現できることを確認するため、使用の際には 
 8053: (@samp{-D} か @samp{-r} による) 日付かタグの指定が要求されます。
 8054: 
 8055: @code{cvs export} に @samp{-kv} を指定すると便利です。
 8056: この指定で全てのキーワードが展開されるため、
 8057: 出荷先で @code{import} されても
 8058: キーワードによるリビジョン情報が失われません。
 8059: しかしモジュールがバイナリ・ファイルを含む場合は、
 8060: 正しく処理されない可能性があるので注意が必要です。
 8061: また @samp{-kv} を使用した後では、@code{ident} コマンド (@sc{rcs} を
 8062: 構成するコマンドの一つです---@samp{ident(1)} を参照) を使用して、
 8063: キーワード文字列を抜き出すことができません。
 8064: 従って @code{ident} を使用するつもりなら、
 8065: @samp{-kv} を指定してはいけません。
 8066: 
 8067: @menu
 8068: * export options::              export のオプション
 8069: @end menu
 8070: 
 8071: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8072: @node export options
 8073: @appendixsubsec export のオプション
 8074: 
 8075: @code{export} では、以下の標準オプションが利用できます 
 8076: (完全な記述は @pxref{Common options}):
 8077: 
 8078: @table @code
 8079: @item -D @var{date}
 8080: @var{date} 以前の最も新しいリビジョンを取り出します。
 8081: 
 8082: @item -f
 8083: 指定したリビジョンが見付からなかった場合、
 8084: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 8085: 
 8086: @item -l
 8087: Local、つまり現在の作業ディレクトリでのみコマンドが
 8088: 実行されます。
 8089: 
 8090: @item -n
 8091: ファイルを取り出したとき、通常実行されるプログラムを実行しません。
 8092: 
 8093: @item -R
 8094: ディレクトリを再帰的に取り出します。
 8095: このオプションは指定しなくても実行されます。
 8096: 
 8097: @item -r @var{tag}
 8098: @var{tag} で指定されたリビジョンを取り出します。
 8099: @end table
 8100: 
 8101: さらに (@code{checkout} と @code{export} で共通な) 
 8102: 以下のオプションも使用可能です:
 8103: 
 8104: @table @code
 8105: @item -d @var{dir}
 8106: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 8107: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8108: 
 8109: @item -k @var{subst}
 8110: キーワード置換モードを設定します (@pxref{Substitution modes})。
 8111: 
 8112: @item -N
 8113: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 8114: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8115: @end table
 8116: 
 8117: @ignore
 8118: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8119: @c @node export examples
 8120: @appendixsubsec export examples
 8121: 
 8122: Contributed examples are gratefully accepted.
 8123: @c -- Examples here!!
 8124: @end ignore
 8125: 
 8126: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8127: @node history
 8128: @appendixsec history---ファイルと使用者の状態を表示
 8129: @cindex History (subcommand)
 8130: 
 8131: @itemize @bullet
 8132: @item
 8133: 書式:     history [-report] [-flags] [-options args] [files@dots{}]
 8134: @item
 8135: 必須: ファイル @file{$CVSROOT/CVSROOT/history}
 8136: @item
 8137: 変更: なし
 8138: @end itemize
 8139: 
 8140: @sc{cvs} は、@code{checkout}, @code{commit}, @code{rtag}, 
 8141: @code{update}, @code{release} コマンドの実行履歴を、
 8142: ファイル @file{history} に記録しています。
 8143: @code{history} を使って、様々な形式で
 8144: この情報を表示することができます。
 8145: 
 8146: ログを記録したい場合は、ファイル @file{$CVSROOT/CVSROOT/history} を
 8147: 作成する必要があります。
 8148: 
 8149: @strong{警告:} @code{history} は、@samp{-f}, @samp{-l}, @samp{-n}, 
 8150: @samp{-p} を通常の @sc{cvs} コマンドで用いられるものとは
 8151: 異なる意味で使用しています (@pxref{Common options})。
 8152: 
 8153: @menu
 8154: * history options::             history のオプション
 8155: @end menu
 8156: 
 8157: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8158: @node history options
 8159: @appendixsubsec history のオプション
 8160: 
 8161: 次のオプション (コマンド書式で @samp{-report} の部分) によって、
 8162: 生成する報告の種類を決定します:
 8163: 
 8164: @table @code
 8165: @item -c
 8166: 現在までに使用された @code{commit} (つまりリポジトリの変更) 
 8167: について報告します。
 8168: 
 8169: @item -e
 8170: 全て (全記録種別) を報告します。全ての記録種別に @samp{-x} を指定する
 8171: ことと等価です。もちろん、@samp{-e} は将来のバージョンの @sc{cvs} に加
 8172: えられた記録種別も含みます。特定の記録種別だけを扱うことのできるスクリ
 8173: プトを書いているなら、@samp{-x} を指定する方が良いでしょう。
 8174: 
 8175: @item -m @var{module}
 8176: 特定のモジュールについて報告します 
 8177: (必要ならば複数の @samp{-m} をコマンド行に並べても構いません)。
 8178: 
 8179: @item -o
 8180: 取り出されたモジュールについて報告します。
 8181: 
 8182: @item -T
 8183: 全てのタグについて報告します。
 8184: 
 8185: @item -x @var{type}
 8186: 報告を受けたい記録種別の組を @var{type} に指定して、
 8187: @sc{cvs} の実行履歴から取り出します。
 8188: 種別は各々一文字で表され、これを組み合わせて指定します。
 8189: 
 8190: 以下のコマンドには、各々一つの記録種別を割り当てています:
 8191: 
 8192: @table @code
 8193: @item F
 8194: release
 8195: @item O
 8196: checkout
 8197: @item E
 8198: export
 8199: @item T
 8200: rtag
 8201: @end table
 8202: 
 8203: @noindent
 8204: 更新の結果は、以下の四つの記録種別のうちのどれかになります:
 8205: 
 8206: @table @code
 8207: @item C
 8208: マージを実行した結果、衝突が検出された場合 (手動でのマージが必要)。
 8209: @item G
 8210: マージを実行して成功した場合。
 8211: @item U
 8212: 作業ファイルがリポジトリからコピーされた場合。
 8213: @item W
 8214: (リポジトリから相当するファイルが削除されたため) 
 8215: 更新の際に作業ファイルが削除された場合。
 8216: @end table
 8217: 
 8218: @noindent
 8219: 格納の結果は、以下の三つの記録種別のうちのどれかになります:
 8220: 
 8221: @table @code
 8222: @item A
 8223: ファイルが初めて追加された場合。
 8224: @item M
 8225: ファイルが修正された場合。
 8226: @item R
 8227: ファイルが削除された場合。
 8228: @end table
 8229: @end table
 8230: 
 8231: 次のオプション (コマンド書式で @samp{-flags} の部分) によって、
 8232: 報告の範囲を限定もしくは拡大します。引数はありません:
 8233: 
 8234: @table @code
 8235: @item -a
 8236: 全ての使用者の情報を表示します 
 8237: (既定では @code{history} を実行した人物の情報のみを表示します)。
 8238: 
 8239: @item -l
 8240: 最後の変更のみを表示します。
 8241: 
 8242: @item -w
 8243: @code{history} を実行したのと同じ作業ディレクトリから行われた
 8244: 変更に関する記録のみを表示します。
 8245: @end table
 8246: 
 8247: 次のオプション (コマンド書式で @samp{-options @var{args}} の部分) は、
 8248: 引数に基づいて報告の範囲を限定します:
 8249: 
 8250: @table @code
 8251: @item -b @var{str}
 8252: モジュール名, ファイル名, リポジトリのパスのいずれかに、
 8253: 文字列 @var{str} が含まれる記録のみを表示します。
 8254: 
 8255: @item -D @var{date}
 8256: @var{date} 以降のデータを表示します。
 8257: 普通の @samp{-D @var{date}} は @var{date} 以前の
 8258: 最新リビジョンを選択しますから、少し意味が違います。
 8259: 
 8260: @item -p @var{repository}
 8261: 指定したリポジトリのデータを表示します 
 8262: (必要ならば複数の @samp{-p} をコマンド行に並べても構いません。)
 8263: 
 8264: @item -r @var{rev}
 8265: リビジョンもしくはタグを @var{rev} に指定して、
 8266: このリビジョン以降の記録を表示します。
 8267: 実行時に全ての @sc{rcs} ファイルについて @var{rev} を検索します。
 8268: 
 8269: @item -t @var{tag}
 8270: 履歴ファイルにタグ @var{tag} が
 8271: 追加された後の記録を表示します。
 8272: このオプションを指定した場合、@sc{rcs} ファイルを検索せず、
 8273: 履歴ファイルのみを参照するため、
 8274: オプション @samp{-r} の場合よりもかなり高速です。
 8275: 
 8276: @item -u @var{name}
 8277: @var{name} で指定された使用者の記録を表示します。
 8278: @end table
 8279: 
 8280: @ignore
 8281: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8282: @c @node history examples
 8283: @appendixsubsec history examples
 8284: 
 8285: Contributed examples will gratefully be accepted.
 8286: @c -- Examples here!
 8287: @end ignore
 8288: 
 8289: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8290: @node import
 8291: @appendixsec import---CVS にソースを取り込む, ベンダー枝を使用
 8292: @cindex Import (subcommand)
 8293: 
 8294: @c FIXME: This node is way too long for one which has subnodes.
 8295: 
 8296: @itemize @bullet
 8297: @item
 8298: 書式: import [-options] repository vendortag releasetag@dots{}
 8299: @item
 8300: 必須: リポジトリ, ソースの配布ディレクトリ
 8301: @item
 8302: 変更: リポジトリ
 8303: @end itemize
 8304: 
 8305: @code{import} を用いて、外部の供給元 (例えばソース・ベンダー) 
 8306: からのソース配布物全体を、自分のリポジトリに取り入れることができます。
 8307: リポジトリを最初に作成する場合と、外部の供給元がモジュールを
 8308: 大幅に更新した場合の両方でこのコマンドを用います。
 8309: この件については @xref{Tracking sources}.
 8310: 
 8311: @var{repository} には、リポジトリにするディレクトリの名前 
 8312: (もしくは、ディレクトリへのパス) を、
 8313: @sc{cvs} のルート・ディレクトリからの相対パス名で指定します。
 8314: 指定したディレクトリが存在しなくても自動的に作成されます。
 8315: 
 8316: (前回の import から) ずっと変更を加えてきたリポジトリに対し、
 8317: ソースを更新するために import を用いると、
 8318: 互いの開発系統間で衝突が発生したファイル全てが報告されます。
 8319: この時 import から具体的な指示がありますので、
 8320: それを参考にしながら @samp{checkout -j} を使って変更点を取り入れて下さい。
 8321: 
 8322: @sc{cvs} は無視するように設定されたファイルは (@pxref{cvsignore})、
 8323: 取り込まず、無視したことを示すため 
 8324: @samp{I } に続けてファイル名を表示します 
 8325: (出力に関する完全な説明は @pxref{import output})。
 8326: 
 8327: @file{$CVSROOT/CVSROOT/cvswrappers} が存在する場合、
 8328: このファイルの記述に合致するファイルやディレクトリは
 8329: 各々一括して扱われ、リポジトリに取り込まれる前に、
 8330: 適切なフィルタが適用されます。@xref{Wrappers}.
 8331: 
 8332: 外部からのソースは第一層の枝、既定だと 1.1.1 に保存されます。
 8333: 以降の更新は全てこの枝の葉となります。
 8334: 例えば最初に取り込んだソース集合のファイルは
 8335: リビジョン 1.1.1.1 になり、次の取り込みで
 8336: そのファイルが更新された場合には 1.1.1.2 となり、以下同様に続きます。
 8337: 
 8338: 少なくとも次の三つの引数を指定する必要があります。
 8339: まずソース集合を識別するために @var{repository} が必要です。
 8340: 次の @var{vendortag} は枝全体 (例えば 1.1.1) を示すタグ名です。
 8341: そして @code{import} を実行する度に作成される葉のうち、
 8342: どの葉のファイルかを識別するため、
 8343: 最低一つの @var{releasetag} を指定しなくてはいけません。
 8344: 
 8345: @c I'm not completely sure this belongs here.  But
 8346: @c we need to say it _somewhere_ reasonably obvious; it
 8347: @c is a common misconception among people first learning CVS
 8348: @code{import} はそれを起動したディレクトリを変更 @emph{しない} という
 8349: ことに注意してください。特に、ディレクトリを @sc{cvs} の作業ディレクト
 8350: リとして設定しないことに注意してください。もし作業をしたいなら、まずソー
 8351: スを取り込んで、それから違うディレクトリに取り出してください 
 8352: (@pxref{Getting the source})。
 8353: 
 8354: @menu
 8355: * import options::              import のオプション
 8356: * import output::               import の出力
 8357: * import examples::             import の使用例
 8358: @end menu
 8359: 
 8360: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8361: @node import options
 8362: @appendixsubsec import のオプション
 8363: 
 8364: @code{import} では、以下の標準オプションが利用できます 
 8365: (完全な記述は @pxref{Common options}):
 8366: 
 8367: @table @code
 8368: @item -m @var{message}
 8369: エディタを立ち上げる代りに、@var{message} をログ情報に指定します。
 8370: @end table
 8371: 
 8372: 以下のような追加の特別なオプションがあります。
 8373: 
 8374: @table @code
 8375: @item -b @var{branch}
 8376: @ref{Multiple vendor branches} 参照。
 8377: 
 8378: @item -k @var{subst}
 8379: 希望するキーワード置換モードを指定します。
 8380: この設定は、新たに取り入れる全てのファイルに適用されますが、
 8381: リポジトリに既に存在するファイルには適用されません。
 8382: @samp{-k} に使用できる設定の一覧は @ref{Substitution modes} 参照。
 8383: 
 8384: @item -I @var{name}
 8385: 取り込む際に無視するファイル名を指定します。
 8386: 無視したいファイルが複数あるときは、
 8387: このオプションを何個並べても構いません。
 8388: 全てのファイルを無視したくない場合は、
 8389: (それらは既定では無視されるとしても) `-I !' と指定して下さい。
 8390: 
 8391: @var{name} には、ファイル @file{.cvsignore} と同じ
 8392: ファイル名形式が使用できます。@xref{cvsignore}.
 8393: @c -- Is this really true?
 8394: 
 8395: @item -W @var{spec}
 8396: 取り込む際に、
 8397: フィルタを適用したいファイル名を指定します。
 8398: フィルタを適用したいファイルが複数あるときは、
 8399: このオプションを何個並べても構いません。
 8400: 
 8401: @var{spec} には、ファイル @file{.cvswrappers} と同じ
 8402: ファイル名形式が使用できます。@xref{Wrappers}.
 8403: @end table
 8404: 
 8405: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8406: @node import output
 8407: @appendixsubsec import の出力
 8408: 
 8409: @code{import} の進行状況を知らせるために、
 8410: 処理中のファイル名が一行ずつ表示され、
 8411: 行頭にはファイルの状態を示す文字が付加されます:
 8412: 
 8413: @table @code
 8414: @item U @var{file}
 8415: このファイルが既にリポジトリに存在し、かつ変更されてないことを示します。
 8416: (必要ならば) 新しいリビジョンが作成されます。
 8417: 
 8418: @item N @var{file}
 8419: このファイルが新規であり、リポジトリに追加されたことを示します。
 8420: 
 8421: @item C @var{file}
 8422: このファイルが既にリポジトリに存在し、かつ変更されていて、
 8423: マージが必要であることを示します。
 8424: 
 8425: @item I @var{file}
 8426: このファイルが無視されることを示します (@pxref{cvsignore})。
 8427: 
 8428: @cindex symbolic link, importing
 8429: @cindex link, symbolic, importing
 8430: @c FIXME: also (somewhere else) probably
 8431: @c should be documenting what happens if you "cvs add"
 8432: @c a symbolic link.  Also maybe what happens if
 8433: @c you manually create symbolic links within the
 8434: @c repository (? - not sure why we'd want to suggest
 8435: @c doing that).
 8436: @item L @var{file}
 8437: このファイルがシンボリック・リンクであることを示します。
 8438: @code{cvs import} はシンボリック・リンクを無視します。いろんな人が定期
 8439: 的にこの振舞いは変更されるべきだと提案しますが、どれに変更されるべきか
 8440: についての同意があるとすれば、それは明らかでないように思われます。
 8441: (管理用ファイル @file{modules} の各種オプションを checkout や update
 8442: 等でシンボリック・リンクを再生成するために使うことができます。
 8443: @pxref{modules}。)
 8444: @end table
 8445: 
 8446: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8447: @node import examples
 8448: @appendixsubsec import の使用例
 8449: 
 8450: @ref{Tracking sources} と @ref{From files} を参照して下さい。
 8451: 
 8452: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8453: @node log
 8454: @appendixsec log---ファイルのログ情報を表示
 8455: @cindex Log (subcommand)
 8456: 
 8457: @itemize @bullet
 8458: @item
 8459: 書式: log [options] [files@dots{}]
 8460: @item
 8461: 必須: リポジトリ, 作業ディレクトリ
 8462: @item
 8463: 変更: なし
 8464: @end itemize
 8465: 
 8466: ファイルのログ情報を表示します。以前の @code{log} は 
 8467: @sc{rcs} のコマンド @code{rlog} を呼び出していましたが、
 8468: 現在はそうではありません。しかしこのような経緯から、
 8469: このコマンドの出力やオプションは、
 8470: 他の @sc{cvs} コマンドとは異なったものになっています。
 8471: 
 8472: @cindex timezone, in output
 8473: @cindex zone, time, in output
 8474: @c Kind of a funny place to document the timezone used
 8475: @c in output from commands other than @code{log}.
 8476: @c There is also more we need to say about this,
 8477: @c including what happens in a client/server environment.
 8478: このコマンドの出力には、@sc{rcs} ファイルの所在、
 8479: @dfn{先頭}リビジョン (幹の最新リビジョン)、
 8480: 全てのタグ名などが含まれます。
 8481: 各リビジョンに対しては、リビジョン番号、格納者、
 8482: 追加/削除された行数、ログ・メッセージが表示されます。
 8483: また時間は全て協定世界時 (UTC) で表示されます。
 8484: (@sc{cvs} の他の部分では地方時間帯による時刻を表示します。)
 8485: @c FIXCVS: need a better way to control the timezone
 8486: @c used in output.  Previous/current versions of CVS did/do
 8487: @c sometimes support -z in RCSINIT, and/or an
 8488: @c undocumented (except by reference to 'rlog') -z option
 8489: @c to cvs log, but this has not been a consistent,
 8490: @c documented feature.  Perhaps a new global option,
 8491: @c where LT means the client's timezone, which the
 8492: @c client then communicates to the server, is the
 8493: @c right solution.
 8494: 
 8495: @strong{警告:} @code{log} は @samp{-R} を @sc{cvs} 普通の使用と衝突す
 8496: る方法で使います (@pxref{Common options})。
 8497: 
 8498: @menu
 8499: * log options::                 log のオプション
 8500: * log examples::                log の例
 8501: @end menu
 8502: 
 8503: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8504: @node log options
 8505: @appendixsubsec log のオプション
 8506: 
 8507: オプションを指定しなければ、@code{log} は利用できる全ての
 8508: 情報を表示します。つまりオプションは全て出力を制限するものです。
 8509: 
 8510: @table @code
 8511: @item -b
 8512: 既定の枝 (通常は幹で最も大きな番号の枝) に関する情報を表示します。
 8513: 
 8514: @item -d @var{dates}
 8515: @var{dates} に示されたリビジョンの情報を表示します。
 8516: @var{dates} には格納日時の範囲をセミコロンで区切って記述します。
 8517: 日時の表現形式は他の @sc{cvs} コマンドの 
 8518: @samp{-D} オプションと同じです (@pxref{Common options})。
 8519: それを次のように組み合わせて、格納日時の範囲を表現します:
 8520: 
 8521: @c Should we be thinking about accepting ISO8601
 8522: @c ranges?  For example "1972-09-10/1972-09-12".
 8523: @table @code
 8524: @item @var{d1}<@var{d2}
 8525: @itemx @var{d2}>@var{d1}
 8526: @var{d1} から @var{d2} までの間に格納されたリビジョンを選択します。
 8527: 
 8528: @item <@var{d}
 8529: @itemx @var{d}>
 8530: @var{d} より前に格納された全てのリビジョンを選択します。
 8531: 
 8532: @item @var{d}<
 8533: @itemx >@var{d}
 8534: @var{d} より後に格納された全てのリビジョンを選択します。
 8535: 
 8536: @item @var{d}
 8537: @var{d} 以前の最新のリビジョンを一つ選択します。
 8538: @end table
 8539: 
 8540: @samp{>} や @samp{<} の後に @samp{=} を付ければ、端を含まない
 8541: 範囲指定ではなく、端を含むような範囲指定が可能です。
 8542: 
 8543: 要素の区切りがセミコロン @samp{;} であることに注意して下さい。
 8544: 
 8545: @item -h
 8546: @sc{rcs} ファイルの名前, 作業ディレクトリのファイル名, 先頭リビジョン,
 8547: 既定の枝, 利用者一覧, ロックモード, タグ名, 拡張子を表示します。
 8548: 
 8549: @item -l
 8550: Local、つまり現在の作業ディレクトリでのみコマンドが
 8551: 実行されます。(これを指定しない場合再帰的に実行されます)。
 8552: 
 8553: @item -N
 8554: このファイルではタグ名の一覧を表示しません。
 8555: タグ名を多く使用していると、その表示だけで3ページ以上のタグ情報を 
 8556: "more" することになります。
 8557: タグ名を省略したログ情報でも構わないときは、
 8558: このオプションを指定すると便利です。
 8559: 
 8560: @item -R
 8561: @sc{rcs} ファイルの名前だけを表示します。
 8562: 
 8563: @c Note that using a bare revision (in addition to not
 8564: @c being explicitly documented here) is potentially
 8565: @c confusing; it shows the log message to get from the
 8566: @c previous revision to that revision.  "-r1.3 -r1.6"
 8567: @c (equivalent to "-r1.3,1.6") is even worse; it
 8568: @c prints the messages to get from 1.2 to 1.3 and 1.5
 8569: @c to 1.6.  By analogy with "cvs diff", users might
 8570: @c expect that it is more like specifying a range.
 8571: @c It is not 100% clear to me how much of this should
 8572: @c be documented (for example, multiple -r options
 8573: @c perhaps could/should be deprecated given the false
 8574: @c analogy with "cvs diff").
 8575: @c In general, this section should be rewritten to talk
 8576: @c about messages to get from revision rev1 to rev2,
 8577: @c rather than messages for revision rev2 (that is, the
 8578: @c messages are associated with a change not a static
 8579: @c revision and failing to make this distinction causes
 8580: @c much confusion).
 8581: @item -r@var{revisions}
 8582: @var{revisions} に示されたリビジョンの情報を表示します。
 8583: @var{revisions} にはリビジョンの範囲をカンマで区切って記述します。
 8584: 利用可能な範囲指定の書式を次に示します:
 8585: 
 8586: @table @code
 8587: @item @var{rev1}:@var{rev2}
 8588: @var{rev1} から @var{rev2} までのリビジョンを選択します (同じ枝である
 8589: 必要があります)。
 8590: 
 8591: @item :@var{rev}
 8592: 枝の最初から @var{rev} までのリビジョンを選択します。
 8593: 
 8594: @item @var{rev}:
 8595: @var{rev} から同じ枝の最後のリビジョンまでを選択します。
 8596: 
 8597: @item @var{branch}
 8598: 枝 @var{branch} にある全てのリビジョンを選択します。
 8599: 
 8600: @item @var{branch1}:@var{branch2}
 8601: この範囲内の枝にある全てのリビジョンを選択します。
 8602: 
 8603: @item @var{branch}.
 8604: 枝 @var{branch} の最新リビジョンを選択します。
 8605: @end table
 8606: 
 8607: リビジョンを指定せず @samp{-r} だけを指定した場合、
 8608: 既定の枝、通常は幹の最新リビジョンを選択します。
 8609: 従って @samp{-r} と引数との間に空白を入れないようにして下さい。
 8610: 
 8611: @item -s @var{states}
 8612: @var{states} と状態が一致するリビジョンの情報を表示します。
 8613: @var{states} にはファイルの状態をカンマで区切って記述します。
 8614: 
 8615: @item -t
 8616: @samp{-h} の情報に、ファイルの説明文を追加して表示します。
 8617: 
 8618: @item -w@var{logins}
 8619: @var{logins} に示された使用者が格納したリビジョンの情報を表示します。
 8620: @var{logins} には使用者名をカンマで区切って記述します。
 8621: @var{logins} を省略した場合、コマンドを起動した人物の
 8622: 使用者名が用いられます。
 8623: 従って @samp{-w} と引数との間に空白を入れないようにして下さい。
 8624: @end table
 8625: 
 8626: @code{log} は、オプション @samp{-d}, @samp{-s}, @samp{-w} の
 8627: 全てに適合し、かつ @samp{-b}, @samp{-r} のいずれかに適合した
 8628: リビジョンに関する情報を表示します。
 8629: 
 8630: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8631: @node log examples
 8632: @appendixsubsec log の使用例
 8633: 
 8634: 使用例を募集しています。
 8635: 
 8636: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8637: @node rdiff
 8638: @appendixsec rdiff---リリース間の `patch' 形式の差分
 8639: @cindex Rdiff (subcommand)
 8640: 
 8641: @itemize @bullet
 8642: @item
 8643: 書式: rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules@dots{}
 8644: @item
 8645: 必須: リポジトリ
 8646: @item
 8647: 変更: なし
 8648: @item
 8649: 別名: patch
 8650: @end itemize
 8651: 
 8652: 二つのリリース間の差分を、
 8653: Larry Wall の @samp{patch(1)} ファイル形式で生成します。
 8654: この出力を直接 @code{patch} プログラムに食わせて、
 8655: 古いリリースを新しいリリースに更新できます。
 8656: (これは作業ディレクトリを必要とせず、直接リポジトリを操作する
 8657: 数少ない @sc{cvs} コマンドの一つです。) 
 8658: このコマンドの実行結果は標準出力に送られます。
 8659: 
 8660: 一つないし二つのリビジョンか日付の組み合わせを 
 8661: (標準オプション @samp{-r} や @samp{-D} を用いて) 
 8662: 指定することができます。
 8663: リビジョンか日付を一つだけ指定した場合、
 8664: 指定したものと @sc{rcs} ファイルの先頭リビジョンとの差分が
 8665: パッチ・ファイルとして出力されます。
 8666: 
 8667: ソフトウェア配布物が複数のディレクトリから構成される場合、
 8668: 別のディレクトリに置かれた古いソースを参照するために、
 8669: @code{patch} コマンドにオプション @samp{-p} を
 8670: 指定する必要があるかも知れません。
 8671: 
 8672: @menu
 8673: * rdiff options::               rdiff のオプション
 8674: * rdiff examples::              rdiff の使用例
 8675: @end menu
 8676: 
 8677: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8678: @node rdiff options
 8679: @appendixsubsec rdiff のオプション
 8680: 
 8681: @code{rdiff} では、以下の標準オプションが利用できます 
 8682: (完全な記述は @pxref{Common options}):
 8683: 
 8684: @table @code
 8685: @item -D @var{date}
 8686: @var{date} 以前の最も新しいリビジョンを利用します。
 8687: 
 8688: @item -f
 8689: 指定したリビジョンが見付からなかった場合、
 8690: (そのファイルを無視せずに) 最も新しいリビションを用います。
 8691: 
 8692: @item -l
 8693: Local、つまり現在の作業ディレクトリでのみコマンドが
 8694: 実行されます。
 8695: 
 8696: @item -R
 8697: ディレクトリを再帰的に検査します。
 8698: このオプションは指定しなくても実行されます。
 8699: 
 8700: @item -r @var{tag}
 8701: @var{tag} で指定されたリビジョンを用います。
 8702: @end table
 8703: 
 8704: さらに以下のオプションも使用可能です:
 8705: 
 8706: @table @code
 8707: @item -c
 8708: Context 形式で出力します。
 8709: これが既定形式なので指定する必要はありません。
 8710: 
 8711: @item -s
 8712: パッチの代りに変更要旨だけが報告されます。
 8713: 指定したリリース間で変更されたり追加されたファイルの情報が
 8714: 標準出力に送られます。
 8715: これは例えば、二つの日付やリビジョン間で変更された
 8716: ファイルを一覧するのに便利です。
 8717: 
 8718: @item -t
 8719: 先頭にある二つのリビジョン間の差分を標準出力に送ります。
 8720: これは、そのファイルの最新の変更点を見るときに使います。
 8721: 
 8722: @item -u
 8723: Context 形式ではなく、unidiff 形式を用います。
 8724: 使用する @code{diff} が unidiff 形式を出力できない場合、
 8725: このオプションは利用できません。
 8726: 古いバージョンの @code{patch} プログラムは unidiff 形式を扱えないので、
 8727: パッチをネットに投稿するつもりならば、
 8728: @samp{-u} を使用しない方が賢明でしょう。
 8729: 
 8730: @item -V @var{vn}
 8731: @sc{rcs} のバージョン @var{vn} における展開方法に従って、
 8732:  キーワードを展開します 
 8733: (@sc{rcs} のバージョン 5 で展開方法が変更されました)。
 8734: このオプションはもう使用できないことに注意してください。
 8735: CVS は @sc{rcs} バージョン 5 がするように常にキーワードを展開します。
 8736: @end table
 8737: 
 8738: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8739: @node rdiff examples
 8740: @appendixsubsec rdiff の使用例
 8741: 
 8742: @t{foo@@bar.com} から、
 8743: コンパイラ @samp{tc} をリリース 1.2 から 1.4 へ更新したい、
 8744: というメールを受け取ったと仮定します。
 8745: 手元にそんなパッチがない場合でも、
 8746: @sc{cvs} なら次のようなコマンドを使って簡単に対応できます:
 8747: 
 8748: @example
 8749: $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
 8750: $$ Mail -s 'The patches you asked for' foo@@bar.com
 8751: @end example
 8752: 
 8753: リリース 1.3 のバグ修正用に枝 @samp{R_1_3fix} を作成し、
 8754: 修正後のリリース 1.3.1 にタグ @samp{R_1_3_1} を付けたと仮定します。
 8755: この枝に対して、修正版以降に加えられた開発の概略を知りたい場合は、
 8756: 次のようなコマンドを使います:
 8757: 
 8758: @example
 8759: $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
 8760: cvs rdiff: Diffing module-name
 8761: File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
 8762: File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
 8763: File bar.h,v changed from revision 1.29.2.1 to 1.2
 8764: @end example
 8765: 
 8766: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8767: @node release
 8768: @appendixsec release---モジュールの放棄を表明する
 8769: @cindex Release (subcommand)
 8770: 
 8771: @itemize @bullet
 8772: @item
 8773: 書式: release [-d] directories@dots{}
 8774: @item
 8775: 必須: 作業ディレクトリ
 8776: @item
 8777: 変更: 作業ディレクトリ, history のログ情報
 8778: @end itemize
 8779: 
 8780: このコマンドは @samp{cvs checkout} の効果を安全に消し去ります。
 8781: @sc{cvs} はファイルをロックしないため、
 8782: このコマンドが絶対に必要なわけではありません。
 8783: 作業ディレクトリを単に削除したいなら、それでも構いません。
 8784: ただしこの場合、うっかりすると変更内容を失う恐れがあります。
 8785: またファイル @file{history} (@pxref{history file}) にも、
 8786: 作業ディレクトリを放棄したという情報が残りません。
 8787: 
 8788: これらの問題を避けるためにも @samp{cvs release} を使用して下さい。
 8789: このコマンドは、未格納の変更点が残ってないかどうか調べます。
 8790: 次に @sc{cvs} の作業ディレクトリのすぐ上で実行しているかどうか調べます。
 8791: さらに作業ディレクトリに記録されたリポジトリが、
 8792: モジュールに定義されているリポジトリと等しいかどうか調べます。
 8793: 
 8794: 上記全ての条件が満たされた場合にだけ、
 8795: (作業ディレクトリを故意に放棄した証拠として) 
 8796: @sc{cvs} の履歴ログ に @samp{cvs release} の実行記録が残されます。
 8797: 
 8798: @menu
 8799: * release options::             release のオプション
 8800: * release output::              release の出力
 8801: * release examples::            release の使用例
 8802: @end menu
 8803: 
 8804: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8805: @node release options
 8806: @appendixsubsec release のオプション
 8807: 
 8808: @code{release} ではオプションが一つだけ利用できます:
 8809: 
 8810: @table @code
 8811: @item -d
 8812: 放棄判定に成功したとき、作業ディレクトリを削除します。
 8813: このフラグを指定しない場合、
 8814: 作業ディレクトリはそのまま残されます。
 8815: 
 8816: @strong{警告:}  @code{release} コマンドは
 8817: 全てのディレクトリとファイルを再帰的に削除していきます。
 8818: これには重篤な副作用があり、作業ディレクトリに作成したけれど、
 8819: リポジトリには追加してないディレクトリ全てが、
 8820: (@code{add} コマンド使って。@pxref{Adding files})
 8821: 何の表示も無く削除されます---その中身が空でなくても!
 8822: @end table
 8823: 
 8824: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8825: @node release output
 8826: @appendixsubsec release の出力
 8827: 
 8828: @code{release} によって作業ディレクトリを放棄する前に、
 8829: 最新でないファイルそれぞれについて一行ずつ状態を表示します。
 8830: 
 8831: @strong{警告:}  作成はしたけれど、@code{add} コマンドを用いて 
 8832: (@pxref{Adding files}) @sc{cvs} のディレクトリ階層に
 8833: 加えてないディレクトリは、全て中身があっても完全に無視され 
 8834: (@samp{-d} が指定されていれば削除され) ます。
 8835: @c FIXCVS: This is a bug.  But is it true?  I think
 8836: @c maybe they print "? dir" now.
 8837: 
 8838: @table @code
 8839: @item U @var{file}
 8840: @itemx P @var{file}
 8841: より新しいリビジョンがリポジトリに存在し、
 8842: かつ作業ファイルが編集されてないことを示します。
 8843: (@samp{U} と @samp{P} は同じです。)
 8844: 
 8845: @item A @var{file}
 8846: 作業ディレクトリにファイルが追加されたけれど、
 8847: まだリポジトリには格納されてないことを示します。
 8848: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 8849: 
 8850: @item R @var{file}
 8851: 作業ファイルは削除されているけれど、まだこの変更が格納されてないため、
 8852: リポジトリからは削除されてないことを示します。@xref{commit}.
 8853: 
 8854: @item M @var{file}
 8855: 作業ディレクトでファイルが修正されています。リポジトリにも新しいリビジョ
 8856: ンがあるかもしれません。
 8857: 
 8858: @item ? @var{file}
 8859: 作業ディレクトリに @var{file} というファイルがあるが、
 8860: リポジトリには対応するファイルが無く、
 8861: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 8862: (@samp{-I} オプションの説明の参照と、@pxref{cvsignore})。
 8863: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 8864: @end table
 8865: 
 8866: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8867: @node release examples
 8868: @appendixsubsec release の使用例
 8869: 
 8870: モジュールの放棄判定をしてから作業ディレクトリを削除します。
 8871: 
 8872: @example
 8873: $ cd ..         # @r{@samp{cvs release} は作業ディレクトリの}
 8874:                 # @r{すぐ上で実行しなくてはいけません。}
 8875: $ cvs release -d tc
 8876: You have [0] altered files in this repository.
 8877: Are you sure you want to release (and delete) module `tc': y
 8878: $
 8879: @end example
 8880: 
 8881: @node rtag
 8882: @appendixsec rtag---モジュールにタグ名を付ける
 8883: @cindex Rtag (subcommand)
 8884: 
 8885: @itemize @bullet
 8886: @item
 8887: 書式: rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules@dots{}
 8888: @item
 8889: 必須: リポジトリ
 8890: @item
 8891: 変更: リポジトリ
 8892: @item
 8893: 別名: rfreeze
 8894: @end itemize
 8895: 
 8896: このコマンドは、
 8897: 明示的に指定した特定のリビジョンにタグ名を付けます。
 8898: @code{rtag} は、リポジトリに対して直接作用します 
 8899: (作業ディレクトリは不必要)。
 8900: 作業ディレクトリのリビジョンにタグ名を付けたい場合は、
 8901: 代りに @code{tag} を用いて下さい (@pxref{tag})。
 8902: 
 8903: 既存のタグ名を指定した場合、エラー・メッセージが表示され、
 8904: タグ名は上書きされません。
 8905: 既存のタグ名を無理矢理使うにはオプション @samp{-F} を用いて下さい。
 8906: 
 8907: @menu
 8908: * rtag options::                rtag のオプション
 8909: @end menu
 8910: 
 8911: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8912: @node rtag options
 8913: @appendixsubsec rtag のオプション
 8914: 
 8915: @code{rtag} では、以下の標準オプションが利用できます 
 8916: (完全な記述は @xref{Common options}.):
 8917: 
 8918: @table @code
 8919: @item -D @var{date}
 8920: @var{date} 以前の最も新しいリビジョンにタグを付けます。
 8921: 
 8922: @item -f
 8923: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 8924: 指定したリビジョンが見付からなかった場合、
 8925: (そのファイルを無視せずに) 最も新しいリビションを用います。
 8926: 
 8927: @item -F
 8928: 既存のタグ名に、前と違うリビジョンを上書きします。
 8929: @c FIXME: Needs an example, and/or more explanation.
 8930: @c Also needs to contrast this with the behavior if -F
 8931: @c is not specified, and the description needs to be
 8932: @c moved somewhere where it is shared between "tag" and
 8933: @c "rtag" (probably some sub-node of Revisions and
 8934: @c branches).  Also should be clear about whether this
 8935: @c applies to branch tags, non-branch tags, or both.
 8936: @c Also this is *not* a common option.
 8937: 
 8938: @item -l
 8939: Local、つまり現在の作業ディレクトリでのみコマンドが
 8940: 実行されます。
 8941: 
 8942: @item -n
 8943: @code{rtag} を用いたとき、通常は実行されるプログラムを実行しません。
 8944: このプログラムは管理用ファイル @file{modules} の
 8945: オプション @samp{-t} で指定されます (@pxref{modules})。
 8946: 
 8947: @item -R
 8948: 再帰的にタグを付けます。
 8949: このオプションは指定しなくても実行されます。
 8950: 
 8951: @c FIXME: this discussion is confusing.  What part of
 8952: @c the rename operation being discussed relates to
 8953: @c "rtag -r" (that whole discussion needs an example,
 8954: @c and probably to be moved somewhere else)?
 8955: @item -r @var{tag}
 8956: @var{tag} を含むファイルだけにタグを付けます。
 8957: これはタグを改名するのに便利です。
 8958: まず古いタグを持つファイルだけにタグを付け、そして古いタグを削除します。
 8959: これで古いタグと全く同じファイルに新しいタグ名が付きます。
 8960: @end table
 8961: 
 8962: 上記の共通オプションに加えて、
 8963: 次のオプションも使用可能です:
 8964: 
 8965: @table @code
 8966: @item -a
 8967: @c FIXME: What does this option mean in terms of user
 8968: @c concepts, not CVS internals?
 8969: オプション @samp{-a} を使うと、@code{rtag} は
 8970: 削除されたファイルに指定したタグが含まれるか調べるため、
 8971: @file{Attic} (@pxref{Removing files}) の中身も検索します。
 8972: 将来の開発のため、一旦タグを削除して再利用したい場合に使用します。
 8973: (これ以降は、配布物からこれらのファイルが削除されます)。
 8974: 
 8975: @item -b
 8976: 枝を作成してタグ名を付けます。 @xref{Branching and merging}.
 8977: 
 8978: @item -d
 8979: タグを付けずに削除します。
 8980: 
 8981: 通常は、(たいていはソフトウェア配布物を特定するために付けられる) 
 8982: タグ名を削除すべきではありません。
 8983: しかし絶対に使用されないタグ名 (例えばα版とか
 8984: 間違って付けたタグとか) を削除するために、
 8985: 一応オプション @samp{-d} が用意されています。
 8986: @end table
 8987: 
 8988: @ignore
 8989: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8990: @c @node rtag examples
 8991: @appendixsubsec rtag examples
 8992: 
 8993: @c -- Examples here!
 8994: @end ignore
 8995: 
 8996: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8997: @node tag
 8998: @appendixsec tag---取り出したバージョンにタグ名を付ける
 8999: @c --                    //////// - unnecessary. Also
 9000: @c --                               in a lot of other
 9001: @c --                               places.
 9002: @cindex Tag (subcommand)
 9003: 
 9004: @itemize @bullet
 9005: @item
 9006: 書式: tag [-lR] [-b] [-c] [-d] symbolic_tag [files@dots{}]
 9007: @item
 9008: 必須: 作業ディレクトリ, リポジトリ
 9009: @item
 9010: 変更: リポジトリ
 9011: @item
 9012: 別名: freeze
 9013: @end itemize
 9014: 
 9015: このコマンドは、あなたの作業コピーの由来となった
 9016: リポジトリのバージョンにタグ名を付けます。
 9017: @code{rtag} と同じくリポジトリに直接作用しますが、
 9018: タグを付けるバージョンは明示的に指定されず、
 9019: @sc{cvs} の記録から各作業ファイルの出自を参照して補います。
 9020: 
 9021: タグの主な用途は、ソフトウェアの凍結日における
 9022: ソースのスナップショットを記録することです。
 9023: その凍結日以降にバグを修正したような場合、
 9024: 修正後のソースに再度タグを付ける必要があります。
 9025: 
 9026: タグ名は、あるソフトウェア配布物の作成に使用したファイルとリビジョンを、
 9027: いつまでも記憶しておくために使われます。
 9028: タグを付けた後にファイルが変更されたり追加されたり削除されても、
 9029: @code{checkout} や @code{update} コマンドを用いれば、
 9030: 将来のいつでも、タグを付けた時と全く同じコピーを復元できます。
 9031: 
 9032: また、このコマンドは
 9033: タグ名の削除や枝の作成にも用いられます。
 9034: 後述するオプションの項を参照して下さい。
 9035: 
 9036: 既存のタグ名を指定した場合、エラー・メッセージが表示され、
 9037: タグ名は上書きされません。
 9038: 既存のタグ名を無理矢理使うにはオプション @samp{-F} を用いて下さい。
 9039: 
 9040: 
 9041: @menu
 9042: * tag options::                 tag のオプション
 9043: @end menu
 9044: 
 9045: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9046: @node tag options
 9047: @appendixsubsec tag のオプション
 9048: 
 9049: @code{tag} では、以下の標準オプションが利用できます 
 9050: (完全な記述は @pxref{Common options}):
 9051: 
 9052: @table @code
 9053: @cindex renaming tags
 9054: @cindex tags, renaming
 9055: @cindex moving tags
 9056: @c FIXME: Where does this talk about renaming tags?
 9057: @c And what about rtag?  This needs to be moved to
 9058: @c the body of the manual.
 9059: @c Also see:
 9060: @c  "How do I move or rename a magic branch tag?"
 9061: @c in the FAQ (I think the issues it talks about still
 9062: @c apply, but this could use some sanity.sh work).
 9063: @item -F
 9064: 既存のタグ名に、前と違うリビジョンを上書きします。
 9065: @c FIXME: See "rtag -F" for comments on this.
 9066: 
 9067: @item -l
 9068: Local、つまり現在の作業ディレクトリでのみコマンドが
 9069: 実行されます。
 9070: 
 9071: @item -R
 9072: ディレクトリを再帰的にタグ付けします。
 9073: このオプションは指定しなくても実行されます。
 9074: @end table
 9075: 
 9076: さらに二つの固有オプションが使用可能です:
 9077: 
 9078: @table @code
 9079: @item -b
 9080: 別々の開発を同時に行なうため、
 9081: 枝を作成してタグを付けます (@pxref{Branching and merging})。
 9082: このオプションは、既に配布済のソフトウェアに対して
 9083: パッチを作成したいときにとても便利です。
 9084: 
 9085: @item -c
 9086: オプション @samp{-c} は、
 9087: タグを付けるファイル全てが無修正かどうかを確認します。
 9088: 現在のファイルの内容が完全に復元できることを保証したい場合に使用します。
 9089: 
 9090: @item -d
 9091: タグを削除します。
 9092: 
 9093: @samp{cvs tag -d symbolic_tag} を用いると、
 9094: 指定したタグ名は追加されずに削除されます。
 9095: 警告: タグを削除する前に、その妥当性を何度も慎重に確かめて下さい。
 9096: このコマンドにより履歴情報の一部が永久に失われ、
 9097: 後から必要になっても復元する方法はありません。
 9098: @end table
 9099: 
 9100: @ignore
 9101: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9102: @c @node tag examples
 9103: @appendixsubsec tag examples
 9104: 
 9105: @c -- FIXME
 9106: @end ignore
 9107: 
 9108: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 9109: @node update
 9110: @appendixsec update---作業コピーをリポジトリと一致させる
 9111: @cindex Update (subcommand)
 9112: 
 9113: @itemize @bullet
 9114: @item
 9115: 書式: update [-AdflPpR] [-d] [-r tag|-D date] files@dots{}
 9116: @item
 9117: 必須: リポジトリ, 作業ディレクトリ
 9118: @item
 9119: 変更: 作業ディレクトリ
 9120: @end itemize
 9121: 
 9122: 共有するリポジトリから作業コピーを取り出した後でも、
 9123: 他の開発者はリポジトリのソースを変更し続けるでしょう。
 9124: 開発工程の然るべき時に @code{update} コマンドを使えば、
 9125: 最後の @code{checkout} や @code{update} 以降の、
 9126: どのリビジョンでも取り入れることができます。
 9127: 
 9128: @menu
 9129: * update options::              update のオプション
 9130: * update output::               update の出力
 9131: @end menu
 9132: 
 9133: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9134: @node update options
 9135: @appendixsubsec update のオプション
 9136: 
 9137: @code{update} では、以下の標準オプションが利用できます 
 9138: (完全な記述は @pxref{Common options}):
 9139: 
 9140: @table @code
 9141: @item -D date
 9142: @var{date} 以前の最も新しいリビジョンを利用します。
 9143: このオプションは貼り付けられ、
 9144: 勝手に @samp{-P} オプションも実行されます。
 9145: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9146: 
 9147: @item -f
 9148: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 9149: 指定したリビジョンが見付からなかった場合、
 9150: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 9151: 
 9152: @item -k @var{kflag}
 9153: キーワード置換モードを @var{kflag} に指定します。
 9154: 詳細は @ref{Substitution modes} を参照。
 9155: このオプションは貼り付けられます。つまりこれ以後、
 9156: この作業ディレクトリでファイルが更新されるときには、
 9157: 同じ @var{kflag} が使用され続けます。
 9158: @code{status} コマンドを用いて
 9159: 貼り付いたオプションを見ることができます。
 9160: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 9161: 
 9162: @item -l
 9163: Local、つまり現在の作業ディレクトリでのみコマンドが
 9164: 実行されます。@xref{Recursive behavior}.
 9165: 
 9166: @item -P
 9167: 空になったディレクトリを削除 (prune) します。
 9168: @ref{Moving directories} 参照。
 9169: 
 9170: @item -p
 9171: ファイルを標準出力に送り (pipe) ます。
 9172: 
 9173: @item -R
 9174: ディレクトリを再帰的に更新します (既定)。@xref{Recursive behavior}.
 9175: 
 9176: @item -r rev
 9177: @var{tag} で指定されたリビジョン/タグを取り出します。
 9178: このオプションは貼り付けられ、
 9179: @samp{-P} オプションも勝手に実行されます。
 9180: 貼り付いたタグ/日付についての詳細は @pxref{Sticky tags}.
 9181: @end table
 9182: 
 9183: @need 800
 9184: さらに @code{update} では次の固有オプションも使用可能です。
 9185: 
 9186: @table @code
 9187: @item -A
 9188: 貼り付いた全てのタグや日付、
 9189: また @samp{-k} オプションの指定を剥がします。
 9190: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9191: 
 9192: @item -d
 9193: リポジトリに存在し、
 9194: 作業ディレクトリに無いディレクトリを作成します。
 9195: 通常は作業ディレクトリに既に存在するものだけが、
 9196: @code{update} の対象となります。
 9197: 
 9198: 最初に @code{checkout} した後にリポジトリに作成された、
 9199: 新たなディレクトリを取り出すときに使用します。
 9200: しかし残念なことに副作用があります。
 9201: 作業ディレクトリを作成するときに、
 9202: (モジュール名を利用したり、
 9203: コマンド行で望みのファイルやディレクトリを明示したりして) 
 9204: 特定のディレクトリを故意に避けていた場合、
 9205: @samp{-d} を使用すると余計なディレクトリまで作成されてしまいます。
 9206: 
 9207: @item -I @var{name}
 9208: @code{update} の際に、
 9209: @var{name} と一致するファイル名が無視されます。
 9210: 無視したいファイルが複数あるときは、
 9211: コマンド行に @samp{-I} を必要なだけ並べても構いません。
 9212: 全てのファイルを無視したくない場合は、
 9213: @samp{-I !} と指定して下さい。
 9214: @sc{cvs} にファイルを無視させる他の方法は @xref{cvsignore}.
 9215: 
 9216: @item -W@var{spec}
 9217: @code{update} の際に、
 9218: フィルタを掛けるべきファイル名を指定します。
 9219: このオプションは繰り返し利用することができます。
 9220: 
 9221: @file{.cvswrappers} と同じ形式を用いて、
 9222: @var{spec} にファイル名を指定します。@xref{Wrappers}.
 9223: 
 9224: @item -j@var{revision}
 9225: @samp{-j} オプションを二つ指定した場合、
 9226: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 9227: 作業ディレクトリにマージします。
 9228: 
 9229: @samp{-j} オプションが一つの場合、
 9230: その分岐リビジョンから指定したリビジョンへの変更を、
 9231: 作業ディレクトリにマージします。
 9232: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 9233: @samp{-j} で指定したリビジョンとの共通の祖先です。
 9234: 
 9235: @samp{-j} オプションに枝を指定する場合、
 9236: 日付の指定を付加することができます。
 9237: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 9238: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 9239: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 9240: 
 9241: @xref{Branching and merging}.
 9242: 
 9243: @end table
 9244: 
 9245: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9246: @node update output
 9247: @appendixsubsec update の出力
 9248: 
 9249: @code{update} や @code{checkout} の進行状況を知らせるために、
 9250: 処理中のファイル名が一行ずつ表示され、
 9251: 行頭にはファイルの状態を示す文字が付加されます:
 9252: 
 9253: @table @code
 9254: @item U @var{file}
 9255: リポジトリと一致するようにファイルが更新されたことを示します。
 9256: リポジトリに存在するファイルが作業ディレクトリに無かった場合や、
 9257: 修正していない作業コピーよりも新しいバージョンが
 9258: リポジトリに格納されていた場合の処理です。
 9259: 
 9260: @item P @var{file}
 9261: @samp{U} と同様ですが、@sc{cvs} サーバはファイル全体ではなく、パッチを
 9262: 送ります。2つ共結果は同じです。
 9263: 
 9264: @item A @var{file}
 9265: 作業ディレクトリにファイルが加えられ、それをリポジトリに
 9266: 反映するために @samp{commit} の実行が必要な状態を示します。
 9267: つまりファイルの格納を忘れないように注意を促しています。
 9268: 
 9269: @item R @var{file}
 9270: 作業ディレクトリからファイルが削除され、それをリポジトリに
 9271: 反映するために @samp{commit} の実行が必要な状態を示します。
 9272: つまりファイルの格納を忘れないように注意を促しています。
 9273: 
 9274: @item M @var{file}
 9275: 作業ディレクトリで修正されたファイルであることを示します。
 9276: 
 9277: @samp{M} は、ファイルに対する次の二つの修正状態のうちの一方を示します。
 9278: 一つ目は、リポジトリの当該ファイルが修正されていないため、
 9279: このファイルはあなたが最後に見たときと同じ状態にある場合です。
 9280: 二つ目は、作業コピーと同様に、
 9281: リポジトリの当該ファイルも修正されていたため、
 9282: これらを作業ディレクトリでマージした結果、
 9283: 衝突することなく正常に処理された場合です。
 9284: 
 9285: ファイルのマージが行われるとその旨が表示され、
 9286: (@code{update} が実行される前と同じ内容の) 
 9287: 作業ファイルのバックアップ・コピーが生成されます。
 9288: @code{update} の実行中にそのファイルの名前もちゃんと表示されます。
 9289: 
 9290: @item C @var{file}
 9291: @cindex .# files
 9292: @cindex __ files (VMS)
 9293: @var{file} の作業コピーへの変更とリポジトリでの変更をマージした際に、
 9294: 衝突が見つかったことを示します。
 9295: @var{file} (作業コピー) は
 9296: 2つのリビジョンをマージしようとした結果に置き換えられ、
 9297: 元のファイルは @file{.#@var{file}.@var{revision}} という名前で、
 9298: 作業ディレクトリに保存されます。ここで @var{revision} は、
 9299: ファイルの修正を開始した時点での @sc{rcs} 
 9300: リビジョンです。@ref{Conflicts example} の説明を参考にして
 9301: 衝突を解決して下さい。
 9302: @c "some systems" as in out-of-the-box OSes?  Not as
 9303: @c far as I know.  We need to advise sysadmins as well
 9304: @c as users how to set up this kind of purge, if that is
 9305: @c what they want.
 9306: @c We also might want to think about cleaner solutions,
 9307: @c like having CVS remove the .# file once the conflict
 9308: @c has been resolved or something like that.
 9309: (@file{.#} で始まるファイルを数日間利用しなかった場合、
 9310: 自動的に削除するシステムがあることに注意して下さい。
 9311: 元のファイルを保存したい場合は名前を変更すると良いでしょう。) 
 9312: @sc{vms} ではファイル名の先頭に、
 9313: @file{.#} ではなく @file{__} を使用します。
 9314: 
 9315: @item ? @var{file}
 9316: 作業ディレクトリに @var{file} というファイルがあるけれど、
 9317: リポジトリには対応するファイルが無く、
 9318: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 9319: (@samp{-I} オプションの説明及び @pxref{cvsignore} を参照)。
 9320: @end table
 9321: 
 9322: @node Invoking CVS
 9323: @appendix CVS コマンドの簡単な便覧
 9324: @cindex Command reference
 9325: @cindex Reference, commands
 9326: @cindex Invoking CVS
 9327: 
 9328: この付録は、それぞれのコマンドや機能が詳しく説明されているところへの参
 9329: 照とともに、@sc{cvs} の実行のしかたを説明します。他の参照は、@code{cvs
 9330: --help} コマンドを実行するか、@ref{Index} を参照してください。
 9331: 
 9332: @sc{cvs} コマンドは以下の様になります:
 9333: 
 9334: @example
 9335: cvs [ @var{global_options} ] @var{command} [ @var{command_options} ] [ @var{command_args} ]
 9336: @end example
 9337: 
 9338: 標準オプション:
 9339: 
 9340: @table @code
 9341: @item --allow-root=@var{rootdir}
 9342: 正しい @sc{cvsroot} ディレクトリを指定します (サーバのみ) (@sc{cvs} 
 9343: 1.9 以前にはありません)。 @ref{Password authentication server} 参照。
 9344: 
 9345: @item -a
 9346: 全ての通信を認証します (クライアントのみ) (@sc{cvs} 1.9 以前にはありま
 9347: せん)。@ref{Global options} 参照。
 9348: 
 9349: @item -b
 9350: RCS の位置を指定します (@sc{cvs} 1.9 以前)。@ref{Global options} 参照。
 9351: 
 9352: @item -d @var{root}
 9353: @sc{cvsroot} を指定します。@ref{Repository} 参照。
 9354: 
 9355: @item -e @var{editor}
 9356: @var{editor} でメッセージを編集します。@ref{Committing your changes} 
 9357: 参照。
 9358: 
 9359: @item -f
 9360: @file{~/.cvsrc} ファイルを読み込みません。@ref{Global options} 参照。
 9361: 
 9362: @item -H
 9363: @itemx --help
 9364: ヘルプメッセージを印字します。@ref{Global options} 参照。
 9365: 
 9366: @item -l
 9367: CVSROOT/history ファイルにログを残しません。@ref{Global options} 参照。
 9368: 
 9369: @item -n
 9370: どのファイルも変更しません。@ref{Global options} 参照。
 9371: 
 9372: @item -Q
 9373: 本当に出力を抑えます。@ref{Global options} 参照。
 9374: 
 9375: @item -q
 9376: 少しばかり出力を抑えます。@ref{Global options} 参照。
 9377: 
 9378: @item -r
 9379: 新しい作業ファイルを読み込み専用にします。@ref{Global options} 参照。
 9380: 
 9381: @item -s @var{variable}=@var{value}
 9382: 使用者変数を設定します。@ref{Variables} 参照。
 9383: 
 9384: @item -T @var{tempdir}
 9385: 一時ファイルを @var{tempdir} に置きます。@ref{Global options} 参照。
 9386: 
 9387: @item -t
 9388: @sc{cvs} の実行を追跡します。@ref{Global options} 参照。
 9389: 
 9390: @item -v
 9391: @item --version
 9392: @sc{cvs} のバージョンと著作権情報を表示します。
 9393: 
 9394: @item -w
 9395: 新しいファイルを読み込み書き込み可にします。@ref{Global options} 参照。
 9396: 
 9397: @item -x
 9398: 全ての通信を暗号化します (クライアントのみ)。@ref{Global options} 参照。
 9399: 
 9400: @item -z @var{gzip-level}
 9401: 圧縮の度合を設定します (クライアントのみ)。
 9402: @c FIXME: what are the valid values for gzip-level.
 9403: @c And shouldn't this be documented in at least a
 9404: @c little bit of detail somewhere?
 9405: 
 9406: @end table
 9407: 
 9408: キーワード展開モード (@pxref{Substitution modes}):
 9409: 
 9410: @example
 9411: -kkv  $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
 9412: -kkvl $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9413: -kk   $@asis{}Id$
 9414: -kv   file1,v 1.1 1993/12/09 03:21:13 joe Exp
 9415: -ko   @i{非展開}
 9416: -kb   @i{非展開、ファイルはバイナリ}
 9417: @end example
 9418: 
 9419: キーワード (@pxref{Keyword list}):
 9420: 
 9421: @example
 9422: $@asis{}Author: joe $
 9423: $@asis{}Date: 1993/12/09 03:21:13 $
 9424: $@asis{}Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9425: $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9426: $@asis{}Locker: harry $
 9427: $@asis{}Name: snapshot_1_14 $
 9428: $@asis{}RCSfile: file1,v $
 9429: $@asis{}Revision: 1.1 $
 9430: $@asis{}Source: /home/files/file1,v $
 9431: $@asis{}State: Exp $
 9432: $@asis{}Log: file1,v $
 9433: Revision 1.1  1993/12/09 03:30:17  joe
 9434: Initial revision
 9435: 
 9436: @end example
 9437: 
 9438: @c The idea behind this table is that we want each item
 9439: @c to be a sentence or two at most.  Preferably a
 9440: @c single line.
 9441: @c
 9442: @c In some cases refs to "foo options" are just to get
 9443: @c this thing written quickly, not because the "foo
 9444: @c options" node is really the best place to point.
 9445: コマンド、コマンドのオプション、コマンドの引数:
 9446: 
 9447: @table @code
 9448: @item add [@var{options}] [@var{files}@dots{}]
 9449: 新しいファイル/ディレクトリを加えます。@ref{Adding files} 参照。
 9450: 
 9451: @table @code
 9452: @item -k @var{kflag}
 9453: キーワード展開を設定します。
 9454: 
 9455: @item -m @var{msg}
 9456: ファイルの説明を設定します。
 9457: @end table
 9458: 
 9459: @item admin [@var{options}] [@var{files}@dots{}]
 9460: リポジトリの履歴ファイルの管理です。@ref{admin} 参照。
 9461: @c This list omits those options which are not
 9462: @c documented as being useful with CVS.  That might be
 9463: @c a mistake...
 9464: 
 9465: @table @code
 9466: @item -b[@var{rev}]
 9467: 既定枝を設定します。@ref{Reverting local changes} 参照。
 9468: 
 9469: @item -c@var{string}
 9470: 註釈符を設定します。
 9471: 
 9472: @item -k@var{subst}
 9473: キーワード置換を設定します。@ref{Keyword substitution} 参照。
 9474: 
 9475: @item -l[@var{rev}]
 9476: @var{rev} か、最新のリビジョンをロックします。
 9477: 
 9478: @item -m@var{rev}:@var{msg}
 9479: リビジョン @var{rev} のログメッセージを @var{msg} で置換します。
 9480: 
 9481: @item -o@var{range}
 9482: リポジトリからリビジョンを消去します。@ref{admin options} 参照。
 9483: 
 9484: @item -q
 9485: 静かに実行します。診断情報を印字しません。
 9486: 
 9487: @item -s@var{state}[:@var{rev}]
 9488: 状態を設定します。
 9489: 
 9490: @c Does not work for client/server CVS
 9491: @item -t
 9492: 標準入力からファイルの説明を設定します。
 9493: 
 9494: @item -t@var{file}
 9495: ファイルの説明を @var{file} から設定します。
 9496: 
 9497: @item -t-@var{string}
 9498: ファイルの説明を @var{string} にします。
 9499: 
 9500: @item -u[@var{rev}]
 9501: リビジョン @var{rev} か、最新のリビジョンのロックを外します。
 9502: @end table
 9503: 
 9504: @item annotate [@var{options}] [@var{files}@dots{}]
 9505: それぞれの行が修正された最新のリビジョンを表示します。@ref{annotate}
 9506: 参照。
 9507: 
 9508: @table @code
 9509: @item -D @var{date}
 9510: @var{date} 以前で一番新しいリビジョンを annotate します。@ref{Common
 9511: options} 参照。
 9512: 
 9513: @item -f
 9514: タグ/日付が見つからない場合は先頭のリビジョンを使います。@ref{Common
 9515: options} 参照。
 9516: 
 9517: @item -l
 9518: Local、つまり現在の作業ディレクトリでのみコマンドが
 9519: 実行されます。@xref{Recursive behavior}.
 9520: 
 9521: @item -R
 9522: 再帰的に動作します (既定動作)。@xref{Recursive behavior}.
 9523: 
 9524: @item -r @var{tag}
 9525: リビジョン @var{tag} を annotate します。@ref{Common options} 参照。
 9526: @end table
 9527: 
 9528: @item checkout [@var{options}] @var{modules}@dots{}
 9529: ソースのコピーを取得します。@ref{checkout} 参照。
 9530: 
 9531: @table @code
 9532: @item -A
 9533: 貼り付いたタグ/日付/オプションを元に戻します。@ref{Sticky tags} と 
 9534: @ref{Keyword substitution} 参照。
 9535: 
 9536: @item -c
 9537: モジュールデータベースを出力します。@ref{checkout options}.
 9538: 
 9539: @item -D @var{date}
 9540: @var{date} のリビジョンを取り出します (貼り付きます)。@ref{Common
 9541: options} 参照。
 9542: 
 9543: @item -d @var{dir}
 9544: @var{dir} に取り出します。@ref{checkout options} 参照。
 9545: 
 9546: @item -f
 9547: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9548: options} 参照。
 9549: 
 9550: @c Probably want to use rev1/rev2 style like for diff
 9551: @c -r.  Here and in on-line help.
 9552: @item -j @var{rev}
 9553: 変更をマージします。@ref{checkout options} 参照。
 9554: 
 9555: @item -k @var{kflag}
 9556: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9557: 
 9558: @item -l
 9559: Local、つまり現在の作業ディレクトリでのみコマンドが
 9560: 実行されます。@xref{Recursive behavior}.
 9561: 
 9562: @item -N
 9563: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{checkout
 9564: options} 参照。
 9565: 
 9566: @item -n
 9567: モジュールプログラム (もしあれば) を実行しません。@ref{checkout
 9568: options} 参照。
 9569: 
 9570: @item -P
 9571: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9572: 
 9573: @item -p
 9574: ファイルを標準出力に取り出します (貼り付きを避けます)。@ref{checkout
 9575: options}。
 9576: 
 9577: @item -R
 9578: 再帰的に動作します(既定動作です)。@xref{Recursive behavior}.
 9579: 
 9580: @item -r @var{tag}
 9581: リビジョン @var{tag} を取り出します。@ref{Common options} 参照。
 9582: 
 9583: @item -s
 9584: -c と似ていますが、モジュールの状態を含みます。@ref{checkout options} 
 9585: 参照。
 9586: @end table
 9587: 
 9588: @item commit [@var{options}] [@var{files}@dots{}]
 9589: 変更をリポジトリに格納します。@ref{commit} 参照。
 9590: 
 9591: @table @code
 9592: @item -F @var{file}
 9593: @var{file} からログメッセージを読み込みます。@ref{commit options} 参照。
 9594: 
 9595: @item -f
 9596: @c What is this "disables recursion"?  It is from the
 9597: @c on-line help; is it documented in this manual?
 9598: ファイルを強制的に格納します。再帰的動作を使用不可にします。
 9599: @ref{commit options} 参照。
 9600: 
 9601: @item -l
 9602: Local、つまり現在の作業ディレクトリでのみコマンドが
 9603: 実行されます。@xref{Recursive behavior}.
 9604: 
 9605: @item -m @var{msg}
 9606: @var{msg} をログメッセージとして使います。@ref{commit options} 参照。
 9607: 
 9608: @item -n
 9609: モジュールプログラム (もしあれば) を実行しません。@ref{commit options}
 9610: 参照。
 9611: 
 9612: @item -R
 9613: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9614: 
 9615: @item -r @var{rev}
 9616: @var{rev} に格納します。@ref{commit options} 参照。
 9617: @c FIXME: should be dragging over text from
 9618: @c commit options, especially if it can be cleaned up
 9619: @c and made concise enough.
 9620: @end table
 9621: 
 9622: @item diff [@var{options}] [@var{files}@dots{}]
 9623: リビジョン間の差分を表示します。@ref{diff} 参照。以下のオプションに加
 9624: えて、出力様式を変更するいろいろなオプションを受け付けます。例えば、
 9625: context diff のための @samp{-c} です。
 9626: 
 9627: @table @code
 9628: @item -D @var{date1}
 9629: 作業ディレクトと日付のリビジョンの差分を取ります。@ref{diff options}
 9630: 参照。
 9631: 
 9632: @item -D @var{date2}
 9633: @var{rev1}/@var{date1} と @var{date2} 間の差分を取ります。@ref{diff
 9634: options} 参照。
 9635: 
 9636: @item -l
 9637: Local、つまり現在の作業ディレクトリでのみコマンドが
 9638: 実行されます。@ref{Recursive behavior} 参照。
 9639: 
 9640: @item -N
 9641: 追加されたり削除されたりしたファイルの差分も含みます。@ref{diff
 9642: options} 参照。
 9643: 
 9644: @item -R
 9645: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9646: 
 9647: @item -r @var{rev1}
 9648: リビジョン @var{rev1} と作業ファイル間の差分を取ります。@ref{diff
 9649: options} 参照。
 9650: 
 9651: @item -r @var{rev2}
 9652: @var{rev1}/@var{date1} と @var{rev2} 間の差分を取ります。@ref{diff
 9653: options} 参照。
 9654: @end table
 9655: 
 9656: @item edit [@var{options}] [@var{files}@dots{}]
 9657: 監視下のファイルを編集する準備をします。@ref{Editing files} 参照。
 9658: 
 9659: @table @code
 9660: @item -a @var{actions}
 9661: 一時監視のための動作を指定します。引数は @code{actions}, @code{edit},
 9662: @code{unedit}, @code{commit}, @code{all}, @code{none} のどれかです。
 9663: @ref{Editing files} 参照。
 9664: 
 9665: @item -l
 9666: Local、つまり現在の作業ディレクトリでのみコマンドが
 9667: 実行されます。@xref{Recursive behavior}.
 9668: 
 9669: @item -R
 9670: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9671: @end table
 9672: 
 9673: @item editors [@var{options}] [@var{files}@dots{}]
 9674: 誰が監視下のファイルを編集しているを見ます。@ref{Watch information} 参
 9675: 照。
 9676: 
 9677: @table @code
 9678: @item -l
 9679: Local、つまり現在の作業ディレクトリでのみコマンドが
 9680: 実行されます。@ref{Recursive behavior} 参照。
 9681: 
 9682: @item -R
 9683: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9684: @end table
 9685: 
 9686: @item export [@var{options}] @var{modules}@dots{}
 9687: CVS からフィルを export するときに使います。@ref{export} 参照。
 9688: 
 9689: @table @code
 9690: @item -D @var{date}
 9691: @var{date} のリビジョンを取り出します。@ref{Common options} 参照。
 9692: 
 9693: @item -d @var{dir}
 9694: @var{dir} に取り出します。@ref{export options} 参照。
 9695: 
 9696: @item -f
 9697: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9698: options} 参照。
 9699: 
 9700: @item -k @var{kflag}
 9701: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9702: 
 9703: @item -l
 9704: Local、つまり現在の作業ディレクトリでのみコマンドが
 9705: 実行されます。@ref{Recursive behavior} 参照。
 9706: 
 9707: @item -N
 9708: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{export
 9709: options} 参照。
 9710: 
 9711: @item -n
 9712: モジュールプログラム (もしあっても) を実行しません。@ref{export
 9713: options} 参照。
 9714: 
 9715: @item -P
 9716: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9717: 
 9718: @item -R
 9719: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9720: 
 9721: @item -r @var{tag}
 9722: リビジョン @var{tag} を取り出します (貼り付きます)。@ref{Common
 9723: options} 参照。
 9724: @end table
 9725: 
 9726: @item history [@var{options}] [@var{files}@dots{}]
 9727: リポジトリ接続履歴を表示します。@ref{history} 参照。
 9728: 
 9729: @table @code
 9730: @item -a
 9731: 全ての使用者にします (既定は自分自身です)。@ref{history options} 参照。
 9732: 
 9733: @item -b @var{str}
 9734: モジュール名, ファイル名, リポジトリのパスのいずれかに、
 9735: 文字列 @var{str} が含まれる記録のみを表示します。@ref{history options}
 9736: 参照。
 9737: 
 9738: @item -c
 9739: 格納された (修正された) ファイルについて報告します。@ref{history
 9740: options} 参照。
 9741: 
 9742: @item -D @var{date}
 9743: @var{date} から。@ref{history options} 参照。
 9744: 
 9745: @item -e
 9746: 全ての記録種別について報告します。@ref{history options} 参照。
 9747: 
 9748: @item -l
 9749: 最後に修正された (格納されたか、修正されたという報告) もの。
 9750: @ref{history options} 参照。
 9751: 
 9752: @item -m @var{module}
 9753: @var{module} について報告します (繰り返し可能)。@ref{history options}
 9754: 参照。
 9755: 
 9756: @item -n @var{module}
 9757: @var{module} だけ。@ref{history options} 参照。
 9758: 
 9759: @item -o
 9760: 取り出されたモジュールについて報告します。@ref{history options} 参照。
 9761: 
 9762: @item -r @var{rev}
 9763: リビジョン @var{rev} から。@ref{history options} 参照。
 9764: Since revision @var{rev}.  See @ref{history options}.
 9765: 
 9766: @item -T
 9767: @c What the @#$@# is a TAG?  Same as a tag?  This
 9768: @c wording is also in the online-line help.
 9769: 全てのタグについて報告します。@ref{history options} 参照。
 9770: 
 9771: @item -t @var{tag}
 9772: tag の記録が履歴ファイルに (誰かによって) 置かれてから。@ref{history
 9773: options} 参照。
 9774: 
 9775: @item -u @var{user}
 9776: 使用者 @var{user} (繰り返し可能)。@ref{history options} 参照。
 9777: 
 9778: @item -w
 9779: 作業ディレクトリが合わなくてはいけません。@ref{history options} 参照。
 9780: 
 9781: @item -x @var{types}
 9782: @var{types} について報告します。@code{TOEFWUCGMAR} から1つ以上指定しま
 9783: す。@ref{history options} 参照。
 9784: 
 9785: @item -z @var{zone}
 9786: 標準時間帯 @var{zone} で出力します。@ref{history options} 参照。
 9787: @end table
 9788: 
 9789: @item import [@var{options}] @var{repository} @var{vendor-tag} @var{release-tags}@dots{}
 9790: ベンダー枝を使用して CVS にファイルを持ち込みます。@ref{import} 参照。
 9791: 
 9792: @table @code
 9793: @item -b @var{bra}
 9794: ベンダー枝 @var{bra} に持ち込みます。@ref{Multiple vendor branches} 参
 9795: 照。
 9796: 
 9797: @item -d
 9798: ファイルの修正時刻を持ち込みの時間として使用します。@ref{import
 9799: options} 参照。
 9800: 
 9801: @item -k @var{kflag}
 9802: 既定のキーワード置換モードを設定します。@ref{import options} 参照。
 9803: 
 9804: @item -m @var{msg}
 9805: @var{msg} をログメッセージに使います。@ref{import options} 参照。
 9806: 
 9807: @item -I @var{ign}
 9808: 無視するファイルです (無効にするためには ! を使います)。@ref{import
 9809: options} 参照。
 9810: 
 9811: @item -W @var{spec}
 9812: ラッパーです。@ref{import options} 参照。
 9813: @end table
 9814: 
 9815: @item init
 9816: 存在しない場合は CVS リポジトリを作成します。@ref{Creating a
 9817: repository} 参照。
 9818: 
 9819: @item log [@var{options}] [@var{files}@dots{}]
 9820: ファイルの履歴情報を印字します。@ref{log} 参照。
 9821: 
 9822: @table @code
 9823: @item -b
 9824: 既定枝のリビジョンのみを一覧表示します。@ref{log options} 参照。
 9825: 
 9826: @item -d @var{dates}
 9827: 日付を指定します (範囲は @var{d1}<@var{d2} で、それ以前の最新は 
 9828: @var{d} で)。@ref{log options} 参照。
 9829: Specify dates (@var{d1}<@var{d2} for range, @var{d} for
 9830: latest before).  See @ref{log options}.
 9831: 
 9832: @item -h
 9833: ヘッダーのみを印字します。@ref{log options} 参照。
 9834: 
 9835: @item -l
 9836: Local、つまり現在の作業ディレクトリでのみコマンドが
 9837: 実行されます。@ref{Recursive behavior} 参照。
 9838: 
 9839: @item -N
 9840: タグを一覧表示しません。@ref{log options} 参照。
 9841: 
 9842: @item -R
 9843: RCS ファイルの名前のみを印字します。@ref{log options} 参照。
 9844: 
 9845: @item -r@var{revs}
 9846: リビジョン @var{revs} のみを一覧表示します。@ref{log options} 参照。
 9847: 
 9848: @item -s @var{states}
 9849: 指定された状態のリビジョンのみを一覧表示します。@ref{log options} 参照。
 9850: 
 9851: @item -t
 9852: ヘッダーと説明文のみを印字します。@ref{log options} 参照。
 9853: 
 9854: @item -w@var{logins}
 9855: logins で指定された使用者が格納したリビジョンのみを一覧表示します。
 9856: @ref{log options} 参照。
 9857: @end table
 9858: 
 9859: @item login
 9860: 認証サーバのパスワードの入力を促進します。@ref{Password authentication
 9861: client} 参照。
 9862: 
 9863: @item logout
 9864: 保存されている認証サーバのパスワードを消去します。
 9865: @ref{Password authentication client} 参照。
 9866: 
 9867: @item rdiff [@var{options}] @var{modules}@dots{}
 9868: リリース間の差分を表示します。@ref{rdiff} 参照。
 9869: 
 9870: @table @code
 9871: @item -c
 9872: Context diff 出力様式です (既定)。@ref{rdiff options} 参照。
 9873: 
 9874: @item -D @var{date}
 9875: @var{date} に基づいたリビジョンを選択します。@ref{Common options} 参照。
 9876: 
 9877: @item -f
 9878: タグ/日付が見つからない場合は先頭のリビジョンを使用します。@ref{Common
 9879: options} 参照。
 9880: 
 9881: @item -l
 9882: Local、つまり現在の作業ディレクトリでのみコマンドが
 9883: 実行されます。@ref{Recursive behavior} 参照。
 9884: 
 9885: @item -R
 9886: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9887: 
 9888: @item -r @var{rev}
 9889: @var{rev} に基づいたリビジョンを選択します。@ref{Common options} 参照。
 9890: 
 9891: @item -s
 9892: 短いパッチです - ファイルにつき一行です。@ref{rdiff options} 参照。
 9893: 
 9894: @item -t
 9895: 先頭の2つの差分です - ファイルへの最後の変更です。@ref{diff options}
 9896: 参照。
 9897: 
 9898: @item -u
 9899: Unidiff 出力様式です。@ref{rdiff options} 参照。
 9900: 
 9901: @item -V @var{vers}
 9902: RCS バージョン @var{vers} をキーワード展開に使用します (旧式)。
 9903: @ref{rdiff options} 参照。
 9904: @end table
 9905: 
 9906: @item release [@var{options}] @var{directory}
 9907: ディレクトリがもう使われていないことを示します。@ref{release} 参照。
 9908: 
 9909: @table @code
 9910: @item -d
 9911: 与えられたディレクトリを消去します。@ref{release options} 参照。
 9912: @end table
 9913: 
 9914: @item remove [@var{options}] [@var{files}@dots{}]
 9915: リポジトリから登録を消去します。@ref{Removing files} 参照。
 9916: 
 9917: @table @code
 9918: @item -f
 9919: 削除する前にファイルを消去します。@ref{Removing files} 参照。
 9920: 
 9921: @item -l
 9922: Local、つまり現在の作業ディレクトリでのみコマンドが
 9923: 実行されます。@ref{Recursive behavior} 参照。
 9924: 
 9925: @item -R
 9926: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9927: @end table
 9928: 
 9929: @item rtag [@var{options}] @var{tag} @var{modules}@dots{}
 9930: モジュールにタグ名を追加します。@ref{rtag} 参照。
 9931: 
 9932: @table @code
 9933: @c Is this one of those dumb options which used to
 9934: @c work around the lack of death support?
 9935: @item -a
 9936: 削除されたファイルからそうでない場合に付いているタグを消去します。
 9937: @ref{rtag options} 参照。
 9938: 
 9939: @item -b
 9940: @var{tag} という名前の枝を作成します。@ref{rtag options} 参照。
 9941: 
 9942: @item -D @var{date}
 9943: @var{date} のリビジョンにタグを付けます。@ref{rtag options} 参照。
 9944: 
 9945: @item -d
 9946: 与えられたタグを消去します。@ref{rtag options} 参照。
 9947: 
 9948: @item -F
 9949: 既にタグが存在していれば移動します。@ref{rtag options} 参照。
 9950: 
 9951: @item -f
 9952: タグ/日付が見つからなければ、先頭のリビジョンとの合致を強制します。
 9953: @ref{rtag options} 参照。
 9954: 
 9955: @item -l
 9956: Local、つまり現在の作業ディレクトリでのみコマンドが
 9957: 実行されます。@ref{Recursive behavior} 参照。
 9958: 
 9959: @item -n
 9960: タグプログラムを実行しません。@ref{rtag options} 参照。
 9961: 
 9962: @item -R
 9963: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9964: 
 9965: @item -r @var{tag}
 9966: 存在するタグ @var{tag} にタグを付けます。@ref{rtag options} 参照。
 9967: @end table
 9968: 
 9969: @item status [@var{options}] @var{files}@dots{}
 9970: 作業ディレクトリの状態の情報を表示します。@ref{File status} 参照。
 9971: 
 9972: @table @code
 9973: @item -l
 9974: Local、つまり現在の作業ディレクトリでのみコマンドが
 9975: 実行されます。@ref{Recursive behavior} 参照。
 9976: 
 9977: @item -R
 9978: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9979: 
 9980: @item -v
 9981: ファイルにタグ情報を含めます。@ref{Tags} 参照。
 9982: @end table
 9983: 
 9984: @item tag [@var{options}] @var{tag} [@var{files}@dots{}]
 9985: ファイルの取り出されたリビジョンにタグ名を追加します。@ref{Revisions}
 9986: と @ref{Branching and merging} 参照。
 9987: 
 9988: @table @code
 9989: @item -b
 9990: @var{tag} という名前の枝を作成します。@ref{tag options} 参照。
 9991: 
 9992: @item -D @var{date}
 9993: @var{date} の時点のリビジョンにタグを付けます。@ref{tag options} 参照。
 9994: 
 9995: @item -d
 9996: 与えられたタグを消去します。@ref{tag options} 参照。
 9997: 
 9998: @item -F
 9999: タグが存在していればそれを移動します。@ref{tag options} 参照。
10000: 
10001: @item -f
10002: タグ/日付が見つからなければ先頭のリビジョンとの合致を強制します。
10003: @ref{tag options} 参照。
10004: 
10005: @item -l
10006: Local、つまり現在の作業ディレクトリでのみコマンドが
10007: 実行されます。@ref{Recursive behavior} 参照。
10008: 
10009: @item -n
10010: タグプログラムを実行しません。@ref{tag options} 参照。
10011: 
10012: @item -R
10013: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10014: 
10015: @item -r @var{tag}
10016: 存在するタグ @var{tag} にタグを付けます。@ref{tag options} 参照。
10017: @end table
10018: 
10019: @item unedit [@var{options}] [@var{files}@dots{}]
10020: edit コマンドの効果を取り消します。@ref{Editing files} 参照。
10021: 
10022: @table @code
10023: @item -a @var{actions}
10024: @var{actions} は @code{edit}, @code{unedit}, @code{commit},
10025: @code{all},  @code{none} のどれかです。@ref{Editing files} 参照。
10026: 
10027: @item -l
10028: Local、つまり現在の作業ディレクトリでのみコマンドが
10029: 実行されます。@ref{Recursive behavior} 参照。
10030: 
10031: @item -R
10032: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10033: @end table
10034: 
10035: @item update [@var{options}] [@var{files}@dots{}]
10036: 作業木とリポジトリとの同期を取ります。@ref{update} 参照。
10037: 
10038: @table @code
10039: @item -A
10040: 貼り付いたタグ/日付/オプションを取ります。@ref{Sticky tags} と
10041: @ref{Keyword substitution} 参照。
10042: 
10043: @item -D @var{date}
10044: @var{date} 時点でのリビジョンを取り出します (貼り付きます)。
10045: @ref{Common options} 参照。
10046: 
10047: @item -d
10048: ディレクトリを作成します。@ref{update options} 参照。
10049: 
10050: @item -f
10051: タグ/日付が見つからなければ先頭のリビジョンを使用します。@ref{Common
10052: options} 参照。
10053: 
10054: @item -I @var{ign}
10055: ファイルを無視します (無効にするためには ! を使います)。@ref{import
10056: options} 参照。
10057: 
10058: @c Probably want to use rev1/rev2 style like for diff
10059: @c -r.  Here and in on-line help.
10060: @item -j @var{rev}
10061: 変更をマージします。@ref{update options} 参照。
10062: 
10063: @item -k @var{kflag}
10064: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
10065: 
10066: @item -l
10067: Local、つまり現在の作業ディレクトリでのみコマンドが
10068: 実行されます。@ref{Recursive behavior} 参照。
10069: 
10070: @item -P
10071: 空のディレクトリを削除します。@ref{Moving directories} 参照。
10072: 
10073: @item -p
10074: ファイルを標準出力に取り出します (貼り付きを回避します)。@ref{update
10075: options} 参照。
10076: 
10077: @item -R
10078: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10079: 
10080: @item -r @var{tag}
10081: リビジョン @var{tag} を取り出します (貼り付きます)。@ref{Common
10082: options} 参照。
10083: 
10084: @item -W @var{spec}
10085: ラッパーです。@ref{import options} 参照。
10086: @end table
10087: 
10088: @item watch [on|off|add|remove] [@var{options}] [@var{files}@dots{}]
10089: 
10090: on/off: ファイルの読み込み専用取り出しを on/off します。@ref{Setting a
10091: watch} 参照。
10092: 
10093: add/remove: 動作の通知を追加削除します。@ref{Getting Notified} 参照。
10094: 
10095: @table @code
10096: @item -a @var{actions}
10097: 一時監視への動作を指定します。
10098: @var{actions} は @code{edit}, @code{unedit},
10099: @code{commit}, @code{all}, @code{none} のどれかです。
10100: @ref{Editing files} 参照。
10101: 
10102: @item -l
10103: Local、つまり現在の作業ディレクトリでのみコマンドが
10104: 実行されます。@ref{Recursive behavior} 参照。
10105: 
10106: @item -R
10107: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10108: @end table
10109: 
10110: @item watchers [@var{options}] [@var{files}@dots{}]
10111: 誰がファイル監視しているかを見ます。@ref{Watch information} 参照。
10112: 
10113: @table @code
10114: @item -l
10115: Local、つまり現在の作業ディレクトリでのみコマンドが
10116: 実行されます。@ref{Recursive behavior} 参照。
10117: 
10118: @item -R
10119: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10120: @end table
10121: 
10122: @end table
10123: 
10124: @c ---------------------------------------------------------------------
10125: @node Administrative files
10126: @appendix 管理用ファイル便覧
10127: @cindex Administrative files (reference)
10128: @cindex Files, reference manual
10129: @cindex Reference manual (files)
10130: @cindex CVSROOT (file)
10131: 
10132: @c FIXME?  Somewhere there needs to be a more "how-to"
10133: @c guide to writing these.  I think the triggers
10134: @c (commitinfo, loginfo, taginfo, &c) are perhaps a
10135: @c different case than files like modules.  One
10136: @c particular issue that people sometimes are
10137: @c (unnecessarily?) worried about is performance, and
10138: @c the impact of writing in perl or sh or ____.
10139: リポジトリ中のディレクトリ @file{$CVSROOT/CVSROOT} に、
10140: @sc{cvs} を支援する多くのファイルが置かれます。
10141: これらのファイルが無いと @sc{cvs} の能力が制限されてしまいますが、
10142: 適切に設定すれば種々の操作を簡略化することができます。
10143: これらを編集する方法は @ref{Intro administrative files} 参照。
10144: 
10145: これらの内で最も重要なファイルは @file{modules} で、
10146: リポジトリ内のモジュールを定義します。
10147: 
10148: @menu
10149: * modules::                     モジュールを定義する
10150: * Wrappers::                    ディレクトリをファイルとして扱う
10151: * commit files::                格納を支援するファイル
10152: * commitinfo::                  格納前にチェックする
10153: * verifymsg::                   ログメッセージはどのように評価されるのか?
10154: * editinfo::                    ログ・メッセージの作成方法を指示
10155:                                 (旧式)
10156: * loginfo::                     ログ・メッセージをどこに送るか?
10157: * rcsinfo::                     ログ・メッセージの雛型
10158: * cvsignore::                   無視するファイルを設定する
10159: * history file::                履歴情報を記録する
10160: * Variables::                   各種変数の展開
10161: * config::                      その他の CVS の設定
10162: @end menu
10163: 
10164: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10165: @node modules
10166: @appendixsec The modules file
10167: @cindex Modules (admin file)
10168: @cindex Defining modules (reference manual)
10169: 
10170: 管理用ファイル @file{modules} には、
10171: ソース・コードの集合体の名前の定義を記述します。
10172: 新たな定義を @sc{cvs} に理解させるには、
10173: @sc{cvs} を用いてファイル @file{modules} を修正して下さい 
10174: (@code{add}, @code{commit} など普通のコマンドを使用します)。
10175: 
10176: ファイル @file{modules} には、モジュールの定義だけでなく、
10177: 空白行や註釈行 (@samp{#} で始まる行) も記述できます。
10178: またバックスラッシュ (@samp{\}) を行の最後に加えて、
10179: 長い行を次の行にまで続けることができます。
10180: 
10181: モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア
10182: ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト
10183: リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには 
10184: @file{first-dir} というディレクトリがあり、そこには @file{file1} と 
10185: @file{file2} というファイルがあり、@file{sdir} というディレクトリがあ
10186: ります。@file{first-dir/sdir} には @file{sfile} というファイルがありま
10187: す。
10188: 
10189: @c FIXME: should test all the examples in this section.
10190: 
10191: @menu
10192: * Alias modules::             一番簡単なモジュール
10193: * Regular modules::
10194: * Ampersand modules::
10195: * Excluding directories::     モジュールからディレクトリを除外する
10196: * Module options::            一般とアンドモジュールはオプションを取れる
10197: @end menu
10198: 
10199: @node Alias modules
10200: @appendixsubsec 別名モジュール
10201: @cindex Alias modules
10202: @cindex -a, in modules file
10203: 
10204: 別名モジュールが一番簡単な種類のモジュールです:
10205: 
10206: @table @code
10207: @item @var{mname} -a @var{aliases}@dots{}
10208: これはモジュール @var{mname} の最も簡単な定義方法を表わします。
10209: @samp{-a} フラグは単純に別名の定義を行います:
10210: @sc{cvs} に (コマンドの引数として) @var{mname} が与えられると、
10211: @var{aliases} に記述された名前の一覧を代りに使用します。
10212: @var{aliases} は他のモジュール名もしくはパス名から構成します。
10213: @var{aliases} にパス名を使用した場合、
10214: @sc{cvs} の引数にパス名を明示した場合と同じく、
10215: @code{checkout} したとき途中の全てのディレクトリが
10216: 作業ディレクトリに作成されます。
10217: @end table
10218: 
10219: 例えば、モジュールファイルの内容が以下のようであると:
10220: 
10221: @example
10222: amodule -a first-dir
10223: @end example
10224: 
10225: @noindent
10226: 次の2つのコマンドは等価です:
10227: 
10228: @example
10229: $ cvs co amodule
10230: $ cvs co first-dir
10231: @end example
10232: 
10233: @noindent
10234: そして、それらは以下のような出力を出します:
10235: 
10236: @example
10237: cvs checkout: Updating first-dir
10238: U first-dir/file1
10239: U first-dir/file2
10240: cvs checkout: Updating first-dir/sdir
10241: U first-dir/sdir/sfile
10242: @end example
10243: 
10244: @node Regular modules
10245: @appendixsubsec 一般モジュール
10246: @cindex Regular modules
10247: 
10248: @table @code
10249: @item @var{mname} [ options ] @var{dir} [ @var{files}@dots{} ]
10250: この形式のモジュール定義を最も単純にすると、
10251: @samp{@var{mname} @var{dir}} となります。
10252: これはディレクトリ @var{dir} の全てのファイルを、
10253: モジュール @var{mname} と定義します。
10254: @var{dir} は (@code{$CVSROOT} から) 
10255: ソースのあるディレクトリへの相対パス名です。
10256: この場合にソースを取り出すと、
10257: @var{mname} というディレクトリだけが作業ディレクトリに作成されます。
10258: つまり @var{dir} が複数のディレクトリ階層から成るパス名であっても、
10259: 既定では途中のディレクトリ階層は使用されません。
10260: @end table
10261: 
10262: 例えば、モジュールが以下で定義されていると:
10263: 
10264: @example
10265: regmodule first-dir
10266: @end example
10267: 
10268: @noindent
10269: regmodule は first-dir のファイルを含みます:
10270: 
10271: @example
10272: $ cvs co regmodule
10273: cvs checkout: Updating regmodule
10274: U regmodule/file1
10275: U regmodule/file2
10276: cvs checkout: Updating regmodule/sdir
10277: U regmodule/sdir/sfile
10278: $
10279: @end example
10280: 
10281: @var{dir} の後で明示的にモジュールを指定することで、特定のファイルをディ
10282: レクトリ @var{dir} から選択することができます。例:
10283: 
10284: @example
10285: regfiles first-dir/sdir sfile
10286: @end example
10287: 
10288: @noindent
10289: この定義により、regfiles モジュールを取得すると、一覧に挙げられたファ
10290: イルがある単独のディレクトリ @file{regfiles} を作成し、それは @sc{cvs}
10291: のソースリポジトリのより深いディレクトリから来ています。
10292: 
10293: @example
10294: $ cvs co regfiles
10295: U regfiles/sfile
10296: $
10297: @end example
10298: 
10299: @node Ampersand modules
10300: @appendixsubsec アンドモジュール
10301: @cindex Ampersand modules
10302: @cindex &, in modules file
10303: 
10304: モジュール定義は定義に @samp{&@var{module}} を含めることで他のモジュー
10305: ルを参照することができます。
10306: @example
10307: @var{mname} [ options ] @var{&module}@dots{}
10308: @end example
10309: 
10310: そうすると、モジュールを取得したときに、モジュールのあるディレクトリで、
10311: それぞれのモジュールのためのサブディレクトリを作成します。
10312: 
10313: @example
10314: ampermod &first-dir
10315: @end example
10316: 
10317: そうすると、checkout は @code{ampermod} ディレクトリを作成し、それには 
10318: @code{first-dir} というディレクトリがあり、それは今度は自分の全てのファ
10319: イルとディレクトリを持っています。例えば、コマンド
10320: 
10321: @example
10322: $ cvs co ampermod
10323: @end example
10324: 
10325: @noindent
10326: は以下のファイルを作成します:
10327: 
10328: @example
10329: ampermod/first-dir/file1
10330: ampermod/first-dir/file2
10331: ampermod/first-dir/sdir/sfile
10332: @end example
10333: 
10334: ここには、一つ癖/バグがあります: @sc{cvs} が印字するメッセージは 
10335: @file{ampermod} を省略するので、ファイルが取り出された位置を正確に表示
10336: しません。
10337: 
10338: @example
10339: $ cvs co ampermod
10340: cvs checkout: Updating first-dir
10341: U first-dir/file1
10342: U first-dir/file2
10343: cvs checkout: Updating first-dir/sdir
10344: U first-dir/sdir/sfile
10345: $
10346: @end example
10347: 
10348: このバグっぽい動作に頼らないでください。@sc{cvs} の将来のリリースでは
10349: 修正されているかもしれません。
10350: 
10351: @c FIXCVS: What happens if regular and & modules are
10352: @c combined, as in "ampermodule first-dir &second-dir"?
10353: @c When I tried it, it seemed to just ignore the
10354: @c "first-dir".  I think perhaps it should be an error
10355: @c (but this needs further investigation).
10356: @c In addition to discussing what each one does, we
10357: @c should put in a few words about why you would use one or
10358: @c the other in various situations.
10359: 
10360: @node Excluding directories
10361: @appendixsubsec ディレクトリの除外
10362: @cindex excluding directories, in modules file
10363: @cindex !, in modules file
10364: 
10365: 別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符 
10366: (@samp{!}) を付けることで、特定のディレクトリを除外することができます。
10367: 
10368: 例えば、モジュールファイルが以下のようになっていると:
10369: 
10370: @example
10371: exmodule -a !first-dir/sdir first-dir
10372: @end example
10373: 
10374: モジュール @samp{exmodule} を取り出すと、サブディレクトリ 
10375: @samp{first-dir/sdir} にあるファイル以外の全てを取り出します。
10376: @c Note that the "!first-dir/sdir" sometimes must be listed
10377: @c before "first-dir".  That seems like a probable bug, in which
10378: @c case perhaps it should be fixed (to allow either
10379: @c order) rather than documented.  See modules4 in testsuite.
10380: 
10381: @node Module options
10382: @appendixsubsec モジュールのオプション
10383: @cindex options, in modules file
10384: 
10385: 標準モジュールとアンドモジュールのどちらもオプションを含むことができ、
10386: それはモジュールの追加情報を提供します。
10387: 
10388: @table @code
10389: @cindex -d, in modules file
10390: @item -d @var{name}
10391: 作業ディレクトリの名前をモジュール名とは別のものにします。
10392: @c FIXME: Needs a bunch of examples, analogous to the
10393: @c examples for alias, regular, and ampersand modules
10394: @c which show where the files go without -d.
10395: 
10396: @cindex Export program
10397: @cindex -e, in modules file
10398: @item -e @var{prog}
10399: モジュールのファイルが export されたときに常に実行されるプログラム
10400: @var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
10401: 行されます。
10402: @c FIXME: Is it run on server? client?
10403: 
10404: @cindex Checkin program
10405: @cindex -i, in modules file
10406: @item -i @var{prog}
10407: モジュールのファイルが格納されたときに常に実行されるプログラム 
10408: @var{prog} を指定します。@var{prog} はソースリポジトリの影響を受けるディ
10409: レクトリのフルパス名である唯一の引数と共に実行されます。
10410: @file{commitinfo}, @file{loginfo}, @file{veryfymsg} ファイルは格納時に
10411: プログラムを呼ぶ他の方法を提供します。
10412: @c FIXME: Is it run on server? client?
10413: 
10414: @cindex Checkout program
10415: @cindex -o, in modules file
10416: @item -o @var{prog}
10417: ファイルのモジュールが取り出されたときに常に実行されるプログラム 
10418: @var{prog} を指定します。@var{prog} は単独の引数、モジュール名と共に実
10419: 行されます。
10420: @c FIXME: Is it run on server? client?
10421: 
10422: @cindex Status of a module
10423: @cindex Module status
10424: @cindex -s, in modules file
10425: @item -s @var{status}
10426: モジュールに状態を割当てます。モジュールファイルが @samp{cvs checkout
10427: -s} で印字されると、モジュールが主モジュール状態に従って並び換えられ、
10428: それからモジュール名に従って並び換えられます。このオプションは他に意味
10429: はありません。状態以外のいくつかのことにこのオプションを使うことができ
10430: ます: 例えば、このモジュールに責任のある人の一覧などです。
10431: 
10432: @cindex Tag program
10433: @cindex -t, in modules file
10434: @item -t @var{prog}
10435: モジュールのファイルが @code{rtag} でタグ付けされたとに常に実行される
10436: プログラム @var{prog} を指定します。@var{prog} は2つの引数と共に実行さ
10437: れます: モジュール名と @code{rtag} に指定されたタグ名です。@code{tag} 
10438: が行われたときは実行されません。一般的に、taginfo の方が良い解決法です 
10439: (@pxref{user-defined logging})。
10440: @c FIXME: Is it run on server? client?
10441: @c Problems with -t include:
10442: @c * It is run after the tag not before
10443: @c * It doesn't get passed all the information that
10444: @c   taginfo does ("mov", &c).
10445: @c * It only is run for rtag, not tag.
10446: 
10447: @cindex Update program
10448: @cindex -u, in modules file
10449: @item -u @var{prog}
10450: 取り出されたモジュールの最上位のディレクトリで @samp{cvs} が行なわれた
10451: ときに常に実行されるプログラム @var{protg} を指定します。@var{prog} は
10452: 単独の引数、このモジュールのソースリポジトリのフルパスとともに実行され
10453: ます。
10454: @c FIXME: Is it run on server? client?
10455: @c One drawback of -u and -i are that CVS/Update.prog
10456: @c and CVS/Checkin.prog only get updated on initial
10457: @c checkout, and don't get updated if the modules file
10458: @c changes.  Also, the user can edit them, which means
10459: @c they are no good for security-type stuff.
10460: @end table
10461: 
10462: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10463: @node Wrappers
10464: @appendixsec The cvswrappers file
10465: @cindex cvswrappers (admin file)
10466: @cindex CVSWRAPPERS, environment variable
10467: @cindex Wrappers
10468: 
10469: @c FIXME: need some better way of separating this out
10470: @c by functionality.  -t/-f is one feature, -m is
10471: @c another, and -k is a third.  And this discussion
10472: @c should be better motivated (e.g. start with the
10473: @c problems, then explain how the feature solves it).
10474: 
10475: Wrapper 機能を用いれば、ファイルを @sc{cvs} に取り込む/取り出す際に、
10476: 適切な方法で変換するように設定することができます。
10477: 
10478: 管理用ファイル @file{cvswrappers} には、
10479: ファイル名に合致する正規表現と、
10480: そのファイルに対して実行されるスクリプトが記述されます。
10481: 個々のファイルやディレクトリに対して、二つのスクリプトが記述できます。
10482: 各々リポジトリに格納する前 (@samp{-t} フラグが付けられます) と、
10483: リポジトリから取り出すとき (@samp{-f} フラグが付けられます) に
10484: 実行するものです。@samp{-t}/@samp{-f} 機能はクライアント/サーバの 
10485: @sc{cvs} では動作しません。
10486: @c I think maybe -t/-f works client/server if a single
10487: @c file converts to/from a single file, as opposed to
10488: @c the file<->directory case.  Could use more
10489: @c investigation...
10490: 
10491: また @file{cvswrappers} には、非バイナリ・ファイルを更新するときの
10492: マージ方針について記述するオプション @samp{-m} があります。
10493: @code{MERGE} は @sc{cvs} が通常用いる方法です:
10494: ファイルをマージしようとすることを意味します。@code{COPY} は @code{cvs
10495: update} はファイルのマージを拒否するという意味で、@samp{-kb} でバイナ
10496: リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
10497: されていれば、@samp{-m 'COPY'} を指定する必要はありません。
10498: CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
10499: ために使用者が @sc{cvs} の外の機構を使用することを要求します。
10500: @strong{警告}: @sc{cvs} 1.9 以前では @code{COPY} を使わないでくださ
10501: い---それらのバージョンの @sc{cvs} はあるバージョンを別の物の上にコピー
10502: し、以前の内容を消し去ってしまいます。
10503: @c Ordinarily we don't document the behavior of old
10504: @c versions.  But this one is so dangerous, I think we
10505: @c must.  I almost renamed it to -m 'NOMERGE' so we
10506: @c could say "never use -m 'COPY'".
10507: Wrapper オプション @samp{-m} は更新時のマージ方針にのみ影響し、
10508: ファイルの格納方法には影響しません。
10509: バイナリ・ファイルの詳細は @ref{Binary files} 参照。
10510: 
10511: 管理用ファイル @file{cvswrappers} の基本的な書式:
10512: 
10513: @c FIXME: @example is all wrong for this.  Use @deffn or
10514: @c something more sensible.
10515: @example
10516: ワイルドカード    [オプション 値][オプション 値]...
10517: 
10518: 利用できるオプションを以下に挙げます。
10519: -f                取得時のフィルタ        値: フィルタのパス
10520: -t                格納時のフィルタ        値: フィルタのパス
10521: -m                マージ方針              値: MERGE か COPY
10522: -k                キーワード展開          値: 置換モード
10523: 
10524: 値は以下のように単引用符で囲みます。
10525: @end example
10526: 
10527: @example
10528: *.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
10529: *.c      -t 'indent %s %s'
10530: @end example
10531: @c When does the filter need to be an absolute pathname
10532: @c and when will something like the above work?  I
10533: @c suspect it relates to the PATH of the server (which
10534: @c in turn depends on all kinds of stuff, e.g. inetd
10535: @c for pserver).  I'm not sure whether/where to discuss
10536: @c this.
10537: @c FIXME: What do the %s's stand for?
10538: 
10539: @noindent
10540: @file{cvswrappers} の上側の例では、
10541: @samp{.nib} で終わる全てのファイル/ディレクトリを、
10542: リポジトリに格納する前に @file{wrap} プログラムで
10543: 整形することが記述されています。
10544: リポジトリから取り出す際には @file{unwrap} プログラムが用いられます。
10545: またファイルを更新する際には
10546: @code{COPY} する方針を採ることが記述されています 
10547: (すなわち、マージを行いません)。
10548: 
10549: @c What pitfalls arise when using indent this way?  Is
10550: @c it a winning thing to do?  Would be nice to at least
10551: @c hint at those issues; we want our examples to tell
10552: @c how to solve problems, not just to say that cvs can
10553: @c do certain things.
10554: 最後の行の例では、@samp{.c} で終わるファイル全てを、
10555: リポジトリに格納する前に @file{indent} で整形することが記述されています。
10556: 前の例とは異なり、リポジトリから取り出す際には整形されません。
10557: @noindent
10558: @samp{-t} に記述されるフィルタには二つの引数が与えられます。
10559: 最初は整形されるファイル/ディレクトリで、
10560: 次には整形された結果が出力されるファイルのパス名です。
10561: 
10562: @noindent
10563: @samp{-f} に記述されるフィルタには、
10564: 整形されるファイル名が引数として与えられます。
10565: 整形された結果は、作業ディレクトリにファイルとして置かれます。
10566: 
10567: @samp{-t}/@samp{-f} 機能は CVS の操作の一部分---ファ
10568: イルが修正されたとき---を便利に扱えません。CVS はまだファイル (もしく
10569: はディレクトリ) が存在することを望み、その修正時刻をファイルが修正され
10570: たかどうかを決定するために使います。もし CVS が間違ってファイルが未修
10571: 正であると考えれば (例えば、ディレクトリは無変更だけど、その中のファイ
10572: ルのどれかが変更されたとき)、@code{cvs commit} に @samp{-f} オプション
10573: を指定することでとにかくファイルの格納を強制できます (@pxref{commit
10574: options})。
10575: @c This is, of course, a serious design flaw in -t/-f.
10576: @c Probably the whole functionality needs to be
10577: @c redesigned (starting from requirements) to fix this.
10578: 
10579: 次の例では、@samp{.exe} で終わるファイルをバイナリとして扱いながら、
10580: ディレクトリを取り入れます:
10581: 
10582: @example
10583: cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
10584: @end example
10585: 
10586: @c Another good example, would be storing files
10587: @c (e.g. binary files) compressed in the repository.
10588: @c 	::::::::::::::::::
10589: @c 	cvswrappers
10590: @c 	::::::::::::::::::
10591: @c 	*.t12 -m 'COPY'
10592: @c 	*.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
10593: @c
10594: @c	::::::::::::::::::
10595: @c	gunzipcp
10596: @c	::::::::::::::::::
10597: @c	:
10598: @c	[ -f $1 ] || exit 1
10599: @c	zcat $1 > /tmp/.#$1.$$
10600: @c	mv /tmp/.#$1.$$ $1
10601: @c
10602: @c	::::::::::::::::::
10603: @c	gzipcp
10604: @c	::::::::::::::::::
10605: @c	:
10606: @c	DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
10607: @c	if [ ! -d $DIRNAME ] ; then
10608: @c	      DIRNAME=`echo $1 | sed -e "s|.*/||g"`
10609: @c	fi
10610: @c	gzip -c  $DIRNAME  > $2
10611: @c One catch--"cvs diff" will not invoke the wrappers
10612: @c (probably a CVS bug, although I haven't thought it out).
10613: 
10614: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10615: @node commit files
10616: @appendixsec 格納を支援するファイル
10617: @cindex Commit files
10618: 
10619: ファイル @file{modules} 中の @samp{-i} フラグは、
10620: ファイルが格納された時に特定のプログラムを実行するのに用いられます 
10621: (@pxref{modules})。
10622: この節で説明するファイルは、
10623: ファイルの格納時にプログラムを実行するための、
10624: より柔軟な方法を提供します。
10625: 
10626: 格納時に実行できるプログラムは三種類に分けられます。
10627: これらのプログラムはリポジトリ中のファイルに記述されます。
10628: 次に示すのは、
10629: ファイル名と、対応するプログラムに必要な機能を示したものです。
10630: 
10631: @table @file
10632: @item commitinfo
10633: ここに記述されるプログラムは、
10634: 格納が許されるかどうか判断する責任を持ちます。
10635: このプログラムが正常終了しなければ、
10636: 格納が中止されます。
10637: 
10638: @item verifymsg
10639: 指定されたプログラムはログメッセージを評価するために使用され、それは全
10640: ての要求部分を備えているかを検証するかもしれません。これはログメッセー
10641: ジの雛型を保持することのできる @file{rcsinfo} ファイルと組合せて使うと
10642: とても役に立ちます (@pxref{rcsinfo})。
10643: 
10644: @item editinfo
10645: ここに記述されるプログラムは、
10646: ログ・メッセージを編集するのに用いられ、
10647: 全ての要求される項目が含まれるかどうか可能な限り確かめます。
10648: ログ・メッセージの雛型を記述する @file{rcsinfo} ファイルと
10649: 組み合せることで、より便利になります (@pxref{rcsinfo})。(旧式)
10650: 
10651: @item loginfo
10652: ここに記述されるプログラムは、
10653: 格納が完了した時点で呼び出されます。
10654: ログ・メッセージと追加情報とを受け取り、ファイルに格納するか、
10655: 特定の人物にメールとして出すか、またはニュース・グループに投稿するとか、
10656: または@dots{} あなたの想像力だけがその制限です。
10657: @end table
10658: 
10659: @menu
10660: * syntax::                      共通の構文
10661: @end menu
10662: 
10663: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10664: @node syntax
10665: @appendixsubsec 共通の構文
10666: @cindex Info files (syntax)
10667: @cindex Syntax of info files
10668: @cindex Common syntax of info files
10669: 
10670: @c FIXME: having this so totally separate from the
10671: @c Variables node is rather bogus.
10672: 
10673: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{editinfo},
10674: @file{verifymsg}, などのような管理ファイルには共通の書式があります。
10675: 各ファイルの目的は後述します。
10676: ここでは共通の構文について説明します。
10677: 
10678: @cindex regular expression syntax
10679: 各行は次の要素から構成されます:
10680: @itemize @bullet
10681: @item
10682: @c Say anything about DEFAULT and ALL?  Right now we
10683: @c leave that to the description of each file (and in fact
10684: @c the practice is inconsistent which is really annoying).
10685: 正規表現。これは GNU emacs で使われる構文の基本正規表現です。
10686: @c FIXME: What we probably should be saying is "POSIX Basic
10687: @c Regular Expression with the following extensions (`\('
10688: @c `\|' '+' etc)"
10689: @c rather than define it with reference to emacs.
10690: @c The reference to emacs is not strictly speaking
10691: @c true, as we don't support \=, \s, or \S.  Also it isn't
10692: @c clear we should document and/or promise to continue to
10693: @c support all the obscure emacs extensions like \<.
10694: @c Also need to better cite (or include) full
10695: @c documentation for the syntax.
10696: @c Also see comment in configure.in about what happens to the
10697: @c syntax if we pick up a system-supplied regexp matcher.
10698: 
10699: @item
10700: 項目間の空白---一つ以上のスペース又はタブです。
10701: 
10702: @item
10703: ファイル名又はコマンド行の形式。
10704: @end itemize
10705: 
10706: @noindent
10707: 空白行は無視されます。
10708: また @samp{#} という文字で始まる行は註釈行として扱われます。
10709: 残念ながら、長い行を複数行に分割することは@emph{できません}。
10710: 
10711: リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。
10712: 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。
10713: 
10714: @c FIXME: need an example.  In particular, show what
10715: @c the regular expression is matched against (one
10716: @c ordinarily clueful person got confused about whether it
10717: @c includes the filename--"directory name" above should be
10718: @c unambiguous but there is nothing like an example to
10719: @c confirm people's understanding of this sort of thing).
10720: 
10721: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10722: @node commitinfo
10723: @appendixsec 管理用ファイル commitinfo
10724: @cindex Commitinfo
10725: @cindex Checking commits
10726: @cindex Precommit checking
10727: 
10728: @samp{cvs commit} を実行する直前に必ず実行したいプログラムを、
10729: ファイル @file{commitinfo} に記述します。
10730: 修正、追加、削除されたファイルを格納しても良いかどうか、
10731: このプログラムを用いて格納前に判断します。
10732: 例えば、変更されたファイルがあなたのサイトの
10733: コーディング・スタイルの標準に従っているか確かめることもできます。
10734: 
10735: 前に書いたように、@file{commitinfo} の各行は、第一項の正規表現、
10736: 残りの部分のコマンド行形式から構成されます。
10737: コマンド行の部分には、
10738: プログラム名と適切な数の引数とを記述することができます。
10739: また実行の際には、リポジトリのフルパスと
10740: 格納しようとするファイル名 (追加, 削除, 修正されたファイル名) 
10741: がコマンド行の最後に与えられます。
10742: 
10743: @cindex exit status, of commitinfo
10744: モジュールへの相対パスと正規表現とが合致する最初の行が実行されます。
10745: そしてコマンドが非零で終了した場合は、格納が中止されます。
10746: 
10747: @cindex DEFAULT in commitinfo
10748: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
10749: ファイル中のどの正規表現にも合致しない場合に適用されます。
10750: 
10751: @cindex ALL in commitinfo
10752: 第一項が @samp{ALL} である行全てが、
10753: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
10754: 
10755: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
10756: @file{commitinfo} に記述された行は、
10757: クライアント側ではなく@emph{別のマシン} (サーバ) 側で実行されます 
10758: (@pxref{Remote repositories})。
10759: 
10760: @c FIXME: should discuss using commitinfo to control
10761: @c who has checkin access to what (e.g. Joe can check into
10762: @c directories a, b, and c, and Mary can check into
10763: @c directories b, c, and d--note this case cannot be
10764: @c conveniently handled with unix groups).  Of course,
10765: @c adding a new set of features to CVS might be a more
10766: @c natural way to fix this problem than telling people to
10767: @c use commitinfo.
10768: @c FIXME: Should make some reference, especially in
10769: @c the context of controlling who has access, to the fact
10770: @c that commitinfo can be circumvented.  Perhaps
10771: @c mention SETXID (but has it been carefully examined
10772: @c for holes?).  This fits in with the discussion of
10773: @c general CVS security in "Password authentication
10774: @c security" (the bit which is not pserver-specific).
10775: 
10776: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10777: @node verifymsg
10778: @appendixsec ログメッセージの検証
10779: @cindex verifymsg (admin file)
10780: @cindex log message, verifying
10781: 
10782: 一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために
10783: そのメッセージを評価することができます。ログメッセージを検証するための
10784: プログラムを指定するために @file{verifymsg} ファイルを使用することがで
10785: きます。このプログラムは入力されたメッセージに必要なフィールドがあるか
10786: どうかを調べる簡単なスプリプトでも良いでしょう。
10787: 
10788: @file{verifymsg} ファイルは、ログメッセージの雛型を指定するために使う
10789: ことのできる @file{rcsinfo} ファイルと一緒に使用されたときにとても役に
10790: 立つことが多いです。
10791: 
10792: @file{verifymsg} ファイルは正規表現とコマンド行の雛型から成ります。雛
10793: 型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで
10794: きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加
10795: されます。
10796: 
10797: 一つ注意しなければならないのは、@samp{ALL} キーワードは使えないという
10798: ことです。一行以上合致した場合、最初のものが使われます。これはモジュー
10799: ルで既定の検証スクリプトを指定して、サブディレクトリで上書きするときに
10800: 役に立ちます。
10801: 
10802: @cindex DEFAULT in verifymsg
10803: リポジトリ名がこのファイルのどの正規表現にも合致しなければ、
10804: @samp{DEFAULT} が指定されていると、それが使用されます。
10805: 
10806: @cindex exit status, of verifymsg
10807: 検証スクリプトが非零の値で終了すれば、格納は中止されます。
10808: 
10809: 検証スクリプトはログメセージを変更できないことに注意してください。単に
10810: 受け入れるか拒否するかのどちらかです。
10811: @c FIXME?  Is this an annoying limitation?  It would be
10812: @c relatively easy to fix (although it would *not* be a
10813: @c good idea for a verifymsg script to interact with the user
10814: @c at least in the client/server case because of locks
10815: @c and all that jazz).
10816: 
10817: 以下は、@file{verifymsg} ファイルのちょっとしたばかげた例と、それに対
10818: 応する @file{rcsinfo} ファイル、ログメッセージの雛型と検証スクリプトで
10819: す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの
10820: 最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの
10821: です。以下の雛型ファイルは @file{/usr/cvssupport/tc.template} にありま
10822: す。
10823: 
10824: @example
10825: BugId:
10826: @end example
10827: 
10828: スクリプト @file{/usr/cvssupoort/bugid.verify} はログメッセージの評価
10829: に使われます。
10830: 
10831: @example
10832: #!/bin/sh
10833: #
10834: #       bugid.verify filename
10835: #
10836: #  Verify that the log message contains a valid bugid
10837: #  on the first line.
10838: #
10839: if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
10840:     exit 0
10841: else
10842:     echo "No BugId found."
10843:     exit 1
10844: fi
10845: @end example
10846: 
10847: @file{verifymsg} ファイルには以下の行があります:
10848: 
10849: @example
10850: ^tc     /usr/cvssupport/bugid.verify
10851: @end example
10852: 
10853: @file{rcsinfo} ファイルには以下の行があります:
10854: 
10855: @example
10856: ^tc     /usr/cvssupport/tc.template
10857: @end example
10858: 
10859: 
10860: 
10861: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10862: @node editinfo
10863: @appendixsec Editinfo
10864: @cindex editinfo (admin file)
10865: @cindex Editor, specifying per module
10866: @cindex Per-module editor
10867: @cindex Log messages, editing
10868: 
10869: @emph{注意:} @file{editinfo} 機能は旧式になっています。ログメッセージ
10870: の既定のエディタを設定するためには、@code{EDITOR} 環境変数 
10871: (@pxref{Environment variables}) か @samp{-e} 広域オプション
10872: (@pxref{Global options}) を使用してください。ログメッセージを評価する
10873: ための @file{verifymsg} 機能を使うための情報は @ref{verifymsg} を参照
10874: してください。
10875: 
10876: いつも同じ形式でログ・メッセージを記録したい場合に、
10877: ログ・メッセージを編集するプログラムを @file{editinfo} に
10878: 指定することができます。
10879: 指定するプログラムは、
10880: ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、
10881: エディタを呼び出して、入力されたメッセージが必要項目を
10882: 満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。
10883: 
10884: 合致する行が @file{editinfo} になかった場合、
10885: 環境変数 @code{$CVSEDITOR} に指定されたエディタを使用します。
10886: この環境変数が設定されていない場合には、
10887: 環境変数 @code{$EDITOR} に指定されたエディタを代わりにします。
10888: そしてこの環境変数も設定されていない場合は、
10889: 既定のものが使われます。@ref{Committing your changes} 参照。
10890: 
10891: @file{rcsinfo} にログ・メッセージの雛型を指定すると、
10892: より効果的に @file{editinfo} を利用できるでしょう。
10893: 
10894: @file{editinfo} の各行は、第一項の正規表現、
10895: 残りの部分のコマンド行形式から構成されます。
10896: コマンド行の部分には、
10897: プログラム名と適切な数の引数とを記述することができます。
10898: また実行の際には、ログ・メッセージの雛型へのフルパス
10899: がコマンド行の最後に与えられます。
10900: 
10901: @samp{ALL} が利用できないことに注意して下さい。
10902: 合致する行が複数あった場合は、最初の行が実行されます。
10903: これは、モジュールの編集スクリプトが設定されていて、
10904: サブディレクトリでは別のものを使用したい場合を考慮しています。
10905: 
10906: @cindex DEFAULT in editinfo
10907: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
10908: ファイル中のどの正規表現にも合致しない場合に適用されます。
10909: 
10910: 編集スクリプトが非零で終了した場合は、格納が中止されます。
10911: 
10912: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合や、
10913: @code{cvs commit} の @samp{-m} または @samp{-F} オプションを
10914: 使用した場合、@file{editinfo} は参照されません。
10915: この問題を解決する良い方法は今のところありません。
10916: 代わりに @file{verifymsg} を使ってください。
10917: 
10918: @menu
10919: * editinfo example::            editinfo 記述例
10920: @end menu
10921: 
10922: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10923: @node editinfo example
10924: @appendixsubsec editinfo 記述例
10925: 
10926: 次に、ちょっとアホくさい @file{editinfo} の使用例を、
10927: 対応する @file{rcsinfo}、ログ・メッセージの雛型、
10928: エディタ・スクリプトと併わせて紹介します。
10929: まずログ・メッセージの雛型ですが、
10930: 最初の行に必ずバグ番号を記録するように促し、
10931: 残りは自由に記述してもらいます。
10932: この雛型は @file{/usr/cvssupport/tc.template} に置くことにします。
10933: 
10934: @example
10935: BugId:
10936: @end example
10937: 
10938: ログ・メッセージを編集するため、
10939: 次のスクリプト @file{/usr/cvssupport/bugid.edit} を使用します。
10940: 
10941: @example
10942: #!/bin/sh
10943: #
10944: #       bugid.edit filename
10945: #
10946: #  Call $EDITOR on FILENAME, and verify that the
10947: #  resulting file contains a valid bugid on the first
10948: #  line.
10949: if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
10950: if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
10951: $CVSEDITOR $1
10952: until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
10953: do  echo -n  "No BugId found.  Edit again? ([y]/n)"
10954:     read ans
10955:     case $@{ans@} in
10956:         n*) exit 1;;
10957:     esac
10958:     $CVSEDITOR $1
10959: done
10960: @end example
10961: 
10962: ファイル @file{editinfo} には次の行を記述します:
10963: 
10964: @example
10965: ^tc     /usr/cvssupport/bugid.edit
10966: @end example
10967: 
10968: ファイル @file{rcsinfo} には次の行を記述します:
10969: 
10970: @example
10971: ^tc     /usr/cvssupport/tc.template
10972: @end example
10973: 
10974: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10975: @node loginfo
10976: @appendixsec 管理用ファイル loginfo
10977: @cindex loginfo (admin file)
10978: @cindex Storing log messages
10979: @cindex Mailing log messages
10980: @cindex Distributing log messages
10981: @cindex Log messages
10982: 
10983: @c "cvs commit" is not quite right.  What we
10984: @c mean is "when the repository gets changed" which
10985: @c also includes "cvs import" and "cvs add" on a directory.
10986: @file{loginfo} を用いて、
10987: @samp{cvs commit} によるログ情報の送り先を管理します。
10988: 各行の第一項には正規表現が記述され、
10989: 行の残りの部分はフィルタでなくてはいけません。
10990: 変更を加えたディレクトリを 
10991: @code{$CVSROOT} からの相対パスで表わしたものと、
10992: 各行の正規表現が合致するかどうか試されます。
10993: 合致した場合は、
10994: その行の残りの部分であるフィルタ・プログラムの標準入力に、
10995: ログ情報を与えます。
10996: 
10997: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
10998: ファイル中のどの正規表現にも合致しない場合に適用されます。
10999: 
11000: 第一項が @samp{ALL} である行全てが、
11001: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11002: 
11003: 正規表現が合致する最初の行が実行されます。
11004: 
11005: ファイル @file{loginfo} の構文についての記述は @xref{commit files}.
11006: 
11007: 使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は 
11008: @samp{%} の後に空白か、単独のフォーマット文字、もしくは分離器 
11009: @samp{@{} と @samp{@}} に囲まれたいくつかのフォーマット文字が続いた物
11010: です。フォーマット文字は:
11011: 
11012: @table @t
11013: @item s
11014: ファイル名
11015: @item V
11016: 古いバージョン番号 (格納前)
11017: @item v
11018: 新しいバージョン番号 (格納後)
11019: @end table
11020: 
11021: フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます
11022: (フィールドを分離するコンマはまだ提供されされています。)
11023: 
11024: 例えば、有効なフォーマット文字列は @samp{%}, @samp{%s}, @samp{%@{s@}}, 
11025: @samp{%@{sVv@}} などです。
11026: 
11027: 出力は空白で区切られた語からなる文字列になります。下位互換のために、最
11028: 初の語はリポジトリ名になります。残りの語はフォーマット文字列で要求され
11029: た情報をコンマで分けたリストです。例えば、@samp{/u/src/master} がリポ
11030: ジトリで @samp{%@{sVv@}} がフォーマット文字列、3つのファイル
11031: (@t{ChangeLog}, @t{Makefile}, @t{foo.c}) が修正されていると、出力は:
11032: 
11033: @example
11034: /u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
11035: @end example
11036: 
11037: 別の例として、@samp{%@{@}} ではリポジトリ名のみが作成されます。
11038: 
11039: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
11040: @file{loginfo} はクライアント側ではなく、@emph{別のマシン} 
11041: (サーバ) 側で実行されます 
11042: (@pxref{Remote repositories})。
11043: 
11044: @menu
11045: * loginfo example::             loginfo 記述例
11046: * Keeping a checked out copy::  格納毎にディレクトリを更新
11047: @end menu
11048: 
11049: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11050: @node loginfo example
11051: @appendixsubsec loginfo 記述例
11052: 
11053: ここで示す @file{loginfo} ファイルと付属のシェル・スクリプトは、
11054: 格納時に次のような動作をします。
11055: まず全てのログ・メッセージを 
11056: @file{$CVSROOT/CVSROOT/commitlog} に追記します。
11057: 次に全ての管理用ファイル (@file{CVSROOT} 内) の
11058: 格納時のログを @file{/usr/adm/cvsroot-log} に追記します。
11059: @file{prog1} ディクトリへの格納は @t{ceder} にメールで送られます。
11060: 
11061: @c FIXME: is it a CVS feature or bug that only the
11062: @c first matching line is used?  It is documented
11063: @c above, but is it useful?  For example, if we wanted
11064: @c to run both "cvs-log" and "Mail" for the CVSROOT
11065: @c directory, it is kind of awkward if
11066: @c only the first matching line is used.
11067: @example
11068: ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
11069: ^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
11070: ^prog1          Mail -s %s ceder
11071: @end example
11072: 
11073: シェル・スクリプト @file{/usr/local/bin/cvs-log} の内容:
11074: 
11075: @example
11076: #!/bin/sh
11077: (echo "------------------------------------------------------";
11078:  echo -n $2"  ";
11079:  date;
11080:  echo;
11081:  cat) >> $1
11082: @end example
11083: 
11084: @node Keeping a checked out copy
11085: @appendixsubsec 取得済のコピーを最新に保つ
11086: 
11087: @c What other index entries?  It seems like
11088: @c people might want to use a lot of different
11089: @c words for this functionality.
11090: @cindex keeping a checked out copy
11091: @cindex checked out copy, keeping
11092: @cindex web pages, maintaining with CVS
11093: 
11094: あるディレクトリがリポジトリで管理されている場合、
11095: そのディレクトリを常に最新にしておきたい事があるでしょう。
11096: 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、
11097: @sc{cvs} で保守されたウェブ・サイトのファイルを
11098: 格納毎に更新したい場合などです。
11099: @c Can we offer more details on the web example?  Or
11100: @c point the user at how to figure it out?  This text
11101: @c strikes me as sufficient for someone who already has
11102: @c some idea of what we mean but not enough for the naive
11103: @c user/sysadmin to understand it and set it up.
11104: 
11105: これを実現するため、
11106: @code{cvs update} を実行するように @file{loginfo} を設定します。
11107: しかし単純に設定するとロックの問題が発生するので、
11108: @code{cvs update} をバックグラウンドで実行する必要があります。
11109: @c Should we try to describe the problem with locks?
11110: @c It seems like a digression for someone who just
11111: @c wants to know how to make it work.
11112: @c Another choice which might work for a single file
11113: @c is to use "cvs -n update -p" which doesn't take
11114: @c out locks (I think) but I don't see many advantages
11115: @c of that and we might as well document something which
11116: @c works for multiple files.
11117: Unix での例を以下に示します (実際は一行です):
11118: 
11119: @example
11120: ^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
11121:  cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
11122: @end example
11123: 
11124: リポジトリ中の @code{cyclic-pages} で始まるディレクトリに
11125: ファイルが格納された時、
11126: 取得済みのディレクトリ @file{/u/www/local-docs} を更新します。
11127: @c More info on some of the details?  The "sleep 2" is
11128: @c so if we are lucky the lock will be gone by the time
11129: @c we start and we can wait 2 seconds instead of 30.
11130: 
11131: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11132: @node rcsinfo
11133: @appendixsec 管理用ファイル rcsinfo
11134: @cindex rcsinfo (admin file)
11135: @cindex Form for log message
11136: @cindex Log message template
11137: @cindex Template for log message
11138: 
11139: @file{rcsinfo} には、格納時にログ・メッセージを
11140: 書き込むための書式を指定します。@file{rcsinfo} の
11141: 構文は @file{verifymsg}, @file{commitinfo}, @file{loginfo} 
11142: とほぼ同じです。@xref{syntax}.
11143: しかし他のファイルと異なり、
11144: 第二項はコマンド行形式では@emph{ありません}。
11145: 正規表現の次の部分は、ログ・メッセージの雛型を記した
11146: ファイルへのフルパス名でなくてはいけません。
11147: 
11148: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11149: ファイル中のどの正規表現にも合致しない場合に適用されます。
11150: 
11151: 第一項が @samp{ALL} である行全てが、
11152: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11153: 
11154: @c FIXME: should be offering advice, somewhere around
11155: @c here, about where to put the template file.  The
11156: @c verifymsg example uses /usr/cvssupport but doesn't
11157: @c say anything about what that directory is for or
11158: @c whether it is hardwired into CVS or who creates
11159: @c it or anything.  In particular we should say
11160: @c how to version control the template file.  A
11161: @c probably better answer than the /usr/cvssupport
11162: @c stuff is to use checkoutlist (with xref to the
11163: @c checkoutlist doc).
11164: @c Also I am starting to see a connection between
11165: @c this and the Keeping a checked out copy node.
11166: @c Probably want to say something about that.
11167: ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。
11168: しかし、@samp{cvs commit -m @var{message}} や @samp{cvs commit -f
11169: @var{file}} によってログ・メッセージを指定した場合、
11170: こちらが優先されます。
11171: 
11172: @file{rcsinfo} ファイルの記述例は @xref{verifymsg}.
11173: 
11174: @sc{CVS} が別のマシンのリポジトリを利用している場合、
11175: 最初に作業ディレクトリを取り出した時に @file{rcsinfo} に
11176: 記述されていた雛型が使用され、以後変更されません。
11177: @file{rcsinfo} や雛型を変更した場合には、
11178: 新たに作業ディレクトリを取り出す必要があります。
11179: @c Would be nice to fix CVS so this isn't needed.  For
11180: @c example, a mechanism analogous to CVS/Entries, where
11181: @c the client keeps track of what version of the template
11182: @c it has.
11183: 
11184: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11185: @node cvsignore
11186: @appendixsec cvsignore でファイルを無視する
11187: @cindex cvsignore (admin file), global
11188: @cindex Global cvsignore
11189: @cindex Ignoring files
11190: @c -- This chapter should maybe be moved to the
11191: @c tutorial part of the manual?
11192: 
11193: 作業コピーの中に、いつも決まった名前のファイルがあるけれど、
11194: @sc{cvs} の管理下には置きたくないという場合がよくあります。
11195: 例えば、ソースのコンパイル時に生成される
11196: オブジェクト・ファイルなどです。
11197: @samp{cvs update} を実行した場合には通常、
11198: これらのファイル各々に対して、
11199: 知らないファイルがあったと出力されます 
11200: (@pxref{update output})。
11201: 
11202: @sc{cvs} は、@code{update}, @code{import}, @code{release}
11203: @c -- 影響があるのはこの三つで全部か?
11204: の実行時に無視すべきファイルのリストを 
11205: (sh(1) のファイル名形式で) 保持します
11206: このリストは、以下の方法で構築されます。
11207: 
11208: @itemize @bullet
11209: @item
11210: リストは以下のファイル名形式で初期化されます: 
11211: これらは、@sc{cvs} の管理に関するものの他、
11212: 他のソース管理システムと共通のもの、
11213: 一般的なパッチ・ファイル名、オブジェクト・ファイル、
11214: 書庫ファイル、エディタのバックアップ・ファイル、
11215: 他のユーティリティの通常の生成ファイル名等から構成されます。
11216: 現在、既定で無視されるファイル名形式のリストを以下に挙げます:
11217: 
11218: @cindex Ignored files
11219: @cindex Automatically ignored files
11220: @example
11221:     RCS     SCCS    CVS     CVS.adm
11222:     RCSLOG  cvslog.*
11223:     tags    TAGS
11224:     .make.state     .nse_depinfo
11225:     *~      #*      .#*     ,*      _$*     *$
11226:     *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
11227:     *.a     *.olb   *.o     *.obj   *.so    *.exe
11228:     *.Z     *.elc   *.ln
11229:     core
11230: @end example
11231: 
11232: @item
11233: リポジトリ毎のリスト 
11234: @file{$CVSROOT/CVSROOT/cvsignore} が存在すれば、
11235: その内容がリストに付加されます。
11236: 
11237: @item
11238: 使用者毎のリスト @file{.cvsignore} が
11239: あなたのホーム・ディレクトリに存在すれば、
11240: その内容がリストに付加されます。
11241: 
11242: @item
11243: 環境変数 @code{$CVSIGNORE} の内容全てがリストに付加されます。
11244: 
11245: @item
11246: @samp{-I} オプションによって @sc{cvs} に与えられた内容が、
11247: リストに付加されます。
11248: 
11249: @item
11250: 作業ディレクトリを一通り見て @file{.cvsignore} があれば、
11251: その内容をリストに付加します。
11252: @file{.cvsignore} 内の形式は、
11253: それが含まれるディレクトリのみで有効であり、
11254: サブディレクトリに対しては効果を持ちません。
11255: @end itemize
11256: 
11257: 上記五つのファイル内で単感嘆符 (@samp{!}) を記述すると、
11258: 無視するファイルのリストが空になります。
11259: これは、通常は @sc{cvs} に無視されるファイルを、
11260: リポジトリに格納したい場合に使用します。
11261: 
11262: @code{cvs import} に @samp{-I !} を指定すると、全てを持ち込み、それは
11263: 素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
11264: でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
11265: るのがわかると思います。もし配布に @file{.cvsignore} ファイルがあると、
11266: そのファイルの形式は @samp{-I !} が指定されたとしても実行されます。唯
11267: 一の対策は持ち込むために、@file{.cvsigonre} ファイルを消去することです。
11268: これはやっかいなので、将来は @samp{-I !} はそれぞれのディレクトリの
11269: @file{.cvsignore} ファイルを上書きするように修正されるかもしれません。
11270: 
11271: 無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ
11272: れぞれの行が続いたものであることに注意してください。これは空白のある
11273: ファイル名を指定する綺麗な方法を提供しませんが、@file{foo bar} という
11274: 名前のファイルに合致させるために @file{foo?bar} のような対策を使うこと
11275: ができます (@file{fooxbar} などにも合致します)。また、現在は註釈を指定
11276: する方法が無いことにも注意してください。
11277: @c FIXCVS?  I don't _like_ this syntax at all, but
11278: @c changing it raises all the usual compatibility
11279: @c issues and I'm also not sure what to change it to.
11280: 
11281: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11282: @node history file
11283: @appendixsec ファイル history
11284: @cindex History file
11285: @cindex Log information, saving
11286: 
11287: ファイル @file{$CVSROOT/CVSROOT/history} は、
11288: @code{history} コマンドのためにログ情報を記録します 
11289: (@pxref{history})。
11290: ログを記録したい場合には、このファイルを作成する必要があります。
11291: @code{cvs init} でリポジトリを準備すると、
11292: 自動的に作成されます (@pxref{Creating a repository})。
11293: 
11294: @file{history} ファイルの書式を説明したものは、
11295: @sc{cvs} ソース・コード内の註釈しかありません。
11296: @sc{cvs} の将来のリリースで書式が変更されるかも知れないので、
11297: このファイルは必ず @code{cvs history} を通して利用して下さい。
11298: 
11299: @node Variables
11300: @appendixsec 管理用ファイルにおける変数展開
11301: 
11302: 管理用ファイルを記述するときに、@sc{cvs} の動作環境についての
11303: 色々な情報を利用したい場合があると思います。
11304: ここでは、その実現方法を幾つか紹介します。
11305: 
11306: @sc{cvs} を実行した人物のホーム・ディレクトリを 
11307: (環境変数 @code{HOME} から) 参照するには、
11308: @samp{/} または行端の直前に @samp{~} を記述します。
11309: 同様に @var{user} のホーム・ディレクトリは、
11310: @samp{~@var{user}} と記述します。
11311: これらの変数はサーバ側で展開されるため、@code{pserver} 
11312: (@pxref{Password authenticated}) を用いる場合には正しく展開されません。
11313: この場合、@sc{cvs} を実行する人物が動作を変更できるように、
11314: ユーザ変数 (下記参照) を用いると良いでしょう。
11315: @c Based on these limitations, should we deprecate ~?
11316: @c What is it good for?  Are people using it?
11317: 
11318: @sc{cvs} 内部の情報を参照したい場合もあると思います。
11319: @sc{cvs} の内部変数は @code{$@{@var{variable}@}} という書式で参照できます。
11320: この @var{variable} は文字で始まり、
11321: アルファベットと @samp{_} から構成されます。
11322: @var{variable} に続く文字がアルファベットや @samp{_} でない場合は、
11323: @samp{@{} と @samp{@}} とを省略しても構いません。
11324: 参照可能な @sc{cvs} の内部変数には次のようなものがあります:
11325: 
11326: @table @code
11327: @item CVSROOT
11328: @sc{cvs} が使用中のルート・ディレクトリを示します。
11329: ルート・ディレクトリの指定方法は、@xref{Repository}.
11330: 
11331: @item RCSBIN
11332: @sc{cvs} 1.9.18 以前では、これは @sc{cvs} が @sc{rcs} プログラムを探す
11333: 場所を指定していました。@sc{cvs} はもう @sc{rcs} プログラムを実行しま
11334: せんので、今はこの内部変数を指定するとエラーになります。
11335: 
11336: @item CVSEDITOR
11337: @itemx VISUAL
11338: @itemx EDITOR
11339: これらは @sc{cvs} が使用するエディタを示し、
11340: 全て同じ値に展開されます。
11341: 指定方法の説明は、@xref{Global options}.
11342: 
11343: @item USER
11344: @sc{cvs} を実行する人物の (@sc{cvs} サーバでの) 名前に展開されます。
11345: @end table
11346: 
11347: ユーザ変数を用いれば、@sc{cvs} を実行する人物が、
11348: 管理用ファイルで用いる値を自由に設定できます。
11349: ユーザ変数は、管理用ファイルに @code{$@{=@var{variable}@}} と記述します。
11350: ユーザ変数の設定は、@sc{cvs} の広域オプション @samp{-s} に、
11351: 引数 @code{@var{variable}=@var{value}} を続けます。
11352: このオプションは @file{.cvsrc} に記述しておくと良いでしょう 
11353: (@pxref{~/.cvsrc})。
11354: 
11355: 例として、実験用ディレクトリを管理用ファイルから参照するため、
11356: ユーザ変数 @code{TESTDIR} を用います。それから、以下のように @sc{cvs}
11357: を起動し、
11358: 
11359: @example
11360: cvs -s TESTDIR=/work/local/tests
11361: @end example
11362: 
11363: @noindent
11364: 管理ファイルに @code{sh $@{=TESTDIR@}/runtests} と書いてあれば、文字列
11365: は @code{sh /work/local/tests/runtests} に展開されます。
11366: 
11367: @samp{$} が上記以外の解釈を受けることはありません。
11368: また @samp{$} 自身を表現する別の方法も用意されてないため、
11369: @samp{$} という文字を引用することはできません。
11370: 
11371: @node config
11372: @appendixsec The CVSROOT/config configuration file
11373: 
11374: @cindex config, in CVSROOT
11375: @cindex CVSROOT/config
11376: 
11377: 管理ファイル @file{config} は @sc{cvs} の振舞いに影響するいろいろな雑
11378: 多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ
11379: れません。@samp{#} で始まる行は註釈と解釈されます。
11380: @c FIXME: where do we define comments for the other
11381: @c administrative files.
11382: 他の行はキーワード、@samp{=}、値からなります。この構文は厳密であること
11383: に注意してください。余分な空白やタブは使えません。
11384: @c See comments in parseinfo.c:parse_config for more
11385: @c discussion of this strictness.
11386: 
11387: 現在定義されているキーワードは:
11388: 
11389: @table @code
11390: @cindex RCSBIN, in CVSROOT/config
11391: @item RCSBIN=@var{bindir}
11392: @sc{cvs} 1.9.12 から 1.9.18 まで、この設定は @var{bindir} ディレクトリ
11393: にある @sc{rcs} プログラムを探すように @sc{cvs} に教えるために使われて
11394: いました。現在のバージョンの @sc{cvs} は @sc{rcs} プログラムを実行しま
11395: せん。互換性のためのこの設定は可能になってますが、何も起こりません。
11396: 
11397: @cindex SystemAuth, in CVSROOT/config
11398: @item SystemAuth=@var{value}
11399: @var{value} が @samp{yes} であれば、pserver は使用者を調べるときに、
11400: @file{CVSROOT/passwd} に見つからなければ、システムのデータベースを調べ
11401: にいきます。@samp{no} であれば、全ての使用者は @file{CVSROOT/passwd} 
11402: に存在している必要があります。既定値は @samp{yes} です。pserver につい
11403: ては、@ref{Password authenticated} を参照してください。
11404: 
11405: @cindex PreservePermissions, in CVSROOT/config
11406: @item PreservePermissions=@var{value}
11407: リポジトリでの、特別なデバイスファイル、シンボリック・リンク、ファイル
11408: 仕様許可、所有権に関する機能を使用可にします。既定値は @samp{no} です。
11409: このキーワード使用の完全な意味は @xref{Special Files}.
11410: 
11411: @cindex TopLevelAdmin, in CVSROOT/config
11412: @item TopLevelAdmin=@var{value}
11413: @samp{checkout} コマンドが取り出されたディレクトリ中に作成される 
11414: @samp{CVS} に加えて、新しい作業ディレクトリの最上位にも @samp{CVS} ディ
11415: レクトリを作成するように修正します。既定値は @samp{no} です。
11416: 
11417: このオプションは、取り出されたサブディレクトリではなく、最上位のディレ
11418: クトリで多くのコマンドを実行するときに便利です。そこに作成される
11419: @samp{CVS} ディレクトリにより、それぞれのコマンドに @samp{CVSROOT} を
11420: 指定する必要がなくなります。@samp{CVS/Template} ファイルの場所も提供し
11421: ます (@pxref{Working directory storage})。
11422: @end table
11423: 
11424: @c ---------------------------------------------------------------------
11425: @node Environment variables
11426: @appendix CVS に影響する全ての環境変数
11427: @cindex Environment variables
11428: @cindex Reference manual for variables
11429: 
11430: これは、@sc{cvs} に影響する全ての環境変数の
11431: 完全なリストです。
11432: 
11433: @table @code
11434: @cindex CVSIGNORE, environment variable
11435: @item $CVSIGNORE
11436: @sc{cvs} が無視するファイル名を、
11437: 空白で区切ったリストです。@xref{cvsignore}.
11438: 
11439: @cindex CVSWRAPPERS, environment variable
11440: @item $CVSWRAPPERS
11441: @sc{cvs} が wrapper として扱うファイル名形式を
11442: 空白で区切ったリストです。@xref{Wrappers}.
11443: 
11444: @cindex CVSREAD, environment variable
11445: @cindex read-only files, and CVSREAD
11446: @item $CVSREAD
11447: この変数が設定されていると、
11448: @code{checkout} と @code{update} により作成される作業コピーが、
11449: 強制的に読み込み専用となります。
11450: 設定しなければ、作業ファイルの修正許可が与えられます。
11451: 
11452: @item $CVSUMASK
11453: リポジトリのファイルの使用許可を制御します。@ref{File permissions} を
11454: 参照してください。
11455: 
11456: @item $CVSROOT
11457: (@sc{rcs} のファイルが置かれる) 
11458: @sc{cvs} のリポジトリのルート・ディレクトリを、
11459: 絶対パスで指定しなければいけません。
11460: @sc{cvs} の大部分のコマンドを実行するときに、
11461: この情報が利用されます。
11462: @code{$CVSROOT} が設定されていない場合や、
11463: 他のものを優先させたい場合には、
11464: コマンド行で @samp{cvs -d cvsroot cvs_command@dots{}} 
11465: としてリポジトリを指定することができます。
11466: 一旦作業ディレクトリを取り出した後は、
11467: @sc{cvs} が適切なリポジトリを (@file{CVS/Root} に) 記録します。
11468: 従って、最初に作業ディレクトリを取り出す時を除いて、
11469: 通常はこの値に注意する必要はありません。
11470: 
11471: @item $EDITOR
11472: @itemx $CVSEDITOR
11473: 格納時のログ・メッセージを記録する際に、使用するプログラムを指定します。
11474: @code{$CVSEDITOR} は @code{$EDITOR} よりも優先されます。
11475: @ref{Committing your changes} を参照してください。
11476: 
11477: @cindex PATH, environment variable
11478: @item $PATH
11479: @code{$RCSBIN} が設定されておらず、
11480: @sc{cvs} にパス名が埋め込まれていない場合、
11481: 使用する全てのプログラムを捜す時に @code{$PATH} が使用されます。
11482: 
11483: @cindex HOME, environment variable
11484: @item $HOME
11485: @cindex HOMEPATH, environment variable
11486: @item $HOMEPATH
11487: @cindex HOMEDRIVE, environment variable
11488: @item $HOMEDRIVE
11489: これを使用して、@file{.cvsrc} やそのような他のファイルが置かれたディレ
11490: クトリを捜します。Unix では、CVS は HOME だけを調べます。Windows NT で
11491: は、システムは HOMEDRIVE を例えば @samp{d:} に、HOMEPATH を例えば 
11492: @file{\joe} に設定します。Windows 95 ではおそらく自分自身で HOMEDRIVE
11493: と HOMEPATH を設定する必要があるでしょう。
11494: @c We are being vague about whether HOME works on
11495: @c Windows; see long comment in windows-NT/filesubr.c.
11496: 
11497: @cindex CVS_RSH, environment variable
11498: @item $CVS_RSH
11499: 接続経路に @code{:ext:} が指定された時、
11500: @sc{cvs} が接続に使用する外部プログラムを
11501: 指定します。@pxref{Connecting via rsh}。
11502: 
11503: @item $CVS_SERVER
11504: @sc{rsh} を用いたクライアント/サーバ・モードで、
11505: 別のマシンのリポジトリを利用する時に使用されます。
11506: @sc{rsh} を用いて別のマシンのリポジトリを利用する時に、
11507: サーバ側で起動するプログラムの名前を指定します。
11508: 既定値は @code{cvs} です。@pxref{Connecting via rsh}。
11509: 
11510: @item $CVS_PASSFILE
11511: クライアント/サーバ・モードで、
11512: @samp{cvs login @var{server}} が実行された時に使用されます。
11513: 既定値は @file{$HOME/.cvspass} です。
11514: @pxref{Password authentication client}。
11515: 
11516: @item $CVS_CLIENT_PORT
11517: ケルベロスを用いたクライアント/サーバ・モードで
11518: 使用されます。@pxref{Kerberos authenticated}。
11519: 
11520: @cindex CVS_RCMD_PORT, environment variable
11521: @item $CVS_RCMD_PORT
11522: クライアント/サーバ・モードで使用されます。
11523: これを設定した場合、サーバの @sc{rcmd} デーモンを利用する時に、
11524: ここで指定したポート番号が使用されます。
11525: (現在 @sc{unix} クライアントでは使用されません)。
11526: 
11527: @cindex CVS_CLIENT_LOG, environment variable
11528: @item $CVS_CLIENT_LOG
11529: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11530: これを設定した場合、
11531: サーバに送られた全てが @file{@code{$CVS_CLIENT_LOG}.in} に記録され、
11532: サーバから送られた全てが @file{@code{$CVS_CLIENT_LOG}.out} に
11533: 記録されます。
11534: 
11535: @cindex CVS_SERVER_SLEEP, environment variable
11536: @item $CVS_SERVER_SLEEP
11537: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11538: これを設定して、子プロセスを起動する前に指定した秒数を待ち、
11539: デバッガを応答させます。
11540: 
11541: @cindex CVS_IGNORE_REMOTE_ROOT, environment variable
11542: @item $CVS_IGNORE_REMOTE_ROOT
11543: (この変数の目的は何?)
11544: 
11545: @cindex COMSPEC, environment variable
11546: @item $COMSPEC
11547: OS/2 だけで使用されます。コマンド解釈プログラムを指定します。
11548: 既定値は @sc{cmd.exe} です。
11549: 
11550: @cindex TMPDIR, environment variable
11551: @item $TMPDIR
11552: @cindex TMP, environment variable
11553: @itemx $TMP
11554: @cindex TEMP, environment variable
11555: @itemx $TEMP
11556: @cindex temporary files, location of
11557: @c This is quite nuts.  We don't talk about tempnam
11558: @c or mkstemp which we sometimes use.  The discussion
11559: @c of "Global options" is semi-incoherent.
11560: @c I'm not even sure those are the only inaccuracies.
11561: @c Furthermore, the conventions are
11562: @c pretty crazy and they should be simplified.
11563: 一時ファイルが置かれるディレクトリを指定します。
11564: @sc{cvs} サーバは @code{TMPDIR} を使用します。
11565: この指定方法は、@ref{Global options} 参照。
11566: @sc{cvs} には、(システムが提供する @code{_tmpnam} 関数経由で) 
11567: 常に @file{/tmp} を使用する部分があります。
11568: 
11569: Windows NT では (システムが提供する @code{_tempnam} 関数経由で)、
11570: @code{TMP} が使用されます。
11571: 
11572: @sc{cvs} のクライアントが用いる @code{patch} プログラムは、
11573: @code{TMPDIR} を使用します。
11574: 設定されていない場合、(少なくとも GNU patch 2.1 は) 
11575: @file{/tmp} を使用します。
11576: サーバとクライアントの両方共が @sc{cvs} 1.9.10 以降を実行しているなら、
11577: @sc{cvs} は外部の @code{patch} プログラムを呼び出しません。
11578: @end table
11579: 
11580: @node Compatibility
11581: @appendix CVS のバージョン間の互換性
11582: 
11583: @cindex CVS, versions of
11584: @cindex versions, of CVS
11585: @cindex compatibility, between CVS versions
11586: @c We don't mention versions older than CVS 1.3
11587: @c on the theory that it would clutter it up for the vast
11588: @c majority of people, who don't have anything that old.
11589: @c
11590: リポジトリの形式は @sc{cvs} 1.3 から互換です。@sc{cvs} 1.6 以前を使っ
11591: ていて、オプションの開発者間通信機能を使いたいときは、@ref{Watches
11592: Compatibility} を参照してください。
11593: @c If you "cvs rm" and commit using 1.3, then you'll
11594: @c want to run "rcs -sdead <file,v>" on each of the
11595: @c files in the Attic if you then want 1.5 and
11596: @c later to recognize those files as dead (I think the
11597: @c symptom if this is not done is that files reappear
11598: @c in joins).  (Wait: the above will work but really to
11599: @c be strictly correct we should suggest checking
11600: @c in a new revision rather than just changing the
11601: @c state of the head revision, shouldn't we?).
11602: @c The old convert.sh script was for this, but it never
11603: @c did get updated to reflect use of the RCS "dead"
11604: @c state.
11605: @c Note: this is tricky to document without confusing
11606: @c people--need to carefully say what CVS version we
11607: @c are talking about and keep in mind the distinction
11608: @c between a
11609: @c repository created with 1.3 and on which one now
11610: @c uses 1.5+, and a repository on which one wants to
11611: @c use both versions side by side (e.g. during a
11612: @c transition period).
11613: @c Wait, can't CVS just detect the case in which a file
11614: @c is in the Attic but the head revision is not dead?
11615: @c Not sure whether this should produce a warning or
11616: @c something, and probably needs further thought, but
11617: @c it would appear that the situation can be detected.
11618: @c
11619: @c We might want to separate out the 1.3 compatibility
11620: @c section (for repository & working directory) from the
11621: @c rest--that might help avoid confusing people who
11622: @c are upgrading (for example) from 1.6 to 1.8.
11623: @c
11624: @c A minor incompatibility is if a current version of CVS
11625: @c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
11626: @c see this as if there is no tag.  Seems to me this is
11627: @c too obscure to mention.
11628: 
11629: 作業ディレクトリ形式は @sc{cvs} 1.5 から互換です。@sc{cvs} 1.3 と 
11630: @sc{cvs} 1.5 の間で変更されました。@sc{cvs} 1.3 で取り出されたディレク
11631: トリで @sc{cvs} 1.5 か、それより新しいものを実行すると、@sc{cvs} はそ
11632: れを変換しますが、@sc{cvs} 1.3 に戻るためには、新しい作業ディレクトリ
11633: を @sc{cvs} 1.3 で取り出す必要があります。
11634: 
11635: 遠隔プロトコルは @sc{cvs} 1.5 から相互作用可能ですが、それ以前では無理
11636: です (1.5 が遠隔プロトコルのある最初の公的リリースですが、古いバージョ
11637: ンがまだあたりをうろついているかもしれません)。しかし、多くの場合、新
11638: しい機能とバグ修正の利点を得るためにクライアントとサーバの両方を更新す
11639: る必要があります。
11640: 
11641: @c Perhaps should be saying something here about the
11642: @c "D" lines in Entries (written by CVS 1.9; 1.8 and
11643: @c older don't use them).  These are supposed to be
11644: @c compatible in both directions, but I'm not sure
11645: @c they quite are 100%.  One common gripe is if you
11646: @c "rm -r" a directory and 1.9 gets confused, as it
11647: @c still sees it in Entries.  That one is fixed in
11648: @c (say) 1.9.6.  Someone else reported problems with
11649: @c starting with a directory which was checked out with
11650: @c an old version, and then using a new version, and
11651: @c some "D" lines appeared, but not for every
11652: @c directory, causing some directories to be skipped.
11653: @c They weren't sure how to reproduce this, though.
11654: 
11655: @c ---------------------------------------------------------------------
11656: @node Troubleshooting
11657: @appendix 問題の解決
11658: 
11659: @sc{cvs} の使用に問題があれば、この付録が役立つかもしれません。特定の
11660: エラーメッセージが出ているなら、そのメッセージをアルファベット順に探す
11661: ことができます。そうでない場合は、他の問題の章を眺めて説明されているか
11662: どうかを知ることができます。
11663: 
11664: @menu
11665: * Error messages::              CVS のエラーの部分的一覧
11666: * Connection::                  CVS サーバへの接続での問題
11667: * Other problems::              エラーメッセージで既に挙げられていない問題
11668: @end menu
11669: 
11670: @ignore
11671: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11672: @c @node Bad administrative files
11673: @appendixsec Bad administrative files
11674: 
11675: @c -- Give hints on how to fix them
11676: @end ignore
11677: 
11678: @node Error messages
11679: @appendixsec エラーメッセージの部分的一覧
11680: 
11681: これは @sc{cvs} で起こるかもしれないエラー・メッセージの部分的な一覧で
11682: す。完全な一覧ではありません---@sc{cvs} はたくさん、たくさんのエラー・
11683: メッセージを印字する能力があり、しばしば一部分はオペレーティング・シス
11684: テムにより提供されます。しかし、ここでの意図はよくあるもの、混乱する可
11685: 能性のあるエラー・メッセージの、両方もしくはどちらかにあてはまるものの
11686: 一覧を挙げることです。
11687: 
11688: メッセージはアルファベット順ですが、@samp{cvs update: } のような前置き
11689: の文章は順番にするときには省かれています。
11690: 
11691: この一覧は古いバージョンの @sc{cvs} で印字されるメッセージがある場合も
11692: あります (使用者は特定の時にどのバージョンの @sc{cvs} を使用しているか
11693: を必ずしも知らないというのが理由の一つです)。
11694: @c If we want to start retiring messages, perhaps we
11695: @c should pick a cutoff version (for example, no more
11696: @c messages which are specific to versions before 1.9)
11697: @c and then move the old messages to an "old messages"
11698: @c node rather than deleting them completely.
11699: 
11700: @table @code
11701: @c FIXME: What is the correct way to format a multiline
11702: @c error message here?  Maybe @table is the wrong
11703: @c choice?  Texinfo gurus?
11704: @item cvs @var{command}: authorization failed: server @var{host} rejected access
11705: これは pserver のサーバに接続しようとして、それが特定の理由を教えるこ
11706: となく認証を拒否することを選んだときの一般的な反応です。指定された使用
11707: 者名とパスワードが正しいことと、指定された CVSROOT が inetd.conf の 
11708: --allow-root で使用可になっているこを確認してください。
11709: 
11710: @item @var{file}:@var{line}: Assertion '@var{text}' failed
11711: システムによってこのメッセージの正確な形式は異なります。これは 
11712: @sc{cvs} のバグを示し、@ref{BUGS} で説明されているように扱うことができ
11713: ます。
11714: 
11715: @item cvs @var{command}: conflict: removed @var{file} was modified by second party
11716: このメッセージは、あなたがファイルを消去し、誰か別の人がそれを修正した
11717: ということを示します。衝突を解消するために、まず @samp{cvs add
11718: @var{file}} を実行します。それが望まれていれば、他の人々の修正を見てま
11719: だそれを消したいかどうかを決定します。消したくなければ、ここで止めます。
11720: 消去したければ、 @samp{cvs remove @var{file}} を実行して、削除を格納し
11721: ます。
11722: @c Tests conflicts2-142b* in sanity.sh test for this.
11723: 
11724: @item cannot change permissions on temporary directory
11725: @example
11726: Operation not permitted
11727: @end example
11728: このメッセージは、Red Hat Linux 3.0.3 と 4.1 でクライアント/サーバのテ
11729: スト一式を実行しているときいに、再現不可能な方法でときどき発生しました。
11730: 我々は何がそれを起こしたのか、また linux (もしくは、このマシンそのもの!) 
11731: に特有かどうかも分かりません。他の unix でも問題が発生した場合は、おそ
11732: らく @samp{Operation not permitted} は @samp{Not owner} や当のシステム
11733: が unix の @code{EPERM} エラーで使用している他のものになっているでしょ
11734: う。追加の情報があれば、@ref{BUGS} で説明されているように我々に知らせ
11735: てください。もし @sc{cvs} を使用していてこのエラーを経験したときは、そ
11736: れを発生させた操作をもう一度繰り返すとちゃんと動作するでしょう。
11737: @c This has been seen in a variety of tests, including
11738: @c multibranch-2, multibranch-5, and basic1-24-rm-rm,
11739: @c so it doesn't seem particularly specific to any one
11740: @c test.
11741: 
11742: @c For one example see basica-1a10 in the testsuite
11743: @c For another example, "cvs co ." on NT; see comment
11744: @c at windows-NT/filesubr.c (expand_wild).
11745: @c For another example, "cvs co foo/bar" where foo exists.
11746: @item cannot open CVS/Entries for reading: No such file or directory
11747: これは一般的に @sc{cvs} の内部エラーを示し、他の @sc{cvs} のバグと同様
11748: に扱うことがきます (@pxref{BUGS})。たいていの場合、対策があります---正
11749: 確な方法は状況に依りますが、おそらく見付け出すことができるでしょう。
11750: 
11751: @c This is more obscure than it might sound; it only
11752: @c happens if you run "cvs init" from a directory which
11753: @c contains a CVS/Root file at the start.
11754: @item cvs [init aborted]: cannot open CVS/Root: No such file or directory
11755: このメッセージは無害です。もし他のエラーと一緒にでなければ、操作は成功
11756: しています。現在のバージョンの @sc{cvs} では出ないはずですが、@sc{cvs}
11757: 1.9 以前のために説明されています。
11758: 
11759: @item cvs [checkout aborted]: cannot rename file @var{file} to CVS/,,@var{file}: Invalid argument
11760: このメッセージは Solaris 2.5 上での CVS 1.9 でときどき発生することが報
11761: 告されています。原因は不明です。原因についてさらに知っていれば、
11762: @ref{BUGS} で説明されているように我々に知らせてください。
11763: 
11764: @item cvs [@var{command} aborted]: cannot start server via rcmd
11765: この残念ながらあまり詳しくないメッセージは、@sc{cvs} のクライアントを
11766: 実行していてサーバとの接続に問題があったときに @sc{cvs} 1.9 が印字しま
11767: す。現在のバージョンの @sc{cvs} はもっと詳しいエラーメッセージを印字す
11768: るようになっています。クライアントを実行しようとはしていないのにこのメッ
11769: セージが出たときは、おそらく @ref{Repository} で説明されている方法で 
11770: @code{:local:} を指定することを忘れたのでしょう。
11771: 
11772: @item ci: @var{file},v: bad diff output line: Binary files - and /tmp/T2a22651 differ
11773: CVS 1.9 以前は @sc{rcs} が正しくインストールされていないときにバイナリ
11774: ファイルを格納しようとしたときにこのメッセージを印字します。@sc{rcs} 
11775: の配布とともに取得している指示をもう一度読んで、@sc{cvs} 配布の 
11776: @sc{install} ファイルを読んでください。代替法として、@sc{rcs} を経由し
11777: ないで自分自身でファイルを格納する現在のバージョンの @sc{cvs} に変更す
11778: ることもできます。
11779: 
11780: @item cvs checkout: could not check out @var{file}
11781: CVS 1.9 では、これは @code{co} プログラム (@sc{rcs} プログラムの一部で
11782: す) が失敗の値を返したということです。他のエラーメッセージがその前にあ
11783: るはずですが、別のエラーメッセージなしに発生することも確認されており、
11784: 原因はよくわかっていません。現在のバージョンの CVS は @code{co} を実行
11785: しないので、このメッセージが別のエラーメッセージとともに現れなければ、
11786: それは間違いなく CVS のバグです (@pxref{BUGS})。
11787: @c My current suspicion is that the RCS in the rcs (not
11788: @c cvs/winnt/rcs57nt.zip) directory on the _Practical_
11789: @c CD is bad (remains to be confirmed).
11790: @c There is also a report of something which looks
11791: @c very similar on SGI, Irix 5.2, so I dunno.
11792: 
11793: @item cvs [login aborted]: could not find out home directory
11794: これはホームデレクトリの位置を特定するために CVS が使用する環境変数を
11795: 設定する必要があるということです。@ref{Environment variables} の HOME,
11796: HOMEDRIVE, HOMEPATH の議論を参照してください。
11797: 
11798: @item cvs update: could not merge revision @var{rev} of @var{file}: No such file or directory
11799: CVS 1.9 以前は @code{rcsmerge} プログラムを見つけるときに問題が発生し
11800: たときにこのメッセージを印字します。それが @code{PATH} にあることを確
11801: 認するか、外部 @code{rcsmerge} プログラムを必要としない現在のバージョ
11802: ンの CVS に更新してください。
11803: 
11804: @item cvs [update aborted]: could not patch @var{file}: No such file or directory
11805: これは @code{patch} プログラムの探索に問題があったということです。それ
11806: が @code{PATH} 上にあるとを確認してください。メッセージの外観とは違っ
11807: て、@var{file} を見つけるかどうかについて言っているのでは@emph{ない}こ
11808: とに注意してください。クライアントとサーバが現在のバージョンの 
11809: @sc{cvs} を実行しているなら、外部 patch プログラムは必要ではなく、この
11810: メッセージを見ることはないでしょう。しかし、クライアントかサーバが 
11811: @sc{cvs} 1.9 を実行していれば、@code{patch} が必要です。
11812: 
11813: @item cvs update: could not patch @var{file}; will refetch
11814: これは、何らかの理由により、クライアントはサーバが送った patch を適用
11815: できなかったということです。メッセージは心配するようなものではありませ
11816: ん。これは、patch の適用ができなかったというのはちょっと作業を遅らせる
11817: だけで、@sc{cvs} が実行することには影響しないからです。
11818: @c xref to update output.  Or File status?
11819: @c Or some place else that
11820: @c explains this whole "patch"/P/Needs Patch thing?
11821: 
11822: @item dying gasps from @var{server} unexpected
11823: @sc{cvs} 1.9.18 以前のサーバにはこれを発生する既知のバグがあります。私
11824: は、@samp{-t} 広域オプションを使用しているときに再現可能です。もし興味
11825: があれば、それは Andy Piper の1997年11月4日の src/filesubr.c への変更
11826: で修正されました。このメッセージが出たときは、おそらく失敗した操作をた
11827: だもう一度試すことができます。また、この原因に関して情報を発見したなら、
11828: @ref{BUGS} に書かれているように我々に知らせてください。
11829: 
11830: @item end of file from server (consult above messages if any)
11831: このメッセージの一番多い原因は、外部 @code{rsh} プログラムを使用してい
11832: て、それがエラーを出して終了するというものです。この場合 @code{rsh}
11833: プログラムは、上のメッセージの前にメッセージを印字しているはずです。
11834: @sc{cvs} のクライアントとサーバの設定の情報は @ref{Remote
11835: repositories} を参照してください。
11836: 
11837: @cindex mkmodules
11838: @item cvs commit: Executing 'mkmodules'
11839: これはリポジトリが @sc{cvs} 1.8 より前のバージョンの @sc{cvs} で設定さ
11840: れているということです。@sc{cvs} 1.8 以降を使っていると、上記のメッセー
11841: ジの前に以下のものがでます。
11842: 
11843: @example
11844: cvs commit: Rebuilding administrative file database
11845: @end example
11846: 
11847: 両方のメッセージが表示されれば、データベースは2回再構築されていて、こ
11848: れは不必要ですが、無害です。重複を避けたくて、@sc{cvs} 1.7 以前を使っ
11849: ていないなら、@code{modules} ファイルにある全ての @code{-i mkmodules}
11850: を消してください。@code{modules} ファイルの情報は @ref{modules} を参照
11851: してください。
11852: 
11853: @c This messsage comes from "co", and I believe is
11854: @c possible only with older versions of CVS which call
11855: @c co.  The problem with being able to create the bogus
11856: @c RCS file still exists, though (and I think maybe
11857: @c there is a different symptom(s) now).
11858: @c FIXME: Would be nice to have a more exact wording
11859: @c for this message.
11860: @item missing author
11861: 普通これは使用者名が空の RCS ファイルを作成したときに発生します。CVS
11862: は、間違って author 部分に値のない不正な RCS ファイルを作成します。解
11863: 決策は、使用者名が空でないことを確認して、RCS フィルを再作成することで
11864: す。
11865: @c "make sure your username is set" is complicated in
11866: @c and of itself, as there are the environment
11867: @c variables the system login name, &c, and it depends
11868: @c on the version of CVS.
11869: 
11870: @item *PANIC* administration files missing
11871: これは普通は CVS という名前のディレクトリがあるけれど、CVS が CVS ディ
11872: レクトリに置く管理ファイルがないということです。もし問題が CVS 以外の
11873: 何らかの機構で CVS ディレクトリを作ったというものであれば、CVS 以外の
11874: 名前を使ってください。もしそうでなければ、それは CVS のバグを示してい
11875: ます (@pxref{BUGS})。
11876: 
11877: @item rcs error: Unknown option: -x,v/
11878: このメッセージの後には @sc{rcs} の使用法のメッセージが続きます。それは
11879: 古いバージョンの @sc{rcs} (おそらくオペレーティングシステムと共に提供
11880: されたものでしょう) があるということです。CVS は @sc{rcs} バージョン 5
11881: 以降でのみ動作します。
11882: @c For more information on installing @sc{cvs}, see
11883: @c (FIXME: where?  it depends on whether you are
11884: @c getting binaries or sources or what).
11885: @c The message can also say "ci error" or something
11886: @c instead of "rcs error", I suspect.
11887: 
11888: @item cvs [server aborted]: received broken pipe signal
11889: これは、@sc{cvs} かそれが実行されているシステムの追跡が困難なバグ (良
11890: く判っていません---我々はまだ追いかけていません!) により発生するようで
11891: す。@sc{cvs} コマンドが完了した後でのみ発生するようで、メッセージは無
11892: 視できます。しかしながら、その原因に関する情報を発見したなら、
11893: @ref{BUGS} で説明されているように我々に知らせてください。
11894: 
11895: @item Too many arguments!
11896: このメッセージは普通は @sc{cvs} のソース配布の @file{contrib} ディレク
11897: トリにある @file{log.pl} スクリプトにより印字されます。@sc{cvs} のバー
11898: ジョンには、@file{log.pl} が既定の @sc{cvs} インストールに含まれている
11899: ものもあります。@file{log.pl} スクリプトは @file{loginfo} 管理ファイル
11900: から呼ばれます。@file{loginfo} で渡されている引数があなたのバージョン
11901: の @file{log.pl} が期待するものとあっているか調べてください。特に、
11902: @sc{cvs} 1.3 以前の @file{log.pl} はログファイルを引数として期待します
11903: が、@sc{cvs} 1.5 以降の @file{log.pl} はログファイルは @samp{-f} オプ
11904: ションで指定されることを期待します。もちろん、@file{log.pl} が必要でな
11905: ければ、@file{loginfo} 中で註釈にして、使用しないようにすることができ
11906: ます。
11907: 
11908: @item cvs commit: Up-to-date check failed for `@var{file}'
11909: これはあなたが最後に @code{cvs update} を実行した後に誰かが変更を格納
11910: したということです。ですから、@code{cvs commit} を継続する前に 
11911: @code{cvs update} をする必要があります。CVS はあなたのした変更と他の人
11912: がした変更をマージします。衝突が発見されなれば、@samp{M cacErrCodes.h} 
11913: のように報告され、@code{cvs commit} を実行する準備が整っています。もし
11914: 衝突が発見されれば、その由を印字し、@samp{C cacErrCodes.h} と報告され、
11915: 手で衝突を解消する必要があります。この過程の詳細は @ref{Conflicts
11916: example} を参照してください。
11917: 
11918: @item Usage:	diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
11919: @example
11920: Only one of [exEX3] allowed
11921: @end example
11922: これは @code{diff3} と @code{rcsmerge} のインストールに問題があること
11923: を示しています。特に @code{rcsmerge} は GNU diff3 を探すようにコンパイ
11924: ルされているけれど、代わりに unix の diff3 が使われています。一番簡単
11925: な解決法は外部の @code{rcsmerge} や @code{diff3} プログラムに頼らない
11926: 現在のバージョンの @sc{cvs} に更新することです。
11927: 
11928: @item warning: unrecognized response `@var{text}' from cvs server
11929: もし @var{text} が有効な応答 (@samp{ok} のようなもの) で、続きに余分な
11930: キャリッジリターンがあると (多くのシステムではこれはメッセージの2番目
11931: の部分が1番目の部分を上書きします)、おそらく、既定では透過的なデータス
11932: トリームを提供しない、多くの unix でない rsh のバージョンで 
11933: @samp{:ext:} 接続方法を使用としているのでしょう。その様な場合はたぶん 
11934: @samp{:ext:} の代わりに @samp{:server:} を試みるのが良いでしょう。
11935: @var{text} が何か他のものなら、CVS サーバに問題があることを表します。
11936: CVS サーバを設定するための指示を見てインストールを再度確認してください。
11937: 
11938: @item cvs commit: warning: editor session failed
11939: @cindex exit status, of editor
11940: これは @sc{cvs} が使用しているエディタが非零の値で終了したということで
11941: す。vi のバージョンにはファイルの編集に問題がなかったときでさえそうす
11942: るものがあります。もしそうなら、環境変数 @sc{CVSEDITOR} を以下のような
11943: 小さなスクリプトを指すようにしてください:
11944: 
11945: @example
11946: #!/bin/sh
11947: vi $*
11948: exit 0
11949: @end example
11950: 
11951: @c "warning: foo was lost" and "no longer pertinent" (both normal).
11952: @c Would be nice to write these up--they are
11953: @c potentially confusing for the new user.
11954: @end table
11955: 
11956: @node Connection
11957: @appendixsec CVS サーバに接続をしようとするときの問題
11958: 
11959: この章は @sc{cvs} サーバに接続しようとしたときに問題が起こったときに何
11960: をすれば良いかということを書いています。 Windows で @sc{cvs} コマンド
11961: ライン・クライアントを実行しているなら、まず @sc{cvs} 1.9.12 以降に更
11962: 新してください。以前のバージョンのエラー報告は、問題がどうであったかに
11963: ついて、ほとんど情報を提供しません。クライアントが Windows でなければ、
11964: @sc{cvs} 1.9 は問題ありません。
11965: 
11966: 問題を追いかけるためにエラー・メッセージが十分でなければ、次の手段は使
11967: 用している接続方法によってかなり異なります。
11968: 
11969: @table @code
11970: @cindex :ext:, troubleshooting
11971: @item :ext:
11972: コマンド行からの rsh プログラムの実行を試してください。例えば: "rsh
11973: servername cvs -v" は @sc{cvs} のバージョン情報を印字します。もしこれ
11974: が動作しなければ、@sc{cvs} の問題を気にする前にそれを修正する必要があ
11975: ります。
11976: 
11977: @cindex :server:, troubleshooting
11978: @item :server:
11979: この接続方法を使用するためにコマンド行の rsh プログラムは必要ではあり
11980: ませんが、rsh プログラムがあれば、デバッグ道具として役に立つでしょう。:
11981: ext: のところの指示に従ってください。
11982: 
11983: @cindex :pserver:, troubleshooting
11984: @item :pserver:
11985: 良いデバッグ道具は "telnet servername 2401" です。接続後、任意のテキス
11986: ト (例えば、"foo" リターン)。@sc{cvs} が正しく動作していれば、以下のよ
11987: うに反応するはずです。
11988: 
11989: @example
11990: cvs [pserver aborted]: bad auth protocol start: foo
11991: @end example
11992: 
11993: これの動作に失敗すれば、inetd が正しく動作しているか確認してください。
11994: inetd.conf での起動を cvs の代わりに echo プログラムに変更してください。
11995: 例えば:
11996: 
11997: @example
11998: 2401  stream  tcp  nowait  root /bin/echo echo hello
11999: @end example
12000: 
12001: その変更をして、inetd に設定ファイルを再読み込みするように指示した後で
12002: は、"telnet servername 2401" はテキスト hello を表示して、サーバが接続
12003: を切るはずです。これが動作しなければ、@sc{cvs} の問題を気にする前にそ
12004: れを修正してください。
12005: 
12006: AIX システムでは、システムにポート 2401 を使おうとするプログラムがあり
12007: ます。これは、ポート 2401 は @sc{cvs} での使用に登録されているという点
12008: で AIX の問題です。この問題を解決するために AIX のパッチがあるというこ
12009: とを聞いたことがあります。
12010: @end table
12011: 
12012: @node Other problems
12013: @appendixsec 他のよくある問題
12014: 
12015: これは上の分類には合わない問題の一覧です。順番には特に意味はありません。
12016: 
12017: @itemize @bullet
12018: @item
12019: @sc{cvs} 1.9.18 以前を実行していて、@ref{Conflicts example} で説明され
12020: ているように、@code{cvs update} が衝突を発見し、マージを試みたけれど、
12021: 衝突があることを報告しなかったら、@sc{rcs} の古いバージョンが存在しま
12022: す。一番簡単な解決は、おそらく外部 @sc{rcs} プログラムを使用しない現在
12023: のバージョンの @sc{cvs} に変更することです。
12024: @end itemize
12025: 
12026: @c ---------------------------------------------------------------------
12027: @node Credits
12028: @appendix Credits
12029: 
12030: @cindex Contributors (manual)
12031: @cindex Credits (manual)
12032: 当時 Cygnus Support にいた Roland Pesch <@t{roland@@wrs.com}> 
12033: は @sc{cvs} 1.3 とともに頒布されたマニュアルを書きました。
12034: 記述の多くは、彼の文章から受け継いでいます。
12035: また彼にこのマニュアルの初期の草稿を読んでもらい、
12036: 多くのアイディアと訂正を頂きました。
12037: 
12038: メーリング・リスト @code{info-cvs} も時には有益でした。
12039: 私は以下の人物が行なった投稿による情報を含めました:
12040: David G. Grubbs <@t{dgg@@think.com}>.
12041: 
12042: @sc{rcs} の man からいくつか文章を引用しています。
12043: 
12044: David G. Grubbs 氏による @sc{cvs} @sc{faq} は、
12045: 有用な素地を与えてくれました。
12046: @sc{faq} はもうメンテナンスされていませんが、
12047: このマニュアルが (少くとも @sc{cvs} の使用方法の文書化に関して)、
12048: その後継に最も近いものでしょう。
12049: 
12050: また、次に挙げる人物が、私の誤りを訂正してくれました:
12051: 
12052: @display
12053: Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
12054: Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
12055: Karl Pingle <@t{pingle@@acuson.com}>,
12056: Thomas A Peterson <@t{tap@@src.honeywell.com}>,
12057: Inge Wallin <@t{ingwa@@signum.se}>,
12058: Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>,
12059: Michael Brown <@t{brown@@wi.extrel.com}>.
12060: @end display
12061: 
12062: ここの貢献者の一覧は包括的なものであはありません。このマニュアルへの貢
12063: 献者のより完全な一覧は @sc{cvs} のソース配布のファイル 
12064: @file{doc/ChangeLog} を見てください。
12065: 
12066: @c ---------------------------------------------------------------------
12067: @node BUGS
12068: @appendix CVS かこのマニュアルのバグに対処する
12069: 
12070: @cindex Bugs in this manual or CVS
12071: @sc{cvs} もこのマニュアルも完璧ではなく、また永遠にそうならないでしょ
12072: う。@sc{cvs} を使用していて問題にぶつかったり、バグを見つけたと思った
12073: りしたときは、いろいろな方法があります。また、マニュアルにはっきりしな
12074: いところがあれば、マニュアルのバグと考えられますので、これらの問題も 
12075: @sc{cvs} 自身の問題と同様に行動をするに値します。
12076: 
12077: @cindex Reporting bugs
12078: @cindex Bugs, reporting
12079: @cindex Errors, reporting
12080: @itemize @bullet
12081: @item
12082: 報告したバグを誰かに修正して欲しい場合は、代金と交換にしてくれる会社が
12083: あります。そのような会社は2つあります:
12084: 
12085: @cindex Signum Support
12086: @cindex Cyclic Software
12087: @cindex Support, getting CVS support
12088: @example
12089: Signum Support AB
12090: Box 2044
12091: S-580 02  Linkoping
12092: Sweden
12093: Email: info@@signum.se
12094: Phone: +46 (0)13 - 21 46 00
12095: Fax:   +46 (0)13 - 21 47 00
12096: http://www.signum.se/
12097: 
12098: Cyclic Software
12099: United States of America
12100: http://www.cyclic.com/
12101: info@@cyclic.com
12102: @end example
12103: 
12104: @item
12105: @sc{cvs} をオペレーティング・システムのベンダーやフリーウェアの 
12106: @sc{cd-rom} のベンダーのような配布者から取得していれば、配布者がサポー
12107: トを提供しているかどうかを知りたいでしょう。しばしば、サポートしなかっ
12108: たり、最小限のサポートしか提供しないかもしれませんが、それは配布者によっ
12109: て異なります。
12110: 
12111: @item
12112: もし十分な技能と時間があれば、バグを自分自身で修正しようと思うでしょう。
12113: その修正を将来の @sc{cvs} のリリース含めたいときは、@sc{cvs} のソース
12114: 配布にあるファイル @sc{hacking} を見てください。修正の提出方法に関する
12115: たくさんの情報があります。
12116: 
12117: @item
12118: ネット上に助けになるリソースがあるかもしれません。以下の2つは開始する
12119: 良い場所です:
12120: 
12121: @example
12122: http://www.cyclic.com
12123: http://www.loria.fr/~molli/cvs-index.html
12124: @end example
12125: 
12126: もし非常にやる気になれば、ネット上での情報を増やすと感謝される可能性が
12127: 高いでしょう。例えば、標準の @sc{cvs} 配布が Windows 95 について作業を
12128: する前に、@sc{cvs} を Windows 95 で実行するための説明とパッチのあるウェ
12129: ブページがあり、色々な人がその題がメーリングリストやニュースグループで
12130: 出る度にそのページを知らせることで手助けをしていました。
12131: 
12132: 訳註: 日本語のウェブページは以下のものが良いでしょう。
12133: 
12134: @example
12135: http://www.cyclic.com/cvs/lang-jp.html
12136: http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
12137: @end example
12138: 
12139: @item
12140: バグを @code{bug-cvs} に報告することもできます。誰かがあなたのバグ報告
12141: に対して何かをしようと思うかもしれないし、思わないかもしれない、という
12142: ことに注意してください---もし解決策が必要なら、上の方法のどれかを考慮
12143: してください。ですが、おそらく人々は特に大変な結果になるバグと、簡単に
12144: 修正できるバグの両方、もしくはどちらかに該当するもに関心があるでしょう。
12145: また、バグの本質と他の関係する情報を明確にすることで可能性を高めるこが
12146: できます。バグを報告するためには @code{bug-cvs@@gnu.org} に email を送
12147: ります。@code{bug-cvs} へ送ったものは @sc{gnu} Public License の条件の
12148: 下で配布されるかもしれないことに注意してください。もしこれを好まなけれ
12149: ば、送らないでください。普通は、メールを @code{bug-cvs} ではなく、
12150: @sc{cvs} の管理者に直接送ることの正当性はありません。そのようなバグ報
12151: 告に関心のある管理者は @code{bug-cvs} を読んできます。また、バグ報告を
12152: 他のメーリングリストやニュースグループに送ることは @code{bug-cvs} へ送
12153: る代わりには@emph{ならない}ということにも注意してださい。@sc{cvs} のバ
12154: グをどの場所でも好きなところで議論するのは良いことですが、
12155: @code{bug-cvs} 以外に送られたバグ報告を管理者の誰かが読んでいるとは限
12156: りません。
12157: @end itemize
12158: 
12159: @cindex Known bugs in this manual or CVS
12160: 結構頻繁に、既知のバグの一覧や特定のバグが知られたものかどうかの一覧が
12161: あるかどうかを尋ねられます。@sc{cvs} のソース配布の @sc{bugs} ファイル
12162: は既知のバグのリストの一つですが、必ずしも包括的なものであろうとはして
12163: いません。おそらく、既知のバグの包括的な、詳細な一覧は存在することはな
12164: いでしょう。
12165: 
12166: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
12167: @node Translation
12168: @appendix 日本語訳について
12169: 
12170: この @sc{cvs} のマニュアルは、
12171: @sc{cvs} @value{CVSVN} に付属していた、
12172: @file{cvs.texinfo} を日本語訳したものです。
12173: 文書の構造やノード名等は(この節を除いて)そのまま使用しており、
12174: 文章は自分に可能な限り忠実に訳しています。
12175: 修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。
12176: 
12177: @flushright
12178: 廣保 誠 <@t{hiroyasu@@iedc.mke.mei.co.jp}>
12179: @end flushright
12180: 
12181: @unnumberedsubsec 訳者からの謝辞
12182: 
12183: 大阪大学の西田圭介さんが、引地夫妻に問い合わせてこの文書の
12184: 配布条件の推奨訳を入手したり、一部の下訳を送ってくれたりしました。
12185: また @sc{cvs} について日本語で情報交換するためのメーリング・
12186: リストを立ち上げました。現在このメーリング・リストは
12187: 京都工芸繊維大学の西本卓也さんが引き継いでいます。
12188: 詳細は @file{http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html} 
12189: を参照して下さい。@sc{cvs} 1.9 から @sc{cvs} @value{CVSVN} への更新は
12190: 林芳樹 <g740685@@komaba.ecc.u-tokyo.ac.jp> が行いました。
12191: 
12192: @unnumberedsubsec 日本語訳の配布条件
12193: 
12194: この文書を修正・再配布する場合には、
12195: 原英文の配布条件に従って下さい。
12196: 以下に許諾文の参考訳を付けます。
12197: 
12198: Copyright @copyright{} 1992, 1993 Signum Support AB
12199: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
12200: 
12201: 上記の著作権表示と本許可告知が
12202: すべての写しに前もって載せられている場合にのみ、
12203: 本マニュアルをそのまま複写し配布することを許可します。
12204: 
12205: @ignore
12206: TeX による処理結果に本複写許可告知と同一のものが載せられている場合にのみ、
12207: 本マニュアルのファイルを TeX により出力することを許可します。
12208: (ただし、本段落は TeX の処理結果には表れませんので、
12209: 実際の出力物に本段落は削除されることを除きます。)
12210: 
12211: @end ignore
12212: 本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件の
12213: もとに配布される場合にのみ許可します。
12214: 
12215: 本マニュアルの外国語 (英語以外の言語) への翻訳版の複写と配布は、
12216: 上記の修正版の場合に準じますが、
12217: 本許可告知は Free Software Foundation の許可を得た
12218: 翻訳でなければなりません。
12219: 
12220: @c ---------------------------------------------------------------------
12221: @node Index
12222: @unnumbered Index
12223: @cindex Index
12224: 
12225: @printindex cp
12226: 
12227: @summarycontents
12228: 
12229: @contents
12230: 
12231: @bye
12232: 
12233: Local Variables:
12234: fill-column: 70
12235: End:

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