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

    1: \input texinfo  @c -*-texinfo-*-
    2: @comment Documentation for CVS.
    3: @comment Copyright (C) 1992, 1993 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 (RFC2346).
   33: 
   34: @c This document seems to get overfull hboxes with some
   35: @c frequency (probably because the tendency is to
   36: @c sanity-check it with "make info" and run TeX less
   37: @c often).  The big ugly boxes just seem to add insult
   38: @c to injury, and I'm not aware of them helping to fix
   39: @c the overfull hboxes at all.
   40: @finalout
   41: 
   42: @setfilename cvs-ja.info
   43: @include CVSvn.texi
   44: @settitle CVS---Concurrent Versions System (in Japanese)
   45: @setchapternewpage odd
   46: @iftex
   47: @c @documentlanguage ja
   48: @documentencoding EUC-JP
   49: @end iftex
   50: @c FIXJA
   51: 
   52: @c -- TODO list:
   53: @c -- Fix all lines that match "^@c -- "
   54: @c -- Also places marked with FIXME should be manual
   55: @c problems (as opposed to FIXCVS for CVS problems).
   56: 
   57: @ifinfo
   58: @format
   59: START-INFO-DIR-ENTRY
   60: * CVS-JA: (cvs-ja).        Concurrent Versions System (Japanese)
   61: END-INFO-DIR-ENTRY
   62: @end format
   63: @end ifinfo
   64: 
   65: @ifinfo
   66: Copyright @copyright{} 1992, 1993 Signum Support AB
   67: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
   68: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
   69: Copyright @copyright{} 1999 Yoshiki Hayashi
   70: 
   71: Permission is granted to make and distribute verbatim copies of
   72: this manual provided the copyright notice and this permission notice
   73: are preserved on all copies.
   74: 
   75: @ignore
   76: Permission is granted to process this file through Tex and print the
   77: results, provided the printed document carries copying permission
   78: notice identical to this one except for the removal of this paragraph
   79: (this paragraph not being relevant to the printed manual).
   80: 
   81: @end ignore
   82: Permission is granted to copy and distribute modified versions of this
   83: manual under the conditions for verbatim copying, provided also that the
   84: entire resulting derived work is distributed under the terms of a
   85: permission notice identical to this one.
   86: 
   87: Permission is granted to copy and distribute translations of this manual
   88: into another language, under the above conditions for modified versions,
   89: except that this permission notice may be stated in a translation
   90: approved by the Free Software Foundation.
   91: @end ifinfo
   92: 
   93: @comment The titlepage section does not appear in the Info file.
   94: @titlepage
   95: @sp 4
   96: @comment The title is printed in a large font.
   97: @center @titlefont{CVSによるバージョン管理}
   98: @sp 2
   99: @center Version Management with CVS
  100: @center for @sc{cvs} @value{CVSVN}
  101: @center Per Cederqvist et al
  102: @sp 25
  103: @center 日本語訳 : 廣保 誠, 林 芳樹
  104: 
  105: @comment  The following two commands start the copyright page
  106: @comment  for the printed manual.  This will not appear in the Info file.
  107: @page
  108: @vskip 0pt plus 1filll
  109: Copyright @copyright{} 1992, 1993 Signum Support AB
  110: Copyright @copyright{} 1995-1999 Makoto Hiroyasu
  111: Copyright @copyright{} 1999 Yoshiki Hayashi
  112: 
  113: Permission is granted to make and distribute verbatim copies of
  114: this manual provided the copyright notice and this permission notice
  115: are preserved on all copies.
  116: 
  117: Permission is granted to copy and distribute modified versions of this
  118: manual under the conditions for verbatim copying, provided also that the
  119: entire resulting derived work is distributed under the terms of a
  120: permission notice identical to this one.
  121: 
  122: Permission is granted to copy and distribute translations of this manual
  123: into another language, under the above conditions for modified versions,
  124: except that this permission notice may be stated in a translation
  125: approved by the Free Software Foundation.
  126: @end titlepage
  127: 
  128: @comment ================================================================
  129: @comment                   The real text starts here
  130: @comment ================================================================
  131: 
  132: @ifinfo
  133: @c ---------------------------------------------------------------------
  134: @node    Top
  135: @top CVS 1.10.5 Japanese Manual
  136: @c Note: there is a space after that @top command.
  137: @c The texinfo-format-buffer Emacs function and
  138: @c the makeinfo shell command disagree on what arguments
  139: @c @top takes; @top followed by a single space is
  140: @c something they can both cope with.
  141: 
  142: この info manual は、
  143: @sc{cvs} version @value{CVSVN}
  144: の使用方法と管理方法について記述します。
  145: @end ifinfo
  146: 
  147: @c This menu is pretty long.  Not sure how easily that
  148: @c can be fixed (no brilliant ideas right away)...
  149: @menu
  150: * Overview::                    CVS への導入
  151: * Repository::                  全てのソースが保存される場所
  152: * Starting a new project::      CVS でプロジェクトを始める
  153: * Revisions::                   リビジョンの数値とシンボルの名前
  154: * Branching and merging::       開発の枝の多様化/再一本化
  155: * Recursive behavior::          CVS はディレクトリを降りていく
  156: * Adding and removing::         ファイル/ディレクトリを加える/取り除
  157:                                 く/名前を変える
  158: * History browsing::            ファイルの履歴をいろいろな方法で閲覧する
  159: 
  160: CVS と現実の世界
  161: -----------------------
  162: * Binary files::                CVS はバイナリ・ファイルを扱うことができる
  163: * Multiple developers::         CVS の開発者グループの援助の仕方
  164: * Revision management::         リビジョン管理のポリシーへの質問
  165: * Keyword substitution::        CVS はファイルの中にリビジョンを含むこ
  166:                                 とができる
  167: * Tracking sources::            サード・パーティーソースの追っかけ
  168: * Builds::                      CVS とコンパイルに関する問題
  169: * Special Files::		デバイス、リンクと他の普通でないファイ
  170:   171: 
  172: リファレンス
  173: -----------
  174: * CVS commands::                CVS の命令は同じものを使う
  175: * Invoking CVS::                CVS の命令の quick reference
  176: * Administrative files::        管理ファイルへのリファレンスマニュアル
  177: * Environment variables::       CVS に影響する全ての環境変数
  178: * Compatibility::               CVS のバージョンを上げる
  179: * Troubleshooting::             動作しないときのいくらかのこつ
  180: * Credits::                     このマニュアルへの貢献者達
  181: * BUGS::                        CVS かこのマニュアルのバグの対処
  182: * 翻訳者より:Translation.       日本語訳について
  183: * Index::                       索引
  184: @end menu
  185: 
  186: @c ---------------------------------------------------------------------
  187: @node Overview
  188: @chapter 概観
  189: @cindex Overview
  190: 
  191: この章は @sc{cvs} を一度も使ったことが無く、おそらく以前にバージョン管
  192: 理ソフトを使ったことの無い人のためのものです。
  193: 
  194: 既に @sc{cvs} に親しんでいて、特定の機能を学んだり、特定の命令を覚えよ
  195: うとしているときは、ここは全て飛ばしてください。
  196: 
  197: @menu
  198: * What is CVS?::                @sc{cvs} で何が出きるか
  199: * What is CVS not?::            @sc{cvs} が解決しようとしない問題
  200: * A sample session::            基本的な @sc{cvs} の利用のツアー
  201: @end menu
  202: 
  203: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  204: @node What is CVS?
  205: @section CVS とは?
  206: @cindex What is CVS?
  207: @cindex Introduction to CVS
  208: @cindex CVS, introduction to
  209: 
  210: @sc{cvs} はバージョン管理システムであり、
  211: あなたのソース・ファイルの変遷を記録するのに使用します。
  212: 
  213: @c -- ///
  214: @c -- ///Those who cannot remember the past are condemned to repeat it.
  215: @c -- ///               -- George Santayana
  216: @c -- //////
  217: 
  218: @c -- Insert history  quote here!
  219: 例えば、ソフトウェアの修正に伴なってバグが入り込み、
  220: 発見されるまでに長い時間がかかったとします。
  221: @sc{cvs} を使っていれば、古いバージョンを簡単に復元し、
  222: バグの原因となった変更点を正確に調べることができます。
  223: この特徴に救われる時が必ずあります。
  224: 
  225: 全てのバージョンの全てのファイルを保存しておくこともできますが、
  226: ディスク容量の無駄使いでしかありません。
  227: @sc{cvs} は、バージョン間の差分のみを保存する方法により、
  228: 各ファイルの全バージョンを一つのファイルに記録します。
  229: 
  230: @sc{cvs} は、複数の開発者が同じソフトウェアに
  231: 取り組む場合に、真価を発揮します。
  232: このような場合にはよほど気を付けていないと、
  233: 他の人が変更したファイルを上書きしてしまいます。
  234: @sc{gnu} Emacs のようなエディタを使えば、
  235: 複数の人が同時に同じファイルを編集することはありません。
  236: しかし不幸なことに、全員が同じエディタを使うとは限りません。
  237: @sc{cvs} は開発者を互いに隔離することにより、この問題を解決しました。
  238: 全ての開発者は自分のディレクトリで作業し、
  239: その仕事を @sc{cvs} が組み合わせます。
  240: 
  241: @cindex History of CVS
  242: @cindex CVS, history of
  243: @cindex Credits (CVS program)
  244: @cindex Contributors (CVS program)
  245: @sc{cvs} は Dick Grune が作成し、
  246: 1986年 12 月に @code{comp.sources.unix} の volume 6 に投稿した、
  247: シェル・スクリプトから始まりました。
  248: 現在の @sc{cvs} は、
  249: これらのシェル・スクリプトのコードを全く含みませんが、
  250: 衝突解決のアルゴリズムの大部分を受け継いでいます。
  251: 
  252: 1989年 4 月に Brian Berliner が @sc{cvs} を設計し、コーディングしました。
  253: その後、Jeff Polk が @sc{cvs} の ベンダー枝とモジュールの設計を助けました。
  254: 
  255: @cindex Source, getting CVS source
  256: @sc{cvs} をインターネットからの自由なダウンロードなど、いろいろな方法
  257: で取得することができます。 @sc{cvs} のダウンロードや、他の @sc{cvs} の
  258: 話題の情報は、以下のところを参照してください。
  259: 
  260: @example
  261: http://www.cyclic.com/
  262: http://www.loria.fr/~molli/cvs-index.html
  263: @end example
  264: 
  265: @cindex Mailing list
  266: @cindex List, mailing list
  267: @cindex Newsgroups
  268: @w{@code{info-cvs}} という @sc{cvs} 専門のメーリング・リストがあります。
  269: @c このメーリング・リストに
  270: 参加、又は脱退したい場合には、
  271: @w{@code{info-cvs-request@@gnu.org}} にメールを出して下さい。
  272: Usenet グループの方を好むのであれば、正しいグループは
  273: @code{comp.software.config-mgmt} で、@sc{cvs} の議論を
  274: するために適した場所です (他の構成管理システムと一緒で
  275: すが)。 将来は @code{comp.software.config-mgmt.cvs} を
  276: 作ることも可能かもしれませんが、おそらく
  277: @code{comp.software.config-mgmt} に十分な流量があるよう
  278: になったときだけでしょう。
  279: @c Other random data is that past attempts to create a
  280: @c gnu.* group have failed (the relevant authorities
  281: @c say they'll do it, but don't), and that tale was very
  282: @c skeptical of comp.software.config-mgmt.cvs when the
  283: @c subject came up around 1995 or so (for one
  284: @c thing, because creating it would be a "reorg" which
  285: @c would need to take a more comprehensive look at the
  286: @c whole comp.software.config-mgmt.* hierarchy).
  287: 
  288: @ref{BUGS} でより詳細に説明されている bug-cvs メーリン
  289: グリストを講読するともできます。講読するためには、
  290: bug-cvs-request@@gnu.org にメールを送ってください。
  291: 
  292: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  293: @node What is CVS not?
  294: @section CVS は何ではない?
  295: @cindex What is CVS not?
  296: 
  297: @sc{cvs} は多くのことができますが、全ての人に全てのことを
  298: するようにはなっていません。
  299: 
  300: @table @asis
  301: @item @sc{cvs} は構築システムではありません。
  302: 
  303: リポジトリと modules ファイルの構造と構築システム (例. 
  304: @file{Makefile}) とは相互作用するかもしれませんが、本質的
  305: に独立したものです。
  306: 
  307: @sc{cvs} は、何かの作り方を指示したりはしません。
  308: @sc{cvs} はあなたの意思に従って、
  309: ツリー構造から望むファイルを取り出すだけです。
  310: 
  311: @sc{cvs} は、@code{checkout} 先の作業ディレクトリのディスク容量の使用
  312: 法について指示したりはしません。あなたが @file{Makefile} やスクリプトを
  313: 全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
  314: るとすると、リポジトリ全てを取り出す必要が生じます。
  315: 
  316: あなたが仕事をモジュール化し、(@file{Makefile} に link,
  317: mount, @code{VPATH}等を使用して、)ファイルを共有するよ
  318: うな構築システムを構成すれば、好きな様にディスクの利用
  319: 法を決めることが出来ます。
  320: 
  321: しかしこれら@emph{全ての}システムは、
  322: 構築と維持に多大な労力が必要なことに、
  323: 気を付けなければいけません。
  324: @sc{cvs} は、このような問題に関して考慮しません。
  325: 
  326: もちろん、これらの構築システムを支援するための道具
  327: (スクリプト, @file{Makefile} 等) は、
  328: @sc{cvs} の管理下に置くと良いでしょう。
  329: 
  330: 何らかの変更があった際に、再構築が必要なファイルを調べるのは、
  331: やはり @sc{cvs} の守備外です。
  332: 伝統的な手法の一例をあげると、
  333: 構築には @code{make} を用い、
  334: @code{make} に必要な依存関係は自動化されたツールを用いて生成します。
  335: 
  336: @sc{cvs} と結合して構築を行うための情報は @ref{Builds}
  337: を参照してください。
  338: 
  339: @item @sc{cvs} は管理者代理ではありません。
  340: 
  341: あなたの管理者や上司は、期日に従っているかどうかや、 
  342: マージ点、枝の名前、リリースの日時等について、
  343: あなたと度々話しあうことを求められています。
  344: 彼等がそうしないなら、@sc{cvs} は役に立ちません。
  345: 
  346: @sc{cvs} は、あなたの調律に従ってソースを踊らせる楽器の
  347: ようなものです。あなたは楽器奏者もしくは作曲者のような
  348: ものです。どんな楽器も勝手に演奏をしたりしないし、音楽
  349: が勝手に書かれたりもしません。
  350: 
  351: @item @sc{cvs} は開発者同士の意志疎通の代用にはなりません。
  352: 
  353: あるファイルに衝突が起きた場合に、
  354: ほとんどの開発者はそれほど苦労せずに解決します。
  355: しかし、@dfn{衝突} (@dfn{conflict})のより一般的な定義には、
  356: 開発者同士の意志疎通なしには解決できない
  357: 困難な問題も含まれます。
  358: 
  359: 同じファイル (もしくはファイルの集合) に、
  360: 同時に加えられた変更に論理的な衝突があっても、
  361: @sc{cvs} には分りません。
  362: @dfn{衝突}という概念は単に文字列の比較によるもので、
  363: 同じファイルを基に加えられた二つの変更が、
  364: @code{merge} コマンド (つまり @code{diff3}) を驚かせるのに
  365: 十分なほど近接している場合にのみ生じます。
  366: 
  367: @sc{cvs} は、
  368: プログラムの論理に、文字列でない衝突や、散らばった衝突
  369: があったとしても、警告を表示しません。
  370: 
  371: 例: 
  372: あなたは @file{A} で定義された関数 @code{X} の引数を変更したとします。
  373: 同じ時に、誰かが @file{B} を編集して、
  374: 古い引数を使って @code{X} を呼び出したとします。
  375: これは @sc{cvs} の能力の範囲外です。
  376: 
  377: 仕様書を読み、同僚と話し合う習慣を付けましょう。
  378: 
  379: 
  380: @item @sc{cvs} は変更管理をしません。
  381: 
  382: 変更管理という言葉は様々な意味を持ちます。
  383: まず@dfn{バグ追跡}と解釈すれば、バグ報告と各バグの状態
  384: (修正されたか? どのリリースか? 報告者は修正を確認したか? )
  385: についてのデータベース管理を意味します。
  386: @sc{cvs} とバグ追跡システムとの連携については、
  387: @file{rcsinfo} と @file{editinfo} ファイルを見て下さい 
  388: (@pxref{Administrative files})。
  389: 
  390: 論理的には一つと考えられる変更のため、
  391: 複数のファイルが同時に変更されたことを覚えておくことも、
  392: 変更管理と呼ばれます。
  393: 複数のファイルの変更を一つの @code{cvs commit} により格納した場合、
  394: @sc{cvs} はそれらのファイルが同時に格納されたことを忘れてしまいます。
  395: そして、それらのファイルを結ぶ事柄は、
  396: 同じログ・メッセージを持つことだけになるのです。
  397: @sc{gnu} 形式の @file{ChangeLog} を用いれば何らかの助けになるでしょう。
  398: @c FIXME: should have an xref to a section which talks
  399: @c more about keeping ChangeLog's with CVS, but that
  400: @c section hasn't been written yet.
  401: 
  402: 各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
  403: 開発者によって加えられた変更もあれば、
  404: 他の開発者によって追試中の変更もあるとか、そういったことです。
  405: 一般的に @sc{cvs} でこのようなことをするには、
  406: (@code{cvs diff} や @code{diff} を用いて) 差分を生成し、
  407: @code{patch} を当てる人物にメールとして送ります。
  408: これは非常に融通のきく方法ですが、
  409: @sc{cvs} 以外の機構に依存しているので、
  410: 問題が無いことを保証できません。
  411: 
  412: @item @sc{cvs} は自動検査プログラムではありません。
  413: 
  414: @code{commitinfo} ファイルを使えば、
  415: 強制的に必須の項目を検査することは可能だと思います。
  416: しかし、
  417: そんなことをしようとしたプロジェクトのことは聞いたことがありません。
  418: 
  419: @item @sc{cvs} は手順規範を備えていません。
  420: 
  421: 変更やリリースに必要とされる色々な手順や多くの承認を、
  422: 確実に行なう方法を備えたシステムもあります。
  423: @sc{cvs} を用いてこれを達成することも可能ですが、
  424: ちょっと面倒だと思います。
  425: 場合によっては、
  426: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{verifymsg} 
  427: 等のファイルを用いて、変更点を格納する前に、
  428: 必要な手順を確実に踏むように設定できるでしょう。
  429: また枝やタグといった機構を用いて、
  430: 開発用の枝で仕事を実行し、
  431: 安定性が証明された確実な変更だけを
  432: 安定化指向の枝に統合することも考えられます。
  433: @end table
  434: 
  435: @c ---------------------------------------------------------------------
  436: @node A sample session
  437: @section 作業例
  438: @cindex Example of a work-session
  439: @cindex Getting started
  440: @cindex Work-session, example of
  441: @cindex tc, Trivial Compiler (example)
  442: @cindex Trivial Compiler (example)
  443: 
  444: @c I think an example is a pretty good way to start.  But
  445: @c somewhere in here, maybe after the sample session,
  446: @c we need something which is kind of
  447: @c a "roadmap" which is more directed at sketching out
  448: @c the functionality of CVS and pointing people to
  449: @c various other parts of the manual.  As it stands now
  450: @c people who read in order get dumped right into all
  451: @c manner of hair regarding remote repositories,
  452: @c creating a repository, etc.
  453: @c
  454: @c The following was in the old Basic concepts node.  I don't
  455: @c know how good a job it does at introducing modules,
  456: @c or whether they need to be introduced so soon, but
  457: @c something of this sort might go into some
  458: @c introductory material somewhere.
  459: @ignore
  460: @cindex Modules (intro)
  461: リポジトリはディレクトリやファイルを含み、
  462: 任意の場所に設定できます。
  463: 複数のディレクトリやファイルから成る単位を、
  464: @dfn{モジュール} (@dfn{modules}) として一括して管理できます 
  465: (@pxref{modules})。
  466: 各モジュールは、
  467: プロジェクト毎に定義するのが普通です。
  468: @end ignore
  469: 
  470: @sc{cvs} を紹介する方法として、@sc{cvs} を使って典型的な仕事をしてみま
  471: す。最初に理解すべきことは @sc{cvs} は全てのファイルを中央に集められた 
  472: @dfn{リポジトリ} (@dfn{repository}) (@pxref{Repository}) に保存すると
  473: いうことです。この節ではリポジトリは準備されていると仮定します。
  474: @c I'm not sure that the sentence concerning the
  475: @c repository quite tells the user what they need to
  476: @c know at this point.  Might need to expand on "centralized"
  477: @c slightly (maybe not here, maybe further down in the example?)
  478: 
  479: あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語
  480: で書かれたファイルでできていて、@file{Makefile} を含んでいるとします。
  481: このコンパイラを @samp{tc} (Trivial Compiler) と呼ぶことにします。そし
  482: て @samp{tc} というモジュール名でリポジトリに登録されています。
  483: 
  484: @menu
  485: * Getting the source::          作業場所の作成
  486: * Committing your changes::     あなたの仕事を他の人が利用可能にする
  487: * Cleaning up::                 お掃除
  488: * Viewing differences::         差分を見る
  489: @end menu
  490: 
  491: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  492: @node Getting the source
  493: @subsection ソースの取得
  494: @cindex Getting the source
  495: @cindex Checking out source
  496: @cindex Fetching source
  497: @cindex Source, getting from CVS
  498: @cindex Checkout, example
  499: 
  500: まず、@samp{tc} のソースの作業コピーを取ってくることから始めましょう。
  501: これには @code{checkout} コマンドを使用します:
  502: 
  503: @example
  504: $ cvs checkout tc
  505: @end example
  506: 
  507: @noindent
  508: とすると @file{tc} という新しい作業ディレクトリが作られ、
  509: その中にソース・ファイルがコピーされます。
  510: 
  511: @example
  512: $ cd tc
  513: $ ls
  514: CVS         Makefile    backend.c   driver.c    frontend.c  parser.c
  515: @end example
  516: 
  517: @file{CVS} というディレクトリは @sc{cvs} が内部的に使用
  518: します。普通はその中にあるどんなファイルでも修正したり
  519: 削除してはいけません。
  520: 
  521: で、あなたの好きなエディタを用いて @file{backend.c} をハックして、
  522: 数時間後にコンパイラの最適化経路を加えたとします。
  523: @sc{rcs} と @sc{sccs} の利用者への注意: 編集したいファ
  524: イルをロックする必要はありません。その説明は、 @xref{Multiple
  525: developers}.
  526: 
  527: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  528: @node Committing your changes
  529: @subsection 変更の格納
  530: @cindex Committing changes
  531: @cindex Log message entry
  532: @cindex CVSEDITOR, environment variable
  533: @cindex EDITOR, environment variable
  534: 
  535: あなたはコンパイラが相変わらずコンパイル可能であることを確認し、
  536: @file{backend.c} の新しいバージョンとすることに決めました。これは新し
  537: い @file{backend.c} をリポジトリに格納し、同じリポジトリを使っている他
  538: の人が使用できるようにします。
  539: 
  540: @example
  541: $ cvs commit backend.c
  542: @end example
  543: 
  544: @noindent
  545: @sc{cvs} はログ・メッセージを記すためにエディタを開きます。
  546: そこで ``Added an optimization pass.'' などと入力し、
  547: 一時ファイルに保存し、エディタを終了します。
  548: 
  549: どのエディタが開かれるかは環境変数 @code{$CVSEDITOR} により決定されま
  550: す。@code{$CVSEDITOR} が設定されておらず、環境変数 @code{$EDITOR} が設
  551: 定されていれば、これを使用します。@code{$CVSEDITOR} と @code{$EDITOR} 
  552: の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
  553: フォルトが使われます。例えば、unix では @code{vi}で、Windows NT/95 で
  554: は @code{notepad} です。
  555: 
  556: @cindex VISUAL, environment variable
  557: 加えて、@sc{cvs} は @code{$VISUAL} 環境変数も調べます。この動作が望ま
  558: しいか、また @sc{cvs} の将来のリリースが @code{$VISUAL} を調べるべきか
  559: どうか、という意見は人によって異なります。@code{$VISUAL} が設定されて
  560: いないか、@code{$EDITOR} に設定されていることを確実にすることで、どち
  561: らになっても対処することができます。
  562: @c This probably should go into some new node
  563: @c containing detailed info on the editor, rather than
  564: @c the intro.  In fact, perhaps some of the stuff with
  565: @c CVSEDITOR and -m and so on should too.
  566: @sc{cvs} がエディタを開始したときは、修正されたファイルのリストを含ん
  567: でいます。@sc{cvs} のクライアントでは、このリストはファイルの修正時刻
  568: を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
  569: ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
  570: いないというときも、修正されたものとして表示されます。これに対する最も
  571: 簡単な対処法は単純に気にしないことです---それを commitすると、@sc{cvs} 
  572: は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
  573: す。次の @code{update}はファイルが無修正であるという事実に基づき、将来
  574: のセッションでファイルが表示されないように、タイムスタンプを保存されて
  575: いるものに設定し直します。
  576: @c FIXCVS: Might be nice if "commit" and other commands
  577: @c would reset that timestamp too, but currently commit
  578: @c doesn't.
  579: @c FIXME: Need to talk more about the process of
  580: @c prompting for the log message.  Like show an example
  581: @c of what it pops up in the editor, for example.  Also
  582: @c a discussion of how to get the "a)bort, c)ontinue,
  583: @c e)dit" prompt and what to do with it.  Might also
  584: @c work in the suggestion that if you want a diff, you
  585: @c should make it before running commit (someone
  586: @c suggested that the diff pop up in the editor.  I'm
  587: @c not sure that is better than telling people to run
  588: @c "cvs diff" first if that is what they want, but if
  589: @c we want to tell people that, the manual possibly
  590: @c should say it).
  591: 
  592: わざわざエディタを開くのが嫌ならば、代わりにコマンド行の @samp{-m} フ
  593: ラグを使うことでログメッセージを以下のように指定することができます:
  594: 
  595: @example
  596: $ cvs commit -m "Added an optimization pass" backend.c
  597: @end example
  598: 
  599: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  600: @node Cleaning up
  601: @subsection お掃除
  602: @cindex Cleaning up
  603: @cindex Working copy, removing
  604: @cindex Removing your working copy
  605: @cindex Releasing your working copy
  606: 
  607: 他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も
  608: ちろん、次のようにしても可能です
  609: 
  610: @example
  611: $ cd ..
  612: $ rm -r tc
  613: @end example
  614: 
  615: @noindent
  616: しかし、@code{release} コマンドを使用するほうが良いでしょう 
  617: (@pxref{release}):
  618: 
  619: @example
  620: $ cd ..
  621: $ cvs release -d tc
  622: M driver.c
  623: ? tc
  624: You have [1] altered files in this repository.
  625: Are you sure you want to release (and delete) directory `tc': n
  626: ** `release' aborted by user choice.
  627: @end example
  628: 
  629: @code{release} コマンドは、あなたの修正が格納されているかどうか確認し
  630: ます。ログを記録する設定ならば、ファイル @file{history} にメモします。 
  631: @xref{history file}.
  632: 
  633: @code{release} コマンドに @samp{-d} フラグを使用すると、
  634: 確認と同時に作業コピーを削除します。
  635: 
  636: 上の例では、@code{release} コマンドが何行か出力しています。
  637: @samp{? tc} は @sc{cvs} が @file{tc} というファイルを知らないという意味です。
  638: モジュール @samp{tc} のことではなく、
  639: 生成したコンパイラ @file{tc} を指しており、
  640: これはリポジトリに格納しなくて良いので無視して構いません。
  641: この警告を消すための情報は @ref{cvsignore} 参照。
  642: @code{release} の出力の詳細な説明は @ref{release output} 参照。
  643: 
  644: @samp{M driver.c} の方は重要です。
  645: これは、@file{driver.c} というファイルに加えた修正が、
  646: 格納されていないことを指摘しています。
  647: 
  648: @code{release} コマンドは、常に作業コピーの
  649: 修正が加えられたファイルの数を報告した後、
  650: ファイルを削除したり履歴ファイルにメモする前に、
  651: その確認を求めてきます。
  652: 
  653: ここでは大事を取って、最後に @code{release} が確認を求めたときに 
  654: @kbd{n @key{RET}} を入力しました。
  655: 
  656: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  657: @node Viewing differences
  658: @subsection 差分を見る
  659: @cindex Viewing differences
  660: @cindex Diff
  661: 
  662: あなたは @file{driver.c} に加えた修正を覚えていなかったので、
  663: 何をしたのか調べる必要があります。
  664: 
  665: @example
  666: $ cd tc
  667: $ cvs diff driver.c
  668: @end example
  669: 
  670: このコマンドは @code{diff} を実行して、取り出した時と、あなたの作業コ
  671: ピーの @file{driver.c} のバージョンを比較します。その出力を見て、最適
  672: 化経路を有効にするオプションを、コマンド行で指定できるようにしたことを
  673: 思い出しました。その変更を格納して、このモジュールに対する作業を終了し
  674: ます。
  675: @c FIXME: we haven't yet defined the term "check in".
  676: 
  677: @example
  678: $ cvs commit -m "Added an optimization pass" driver.c
  679: Checking in driver.c;
  680: /usr/local/cvsroot/tc/driver.c,v  <--  driver.c
  681: new revision: 1.2; previous revision: 1.1
  682: done
  683: $ cd ..
  684: $ cvs release -d tc
  685: ? tc
  686: You have [0] altered files in this repository.
  687: Are you sure you want to release (and delete) directory `tc': y
  688: @end example
  689: 
  690: @c ---------------------------------------------------------------------
  691: @node Repository
  692: @chapter リポジトリ
  693: @cindex Repository (intro)
  694: @cindex Repository, example
  695: @cindex Layout of repository
  696: @cindex Typical repository
  697: @cindex /usr/local/cvsroot, as example repository
  698: @cindex cvsroot
  699: 
  700: @sc{cvs} の@dfn{リポジトリ} (@dfn{repository}) は、
  701: バージョン管理の対象となる全てのファイルとディレクトリの、
  702: 完全なコピーを保管します。
  703: 
  704: 通常、リポジトリ中のファイルを直接利用することはありません。
  705: その代わりに @sc{cvs} コマンドを使用して、
  706: 作業者自身のファイルのコピーを @dfn{作業ディレクトリ}
  707: に取り出し、そのコピーを用いて作業します。
  708: 
  709: そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も
  710: しくは @dfn{格納} します (@dfn{commit}))。リポジトリは、変更を加えたも
  711: のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され
  712: ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ
  713: とに注意してください。別の位置にあるべきです。
  714: @c Need some example, e.g. repository
  715: @c /usr/local/cvsroot; working directory
  716: @c /home/joe/sources.  But this node is too long
  717: @c as it is; need a little reorganization...
  718: 
  719: @cindex :local:
  720: @sc{cvs} は様々な方法でリポジトリを利用することができます。
  721: リポジトリは、使用中のコンピュータ内であってもいいし、
  722: 別の部屋のコンピュータや、別の国のコンピュータであっても構いません。
  723: リポジトリに接続する方法を区別するために、
  724: リポジトリの名前の最初に@dfn{接続経路} (@dfn{access
  725: method}) を加えることがあります。例えば @code{:local:} は、リポジトリ
  726: であるディレクトリを利用することを意味します。つまり 
  727: @code{:local:/usr/local/cvsroot} で表されるリポジトリは、@sc{cvs} を実
  728: 行したコンピュータの @file{/usr/local/cvsroot} というリポジトリを意味
  729: します。他の接続経路については @ref{Remote repositories} 参照。
  730: 
  731: @c Can se say this more concisely?  Like by passing
  732: @c more of the buck to the Remote repositories node?
  733: 接続経路の指定が省略され、リポジトリに @samp{:} が含まれない場合には、
  734: @code{:local:} が仮定されます。
  735: @samp{:} が含まれていた場合には、
  736: @code{:ext:} か @code{:server:} が仮定されます。
  737: 例えばリポジトリ @file{/usr/local/cvsroot} が同じコンピュータ内にある場合、
  738: @code{:local:/usr/local/cvsroot} を省略して
  739: @code{/usr/local/cvsroot} と記述しても構いません。
  740: しかし(Windows NT などで)、
  741: リポジトリが @file{c:\src\cvsroot} にある場合、 
  742: @code{:local:c:\src\cvsroot} として、
  743: 接続経路を明示する必要があります。
  744: 
  745: @c This might appear to go in Repository storage, but
  746: @c actually it is describing something which is quite
  747: @c user-visible, when you do a "cvs co CVSROOT".  This
  748: @c isn't necessary the perfect place for that, though.
  749: リポジトリは二つの要素から構成されます。
  750: @file{$CVSROOT/CVSROOT} には @sc{cvs} の管理用ファイルが置かれます。
  751: その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。
  752: 
  753: @menu
  754: * Specifying a repository::     どのリポジトリを使うか CVS に教える
  755: * Repository storage::          リポジトリの構造
  756: * Working directory storage::   作業ディレクトリの構造
  757: * Intro administrative files::  モジュールの定義
  758: * Multiple repositories::       複数のリポジトリ
  759: * Creating a repository::       リポジトリの作成
  760: * Backing up::                  リポジトリのバックアップ
  761: * Moving a repository::         リポジトリの移動
  762: * Remote repositories::         別のマシンのリポジトリを利用する
  763: * Read-only access::            リポジトリの読み込みのみの利用を許可する
  764: * Server temporary directory::  サーバは一時ディレクトリを作成する
  765: @end menu
  766: 
  767: @node Specifying a repository
  768: @section CVS にリポジトリの場所を教える
  769: 
  770: @sc{cvs} にリポジトリの場所を教えるには、
  771: いくつか方法があります。
  772: 一つ目はコマンド行で、
  773: @code{-d} ("directory" を示します) オプションを用いて
  774: 指定する方法です:
  775: 
  776: @example
  777: cvs -d /usr/local/cvsroot checkout yoyodyne/tc
  778: @end example
  779: 
  780: @cindex .profile, setting CVSROOT in
  781: @cindex .cshrc, setting CVSROOT in
  782: @cindex .tcshrc, setting CVSROOT in
  783: @cindex .bashrc, setting CVSROOT in
  784: @cindex CVSROOT, environment variable
  785: 二つ目は、環境変数 @code{$CVSROOT} に、
  786: 絶対パスでリポジトリを指定する方法です。
  787: 例では @file{/usr/local/cvsroot}です。
  788: @code{csh} や @code{tcsh} のユーザは各々
  789: @file{.cshrc} や @file{.tcshrc} に次の行を加えて下さい:
  790: 
  791: @example
  792: setenv CVSROOT /usr/local/cvsroot
  793: @end example
  794: 
  795: @noindent
  796: @code{sh} や @code{bash} のユーザは各々 
  797: @file{.profile} や @file{.bashrc} に次の行を加えて下さい:
  798: 
  799: @example
  800: CVSROOT=/usr/local/cvsroot
  801: export CVSROOT
  802: @end example
  803: 
  804: @cindex Root file, in CVS directory
  805: @cindex CVS/Root file
  806: @code{-d} によるリポジトリの指定は、
  807: 環境変数 @code{$CVSROOT} よりも優先されます。
  808: 一旦リポジトリから作業コピーを取得すれば、
  809: リポジトリの場所が記憶されます
  810: (この情報は、作業ディレクトリ内の 
  811: @file{CVS/Root} に記録されます)。
  812: 
  813: オプション @code{-d} とファイル @file{CVS/Root} は、
  814: どちらも環境変数 @code{$CVSROOT} よりも優先されます。
  815: また、@file{-d} と @file{CVS/Root} が一致しない場合は、
  816: 前者が使用されます
  817: もちろん、
  818: 二つともが同じリポジトリを参照するのが、まともなやり方です。
  819: 
  820: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  821: @node Repository storage
  822: @section リポジトリでのデータの保存方法
  823: @cindex Repository, how data is stored
  824: 
  825: @sc{cvs} がリポジトリに情報を保存する@emph{方法}を知っていても、
  826: たいてい何の役にも立ちません。
  827: 実際、過去に書式が変更されましたし、
  828: 将来変更されることもあるでしょう。
  829: ほとんど全ての場合、
  830: @sc{cvs} コマンドを通してリポジトリを利用しますから、
  831: 書式を変更しても混乱は起きません。
  832: 
  833: しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え
  834: ば @sc{cvs} のロック解除が必要な場合 (@pxref{Concurrency}) や、リポジ
  835: トリのファイルの許可属性を適切に設定する必要がある場合などです。
  836: 
  837: @menu
  838: * Repository files::            リポジトリに保管されるファイル
  839: * File permissions::            ファイル使用許可
  840: * Windows permissions::         Windows 特有の問題
  841: * Attic::                       Attic に保存されるファイルもある
  842: * CVS in repository::           CVS ディレクトリの追加情報
  843: * Locks::                       CVS ロックは並列接続を制御する
  844: * CVSROOT storage::             CVSROOT の少しの違い
  845: @end menu
  846: 
  847: @node Repository files
  848: @subsection リポジトリのどこにファイルを保存するか
  849: 
  850: @c @cindex filenames, legal
  851: @c @cindex legal filenames
  852: @c Somewhere we need to say something about legitimate
  853: @c characters in filenames in working directory and
  854: @c repository.  Not "/" (not even on non-unix).  And
  855: @c here is a specific set of issues:
  856: @c 	Files starting with a - are handled inconsistently. They can not
  857: @c   be added to a repository with an add command, because it they are
  858: @c   interpreted as a switch. They can appear in a repository if they are
  859: @c   part of a tree that is imported. They can not be removed from the tree
  860: @c   once they are there.
  861: @c Note that "--" *is* supported (as a
  862: @c consequence of using GNU getopt).  Should document
  863: @c this somewhere ("Common options"?).  The other usual technique,
  864: @c "./-foo", isn't as effective, at least for "cvs add"
  865: @c which doesn't support pathnames containing "/".
  866: 
  867: リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい
  868: ます。例えば、リポジトリが
  869: 
  870: @example
  871: /usr/local/cvsroot
  872: @end example
  873: 
  874: @noindent
  875: にあれば、次のようなディレクトリの木構造になります (ディレクトリだけを
  876: 表示しています):
  877: 
  878: @example
  879: @t{/usr}
  880:  |
  881:  +--@t{local}
  882:  |   |
  883:  |   +--@t{cvsroot}
  884:  |   |    | 
  885:  |   |    +--@t{CVSROOT}
  886:           |      (管理用ファイル)
  887:           | 
  888:           +--@t{gnu}
  889:           |   | 
  890:           |   +--@t{diff}
  891:           |   |   (@sc{gnu} diff のソース)
  892:           |   | 
  893:           |   +--@t{rcs}
  894:           |   |   (@sc{rcs} のソース)
  895:           |   | 
  896:           |   +--@t{cvs}
  897:           |       (@sc{cvs} のソース)
  898:           | 
  899:           +--@t{yoyodyne}
  900:               | 
  901:               +--@t{tc}
  902:               |    |
  903:               |    +--@t{man}
  904:               |    |
  905:               |    +--@t{testing}
  906:               | 
  907:               +--(その他の Yoyodyne のソフトウェア)
  908: @end example                              
  909: 
  910: ディレクトリの中身は、管理下にあるファイルの@dfn{履歴ファイル} 
  911: (@dfn{history files}) です。
  912: 履歴ファイルの名前は、各ファイル名の最後に @samp{,v} を付加したものです。
  913: 次に、ディレクトリ @file{yoyodyne/tc} のリポジトリ構造を示します:
  914: @c FIXME: Should also mention CVS (CVSREP)
  915: @c FIXME? Should we introduce Attic with an xref to
  916: @c Attic?  Not sure whether that is a good idea or not.
  917: @example
  918:   @code{$CVSROOT}
  919:     |
  920:     +--@t{yoyodyne}
  921:     |   |
  922:     |   +--@t{tc}
  923:     |   |   |
  924:             +--@t{Makefile,v}
  925:             +--@t{backend.c,v}
  926:             +--@t{driver.c,v}
  927:             +--@t{frontend.c,v}
  928:             +--@t{parser.c,v}
  929:             +--@t{man}
  930:             |    |
  931:             |    +--@t{tc.1,v}
  932:             |
  933:             +--@t{testing}
  934:                  |
  935:                  +--@t{testpgm.t,v}
  936:                  +--@t{test2.t,v}
  937: @end example
  938: 
  939: @cindex History files
  940: @cindex RCS history files
  941: @c The first sentence, about what history files
  942: @c contain, is kind of redundant with our intro to what the
  943: @c repository does in node Repository....
  944: 履歴ファイルは、
  945: どのリビジョンのファイルでも再構築できる情報を持ち、
  946: また変更内容が格納された時のログ・メッセージと、
  947: その時のユーザの名前も記録しています。
  948: ファイルをこのような書式で保管した最初のプログラムが、
  949: @sc{rcs} というバージョン管理システムであったために、
  950: 履歴ファイルは @dfn{RCS ファイル} と呼ばれます。
  951: ファイル書式の完全な記述は、@sc{rcs} の配布セットにある
  952: @cite{rcsfile(5)} の @code{man} ページか、@sc{cvs} のソー
  953: ス配布のファイル @file{doc/RCSFILES} を参照してください。
  954: このファイル書式は非常に一般的なので、
  955: @sc{cvs} や @sc{rcs} 以外のシステムでも、
  956: 少くとも理解をすることができます。
  957: @c FIXME: Think about including documentation for this
  958: @c rather than citing it?  In the long run, getting
  959: @c this to be a standard (not sure if we can cope with
  960: @c a standards process as formal as IEEE/ANSI/ISO/etc,
  961: @c though...) is the way to go, so maybe citing is
  962: @c better.
  963: 
  964: @sc{cvs} で使用されている @sc{rcs} ファイルは標準の書式と少し違います。
  965: 最大の違いは魔法の枝です。詳細は @ref{Magic branch numbers} を参照して
  966: ください。@sc{cvs} では、有効なタグ名は @sc{rcs} で使用できるもののサ
  967: ブセットになっています。@sc{cvs} の規則は @ref{Tags} を参照してくださ
  968: い。
  969: 
  970: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  971: @node File permissions
  972: @subsection ファイル使用許可
  973: @c -- Move this to @node Creating a repository or similar
  974: @cindex Security
  975: @cindex File permissions, general
  976: @cindex permissions, general
  977: @c FIXME: we need to somehow reflect "permissions in
  978: @c repository" versus "permissions in working
  979: @c directory" in the index entries.
  980: @cindex Group
  981: @cindex read-only files, in repository
  982: 全ての @samp{,v} ファイルは読み込み専用であり、
  983: この使用許可を変えるべきではありません。
  984: これに対し、リポジトリ中のディレクトリは、
  985: ファイルの修正を行なう人物に対して、
  986: 書き込みを許可しなくてはいけません。
  987: これはつまり、
  988: ファイルの修正を行なう人物からなるグループを作って 
  989: (@cite{group(5)}参照)、
  990: そのディレクトリの所有グループとすることを意味しています。
  991: @c See also comment in commitinfo node regarding cases
  992: @c which are really awkward with unix groups.
  993: 
  994: 従って、
  995: ディレクトリ単位でしかファイルのアクセス権を
  996: 管理することができません。
  997: 
  998: @sc{cvs} はロック・ファイルを作成する必要があるため 
  999: (@pxref{Concurrency})、ファイルを取り出す使用者にも、書き込み許可が必
 1000: 要であることに注意して下さい。
 1001: 
 1002: @c CVS seems to use CVSUMASK in picking permissions for
 1003: @c val-tags, but maybe we should say more about this.
 1004: @c Like val-tags gets created by someone who doesn't
 1005: @c have CVSUMASK set right?
 1006: 利用者は @file{CVSROOT/val-tags} ファイルに書き込み許可が必要なことも
 1007: 注意してください。@sc{cvs} はそれをどのタグが有効かを記録するために使
 1008: います (作成時と、ときどきタグが使用されたときに更新されます)。
 1009: 
 1010: それぞれの @sc{rcs} ファイルは最後に書き込んだ利用者に所有されます。こ
 1011: れはあまり重要ではありません。重要なのは誰がディレクトリを所有している
 1012: かです。
 1013: 
 1014: @cindex CVSUMASK, environment variable
 1015: @cindex umask, for repository files
 1016: 木の中に新しいディレクトリを加える場合、
 1017: @sc{cvs} はできるだけ適当な使用許可を与える努力をします。
 1018: しかし新しいディレクトリの使用許可が、
 1019: 親ディレクトリのものと異なる必要がある場合には、
 1020: 手動で変更する必要があります。
 1021: 環境変数 @code{CVSUMASK} を設定すれば、
 1022: リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。
 1023: @code{CVSUMASK} は、作業ディレクトリのファイル使用許可には影響しません。
 1024: 作業コピーの使用許可は、
 1025: 新たに作成したファイルに通常与えられるものと同じです。
 1026: 但し、@sc{cvs} が読み込みだけを許可することがあります
 1027: (監視時 @ref{Setting a watch}, -r 使用時 @ref{Global options},
 1028: CVSREAD 設定時 @ref{Environment variables} を各々参照)。
 1029: @c FIXME: Need more discussion of which
 1030: @c group should own the file in the repository.
 1031: @c Include a somewhat detailed example of the usual
 1032: @c case where CVSUMASK is 007, the developers are all
 1033: @c in a group, and that group owns stuff in the
 1034: @c repository.  Need to talk about group ownership of
 1035: @c newly-created directories/files (on some unices,
 1036: @c such as SunOS4, setting the setgid bit on the
 1037: @c directories will make files inherit the directory's
 1038: @c group.  On other unices, your mileage may vary.  I
 1039: @c can't remember what POSIX says about this, if
 1040: @c anything).
 1041: 
 1042: クライアント/サーバ @sc{cvs} を使用すると (@pxref{Remote
 1043: repositories})、@code{CVSUMASK} を設定する良い方法はありません。クライ
 1044: アントマシンでの設定は効果がありません。@code{rsh} で接続しているなら、
 1045: オペーレーティングシステムの説明に書いてあるように、@file{.bashrc} や
 1046: @file{.cshrc} で @code{CVSUMASK} を設定することができます。この振る舞
 1047: いは将来のバージョンの @sc{cvs} では変更されるかもしれません。クライア
 1048: ントの @code{CVSUMASK} の設定には頼らず、それは無効になるでしょう。
 1049: @c FIXME: need to explain what a umask is or cite
 1050: @c someplace which does.
 1051: @c
 1052: @c There is also a larger (largely separate) issue
 1053: @c about the meaning of CVSUMASK in a non-unix context.
 1054: @c For example, whether there is
 1055: @c an equivalent which fits better into other
 1056: @c protection schemes like POSIX.6, VMS, &c.
 1057: @c
 1058: @c FIXME: Need one place which discusses this
 1059: @c read-only files thing.  Why would one use -r or
 1060: @c CVSREAD?  Why would one use watches?  How do they
 1061: @c interact?
 1062: @c
 1063: @c FIXME: We need to state
 1064: @c whether using CVSUMASK removes the need for manually
 1065: @c fixing permissions (in fact, if we are going to mention
 1066: @c manually fixing permission, we better document a lot
 1067: @c better just what we mean by "fix").
 1068: 
 1069: pserver を使う場合は、一般的に、 @sc{cvsroot} ディレクトリと木構造でそ
 1070: れより上のディレクトリには厳しい使用許可が必要です。@ref{Password
 1071: authentication security} を参照してください。
 1072: 
 1073: @cindex setuid
 1074: @cindex setgid
 1075: @cindex security, setuid
 1076: @cindex installed images (VMS)
 1077: オペレーティングシステムには特定のプログラムが、プログラムの呼び手には
 1078: できないような動作をする能力とともに実行される機能があるものがあります。
 1079: 例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や
 1080: VMS の installed image 機能です。CVS はそのような機能を使用するように
 1081: 書かれていませんので、そのような方法で CVS をインストールすると事故の
 1082: 過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして
 1083: いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使
 1084: 用許可を得るかもしれません。代わりに pserver を使用することを考えるか
 1085: もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ
 1086: キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供
 1087: する可能性がありますので、このオプションを考えているなら、pserver の説
 1088: 明文書を注意深く読んでください。(@ref{Password authentication
 1089: security})。
 1090: 
 1091: @node Windows permissions
 1092: @subsection Windows に特有なファイルの使用許可問題
 1093: @cindex Windows, and permissions
 1094: @cindex File permissions, Windows-specific
 1095: @cindex permissions, Windows-specific
 1096: 
 1097: ファイルの使用許可には Windows オペレーティングシステムに特有の問題も
 1098: あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ
 1099: ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、
 1100: 確かではありません)。
 1101: 
 1102: ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ
 1103: トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる
 1104: ことがあることが報告されています。Samba の設定で WRITE=YES にすると修
 1105: 正される/何とかなると言われています。
 1106: 責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調
 1107: 査をしていません。加えて、問題を避けるために CVS が違ったようにするこ
 1108: とができるかどうかも調べていません。何か発見したなら、@ref{BUGS} に書
 1109: かれているように我々に報せてください。
 1110: 
 1111: @node Attic
 1112: @subsection The attic
 1113: @cindex attic
 1114: 
 1115: ときどき @sc{cvs} は @sc{rcs} ファイルを @code{Attic} に保存することが
 1116: あることに気付くでしょう。例えば、@sc{cvsroot} が 
 1117: @file{/usr/local/cvsroot} でディレクトリ @file{yoyodyne/tc} のファイル
 1118: @file{backend.c} について話をしているとき、普通はファイルは以下のとこ
 1119: ろにあります
 1120: 
 1121: @example
 1122: /usr/local/cvsroot/yoyodyne/tc/backend.c,v
 1123: @end example
 1124: 
 1125: しかし、attic に行けば、代わりに
 1126: 
 1127: @example
 1128: /usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
 1129: @end example
 1130: 
 1131: @cindex dead state
 1132: になります。利用者にとってはファイルが attic にあるかどうかは関係あり
 1133: ません。@sc{cvs} はこれを記録し、必要なときは attic を調べます。詳細を
 1134: 知りたい人のために書くと、幹の先頭リビジョンが @code{dead} の状態であ
 1135: るまさにそのときだけ、ファイルは attic に保存されます。@code{dead} の
 1136: 状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが
 1137: ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは
 1138: @code{dead} の状態になり枝のリビジョンは @code{dead} ではない状態にな
 1139: ります。
 1140: @c Probably should have some more concrete examples
 1141: @c here, or somewhere (not sure exactly how we should
 1142: @c arrange the discussion of the dead state, versus
 1143: @c discussion of the attic).
 1144: 
 1145: @node CVS in repository
 1146: 
 1147: @subsection リポジトリの CVS ディレクトリ
 1148: @cindex CVS directory, in repository
 1149: 
 1150: それぞれのリポジトリのディレクトリの @file{CVS} ディレクトリはファイル
 1151: 属性などの情報が収められています (@file{CVS/fileattr} というファイルで
 1152: す。詳しい情報は CVS のソース配布の fileattr.h を見てください)。将来は
 1153: このディレクトリには他のファイルが加えられる可能性がありますから、実装
 1154: は追加のファイルを静かに無視するのが良いでしょう。
 1155: 
 1156: この動作は @sc{cvs} 1.7 とその後のものだけで実装されています。詳細は
 1157: @ref{Watches Compatibility} を参照してください。
 1158: 
 1159: @node Locks
 1160: @subsection リポジトリの CVS ロック
 1161: 
 1162: @cindex #cvs.rfl, technical details
 1163: @cindex #cvs.wfl, technical details
 1164: @cindex #cvs.lock, technical details
 1165: @cindex locks, cvs, technical details
 1166: 利用者から見える部分の CVS のロックに焦点をあてた紹介は 
 1167: @ref{Concurrency} を参照してください。次の部分は同じリポジトリをアクセ
 1168: スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう
 1169: なツールを書きたい人を対象にしています。@dfn{読み込みロック}
 1170: (@dfn{read lock}), @dfn{書き込みロック} (@dfn{write lock}), @dfn{デッ
 1171: ドロック} (@dfn{deadlock}) のような概念がよくわからなかったら、オペレー
 1172: ティングシステムやデータベースの文献を参照すると良いかもしれません。
 1173: 
 1174: @cindex #cvs.tfl
 1175: リポジトリ中の @file{#cvs.rfl} で始まる全てのファイルは読み込みロック
 1176: です。リポジトリ中の @file{#cvs.wfl} で始まる全てのファイルは書き込み
 1177: ロックです。古いバージョンの CVS (CVS 1.5 以前) は @file{#cvs.tfl} で
 1178: 始まる名前のファイルも作成していましたが、ここではそれらは議論しません。
 1179: ディレクトリ @file{#cvs.lock} はマスターロックとして働きます。すなわち、
 1180: 他のロックを取得する前に、まずこのロックを取得しなければならない、とい
 1181: うことです。
 1182: 
 1183: 書き込みロックを取得するためには、まず @file{#cvs.lock} ディレクトリを
 1184: 作成します。この操作は原子的操作でなければなりません (これはたいていの
 1185: オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた
 1186: めに失敗すれば、しばらく待ってもう一度試します。@file{#cvs.lock} ロッ
 1187: クを取得した後、@file{#cvs.rfl} の後に選択した情報 (例えば、ホスト名と
 1188: プロセス番号) が続いた名前のファイルを作成します。それからマスターロッ
 1189: クを解放するために @file{#cvs.lock} ディレクトリを消去します。それから
 1190: リポジトリを読んで続行します。終った後、読み込みロックを解放するために
 1191: @file{#cvs.rfl} ファイルを消去します。
 1192: 
 1193: 書き込みロックを取得するためには、読み込みロックと同様にまず 
 1194: @file{#cvs.lock} ディレクトリを作成します。それから @file{#cvs.rfl} で
 1195: 始まるファイルが無いかどうかを調べます。もしあれば、@file{#cvs.lock} 
 1196: を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、
 1197: @file{#cvs.wfl} の後に選択した情報を続けた名前のファイルを作成します 
 1198: (例えば、ホスト名とプロセス番号)。ロック @file{#cvs.lock} を続けます。
 1199: リポジトリへの書き込みを実行します。それが終わると、まず 
 1200: @file{#cvs.wfl} ファイルを消去し、それから @file{#cvs.lock} ディレクト
 1201: リを消去します。@file{#cvs.rfl} ファイルと違って、@file{#cvs.wfl} ファ
 1202: イルは情報提供のためだけにあることに注意してください。@file{#cvs.lock} 
 1203: そのもののロックを続ける以上のロック操作の効果はありません。
 1204: 
 1205: それぞれのロック (書き込みロック及び読み込みロック) は @file{Attic} と
 1206: @file{CVS} を含んだリポジトリの単独のディレクトリのみをロックしますが、
 1207: バージョン管理下の他のディレクトリは含まないことに注意してください。木
 1208: 全体をロックするためには、それぞれのディレクトリをロックする必要があり
 1209: ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため
 1210: に再挑戦の前に木全体を解放しなければならないことに注意してください)。
 1211: 
 1212: @sc{cvs} は個々の @file{foo,v} ファイルへのアクセス制御のために書き込
 1213: みロックを期待するということにも注意してください。@sc{rcs} には 
 1214: @file{,foo,} ファイルがロックとして働く機構がありますが、@sc{cvs} はそ
 1215: れを実装しておらず、@sc{cvs} の書き込みロックを取り出すことが推奨され
 1216: ています。さらなる議論/合理性は @sc{cvs} のソースコードの 
 1217: rcs_internal_lockfile のところのコメントを読んでください。
 1218: 
 1219: @node CVSROOT storage
 1220: @subsection CVSROOT ディレクトリでファイルが保管される方法
 1221: @cindex CVSROOT, storage of files
 1222: 
 1223: @file{$CVSROOT/CVSROOT} ディレクトリにはいろいろな管理ファイルがありま
 1224: す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て
 1225: います。そこにはファイル名が @samp{,v} で終わる多くの @sc{rcs} ファイ
 1226: ルがあり、多くの @sc{cvs} コマンドは同じ方法でそれを操作します。しかし、
 1227: 少しの違いはあります。
 1228: 
 1229: それぞれの管理ファイルには、@sc{rcs} ファイルに加えて、ファイルの取り
 1230: 出された版のコピーがあります。例えば、@sc{rcs} ファイル 
 1231: @file{loginfo,v} とそれの最新リビジョンであるファイル @file{loginfo}
 1232: があります。管理ファイルを格納したときは、@sc{cvs} は
 1233: 
 1234: @example
 1235: cvs commit: Rebuilding administrative file database
 1236: @end example
 1237: 
 1238: @noindent
 1239: @cindex checkoutlist
 1240: を印字し、@file{$CVSROOT/CVSROOT} の取り出された版のコピーを更新するよ
 1241: うになっています。もしそうならなければ、何かがおかしくなっています 
 1242: (@pxref{BUGS})。自分自身のファイルをこのように更新されるファイル群に追
 1243: 加するために、それらを管理ファイル @file{checkoutlist} に追加できます。
 1244: 
 1245: @cindex modules.db
 1246: @cindex modules.pag
 1247: @cindex modules.dir
 1248: 初期設定では @file{modules} ファイルは上で説明されているように振舞いま
 1249: す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし
 1250: て保存しているとモジュールの探索が遅くなるかもしれません (@sc{cvs} が
 1251: 最初にこの機能を追加したときほど関心があるかどうかは定かではありません。
 1252: ベンチマークは見ていませんので)。ですから、@sc{cvs} ソースコードに適切
 1253: な修正を加えるとおで、modules ファイルを Berkeley db や GDBM のような 
 1254: @code{ndbm} インターフェースを実装したデータベースで保存することができ
 1255: ます。このオプションが使用されると、modules データベースは
 1256: @file{module.db}, @file{modules} と/もしくは @file{modules.dir} に保存
 1257: されます。
 1258: @c I think fileattr also will use the database stuff.
 1259: @c Anything else?
 1260: 
 1261: いろいろな管理ファイルの意味に関する情報は @ref{Administrative files}
 1262: を参照してください。
 1263: 
 1264: @node Working directory storage
 1265: @section リポジトリでのデータの保存方法
 1266: 
 1267: @c FIXME: Somewhere we should discuss timestamps (test
 1268: @c case "stamps" in sanity.sh).  But not here.  Maybe
 1269: @c in some kind of "working directory" chapter which
 1270: @c would encompass the "Builds" one?  But I'm not sure
 1271: @c whether that is a good organization (is it based on
 1272: @c what the user wants to do?).
 1273: 
 1274: @cindex CVS directory, in working directory
 1275: しばしば表面に現れてくるかもしれない @sc{cvs} の内部についての話をして
 1276: いる間に、@sc{cvs} が作業ディレクトリの @file{CVS} ディレクトリに何を
 1277: 入れるかも話した方が良いでしょう。リポジトリと同様に、@sc{cvs} がこの
 1278: 情報を扱い、普通は @sc{cvs} のコマンドを通してだけそれを使用します。で
 1279: も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター
 1280: フェース の @code{jCVS} や emacs のための @code{VC} パッケージなどの他
 1281: のプログラムがそれを見る必要があるかもしれません。そのようなプログラム
 1282: は、上で書いたプログラムやコマンド行 @sc{cvs} クライアントの将来のバー
 1283: ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望
 1284: むなら、この節の推奨規格に従う必要があります。
 1285: 
 1286: @file{CVS} ディレクトリには複数のファイルがあります。このディレクトリ
 1287: を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在
 1288: するけれどここで説明されていないファイルは静かに無視するのが望ましいで
 1289: す。
 1290: 
 1291: ファイルは使用しているシステムのテキストファイルの習慣に従って保存され
 1292: ます。これはテキストファイルの補完の習慣が違うシステム間では作業ディレ
 1293: クトリは可搬性が無いということです。これは意図的になされていて、おそら
 1294: く CVS で管理されているファイル自体がそのようなシステム間では可搬性が
 1295: ないであろう、という理由に基づいています。
 1296: 
 1297: @table @file
 1298: @item Root
 1299: このファイルは @ref{Specifying a repository} で説明されているように、
 1300: 現在の @sc{cvs} のルートを保持しています。
 1301: 
 1302: @cindex Repository file, in CVS directory
 1303: @cindex CVS/Repository file
 1304: @item Repository
 1305: このファイルは現在のディレクトリが対応するリポジトリでのディレクトリを
 1306: 保持しています。指定は絶対パス名と相対パス名のどちらでも可能です。
 1307: @sc{cvs} は少なくともバージョン 1.3 くらいから両方の形式を読み込む能力
 1308: を備えています。相対パスはルートからの相対位置で、より賢い方法ですが、
 1309: 絶対パス名は非常によく使われており、実装は両方を受け付けることが望まれ
 1310: ます。例えば、以下のコマンドの後で
 1311: 
 1312: @example
 1313: cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
 1314: @end example
 1315: 
 1316: @file{Root} は以下のようになり
 1317: 
 1318: @example
 1319: :local:/usr/local/cvsroot
 1320: @end example
 1321: 
 1322: @file{Repository} は
 1323: 
 1324: @example
 1325: /usr/local/cvsroot/yoyodyne/tc
 1326: @end example
 1327: 
 1328: @noindent
 1329:  1330: 
 1331: @example
 1332: yoyodyne/tc
 1333: @end example
 1334: 
 1335: @noindent
 1336: のどちらかになります。
 1337: 
 1338: 特定の作業ディレクトリがリポジトリのディレクトリに対応しなければ、
 1339: @file{Repository} は @file{CVSROOT/Emptydir} になっているはずです。
 1340: 
 1341: @cindex Entries file, in CVS directory
 1342: @cindex CVS/Entries file
 1343: @item Entries
 1344: このファイルは作業ディレクトリ中のファイルとディレクトリの一覧を挙げて
 1345: います。
 1346: 各行の最初の文字はそれがどんな行かを示します。将来の拡張ができるように、
 1347: 文字を認識できない場合は、ファイルを読み込んでいるファイルは暗黙にその
 1348: 行を飛ばすことが望まれます。
 1349: 
 1350: 最初の文字が @samp{/} であれば、様式は:
 1351: 
 1352: @example
 1353: /@var{name}/@var{revision}/@var{timestamp}[+@var{conflict}]/@var{options}/@var{tagdate}
 1354: @end example
 1355: 
 1356: で、@samp{[} と @samp{]} は登録の一部ではありませんが、その代わりに 
 1357: @samp{+} と衝突の印は省略任意であることを示しています。@var{name} はディ
 1358: レクトリ中のファイルの名前です。@var{revision} は作業中のファイルの元
 1359: のリビジョンで、@samp{0} の場合は追加されたファイル、@samp{-} の後にリ
 1360: ビジョンは削除されたファイルです。@var{timestamp} は @sc{cvs} がファイ
 1361: ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の
 1362: 修正時刻と違えば、ファイルは修正されたということです。それは Universal
 1363: Time (UT) で、ISO c astime() 関数で使われる様式で保存されます (例えば、
 1364: @samp{Sun Apr 7 01:29:26 1996})。ファイルが常に修正されていると見なさ
 1365: れるように、例えば、@samp{Result of merge} のようにその様式とは違う文
 1366: 字列を書くかもしれません。これは特別な場合ではありません。ファイルが修
 1367: 正されたかどうかを調べるために、プログラムはファイルのタイムスタンプを
 1368: 単純に @var{timestamp} と文字列比較をするべきです。@var{conflict} は衝
 1369: 突があったことを示します。もしそれが実際の修正時刻と同じであるなら、ユー
 1370: ザは明かに衝突を解消していません。@var{options} は貼り付けられたオプショ
 1371: ンを保持しています (例えば、バイナリ・ファイルのための @samp{-kbd})。
 1372: @var{tagdate} は @samp{T} の後にタグ名が続いているか、日付 (date) の 
 1373: @samp{D} で、貼り付けられたタグか日付がつづいているかのどちらかを保持
 1374: しています。@var{timestamp} が単独のタイムスタンプではなく、スペースで
 1375: 分離されたタイムスタンプの対であるなら、@sc{cvs} 1.5 より前のバージョ
 1376: ンの @sc{cvs} を扱っているということに注意してください (ここでは説明さ
 1377: れていません)。
 1378: 
 1379: @file{Entries} の行の最初の文字が @samp{D} であると、それはサブディレ
 1380: クトリを現しています。行が @samp{D} だけのときは、 @file{Entries} ファ
 1381: イルを書いたプログラムはサブディレクトリを記録したということを現します 
 1382: (ですから、そのような行があって、他に @samp{D} で始まる行がなければ、
 1383: サブディレクトリがないことがわかります)。そうでなければ、行は次のよう
 1384: になっています:
 1385: 
 1386: @example
 1387: D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
 1388: @end example
 1389: 
 1390: ここで @var{name} はサブディレクトリの名前であり、将来の拡張のために、
 1391: 全ての @var{filler} 部分は暗黙の内に無視されるべきです。@code{Entries} 
 1392: を修正するプログラムはこれらの部分を保存するのが望まれています。
 1393: 
 1394: ファイル @file{Entries} 中の行はどんな順番でも構いません。
 1395: 
 1396: @cindex Entries.Log file, in CVS directory
 1397: @cindex CVS/Entries.Log file
 1398: @item Entries.Log
 1399: このファイルは @file{Entries} に無いさらなる情報を記録することはありま
 1400: せんが、@file{Entries} ファイル全体を再書き込みすることなく、情報を更
 1401: 新するための方法をもたらし、その中には @file{Entries} と 
 1402: @file{Entries.Log} を書いているプログラムが不意に異常終了しても情報を
 1403: 保護する機能もあります。@file{Entries} ファイルを読み込むプログラムは
 1404: @file{Entries.Log} も調べるべきです。後者が存在すれば、@file{Entries} 
 1405: を読み込んで、@file{Entries.Log} にある変更を適用すべきです。変更を適
 1406: 用した後で、@file{Entries} を再度書き込んで、@file{Entries} を消去する
 1407: 習慣が推奨されています。@file{Entries.Log} の行の様式は、単独文字コマ
 1408: ンドがあり、その後にスペースが続き、その後は @file{Entries} の行に指定
 1409: された様式になります。単独文字コマンドは登録が追加されたことを示す
 1410: @samp{A} と登録が消去されたことを示す @samp{R} か、@file{Entries} の登
 1411: 録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2
 1412: 番目の文字が @file{Entries.Log} の行の2番目の文字がスペースでないと、
 1413: それは @sc{cvs} の古いバージョンで書かれています (ここでは説明されてい
 1414: ません)。
 1415: 
 1416: 読み込みではなく、書き込みをしているプログラムは、もし望むならば
 1417: @file{Entries.Log} ファイルを安全に無視することもできます。
 1418: 
 1419: @cindex Entries.Backup file, in CVS directory
 1420: @cindex CVS/Entries.Backup file
 1421: @item Entries.Backup
 1422: これは一時ファイルです。推奨された使用法は、新しい Entriy ファイルを 
 1423: @file{Entries.Backup} に書き、それから @file{Entries} に改名する (もし
 1424: 可能なら原子的操作で) ことです。
 1425: 
 1426: @cindex Entries.Static file, in CVS directory
 1427: @cindex CVS/Entries.Static file
 1428: @item Entries.Static
 1429: このファイルが関連する唯一のことはそれが存在するか否か、ということです。
 1430: もし存在すると、ディレクトリの一部分だけが取得されていて、@sc{cvs} は
 1431: そのディレクトリに追加のファイルを作成しないということです。それを消去
 1432: するためには、@code{update} コマンドを @samp{-d} オプションとともに使っ
 1433: てください。そうすれば、追加のファイルを取得して、
 1434: @file{Entries.Static} を消去します。
 1435: @c FIXME: This needs to be better documented, in places
 1436: @c other than Working Directory Storage.
 1437: @c FIXCVS: The fact that this setting exists needs to
 1438: @c be more visible to the user.  For example "cvs
 1439: @c status foo", in the case where the file would be
 1440: @c gotten except for Entries.Static, might say
 1441: @c something to distinguish this from other cases.
 1442: @c One thing that periodically gets suggested is to
 1443: @c have "cvs update" print something when it skips
 1444: @c files due to Entries.Static, but IMHO that kind of
 1445: @c noise pretty much makes the Entries.Static feature
 1446: @c useless.
 1447: 
 1448: @cindex Tag file, in CVS directory
 1449: @cindex CVS/Tag file
 1450: @cindex Sticky tags/dates, per-directory
 1451: @cindex Per-directory sticky tags/dates
 1452: @item Tag
 1453: このファイルはディレクトリごとの貼り付いたタグを保持します。最初の文字
 1454: は枝のタグには @samp{T}、枝でないタグは @samp{N}、日付は @samp{D} にな
 1455: り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ
 1456: の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付
 1457: は新規に追加されたファイルに適用されること等に使用されることに注意して
 1458: ください。貼り付きタグと日付に関する一般的な情報は @ref{Sticky tags} 
 1459: を参照してください。
 1460: @c FIXME: This needs to be much better documented,
 1461: @c preferably not in the context of "working directory
 1462: @c storage".
 1463: @c FIXME: The Sticky tags node needs to discuss, or xref to
 1464: @c someplace which discusses, per-directory sticky
 1465: @c tags and the distinction with per-file sticky tags.
 1466: 
 1467: @cindex Checkin.prog file, in CVS directory
 1468: @cindex CVS/Checkin.prog file
 1469: @cindex Update.prog file, in CVS directory
 1470: @cindex CVS/Update.prog file
 1471: @item Checkin.prog
 1472: @itemx Update.prog
 1473: これらのファイルはそれぞれ modules ファイルの @samp{-i} と @samp{-u}
 1474: オプションで指定されたプログラムを保存します。
 1475: 
 1476: @cindex Notify file, in CVS directory
 1477: @cindex CVS/Notify file
 1478: @item Notify
 1479: このファイルはまだサーバに送信されていない通知 (例えば、@code{edit} や 
 1480: @code{unedit} のため) を保存します。書式はまだここでは説明されていませ
 1481: ん。
 1482: 
 1483: @cindex Notify.tmp file, in CVS directory
 1484: @cindex CVS/Notify.tmp file
 1485: @item Notify.tmp
 1486: このファイルと @file{Notify} の関係は @file{Entries.Backup} と 
 1487: @file{Entries} の関係と同じです。即ち、@file{Notify} を書くためにはま
 1488: ず新しい内容を @file{Notify.tmp} に書き、それから (可能であれば自動的
 1489: に) それを @file{Notify} に改名します。
 1490: 
 1491: @cindex Base directory, in CVS directory
 1492: @cindex CVS/Base directory
 1493: @item Base
 1494: 監視を使用していると、@code{edit} コマンドはファイルの元のコピーを 
 1495: @file{Base} ディレクトリに保存します。これで、サーバと通信できないとき
 1496: でさえ @code{unedit} コマンドが実行できるようになります。
 1497: 
 1498: @cindex Baserev file, in CVS directory
 1499: @cindex CVS/Baserev file
 1500: @item Baserev
 1501: このファイルは @file{Base} ディレクトリのそれぞれのファイルのリビジョ
 1502: ンを一覧にします。書式は:
 1503: 
 1504: @example
 1505: B@var{name}/@var{rev}/@var{expansion}
 1506: @end example
 1507: 
 1508: で、@var{expansion} は将来の拡張のために、無視されるべきものです。
 1509: 
 1510: @cindex Baserev.tmp file, in CVS directory
 1511: @cindex CVS/Baserev.tmp file
 1512: @item Baserev.tmp
 1513: このファイルと @file{Baserev} の関係は @file{Entries.Backup} と
 1514: @file{Entries} との関係と同じです。即ち、@file{Baserev} に書くために、
 1515: まず新しい内容を @file{Baserev.tmp} に書き、それから (もし可能なら自動
 1516: 的に) それを @file{Baserev} に改名します。
 1517: 
 1518: @cindex Template file, in CVS directory
 1519: @cindex CVS/Template file
 1520: @item Template
 1521: このファイルには @file{rcsinfo} ファイルで指定された雛型が入っています
 1522: (@pxref{rcsinfo})。それはクライアントだけに使われます。非クライアント/
 1523: サーバ型 @sc{cvs} は直接 @file{rcsinfo} ファイルを調べます。
 1524: @end table
 1525: 
 1526: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1527: @node Intro administrative files
 1528: @section 管理用ファイルの紹介
 1529: @cindex Administrative files (intro)
 1530: @cindex Modules file
 1531: @cindex CVSROOT, module name
 1532: @cindex Defining modules (intro)
 1533: 
 1534: @c FIXME: this node should be reorganized into "general
 1535: @c information about admin files" and put the "editing
 1536: @c admin files" stuff up front rather than jumping into
 1537: @c the details of modules right away.  Then the
 1538: @c Administrative files node can go away, the information
 1539: @c on each admin file distributed to a place appropriate
 1540: @c to its function, and this node can contain a table
 1541: @c listing each file and a @ref to its detailed description.
 1542: 
 1543: @file{$CVSROOT/CVSROOT} には、いくつか @dfn{管理用ファイル} 
 1544: (@dfn{administrative files}) があります。完全な説明は 
 1545: @xref{Administrative files}. これらのファイルが無く
 1546: ても @sc{cvs} を使用することができます。しかし、少なくとも 
 1547: @file{modules} というファイルが適切に設定してあれば @sc{cvs} のコマン
 1548: ドはうまく働きます。
 1549: 
 1550: 管理用ファイルの中で、
 1551: 最も重要なファイルは @file{modules} です。
 1552: これはリポジトリの中の全てのモジュールを定義しています。
 1553: @file{modules} ファイルの例を次に示します。
 1554: 
 1555: @c FIXME: The CVSROOT line is a goofy example now that
 1556: @c mkmodules doesn't exist.
 1557: @example
 1558: CVSROOT         CVSROOT
 1559: modules         CVSROOT modules
 1560: cvs             gnu/cvs
 1561: rcs             gnu/rcs
 1562: diff            gnu/diff
 1563: tc              yoyodyne/tc
 1564: @end example
 1565: 
 1566: @file{modules} ファイルは行ごとに意味を持つファイルです。
 1567: @file{modules} ファイルの各行はそれぞれ、
 1568: モジュール名, 空白, モジュールのあるディレクトリ名
 1569: という書式で記述されます。
 1570: モジュールのあるディレクトリ名は、
 1571: @code{$CVSROOT} からの相対パスです。
 1572: @file{modules} ファイルの各行はそれぞれ、
 1573: モジュール名, 空白, モジュールのあるディレクトリ名
 1574: という書式で記述されます。
 1575: モジュールのあるディレクトリ名は、
 1576: @code{$CVSROOT} からの相対パスです。
 1577: 上の例の最後の4行はそのような行の例です。
 1578: 
 1579: @c FIXME: might want to introduce the concept of options in modules file
 1580: @c (the old example which was here, -i mkmodules, is obsolete).
 1581: 
 1582: モジュール @samp{modules} を定義する行については、
 1583: ここでは説明しません。
 1584: より詳しい説明は @ref{modules} 参照。
 1585: 
 1586: @c FIXME: subsection without node is bogus
 1587: @subsection 管理用ファイルの編集
 1588: @cindex Editing administrative files
 1589: @cindex Administrative files, editing them
 1590: 
 1591: 管理用ファイルは、
 1592: 他のモジュールと同じ方法で編集します。
 1593: @samp{cvs checkout CVSROOT} を用いて作業コピーを取り出して、
 1594: 編集し、通常通り変更内容を格納します。
 1595: 
 1596: 間違いのある管理用ファイルを格納することも可能です。
 1597: このような場合には、間違いを正して新たなリビジョンを登録します。
 1598: しかし管理用ファイルに深刻な間違いがあれば、
 1599: 新たなリビジョンの登録さえも不可能になります。
 1600: @c @xref{Bad administrative files} for a hint
 1601: @c about how to solve such situations.
 1602: @c -- administrative file checking--
 1603: 
 1604: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1605: @node Multiple repositories
 1606: @section 複数のリポジトリ
 1607: @cindex Multiple repositories
 1608: @cindex Repositories, multiple
 1609: @cindex Many repositories
 1610: @cindex Parallel repositories
 1611: @cindex Disjoint repositories
 1612: @cindex CVSROOT, multiple repositories
 1613: 
 1614: 特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ
 1615: のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ
 1616: ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変
 1617: 数 @code{$CVSROOT} で設定するか、@sc{cvs} のオプション @samp{-d} に指
 1618: 定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に @sc{cvs} 
 1619: に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ
 1620: けです。
 1621: 
 1622: 複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。
 1623: @sc{cvs} バージョン 1.10 では、単独のコマンドは違うリポジトリのディレ
 1624: クトリを再帰的に辿ることはできません。開発バージョンの @sc{cvs} では、
 1625: 複数のサーバから作業ディレクトリに取り出すことがでます。@sc{cvs} は要
 1626: 求されたコマンドを実行するために必要であれば、再帰的に動作し、対応する
 1627: 数のサーバ・マシンに接続するという細い作業全部を扱います。
 1628: 以下は作業ディレクトリを設定する例です:
 1629: 
 1630: @example
 1631: cvs -d server1:/cvs co dir1
 1632: cd dir1
 1633: cvs -d server2:/root co sdir
 1634: cvs update
 1635: @end example
 1636: 
 1637: @code{cvs co} コマンドは作業ディレクトリを設定し、それから @code{cvs
 1638: update} コマンドは server2 に接続し、dir1/sdir サブディレクトリを更新
 1639: し、その他のものを更新するために server1 に接続します。
 1640: @c FIXME: Does the FAQ have more about this?  I have a
 1641: @c dim recollection, but I'm too lazy to check right now.
 1642: 
 1643: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1644: @node Creating a repository
 1645: @section リポジトリの作成
 1646: 
 1647: @cindex Repository, setting up
 1648: @cindex Creating a repository
 1649: @cindex Setting up a repository
 1650: 
 1651: @sc{cvs} リポジトリを設定するために、まずソースファイルのリビジョン履
 1652: 歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも
 1653: のですので、たいていのマシンは十分なはずです。詳細は @ref{Server
 1654: requirements} を参照してください。
 1655: @c Possible that we should be providing a quick rule of
 1656: @c thumb, like the 32M memory for the server.  That
 1657: @c might increase the number of people who are happy
 1658: @c with the answer, without following the xref.
 1659: 
 1660: ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを
 1661: 移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、
 1662: バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ
 1663: ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに
 1664: なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは
 1665: ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同
 1666: じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、
 1667: 全体の木かそれの一部分のどちらかになります)。
 1668: 
 1669: リポジトリはサーバ経由からか直接 @sc{cvs} を使う全てのマシンからか、
 1670: (直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に
 1671: する必要があります。クライアントのマシンは @sc{cvs} プロトコル経由以外
 1672: でそれにアクセス可能である必要はありません。@sc{cvs} は、リポジトリに
 1673: ロック・ファイルを作成する必要があるため (@pxref{Concurrency})、利用者
 1674: が読み込み許可しか持たないリポジトリを、@sc{cvs} から使うことはできま
 1675: せん。
 1676: 
 1677: @cindex init (subcommand)
 1678: リポジトリを作成するときには、@code{cvs init} コマンドを実行して下さい。
 1679: 通常の方法で指定された @sc{cvs} のルート (@pxref{Repository}) 以下の、
 1680: 空のリポジトリを利用できるように整えます。例えば次のようにします。
 1681: 
 1682: @example
 1683: cvs -d /usr/local/cvsroot init
 1684: @end example
 1685: 
 1686: @code{cvs init} は注意深いので、リポジトリに存在するファイルを上書きし
 1687: ません。従って既に利用できる状態のリポジトリに対して @code{cvs init} 
 1688: を実行しても、何の不都合もありません。
 1689: 
 1690: @code{cvs init} は、操作履歴を記録するように設定します。
 1691: もしこれを望まないのであれば、@code{cvs init} を実行した後に、
 1692: @file{history} ファイルを削除して下さい。@xref{history file}.
 1693: 
 1694: @node Backing up
 1695: @section リポジトリのバックアップ
 1696: @cindex Repository, backing up
 1697: @cindex Backing up, repository
 1698: 
 1699: リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん
 1700: どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき
 1701: 点も幾つかあります。
 1702: 
 1703: @cindex locks, cvs, and backups
 1704: @cindex #cvs.rfl, and backups
 1705: 最初の点は偏執的で、バックアップ中には @sc{cvs} を使用しないか、バック
 1706: アップ中はバックアッププログラムに @sc{cvs} をロックさせる必要がありま
 1707: す。@sc{cvs} を使わないために、リポジトリを操作できるマシンへのログイ
 1708: ンを禁止したり、@sc{cvs} サーバを停止したり、同様な機構を利用するかも
 1709: しれません。詳細はあなたのオペレーティングシステムと、@sc{cvs} を設定
 1710: した方法に依存します。@sc{cvs} をロックするためには、@file{#cvs.rfl} 
 1711: ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう
 1712: に言ってきましたが、これらの事前注意をせずにただバックアップを行なって
 1713: も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元
 1714: すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること
 1715: が非常に難しいということは無いでしょう。
 1716: 
 1717: リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時
 1718: から変更されていると仮定すると、失敗に影響を受けあかったディレクトリは
 1719: 今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし
 1720: れません。そのようなディレクトリで @sc{cvs} を実行しようとすると、普通
 1721: はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す
 1722: 方法の一つに以下のようなものがあります:
 1723: 
 1724: @itemize @bullet
 1725: @item
 1726: 新しい作業ディレクトリを取得します。
 1727: 
 1728: @item
 1729: 失敗前に作業ディレクトリからファイルをコピーします (もちろん、
 1730: @file{CVS} ディレクトリの内容をコピーしないでください)。
 1731: 
 1732: @item
 1733: 新しい作業ディレクトリで作業をし、@code{cvs update} や @code{cvs diff} 
 1734: のようなコマンドを使って何が変更されたかを見つけ、準備がでいたなら、変
 1735: 更をリポジトリに格納します。
 1736: @end itemize
 1737: 
 1738: @node Moving a repository
 1739: @section リポジトリの移動
 1740: @cindex repository, moving
 1741: @cindex moving a repository
 1742: @cindex copying a repository
 1743: 
 1744: リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く
 1745: 似ているように、リポジトリを別の場所に移動する必要があるときも、それは
 1746: 他のファイルの集合を移動するのと非常に良く似ています。
 1747: 
 1748: 主に考慮することは、作業ディレクトリがリポジトリを指しているか、という
 1749: ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し
 1750: い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ
 1751: クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような
 1752: 何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作
 1753: 業ディレクトリを再利用したいなら、@file{CVS/Repository} ファイルを手で
 1754: 手術することで可能です。@file{CVS/Repository}  と @file{CVS/Root} ファ
 1755: イルの情報は @ref{Working  directory storage} で参照することができます
 1756: が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。
 1757: @c FIXME: Surgery on CVS/Repository should be avoided
 1758: @c by making RELATIVE_REPOS the default.
 1759: @c FIXME-maybe: might want some documented way to
 1760: @c change the CVS/Root files in some particular tree.
 1761: @c But then again, I don't know, maybe just having
 1762: @c people do this in perl/shell/&c isn't so bad...
 1763: 
 1764: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 1765: @node Remote repositories
 1766: @section 別のマシンのリポジトリ
 1767: @cindex Repositories, remote
 1768: @cindex Remote repositories
 1769: @cindex Client/Server Operation
 1770: @cindex server, CVS
 1771: 
 1772: ソースの作業コピーはリポジトリと別のマシンに存在することができます。
 1773: @sc{cvs} をこの方法で使うことは @dfn{クライアント/サーバ}
 1774: (@dfn{client/server}) 操作として知られています。@dfn{クライアント} と
 1775: して、@sc{cvs} を作業ディレクトリを mount できるマシンで @sc{cvs} を実
 1776: 行し、@dfn{サーバ} となる、リポジトリを mount できるマシンと通信するよ
 1777: うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式
 1778: が以下のようになることを除き、ローカルのものを使うのと同じです:
 1779: 
 1780: @example
 1781: :@var{method}:@var{user}@@@var{hostname}:/path/to/repository
 1782: @end example
 1783: 
 1784: どれが本当に設定する必要があるかは、サーバに接続している方法に依って変
 1785: わります。
 1786: 
 1787: @var{method} が指定されず、リポジトリ名に @samp{:} が含まれる場合には、
 1788: 使用するオペレーティングシステムに依って @code{ext} か @code{server} 
 1789: が既定値とされます。詳しくは @ref{Connecting via rsh} 参照。
 1790: @c Should we try to explain which platforms are which?
 1791: @c Platforms like unix and VMS, which only allow
 1792: @c privileged programs to bind to sockets <1024 lose on
 1793: @c :server:
 1794: @c Platforms like Mac and VMS, whose rsh program is
 1795: @c unusable or nonexistent, lose on :ext:
 1796: @c Platforms like OS/2 and NT probably could plausibly
 1797: @c default either way (modulo -b troubles).
 1798: 
 1799: @c FIXME: We need to have a better way of explaining
 1800: @c what method to use.  This presentation totally
 1801: @c obscures the fact that :ext: and CVS_RSH is the way to
 1802: @c use SSH, for example.  Plus it incorrectly implies
 1803: @c that you need an @code{rsh} binary on the client to use
 1804: @c :server:.
 1805: @c Also note that rsh not pserver is the right choice if you want
 1806: @c users to be able to create their own repositories
 1807: @c (because of the --allow-root related issues).
 1808: @menu
 1809: * Server requirements::         サーバのためのメモリと他の資源
 1810: * Connecting via rsh::          接続に @code{rsh} プログラムを利用する
 1811: * Password authenticated::      パスワードを利用して直接接続する
 1812: * GSSAPI authenticated::        GSSAPI を利用して直接接続する
 1813: * Kerberos authenticated::      ケルベロスを利用して直接接続する
 1814: * Connecting via fork::         接続に fork された @code{cvs server}を使う
 1815: @end menu
 1816: 
 1817: @node Server requirements
 1818: @subsection サーバの要求
 1819: 
 1820: サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は
 1821: こじんまりとしたものであるということです---32M のメモリやそれ以下のサー
 1822: バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。
 1823: @c Say something about CPU speed too?  I'm even less sure
 1824: @c what to say on that subject...
 1825: 
 1826: もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の
 1827: 見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分
 1828: が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで
 1829: ないものがあれば、この説明文書を更新できるように、@ref{BUGS} に書かれ
 1830: ているように、我々に知らせてください)。
 1831: 
 1832: 大量のメモリ消費をする最初の部分は、@sc{cvs} サーバを使っているときの
 1833: 大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための
 1834: 2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ
 1835: ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー
 1836: ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな
 1837: るか、2メガバイトほどかどちらか大きいものになることが予想されています。
 1838: @c "two megabytes" of course is SERVER_HI_WATER.  But
 1839: @c we don't mention that here because we are
 1840: @c documenting the default configuration of CVS.  If it
 1841: @c is a "standard" thing to change that value, it
 1842: @c should be some kind of run-time configuration.
 1843: @c
 1844: @c See cvsclient.texi for more on the design decision
 1845: @c to not have locks in place while waiting for the
 1846: @c client, which is what results in memory consumption
 1847: @c as high as this.
 1848: 
 1849: それぞれの @sc{cvs} サーバの大きさを予想上の一度に活動するサーバ数で掛
 1850: けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい
 1851: ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ
 1852: リでしょう。
 1853: @c Has anyone verified that notion about swap space?
 1854: @c I say it based pretty much on guessing that the
 1855: @c ->text of the struct buffer_data only gets accessed
 1856: @c in a first in, first out fashion, but I haven't
 1857: @c looked very closely.
 1858: 
 1859: @c What about disk usage in /tmp on the server?  I think that
 1860: @c it can be substantial, but I haven't looked at this
 1861: @c again and tried to figure it out ("cvs import" is
 1862: @c probably the worst case...).
 1863: 
 1864: 大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの
 1865: @code{diff} です。これはバイナリ・ファイルでさえも必要です。大体の目安
 1866: は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が
 1867: 適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を
 1868: するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ 
 1869: でなければ、@sc{cvs} を実行しているマシン) に100メガバイトのメモリがあ
 1870: るのが良いです。これは物理メモリでなく、スワップであるかもしれません。
 1871: メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ
 1872: れるときのためのメモリを準備する必要は特にありません。
 1873: @c The 5-10 times rule of thumb is from Paul Eggert for
 1874: @c GNU diff.  I don't think it is in the GNU diff
 1875: @c manual or anyplace like that.
 1876: @c
 1877: @c Probably we could be saying more about
 1878: @c non-client/server CVS.
 1879: @c I would guess for non-client/server CVS in an NFS
 1880: @c environment the biggest issues are the network and
 1881: @c the NFS server.
 1882: 
 1883: クライアントの資源消費はさらに少ないです---オペレーティングシステムを
 1884: 動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。
 1885: @c Is that true?  I think the client still wants to
 1886: @c (bogusly) store entire files in memory at times.
 1887: 
 1888: ディスク容量に対する要求の情報は、@ref{Creating a repository} を参照し
 1889: てください。
 1890: 
 1891: @node Connecting via rsh
 1892: @subsection rsh で接続する
 1893: 
 1894: @cindex rsh
 1895: CVS はこれらの操作を実行するために @file{rsh} プロトコルを用いますので、
 1896: 遠隔側の使用者のホストはローカルの使用者の接続を許可する
 1897: @file{.rhosts} を持つ必要があります。
 1898: 
 1899: 例えば、あなたがローカルマシン @file{toe.example.com} の利用者
 1900: @file{mozart} であり、サーバマシンは @file{faun.example.org} であると
 1901: しましょう。faun では、以下の行を @file{bach} のホームディレクトリ
 1902: の @file{.rhosts} ファイルに書いてください:
 1903: 
 1904: @example
 1905: toe.example.com  mozart
 1906: @end example
 1907: 
 1908: そして、@code{rsh} の動作を次の行で確認します。
 1909: 
 1910: @example
 1911: rsh -l bach faun.example.org 'echo $PATH'
 1912: @end example
 1913: 
 1914: @cindex CVS_SERVER, environment variable
 1915: 次に @code{rsh} が、
 1916: サーバを発見できるかどうか確認する必要があります。
 1917: 上記の例で @code{rsh} が表示したパスの中に、
 1918: サーバである @code{cvs} のあるディレクトリが
 1919: 含まれているかどうか確認して下さい。
 1920: @file{.login} や @file{.profile} でなく、
 1921: @file{.bashrc}, @file{.cshrc} 等に
 1922: パスを設定する必要があります。
 1923: 代わりに、クライアント側で環境変数 @code{CVS_SERVER} に、
 1924: @file{/usr/local/bin/cvs-1.6} などと、
 1925: 使用したいサーバ名を設定できます。
 1926: @c FIXME: there should be a way to specify the
 1927: @c program in CVSROOT, not CVS_SERVER, so that one can use
 1928: @c different ones for different roots.  e.g. ":server;cvs=cvs-1.6:"
 1929: @c instead of ":server:".
 1930: 
 1931: @file{inetd.conf} を編集したり、
 1932: @sc{cvs} のサーバ・デーモンを走らせる必要はありません。
 1933: 
 1934: @cindex :server:, setting up
 1935: @cindex :ext:, setting up
 1936: @cindex Kerberos, using kerberized rsh
 1937: @cindex SSH (rsh replacement)
 1938: @cindex rsh replacements (Kerberized, SSH, &c)
 1939: @code{rsh} 経由で @code{$CVSROOT} を利用するときに
 1940: 指定できる接続経路は二つあります。
 1941: @code{:server:} を指定した場合、
 1942: @sc{cvs} が内部実装した @code{rsh} のクライアントが用いられますが、
 1943: 移植版では利用できないものもあります。
 1944: @code{:ext:} を指定した場合、外部の @code{rsh} プログラムが用いられます。
 1945: @code{rsh} が既定となっていますが、
 1946: サーバを利用できる他のプログラムを呼び出す場合は、
 1947: 環境変数 @code{CVS_RSH} に設定して下さい 
 1948: (例えば HP-UX 9 では、
 1949: @code{rsh} は何か別のものなので @code{remsh} を用いて下さい)。
 1950: 指定するプログラムは、データを変更しないで送受信できなくてはいけません。
 1951: 例えば Windows NT の @code{rsh} は、
 1952: 既定では @t{CRLF} を @t{LF} に換えるので不適当です。
 1953: @sc{cvs} の OS/2 版はこれを回避するため、
 1954: @code{rsh} に @samp{-b} を渡して切り抜けていますが、
 1955: 標準的な @code{rsh} でないプログラムを黙認する形になるので、
 1956: 将来は別のやり方になるでしょう。
 1957: @code{CVS_RSH} に @code{SSH} 等の @code{rsh} の代替物を設定した場合、
 1958: この節の残りの @file{.rhosts} の使用説明などは、
 1959: おそらく不適当でしょうから、
 1960: 各 @code{rsh} の代替物の文書資料を参照して下さい。
 1961: @c FIXME: there should be a way to specify the
 1962: @c program in CVSROOT, not CVS_RSH, so that one can use
 1963: @c different ones for different roots.  e.g. ":ext;rsh=remsh:"
 1964: @c instead of ":ext:".
 1965: @c See also the comment in src/client.c for rationale
 1966: @c concerning "rsh" being the default and never
 1967: @c "remsh".
 1968: 
 1969: 例を続けます。仮に @file{faun.example.org} の
 1970: リポジトリ @file{/usr/local/cvsroot/} 中の
 1971: モジュール @file{foo} を利用したい場合には、
 1972: もう準備はできています:
 1973: 
 1974: @example
 1975: cvs -d :ext:bach@@faun.example.org:/usr/local/cvsroot checkout foo
 1976: @end example
 1977: 
 1978: (クライアント側とサーバ側で、使用者名が同じ場合には、
 1979: @file{bach@@} を省略することが出来ます。)
 1980: 
 1981: @c Should we mention "rsh host echo hi" and "rsh host
 1982: @c cat" (the latter followed by typing text and ^D)
 1983: @c as troubleshooting techniques?  Probably yes
 1984: @c (people tend to have trouble setting this up),
 1985: @c but this kind of thing can be hard to spell out.
 1986: 
 1987: @node Password authenticated
 1988: @subsection パスワード認証による直接接続
 1989: 
 1990: @sc{cvs} のクライアントは、
 1991: パスワード・プロトコルを用いて、
 1992: サーバと接続することもできます。
 1993: この方法は、
 1994: @code{rsh} の使用が可能でなく 
 1995: (例えばサーバが防火壁の向こうにある場合)、
 1996: またケルベロスも利用できない場合に特に有効です。
 1997: 
 1998: この方法を使用するために、
 1999: サーバとクライアント双方での調整が必要になります。
 2000: 
 2001: @menu
 2002: * Password authentication server::     サーバ側の設定
 2003: * Password authentication client::     クライアントの使用
 2004: * Password authentication security::   この方法が何をして何をしないか
 2005: @end menu
 2006: 
 2007: @node Password authentication server
 2008: @subsubsection パスワード認証のためのサーバの設定
 2009: 
 2010: まず最初に、@file{$CVSROOT} と @file{$CVSROOT/CVSROOT} ディレクトリの
 2011: 使用許可をきつくすることを考えるでしょう。詳細は @ref{Password
 2012: authentication security} を参照してください。
 2013: 
 2014: @cindex Pserver (subcommand)
 2015: @cindex password server, setting up
 2016: @cindex authenticating server, setting up
 2017: @c FIXME: this isn't quite right regarding port
 2018: @c numbers; CVS looks up "cvspserver" in
 2019: @c /etc/services (on unix, but what about non-unix?).
 2020: サーバ側では @file{/etc/inetd.conf} を編集する必要があります。
 2021: 正しいポートに接続を受けた時、
 2022: @code{inetd} がコマンド @code{cvs pserver} を実行する様に変更します。
 2023: ポート番号の既定値は 2401 ですが、
 2024: クライアントをコンパイルした時に、
 2025: @code{CVS_AUTH_PORT} に他の値を定義した場合には異なります。
 2026: 
 2027: あなたの使用する @code{inetd} が、
 2028: ポート番号を素のまま @file{/etc/inetd.conf} に書いて良いならば、
 2029: 次の記述で十分でしょう 
 2030: (@file{inetd.conf} には一行で記述して下さい):
 2031: 
 2032: @example
 2033: 2401  stream  tcp  nowait  root  /usr/local/bin/cvs
 2034: cvs --allow-root=/usr/cvsroot pserver
 2035: @end example
 2036: 
 2037: @samp{-T} オプションで一時ファイルを作成するディレクトリも指定できます。
 2038: 
 2039: @samp{--allow-root} オプションは使用可能な @sc{cvsroot} ディレクトリを
 2040: 指定します。違う @sc{cvsroot} ディレクトリの使用を試みるクライアントは
 2041: 接続できません。許可したい @sc{cvsroot} ディレクトリが2つ以上あるなら、
 2042: オプションを繰り返してください。
 2043: 
 2044: あなたの使用する @code{inetd} が、
 2045: 素のポート番号ではなく、サービス名を要求するならば、
 2046: @file{/etc/services} に次の行を追加して下さい:
 2047: 
 2048: @example
 2049: cvspserver      2401/tcp
 2050: @end example
 2051: 
 2052: そして @file{inetd.conf} には、
 2053: @code{2401} ではなく @code{cvspserver} と記述して下さい。
 2054: 
 2055: 以上を注意して行なった後、
 2056: @code{inetd} を再起動するか、
 2057: 初期設定ファイルを再読させるのに必要な処置を取って下さい。
 2058: 
 2059: これの設定に問題があるときは、@ref{Connection} を参照してください。
 2060: 
 2061: @cindex CVS passwd file
 2062: @cindex passwd (admin file)
 2063: クライアントはパスワードを平文のまま保存または伝送します 
 2064: (ほぼそのように---詳細は @ref{Password authentication security})。
 2065: 従って、リポジトリを利用する時に、
 2066: 正規のパスワードを危険に曝さないために、
 2067: @sc{cvs} では別のパスワードファイルを使用します。
 2068: このファイルは @file{$CVSROOT/CVSROOT/passwd} です。
 2069: その書式は、使用者名、パスワード、サーバが使用する任意に省略可能な使用
 2070: 者名という二つか三つの欄しかない事を除けば、
 2071: @file{/etc/passwd} と同様です。
 2072: 次に例示します:
 2073: 
 2074: @example
 2075: bach:ULtgRLXo7NRxs
 2076: cwang:1sOp854gDF3DY
 2077: @end example
 2078: 
 2079: パスワードは、標準 Unix の関数 @code{crypt()} によって暗号化されます。
 2080: 従って、標準 Unix の @file{passwd} から直接コピーすることも可能です。
 2081: 
 2082: パスワード認証では、まずサーバが、
 2083: @sc{cvs} の @file{passwd} ファイル中の、使用者のエントリを確認します。
 2084: 使用者のエントリがあれば、入力されたパスワードと比較されます。
 2085: 使用者のエントリが無いか、
 2086: あるいは @sc{cvs} の @file{passwd} ファイルが存在しない場合には、
 2087: システムが使用者の調査機構に使用するパスワードと一致するか試されます
 2088: (cofig ファイルで @code{SystemAuth=no} を設定することで、システムの使
 2089: 用者調査機構を使用不能にすることができます)。
 2090: サーバはエントリの三番目の欄にある使用者の権限で実行されます。
 2091: 三番目の欄が無い場合には、最初の欄にある使用者の権限が使用されます 
 2092: (つまり @sc{cvs} の @file{passwd} ファイルに、
 2093: システムで有効な使用者を併せて記述すれば、
 2094: 架空の使用者名を使用できます)。
 2095: どちらの場合でも、
 2096: (有効な) 使用者が持たない特権は付与されません。
 2097: 
 2098: @cindex user aliases
 2099: @file{$CVSROOT/CVSROOT/passwd} ファイルのパスワードの後にコロンとシス
 2100: テムの使用者名を追加することで、CVS 専用の使用者名をシステムの使用者名
 2101: に ``マップ'' することが可能です。(例えば、システムのログイン名に)。例
 2102: えば:
 2103: 
 2104: @example
 2105: cvs:ULtgRLXo7NRxs:kfogel
 2106: generic:1sOp854gDF3DY:spwang
 2107: anyone:1sOp854gDF3DY:spwang
 2108: @end example
 2109: 
 2110: こうやって、次のコマンド:
 2111: 
 2112: @example
 2113: cvs -d :pserver:cvs@@faun.example.org:/usr/local/cvsroot checkout foo
 2114: @end example
 2115: 
 2116: で @file{faun.example.org} のリポジトリに遠隔接続する人は、認証に成功
 2117: すると、システムの kfogel としてサーバを実行することになります。しかし、
 2118: 遠隔使用者は、 @file{$CVSROOT/CVSROOT/passwd} ファイルに @sc{cvs} のみ
 2119: が使用する違ったパスワードがあるかもしれませんので、kfogel のシステム
 2120: パスワードが必ず必要なわけではありません。そして、上記の例で示されてい
 2121: るように、複数の cvs 利用者名を単一のシステムの利用者名にマップするこ
 2122: とができます。
 2123: 
 2124: この機能はリポジトリへの接続をシステムへの完全な接続を行うことなく (特
 2125: に、@ref{Read-only access} を参照してください) 可能にするために設計さ
 2126: れています。しかし、@ref{Password authentication security} も参照して
 2127: ください。どんな種類のリポジトリ接続でも、ある程度の総合的なシステム接
 2128: 続も含んでいる可能性が高いのです。
 2129: 
 2130: 現在、
 2131: @sc{cvs} の @file{passwd} ファイルにパスワードを加えるには、
 2132: 他のどこかからコピーするしか方法がありません。
 2133: いつの日か @code{cvs passwd} コマンドができることでしょう。
 2134: @file{$CVSROOT/CVSROOT} の多くのファイルと違って、@file{passwd} ファイ
 2135: ルは @sc{cvs} 経由ではなく、直接編集します。
 2136: @c We might also suggest using the @code{htpasswd} command
 2137: @c from freely available web servers as well, but that
 2138: @c would open up a can of worms in that the users next
 2139: @c questions are likely to be "where do I get it?" and
 2140: @c "how do I use it?"
 2141: @c Also note that htpasswd, at least the version I had,
 2142: @c likes to clobber the third field.
 2143: 
 2144: @node Password authentication client
 2145: @subsubsection パスワード認証によるクライアントの使用
 2146: @cindex Login (subcommand)
 2147: @cindex password client, using
 2148: @cindex authenticated client, using
 2149: @cindex :pserver:, setting up
 2150: サーバに接続する前に、
 2151: 使用者はコマンド @code{cvs login} を用いて
 2152: @dfn{ログイン}する必要があります。
 2153: サーバのパスワード確認と同時に、
 2154: 後のサーバとの処理のためにパスワードを保存します。
 2155: コマンド @code{cvs login} は、
 2156: 使用者名, サーバのホスト名, リポジトリへのフルパス等の情報が必要で、
 2157: リポジトリの引数もしくは環境変数 @code{CVSROOT} から取得します。
 2158: 
 2159: @code{cvs login} は対話的です---それはパスワード入力を促します:
 2160: 
 2161: @example
 2162: cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot login
 2163: CVS password:
 2164: @end example
 2165: 
 2166: サーバによりパスワードが照合され、
 2167: 正しければ @code{login} が成功しますが、
 2168: 誤りであれば失敗して、パスワードが正しく無いと文句を言います。
 2169: 
 2170: 一度ログインに成功すると、@sc{cvs} に保存されたパスワードを
 2171: 使って認証し、直接サーバに接続するようにさせられます:
 2172: 
 2173: @example
 2174: cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot checkout foo
 2175: @end example
 2176: 
 2177: @sc{cvs} がサーバに接続する際、
 2178: @code{:pserver:} が無ければ、
 2179: @code{rsh} が用いられます (@pxref{Connecting via rsh})。
 2180: 従って、必ず @code{:pserver:} を付加して下さい。
 2181: (一旦作業コピーを取り出した後、
 2182: 作業ディレクトリ中で @sc{cvs} を実行する場合には、
 2183: もう明示的にリポジトリの指定をする必要はありません。
 2184: @sc{cvs} は作業コピーのサブディレクトリ @file{CVS} に、
 2185: 引数のリポジトリを記録しているためです。)
 2186: 
 2187: パスワードは、既定ではファイル @file{$HOME/.cvspass} に保存されます。
 2188: ファイルは人が読める書式で書かれていますが、
 2189: 十分な知識無しに編集してはいけません。
 2190: パスワードは平文ではなく、
 2191: "悪気無く"見られる事 (つまり、システム管理者が偶然そのファイルを見付け、
 2192: 不注意に見るといった事) を防ぐために、
 2193: 簡単な符号化がなされています。
 2194: 
 2195: @c FIXME: seems to me this needs somewhat more
 2196: @c explanation.
 2197: @cindex Logout (subcommand)
 2198: 現在選ばれている遠隔リポジトリのパスワードは @code{cvs logout} コマン
 2199: ドを使用すると CVS_PASSFILE から消去できます。
 2200: 
 2201: 環境変数 @code{CVS_PASSFILE} は、この既定値に優先します。
 2202: この変数を使用するのであれば、
 2203: @code{cvs login} を実行する@emph{前に}設定しなければいけません。
 2204: @code{cvs login} を実行した後に設定した場合、
 2205: その後の @sc{cvs} コマンドは、
 2206: サーバに送るパスワードを見付けられません。
 2207: 
 2208: @node Password authentication security
 2209: @subsubsection パスワード認証における安全性の考察
 2210: 
 2211: @cindex security, of pserver
 2212: パスワードは、
 2213: 平文を簡単に符号化してクライアント側に保存されており、
 2214: 送信の際も同じ符号化が用いられます。
 2215: この符号化は、パスワードが偶然見られること (すなわちシステム管理者が
 2216: 不注意に見てしまう事) を防ぐためのもので、
 2217: 素人の攻撃からパスワードの取得を防ぐことさえ出来ません。
 2218: 
 2219: @c FIXME: The bit about "access to the repository
 2220: @c implies general access to the system is *not* specific
 2221: @c to pserver; it applies to kerberos and SSH and
 2222: @c everything else too.  Should reorganize the
 2223: @c documentation to make this clear.
 2224: @sc{cvs} 独自のパスワードファイルにより 
 2225: (@pxref{Password authentication server})、
 2226: リポジトリを利用する時には、
 2227: システムにログインする時とは別のパスワードが使用できます。
 2228: しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、
 2229: 多様な方法により、サーバ上でプログラムが実行可能になります。
 2230: つまりリポジトリの利用は、
 2231: かなり広範囲にシステムが利用できる事を暗示しています。
 2232: これを防止するように @sc{cvs} を修正する事は可能でしょうが、
 2233: これを書いている時点までには誰もやっていません。
 2234: @c OpenBSD uses chroot() and copies the repository to
 2235: @c provide anonymous read-only access (for details see
 2236: @c http://www.openbsd.org/anoncvs.shar).  While this
 2237: @c closes the most obvious holes, I'm not sure it
 2238: @c closes enough holes to recommend it (plus it is
 2239: @c *very* easy to accidentally screw up a setup of this
 2240: @c type).
 2241: さらに @sc{cvs} を利用して、
 2242: システムに対するより一般的な権限を獲得する別の方法が存在するでしょう。
 2243: しかし誰も徹底した審査を行っていません。
 2244: 
 2245: @file{$CVSROOT/CVSROOT} ディレクトリには @file{passwd} と他のセキュリ
 2246: ティを調べるために使われるファイルがあるので、このディレクトリの使用許
 2247: 可をを @file{/etc} と同じくらいきつくしなければならないことに注意して
 2248: ください。同じことが @file{$CVSROOT} ディレクトリそのものと、木のそれ
 2249: より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ
 2250: クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが
 2251: できます。これらの使用許可は普通は pserver を使っていないときに使用す
 2252: るものよりもきついものであることに注意してください。
 2253: @c TODO: Would be really nice to document/implement a
 2254: @c scheme where the CVS server can run as some non-root
 2255: @c user, e.g. "cvs".  CVSROOT/passwd would contain a
 2256: @c bunch of entries of the form foo:xxx:cvs (or the "cvs"
 2257: @c would be implicit).  This would greatly reduce
 2258: @c security risks such as those hinted at in the
 2259: @c previous paragraph.  I think minor changes to CVS
 2260: @c might be required but mostly this would just need
 2261: @c someone who wants to play with it, document it, &c.
 2262: 
 2263: 要約すると、
 2264: パスワードを得た人物は誰でもリポジトリを利用でき、
 2265: またある程度通常のシステム利用も可能になります。
 2266: ネットワークのパケットを漁ったり、
 2267: 保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、
 2268: 全ての人物がパスワードを入手可能です。
 2269: あなたが本物の安全を望むのならば、ケルベロスにしましょう。
 2270: 
 2271: @node GSSAPI authenticated
 2272: @subsection GSSAPI による直接接続
 2273: 
 2274: @cindex GSSAPI
 2275: @cindex security, GSSAPI
 2276: @cindex :gserver:, setting up
 2277: @cindex Kerberos, using :gserver:
 2278: GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般
 2279: 的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、
 2280: @sc{cvs} を GSSAPI で認証して、直接 @sc{tcp} 接続を通して接続すること
 2281: ができます。
 2282: 
 2283: これをするためには、@sc{cvs} が GSSAPI サポート付きでコンパイルされて
 2284: いる必要があります。@sc{cvs} を configure しているときに、ケルベロス 
 2285: version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま
 2286: す。構築するために @file{--with-gssapi} も使用できます。
 2287: 
 2288: 接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認
 2289: 証@emph{されません}。ストリームの認証を要求するためには、広域オプショ
 2290: ン @code{-a} を使用する必要があります。
 2291: 
 2292: 既定状態では、データ転送は暗号化@emph{されません}。
 2293: クライアントとサーバ双方を、
 2294: 暗号化を有効にしてコンパイルしておく必要があります。
 2295: 構築時に @file{--enable-encryption} オプションを付加して、
 2296: 暗号化機能を有効にして下さい。
 2297: また暗号化を要求するために、
 2298: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2299: 
 2300: GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ
 2301: れます。@ref{Password authentication server} 参照。ケルベロスのような
 2302: 強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ
 2303: る認証を使用不能にしたいと思うかもしれません。そのためには、空の 
 2304: @file{CVSROOT/passwd} パスワードファイルを作成して、config ファイルで 
 2305: @code{SystemAuth=no} を設定します (@pxref{config})。
 2306: 
 2307: GSSAPI サーバは cvs/@var{hostname} の主な名前を使い、@var{hostname} は
 2308: サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ
 2309: うにこれを設定しなければなりません。
 2310: 
 2311: GSSAPI を使用して接続するには、@samp{:gserver:} を使用します。例えば、
 2312: 以下のようになります。
 2313: 
 2314: @example
 2315: cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
 2316: @end example
 2317: 
 2318: @node Kerberos authenticated
 2319: @subsection ケルベロスによる直接接続
 2320: 
 2321: @cindex Kerberos, using :kserver:
 2322: @cindex security, kerberos
 2323: @cindex :kserver:, setting up
 2324: ケルベロスを使う一番簡単な方法は @ref{Connecting via rsh} で説明されて
 2325: いるようにケルベロスの @code{rsh} を使用することです。
 2326: rsh を利用する際の主な欠点は、
 2327: 全てのデータが他のプログラムを経由する必要があるため、
 2328: 時間がかかるかもしれない事です。
 2329: もしケルベロスが導入されているならば、
 2330: ケルベロスの認証により、直接 @sc{tcp} 接続する事が可能です
 2331: 
 2332: この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関
 2333: するものです。ケルベロス バージョン5は前節で説明されているように、
 2334: GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ
 2335: うになっています。
 2336: 
 2337: このためには、
 2338: ケルベロスの支援を受けるように @sc{cvs} をコンパイルする必要があります。
 2339: @sc{cvs} は configre 時に
 2340: ケルベロスが利用できるかどうかを検出しようとしますが、
 2341: 駄目ならフラグ @file{--with-krb4} を用いて強制させることも可能です。
 2342: 
 2343: 既定状態では、データ転送は暗号化され@emph{ません}。
 2344: クライアントとサーバ双方を、
 2345: 暗号化を有効にしてコンパイルしておく必要があります。
 2346: 構築時に @file{--enable-encryption} オプションを付加して、
 2347: 暗号化機能を有効にして下さい。
 2348: また暗号化を要求するために、
 2349: 使用時に広域オプション @samp{-x} を付加する必要があります。
 2350: 
 2351: @cindex CVS_CLIENT_PORT
 2352: サーバの @file{inetd.conf} を編集する必要があります。
 2353: クライアントが使用する既定のポート番号は 1999 です。
 2354: 他のポートを使用したい場合には、
 2355: クライアントの環境変数 @code{CVS_CLIENT_PORT} で指定して下さい。
 2356: 
 2357: @cindex kinit
 2358: @sc{cvs} を利用する前に、
 2359: 通常の方法で切符を取得して下さい (一般的には @code{kinit} です)。
 2360: この切符でサーバへのログインが許可されるはずです。
 2361: これで準備ができました:
 2362: 
 2363: @example
 2364: cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
 2365: @end example
 2366: 
 2367: ここで接続に失敗した場合、
 2368: 以前のバージョンの @sc{cvs} は rsh で再接続を試みましたが、
 2369: このバージョンでは再試行されません。
 2370: 
 2371: @node Connecting via fork
 2372: @subsection fork を通じての接続
 2373: 
 2374: @cindex fork, access method
 2375: @cindex :fork:, setting up
 2376: この接続方法で、ローカル・ディスクのリポジトリに遠隔プロトコルを使って
 2377: 接続することができます。言い換えると、それは @code{:local:} とほとんど
 2378: 同じことをしますが、変な振舞いや、バグやその他のものはローカルの
 2379: @sc{cvs} のものではなく、遠隔 @sc{cvs} のものです。
 2380: 
 2381: 毎日の作業では、@code{:local:} か @code{:fork:} を好むかは個人の好みに
 2382: 依ります。もちろん @code{:fork:} は @code{cvs} と遠隔プロトコルをデバッ
 2383: グしているときは特に役立ちます。特に、我々は他の遠隔アクセス方法のネッ
 2384: トワーク関連の設定、変更、時間切れ設定、認証全てを避けることができ、そ
 2385: の上で遠隔プロトコルを使う接続を作成することができるのです。
 2386: 
 2387: @code{fork} 方法を用いて接続するためには、@samp{:fork:} とローカルのリ
 2388: ポジトリへのパス名を使用します。例えば、:
 2389: 
 2390: @example
 2391: cvs -d :fork:/usr/local/cvsroot checkout foo
 2392: @end example
 2393: 
 2394: @cindex CVS_SERVER, and :fork:
 2395: @code{:ext:} と同様に、サーバは既定値の @samp{cvs} と呼ばれるか、
 2396: @code{CVS_SERVER} 環境変数の値になります。
 2397: 
 2398: @c ---------------------------------------------------------------------
 2399: @node Read-only access
 2400: @section 読み込み専用リポジトリ接続
 2401: @cindex read-only repository access
 2402: @cindex readers (admin file)
 2403: @cindex writers (admin file)
 2404: 
 2405: パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める
 2406: ことができます (@pxref{Password authenticated})。 (他の接続方法は全て
 2407: リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用
 2408: 許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助
 2409: はありません。)
 2410: 
 2411: 読み込み専用接続の使用者は、特定の ``管理'' ファイル (ロックファイルや
 2412: 履歴ファイル) を除いて、リポジトリを変更しない @sc{cvs} の操作のみを実
 2413: 行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ
 2414: う (@pxref{Password authentication server})。
 2415: 
 2416: 以前のバージョンの @sc{cvs} と違って、読み込み専用使用者はリポジトリを
 2417: 読むことができるだけで、サーバのプログラムを実行できないようになってい
 2418: るはずです。そうしないと、予期しないレベルの接続を得ることができてしま
 2419: います。もしくは、より正確に言うと、@emph{既知の}穴は塞がれました。こ
 2420: の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ
 2421: リティへの関心に従って、どのような程度の注意も払うべきというのは正当の
 2422: ようです。
 2423: 
 2424: 使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除
 2425: です。
 2426: 
 2427: "包含" は、使用者を特別に @file{$CVSROOT/CVSROOT/readers} ファイルに一
 2428: 覧表示するということで、それは単純な改行で分離された利用者の一覧です。
 2429: これは @file{readers} ファイルの例です:
 2430: 
 2431: @example
 2432: melissa
 2433: splotnik
 2434: jrandom
 2435: @end example
 2436: 
 2437: (最後の使用者の後の改行を忘れないでください。)
 2438: 
 2439: "排除" は @emph{書き込み} 接続のできる人を全て明示的に一覧表示するとい
 2440: うことです---もしファイル
 2441: 
 2442: @example
 2443: $CVSROOT/CVSROOT/writers
 2444: @end example
 2445: 
 2446: @noindent
 2447: が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その
 2448: 他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相
 2449: 変らず @sc{cvs} @file{passwd} ファイルに挙げられている必要があります。)
 2450: @file{writers} ファイル は @file{readers} ファイルと同じ書式です。
 2451: 
 2452: 注意: @sc{cvs} @file{passwd} ファイルが cvs の使用者をシステムの使用者
 2453: にマップしているときは、@emph{cvs} の使用者名を使って書き込み専用接続
 2454: を拒否したり認めたりしていて、システムの使用者名を使っていないことを確
 2455: 認してください。すなわち、@file{readers} と @file{writers} ファイルに
 2456: cvs の使用者名があるということで、それはシステムの使用者名と同じかもし
 2457: れませんし、違うかもしれません。
 2458: 
 2459: これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ
 2460: の振舞いの完全な説明です。
 2461: 
 2462: @file{readers} が存在して、この使用者がそこに挙げられていれば、読み込
 2463: み専用接続になります。もしくは、@file{writers} が存在していて、使用者
 2464: がそこに挙げられていなければ読み込み専用接続になります (@file{readers}
 2465: が存在するけれど、そこには挙げられていないというときにもそのようになり
 2466: ます)。その他の場合では、完全な読み込み書き込み接続になります。
 2467: 
 2468: もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。
 2469: これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより
 2470: 多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな
 2471: ります。
 2472: 
 2473: @node Server temporary directory
 2474: @section サーバの一時ディレクトリ
 2475: @cindex temporary directories, and server
 2476: @cindex server, temporary directories
 2477: 
 2478: @sc{cvs} サーバは実行中に一時ディレクトリを作成します。それは
 2479: 
 2480: @example
 2481: cvs-serv@var{pid}
 2482: @end example
 2483: 
 2484: @noindent
 2485: のような名前で、@var{pid} はサーバのプロセス番号です。それらは環境変数
 2486: @samp{TMPDIR} (@pxref{Environment variables})、@samp{-T} 広域オプショ
 2487: ン (@pxref{Global options})、で指定されるディレクトリもしくは、それら
 2488: がないと @file{/tmp} に置かれます。
 2489: 
 2490: ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時
 2491: ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな
 2492: い場合がいくつかあります。例えば:
 2493: 
 2494: @itemize @bullet
 2495: @item
 2496: サーバがサーバの内部エラーで異常終了すると、デバッグを助けるためにディ
 2497: レクトリを保存するかもしれません。
 2498: 
 2499: @item
 2500: サーバが後始末をできない方法で kill されたとき (主にほとんど unix での 
 2501: @samp{kill -KILL})。
 2502: 
 2503: @item
 2504: システムが、サーバに後始末をするように告げる通常のシャットダウンをする
 2505: ことなくシャットダウンしたとき。
 2506: @end itemize
 2507: 
 2508: このような場合は、手で @file{cvs-serv@var{pid}} ディレクトリを消去する
 2509: 必要があります。プロセス番号 @var{pid} で動いているサーバが無ければ、
 2510: その行為は安全です。
 2511: 
 2512: @c ---------------------------------------------------------------------
 2513: @node Starting a new project
 2514: @chapter CVS でプロジェクトを始める
 2515: @cindex Starting a project with CVS
 2516: @cindex Creating a project
 2517: 
 2518: @comment --moduledb--
 2519: ファイルの改名とディレクトリ間の移動はうまくできないので、
 2520: 新しいプロジェクトを始めるときには、
 2521: 最初にファイルの構成をよく考えておく必要があります。
 2522: ファイルの改名や移動は、
 2523: 不可能ではありませんが非常にやっかいです。
 2524: 特にディレクトリの改名に関して、
 2525: @sc{cvs} は癖のある動作をします 
 2526: (@pxref{Moving files})。
 2527: 
 2528: 次に何をするかは、始める状況に依ります。
 2529: 
 2530: @menu
 2531: * Setting up the files::        ファイルをリポジトリに加える
 2532: * Defining the module::         ファイルからモジュールを作る
 2533: @end menu
 2534: @c -- File permissions!
 2535: 
 2536: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2537: @node Setting up the files
 2538: @section ファイルの準備
 2539: 
 2540: 始めの一歩は、リポジトリ中にファイルを生成することです。
 2541: これには幾つか異なる方法があります。
 2542: 
 2543: @c -- The contributed scripts
 2544: @menu
 2545: * From files::                  既存のプロジェクトに便利な方法
 2546:                                 (既にファイルが存在する場合)
 2547: * From other version control systems::  古いプロジェクトの、他の
 2548:                                         システムでの履歴を保存する
 2549: * From scratch::                ゼロからディレクトリを作成する
 2550: @end menu
 2551: 
 2552: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2553: @node From files
 2554: @subsection 存在するファイルからディレクトリを生成する
 2555: @cindex Importing files
 2556: 
 2557: @sc{cvs} を使い始める場合に、
 2558: おそらく @sc{cvs} を使用できるプロジェクトが
 2559: 既に幾つかあるでしょう。
 2560: この場合 @code{import} コマンドを使用するのが最も簡単です。
 2561: 例を挙げて説明します。
 2562: @sc{cvs} に組み込みたいファイルが @file{@var{wdir}} にあり、
 2563: それを @file{$CVSROOT/yoyodyne/@var{rdir}} に置きたい時、
 2564: 次のようにします。
 2565: 
 2566: @example
 2567: $ cd @var{wdir}
 2568: $ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
 2569: @end example
 2570: 
 2571: @samp{-m} フラグでログ・メッセージを与えなかった場合、@sc{cvs} により
 2572: エディタが開かれ、メッセージの入力が促されます。文字列 @samp{yoyo} は 
 2573: @dfn{ベンダー・タグ}と呼ばれるものであり、
 2574: @samp{start} は@dfn{リリース・タグ}と呼ばれるもの
 2575: です。この文脈では意味をなさないかもしれませんが、@sc{cvs} はそれらの
 2576: 存在を要求します。詳しくは @xref{Tracking sources}.
 2577: 
 2578: では実際に動作したことを確かめた後、元のソースディレクトリを削除します。
 2579: @c FIXME: Need to say more about "verify that it
 2580: @c worked".  What should the user look for in the output
 2581: @c from "diff -r"?
 2582: 
 2583: @example
 2584: $ cd ..
 2585: $ mv @var{dir} @var{dir}.orig
 2586: $ cvs checkout yoyodyne/@var{dir}       # @r{下で説明}
 2587: $ diff -r @var{dir}.orig yoyodyne/@var{dir}
 2588: $ rm -r @var{dir}.orig
 2589: @end example
 2590: 
 2591: @noindent
 2592: 誤って @sc{cvs} を通さないで編集してしまわないように、下のソースを削除
 2593: すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るの
 2594: が賢明です。
 2595: 
 2596: @code{checkout} コマンドはモジュールの名前 (以前の全ての例のように)、
 2597: または @code{$CVSROOT} からの相対パス (上の例のように) を引数に取りま
 2598: す。
 2599: 
 2600: @sc{cvs} が @samp{$CVSROOT} 中のディレクトリに設定した
 2601: 使用許可とグループ属性が、
 2602: 適切かどうか調べると良いでしょう。@xref{File permissions}.
 2603: 
 2604: 取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、
 2605: wrapper 機能を用いて、どのファイルがバイナリなのか
 2606: 明示するとよいでしょう。@xref{Wrappers}.
 2607: 
 2608: @c The node name is too long, but I am having trouble
 2609: @c thinking of something more concise.
 2610: @node From other version control systems
 2611: @subsection 他のバージョン管理システムからファイルを作成する
 2612: @cindex Importing files, from other version control systems
 2613: 
 2614: @sc{rcs} 等の、
 2615: 他のバージョン管理システムで保守されてきたプロジェクトがあり、
 2616: そのプロジェクトのファイルを @sc{cvs} に移管する場合、
 2617: 各ファイルの修正履歴の維持を望むでしょう。
 2618: 
 2619: @table @asis
 2620: @cindex RCS, importing files from
 2621: @item RCS から
 2622: @sc{rcs} を使用してきた場合、@sc{rcs} ファイルを見付けて下さい---
 2623: 通常 @file{foo.c} という名前のファイルには、
 2624: @file{RCS/foo.c,v} という @sc{rcs} ファイルが対応します 
 2625: (他の場所にあるかもしれませんので、
 2626: 詳細は @sc{rcs} の文書を調べて下さい)。
 2627: 次に、@sc{cvs} リポジトリに適当なディレクトリを作成して下さい。
 2628: そして @sc{cvs} リポジトリの当該ディレクトリに、
 2629: ファイルをコピーして下さい 
 2630: (リポジトリ中のファイル名は、
 2631: ソース・ファイルに @samp{,v} が付加されたものでなくてはならず、
 2632: またファイルは @file{RCS} サブディレクトリではなく、
 2633: 当該ディレクトリに直接置いて下さい)。
 2634: この例のように、@sc{cvs} コマンドを利用せず、
 2635: @sc{cvs} リポジトリを直接利用するほうが適当な場合が稀にあります。
 2636: 以上で作業コピーを新たに取り出す準備ができました。
 2637: @c Someday there probably should be a "cvs import -t
 2638: @c rcs" or some such.  It could even create magic
 2639: @c branches.  It could also do something about the case
 2640: @c where the RCS file had a (non-magic) "0" branch.
 2641: 
 2642: @sc{rcs} ファイルを @sc{cvs} に移動するときに、
 2643: ロックされていてはいけません。
 2644: ロックされている場合には、@sc{cvs} での操作に支障を来します。
 2645: @c What is the easiest way to unlock your files if you
 2646: @c have them locked?  Especially if you have a lot of them?
 2647: @c This is a CVS bug/misfeature; importing RCS files
 2648: @c should ignore whether they are locked and leave them in
 2649: @c an unlocked state.  Yet another reason for a separate
 2650: @c "import RCS file" command.
 2651: 
 2652: @c How many is "many"? Or do they just import RCS files?
 2653: @item 他のバージョン管理システムから
 2654: 多くのバージョン管理システムは、
 2655: 標準形式の @sc{rcs} ファイルを出力する機能を持っています。
 2656: これが可能ならば、@sc{rcs} ファイルを出力して、
 2657: 前項の説明に従って下さい。
 2658: 
 2659: それが駄目なら、おそらく一番良いのは他のシステムのコマンド行のインター
 2660: フェースを使って一回に一つのリビジョンを取り出し、それを @sc{cvs} に格
 2661: 納するスクリプトを書くことでしょう。下の @file{sccs2rs} スクリプトはそ
 2662: のために役に立つ例でしょう。
 2663: 
 2664: @cindex SCCS, importing files from
 2665: @item From SCCS
 2666: @item SCCS から
 2667: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2668: @file{sccs2rcs} という名前のスクリプトがあります。
 2669: これを用いて @sc{sccs} ファイルを @sc{rcs} ファイルに変換できます。
 2670: 注意: @sc{sccs} と @sc{rcs} の両方を持つマシンで実行する必要があり、
 2671: また @file{contrib} 内の他の全てと同様に動作保証はされません 
 2672: (使用者によって評価は異なるでしょう)。
 2673: 
 2674: @cindex PVCS, importing files from
 2675: @item From PVCS
 2676: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 2677: @file{pvcs_to_rcs} という名前のスクリプトがあります。
 2678: これを用いて @sc{pvcs} アーカイブを @sc{rcs} ファイルに変換できます。
 2679: @sc{pvcs} と @sc{rcs} のあるマシンで実行する必要があり、
 2680: また @file{contrib} 内の他の全てと同様に動作保証はされません
 2681: (使用者によって評価は異なるでしょう)。
 2682: 詳細はスクリプト中のコメントを読んでください。
 2683: @end table
 2684: @c CMZ and/or PATCHY were systems that were used in the
 2685: @c high energy physics community (especially for
 2686: @c CERNLIB).  CERN has replaced them with CVS, but the
 2687: @c CAR format seems to live on as a way to submit
 2688: @c changes.  There is a program car2cvs which converts
 2689: @c but I'm not sure where one gets a copy.
 2690: @c Not sure it is worth mentioning here, since it would
 2691: @c appear to affect only one particular community.
 2692: @c Best page for more information is:
 2693: @c http://wwwcn1.cern.ch/asd/cvs/index.html
 2694: @c See also:
 2695: @c http://ecponion.cern.ch/ecpsa/cernlib.html
 2696: 
 2697: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 2698: @node From scratch
 2699: @subsection ゼロからディレクトリを作る
 2700: 
 2701: @c Also/instead should be documenting
 2702: @c $ cvs co -l .
 2703: @c $ mkdir tc
 2704: @c $ cvs add tc
 2705: @c $ cd tc
 2706: @c $ mkdir man
 2707: @c $ cvs add man
 2708: @c etc.
 2709: @c Using import to create the directories only is
 2710: @c probably a somewhat confusing concept.
 2711: 新しいプロジェクトを始める場合、
 2712: まず次のように空のディレクトリを作ります。
 2713: 
 2714: @example
 2715: $ mkdir tc
 2716: $ mkdir tc/man
 2717: $ mkdir tc/testing
 2718: @end example
 2719: 
 2720: その後 @code{import} コマンドを使って、
 2721: リポジトリに各々の (空の) ディレクトリを登録(作成)します:
 2722: 
 2723: @example
 2724: $ cd tc
 2725: $ cvs import -m "Created directory structure" yoyodyne/@var{dir} yoyo start
 2726: @end example
 2727: 
 2728: そして @code{add} コマンドで、
 2729: ファイル (と新しいディレクトリ) を加えていきます。
 2730: 
 2731: その時、 @samp{$CVSROOT} の中のファイルの使用許可が、
 2732: 正しいものかどうかを確認すると良いでしょう。
 2733: 
 2734: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2735: @node Defining the module
 2736: @section モジュールの定義
 2737: @cindex Defining a module
 2738: @cindex Editing the modules file
 2739: @cindex Module, defining
 2740: @cindex Modules file, changing
 2741: 
 2742: 二歩目は @file{modules} ファイルにモジュールの定義をする事です。
 2743: 必ずしも必要ではありませんが、
 2744: 関連するファイルやディレクトリをグループ化するのに便利です。
 2745: 
 2746: モジュールを定義する簡単な手順を示します。
 2747: 
 2748: @enumerate
 2749: @item
 2750: ファイル modules の作業コピーを取ってきます。
 2751: 
 2752: @example
 2753: $ cvs checkout CVSROOT/modules
 2754: $ cd CVSROOT
 2755: @end example
 2756: 
 2757: @item
 2758: ファイルを編集し、モジュールの定義を加えます。
 2759: 導入は @xref{Intro administrative files}.
 2760: 詳細な記述は @ref{modules} 参照。
 2761: モジュール @samp{tc} を定義するには次の行を加えます:
 2762: 
 2763: @example
 2764: tc   yoyodyne/tc
 2765: @end example
 2766: 
 2767: @item
 2768: modules ファイルに変更を格納します。
 2769: 
 2770: @example
 2771: $ cvs commit -m "Added the tc module." modules
 2772: @end example
 2773: 
 2774: @item
 2775: モジュール modules をリリースします。
 2776: 
 2777: @example
 2778: $ cd ..
 2779: $ cvs release -d CVSROOT
 2780: @end example
 2781: @end enumerate
 2782: 
 2783: @c ---------------------------------------------------------------------
 2784: @node Revisions
 2785: @chapter リビジョン
 2786: 
 2787: @sc{cvs} の多くの利用ではあまりリビジョン番号について心配する必要はあ
 2788: りません。@sc{cvs} は @code{1.1}, @code{1.2} などのような番号を割当て、
 2789: それだけが皆が知る必要のあることです。しかし、@sc{cvs} がリビジョン番
 2790: 号を割当てる方法に関してより知識を持ち、より制御したい人もいます。
 2791: 
 2792: どのリビジョンが特定のリリースになったか、などの 1 つより多くのファイ
 2793: ルを含むリビジョンの組を追いかけたいときは、@dfn{タグ} を使います。そ
 2794: れはそれぞれのファイルの数字リビジョンに割当てることのできるリビジョン
 2795: 名です。
 2796: 
 2797: @menu
 2798: * Revision numbers::            リビジョン番号の意味
 2799: * Versions revisions releases::  このマニュアルでの用語
 2800: * Assigning revisions::         リビジョンの割当て
 2801: * Tags::                        タグ--文字によるリビジョン
 2802: * Sticky tags::                 貼り付いたタグ
 2803: * Tagging the working directory::  cvs tag コマンド
 2804: * Tagging by date/tag::         cvs rtag コマンド
 2805: * Modifying tags::              タグの追加、改名、削除
 2806: * Tagging add/remove::          ファイルの追加と削除を伴うタグ
 2807: @end menu
 2808: 
 2809: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2810: @node Revision numbers
 2811: @section リビジョン番号
 2812: @cindex Revision numbers
 2813: @cindex Revision tree
 2814: @cindex Linear development
 2815: @cindex Number, revision-
 2816: @cindex Decimal revision number
 2817: @cindex Branch number
 2818: @cindex Number, branch
 2819: 
 2820: 各バージョンのファイルはそれぞれ一意な@dfn{リビジョン番号} 
 2821: (@dfn{revision number}) を持ちます。
 2822: @samp{1.1}, @samp{1.2} とか @samp{1.3.2.2} とか 
 2823: @samp{1.3.2.2.4.5} なんてのもあります。
 2824: リビジョン番号はピリオドで分けられた偶数個の十進整数です。
 2825: 初期設定ではファイルの最初のリビジョンは 1.1 で、
 2826: リビジョンが新しくなると一番右の番号が1つ増えます。
 2827: 次の絵は、新しいリビジョンを右にして少しリビジョンを図示しています。
 2828: 
 2829: @example
 2830:        +-----+    +-----+    +-----+    +-----+    +-----+
 2831:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 2832:        +-----+    +-----+    +-----+    +-----+    +-----+
 2833: @end example
 2834: 
 2835: 2 つ以上のピリオドを含む番号になることもあります。例えば、
 2836: @samp{1.3.2.2} です。そのようなリビジョンは枝のリビジョンを表します 
 2837: (@pxref{Branching and merging})。そのようなリビジョン番号は 
 2838: @ref{Branching and merging} で詳しく説明されています。
 2839: 
 2840: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2841: @node Versions revisions releases
 2842: @section バージョン、リビジョン、リリース
 2843: @cindex Revisions, versions and releases
 2844: @cindex Versions, revisions and releases
 2845: @cindex Releases, revisions and versions
 2846: 
 2847: 上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト
 2848: ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ
 2849: く @samp{4.1.1} のようなバージョン番号を付けられます。
 2850: 
 2851: バージョンには二つの意味があり、
 2852: 最初のものはこの文書で@dfn{リビジョン}と呼ばれるものです。
 2853: 二番目は@dfn{リリース}と呼ばれるものです。
 2854: 混乱を避けるために、
 2855: この文書ではなるべく@dfn{バージョン}という単語は使わないようにします。
 2856: 
 2857: @node Assigning revisions
 2858: @section リビジョンの割当て
 2859: 
 2860: @c We avoid the "major revision" terminology.  It seems
 2861: @c like jargon.  Hopefully "first number" is clear enough.
 2862: 初期設定では、@sc{cvs} は最初の番号を同じにして 2番目の番号を増加させ
 2863: ることにより数字リビジョンを割当てます。例えば、@code{1.1},
 2864: @code{1.2}, @code{1.3} のように。
 2865: 
 2866: 新しいファイルを加えるときは、2番目の番号は常に 1 で、最初の番号はその
 2867: ディレクトリの中のファイルの最初の番号の一番大きいものと等しくなります。
 2868: 例えば、現在のディレクトリの一番大きい番号が @code{1.7}, @code{3.1},
 2869: @code{4.12} であると、追加されたファイルの数字リビジョンは @code{4.1}
 2870: になります。
 2871: 
 2872: @c This is sort of redundant with something we said a
 2873: @c while ago.  Somewhere we need a better way of
 2874: @c introducing how the first number can be anything
 2875: @c except "1", perhaps.  Also I don't think this
 2876: @c presentation is clear on why we are discussing releases
 2877: @c and first numbers of numeric revisions in the same
 2878: @c breath.
 2879: 普通はリビジョン番号を気にかける必要はありません---それを @sc{cvs} が
 2880: 維持している内部番号のように扱う方が簡単で、タグは製品リリース 1 とリ
 2881: リース 2 のような間を区別するより良い手段です (@pxref{Tags})。 しかし、
 2882: 数字リビジョンを設定したいのであれば、@code{cvs commit} の @samp{-r}
 2883: オプションですることができます。@samp{-r} オプションは @samp{-f} オプ
 2884: ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
 2885: ということになります。
 2886: 
 2887: 例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな
 2888: いものも含めて)、次のように実行するかもしれません:
 2889: 
 2890: @example
 2891: $ cvs commit -r 3.0
 2892: @end example
 2893: 
 2894: @samp{-r} で指定する番号は存在するリビジョン番号より大きくなければなら
 2895: ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、
 2896: @samp{cvs commit -r 1.3} とはできないということです。複数のリリースを
 2897: 並行して維持したいときは、枝を使う必要があります (@pxref{Branching and
 2898: merging}).
 2899: 
 2900: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 2901: @node Tags
 2902: @section タグ--文字によるリビジョン
 2903: @cindex Tags
 2904: 
 2905: リビジョン番号は開発に従って徐々に増えていきますが、
 2906: ソフトウェア製品のリリース番号とは全く何の関係もありません。
 2907: @sc{cvs} の使い方にもよりますが、
 2908: 異なる二つのリリースにおけるリビジョン番号は異なっているでしょう。
 2909: 例えば @sc{rcs} 5.6 を作るソース・ファイルは、
 2910: 次のようなリビジョン番号を持ちます:
 2911: @cindex RCS revision numbers
 2912: 
 2913: @example
 2914: ci.c            5.21
 2915: co.c            5.9
 2916: ident.c         5.3
 2917: rcs.c           5.12
 2918: rcsbase.h       5.11
 2919: rcsdiff.c       5.10
 2920: rcsedit.c       5.11
 2921: rcsfcmp.c       5.9
 2922: rcsgen.c        5.10
 2923: rcslex.c        5.11
 2924: rcsmap.c        5.2
 2925: rcsutil.c       5.10
 2926: @end example
 2927: 
 2928: @cindex tag, command, introduction
 2929: @cindex Tag, symbolic name
 2930: @cindex Symbolic name (tag)
 2931: @cindex Name, symbolic (tag)
 2932: @cindex HEAD, as reserved tag name
 2933: @cindex BASE, as reserved tag name
 2934: @code{tag} コマンドを使えば、
 2935: 特定のリビジョンに名前 (タグ名) を付けることができます。
 2936: 各ファイルに付けられた全てのタグと
 2937: 対応するリビジョン番号を調べたい場合は、
 2938: @code{status} コマンドに @samp{-v} フラグを付けて下さい。
 2939: タグには、大文字と小文字で始まる必要があり、大文字, 小文字, 数字,
 2940: @samp{-}, @samp{_} が使用可能です。
 2941: @code{BASE} と @code{HEAD} の二つのタグ名は、
 2942: @sc{cvs} が使用するために予約されています。
 2943: 将来使われる @sc{cvs} にとって特別な名前は、実際のタグ名との衝突を避け
 2944: るために @code{BASE} や @code{HEAD} などのような名前ではなく、例えば 
 2945: @samp{.} で始まるような特別な方法で命名されることが望まれています。
 2946: @c Including a character such as % or = has also been
 2947: @c suggested as the naming convention for future
 2948: @c special tag names.  Starting with . is nice because
 2949: @c that is not a legal tag name as far as RCS is concerned.
 2950: @c FIXME: CVS actually accepts quite a few characters
 2951: @c in tag names, not just the ones documented above
 2952: @c (see RCS_check_tag).  RCS
 2953: @c defines legitimate tag names by listing illegal
 2954: @c characters rather than legal ones.  CVS is said to lose its
 2955: @c mind if you try to use "/" (try making such a tag sticky
 2956: @c and using "cvs status" client/server--see remote
 2957: @c protocol format for entries line for probable cause).
 2958: @c TODO: The testsuite
 2959: @c should test for whatever are documented above as
 2960: @c officially-OK tag names, and CVS should at least reject
 2961: @c characters that won't work, like "/".
 2962: 
 2963: タグの命名にプログラムの名前とリリースのバージョン番号のような情報に基
 2964: いた何らかの習慣を選びたいでしょう。例えば、CVS 1.9 が @code{cvs1-9} 
 2965: という名前でタグ付けされるように、まずプログラムの名前を使い、その直後
 2966: にバージョン番号の @samp{.} を @samp{-} に変更したものを続けるかもしれ
 2967: ません。同じ習慣を続ければ、常にタグが @code{cvs-1-9} や @code{cvs1_9}
 2968: や他のものであったかを推測する必要はなくなります。taginfo ファイルでそ
 2969: の習慣を強制することさえ考えるかもしれません (@pxref{user-defined
 2970: logging}).
 2971: @c Might be nice to say more about using taginfo this
 2972: @c way, like giving an example, or pointing out any particular
 2973: @c issues which arise.
 2974: 
 2975: @cindex Adding a tag
 2976: @cindex tag, example
 2977: 次の例は、ファイルにタグを付ける方法を示したものです。
 2978: コマンドはあなたの作業ディレクトリで実行して下さい。
 2979: すなわち、@file{backend.c} があるディレクトリでコマンドを実行すべきで
 2980: ある、ということです。
 2981: 
 2982: @example
 2983: $ cvs tag rel-0-4 backend.c
 2984: T backend.c
 2985: $ cvs status -v backend.c
 2986: ===================================================================
 2987: File: backend.c         Status: Up-to-date
 2988: 
 2989:     Version:            1.4     Tue Dec  1 14:39:01 1992
 2990:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 2991:     Sticky Tag:         (none)
 2992:     Sticky Date:        (none)
 2993:     Sticky Options:     (none)
 2994: 
 2995:     Existing Tags:
 2996:         rel-0-4                     (revision: 1.4)
 2997: 
 2998: @end example
 2999: 
 3000: @code{cvs tag} の構文の完全なまとめと、いろいろなオプションの説明は
 3001: @ref{Invoking CVS} を参照してください。
 3002: 
 3003: 単独のファイルにタグを付けるべき理由はほとんどありません。
 3004: タグの主な使い途は、
 3005: モジュールを構成する全てのファイルに同じタグを付け、
 3006: 開発の流れの重要点 (リリース時等) を示すことです。
 3007: 
 3008: @example
 3009: $ cvs tag rel-1-0 .
 3010: cvs tag: Tagging .
 3011: T Makefile
 3012: T backend.c
 3013: T driver.c
 3014: T frontend.c
 3015: T parser.c
 3016: @end example
 3017: 
 3018: (@sc{cvs} に対する引数にディレクトリを指定した場合は、
 3019: そのディレクトリに含まれる全てのファイルにタグが付けられます。
 3020: そのディレクトリ以下の全てのサブディレクトリに対しても
 3021: (再帰的に) 動作します。@xref{Recursive behavior}.)
 3022: 
 3023: @cindex Retrieving an old revision using tags
 3024: @cindex Tag, retrieving old revisions
 3025: @code{checkout} コマンドの @samp{-r} フラグに、
 3026: モジュールから取り出すリビジョンを指定します。
 3027: このフラグを用いて、
 3028: モジュール @samp{ tc} のリリース 1.0 を作るソースを、
 3029: 将来のいつでも簡単に復元することができます:
 3030: 
 3031: @example
 3032: $ cvs checkout -r rel-1-0 tc
 3033: @end example
 3034: 
 3035: @noindent
 3036: リリース時にタグを付けるようにしておけば、
 3037: 過去のリリースにバグが発見されたが最新版には無い、
 3038: という場合などに非常に便利です。
 3039: 
 3040: 任意の時間を指定してモジュールを復元することもできます。 
 3041: @xref{checkout options}. @samp{-r} をこれらのコマンドのどれかに指定す
 3042: るときは、貼り付きタグに注意する必要があります。@ref{Sticky tags} 参照。
 3043: 
 3044: 複数のファイルに同じタグを付けるという事を、
 3045: 「ファイル名とリビジョン番号の行列の中に線を引く」
 3046: と考えると良いでしょう。
 3047: 以下のリビジョンの五つのファイルがあるとしましょう:
 3048: 
 3049: @example
 3050: @group
 3051:         file1   file2   file3   file4   file5
 3052: 
 3053:         1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
 3054:         1.2*-   1.2     1.2    -1.2*-
 3055:         1.3  \- 1.3*-   1.3   / 1.3
 3056:         1.4          \  1.4  /  1.4
 3057:                       \-1.5*-   1.5
 3058:                         1.6
 3059: @end group
 3060: @end example
 3061: 
 3062: 過去の何らかの時点で、
 3063: @code{*} の付けられたバージョンにタグが付けられています。
 3064: 上図では @samp{*} の付いたリビジョンにタグが付けられています。
 3065: 仮にタグ名を「タグ付きリビジョンを結んだ紐」と考えると、
 3066: @code{checkout} の @samp{-r} は
 3067: 「紐を引くとタグ付きリビジョン全てが釣れる」などと解釈できるでしょう。
 3068: あるいはタグ付きリビジョンを水平に並べた方が、分り易いかも知れません:
 3069: 
 3070: @example
 3071: @group
 3072:         file1   file2   file3   file4   file5
 3073: 
 3074:                         1.1
 3075:                         1.2
 3076:                 1.1     1.3                       _
 3077:         1.1     1.2     1.4     1.1              /
 3078:         1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- ここを見る
 3079:         1.3             1.6     1.3              \_
 3080:         1.4                     1.4
 3081:                                 1.5
 3082: @end group
 3083: @end example
 3084: 
 3085: @node Tagging the working directory
 3086: @section 作業ディレクトリからどれをタグ付けするかを指定する
 3087: 
 3088: @cindex Tag (subcommand)
 3089: 前の節の例は、どのリビジョンにタグを付けるかを選ぶ一番普通の方法を表し
 3090: ています。つまり、引数無しの @code{cvs tag} コマンドでは、@sc{cvs} は
 3091: 現在の作業ディレクトリに取り出されたリビジョンを選択します。例えば、作
 3092: 業ディレクトリの @file{backend.c} がリビジョン1.4から取り出されたので
 3093: あれば、@sc{cvs} はリビジョン1.4にタグを付けます。タグはリポジトリのリ
 3094: ビジョン1.4にすぐに適用されることに注意してくさい。タグ付けはファイル
 3095: の修正とは違いますし、まず作業ディレクトリを修正してそれから @code{cvs
 3096: commit} を実行して修正をリポジトリに送信するような他の操作とも違います。
 3097: 
 3098: @code{cvs tag} がリポジトリに作用するという事実による、もしかすると驚
 3099: くかもしれない側面に、格納されたリビジョンにタグを付けていて、それは作
 3100: 業ディレクトリにあるローカルで修正されているファイルと違うかもしれない、
 3101: というものがあります。間違ってそうしてしまわないようにするには、
 3102: @code{cvs tag} に @samp{-c} オプションを指定します。もしローカルで修正
 3103: されたファイルがあれば、@sc{cvs} はファイルをタグ付けする前にエラーを
 3104: 出し、異常終了します:
 3105: 
 3106: @example
 3107: $ cvs tag -c rel-0-4
 3108: cvs tag: backend.c is locally modified
 3109: cvs [tag aborted]: correct the above errors first!
 3110: @end example
 3111: 
 3112: @node Tagging by date/tag
 3113: @section どれにタグを付けるかを日付やリビジョンで指定する
 3114: @cindex Rtag (subcommand)
 3115: 
 3116: @code{cvs rtag} コマンドは特定の日付や時間のリポジトリにタグを付けます
 3117: (もしくは最新のリビジョンにタグを付けることに使うことができます)。
 3118: @code{rtag} はリポジトリの内容に直接作用します (コマンドの前に取り出す
 3119: ことを要求しませんし、作業ディレクトリを見に行きません)。
 3120: 
 3121: 以下のオプションはタグを付ける日付やリビジョンを指定します。完全な説明
 3122: は @ref{Common options} 参照。
 3123: 
 3124: @table @code
 3125: @item -D @var{date}
 3126: @var{date} 以前の一番新しいリビジョンにタグを付けます。
 3127: 
 3128: @item -f
 3129: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒のときにだけ役に立ち
 3130: ます。合致するリビジョンが見つからなければ、(ファイルを無視する代わり
 3131: に) 一番新しいリビジョンを使います。
 3132: 
 3133: @item -r @var{tag}
 3134: 存在するタグ @var{tag} を含むファイルにのみタグを付けます。
 3135: @end table
 3136: 
 3137: @code{cvs tag} コマンドは同じ @samp{-r}, @samp{-D}, @samp{-f} オプショ
 3138: ンを使って、ファイルをリビジョンや日付により指定することもできるように
 3139: なっています。しかし、この機能はおそらくあなたが望むものではないでしょ
 3140: う。その理由は、@code{cvs tag} は与えられたタグ/日付ではなく、存在する
 3141: 作業ディレクトリに基づいてタグを付けるファイルを選ぶからです。ですから、
 3142: 普通は @code{cvs rtag} を使う方がうまくいくでしょう。例外はこのような
 3143: 場合です:
 3144: 
 3145: @example
 3146: cvs tag -r 1.4 backend.c
 3147: @end example
 3148: 
 3149: @node Modifying tags
 3150: @section タグの削除、移動、改名
 3151: 
 3152: @c Also see:
 3153: @c  "How do I move or rename a magic branch tag?"
 3154: @c in the FAQ (I think the issues it talks about still
 3155: @c apply, but this could use some sanity.sh work).
 3156: 
 3157: 普通はタグを修正しません。それはリポジトリの履歴を記録するために存在し
 3158: ており、削除したり意味を変えたりすることは、普通は望むことではないでしょ
 3159: う。
 3160: 
 3161: しかし、一時的にタグを使用したり、偶然に間違った場所に付けてしまったり
 3162: する場合もあるでしょう。ですから、タグを削除、移動、改名するかもしれま
 3163: せん。警告: この節のコマンドは危険です。それは履歴情報を永遠に捨て去り、
 3164: エラーからの復帰が難しくなるか、不可能になります。あなたが @sc{cvs} の
 3165: 管理者なら、これらのコマンドを taginfo で制限することを考えるかもしれ
 3166: ません (@pxref{user-defined logging})。
 3167: 
 3168: @cindex deleting tags
 3169: @cindex removing tags
 3170: @cindex tags, deleting
 3171: タグを削除するには、@samp{-d} オプションを @code{cvs tag} か
 3172: @code{rtag} に指定します。例えば:
 3173: 
 3174: @example
 3175: cvs rtag -d rel-0-4 tc
 3176: @end example
 3177: 
 3178: はモジュール @code{tc} からタグ @code{rel-0-4} を削除します。
 3179: 
 3180: @cindex moving tags
 3181: @cindex tags, moving
 3182: @dfn{移動} とは、同じ名前を違うリビジョンを指すようにすることです。例
 3183: えば、@code{stable} タグは現時点で @file{backend.c} のリビジョン1.4を
 3184: 指しており、おそらくそれをリビジョン1.6を指すようにしたいと思っている
 3185: かもしれません。タグを移動するには、@samp{-F} オプションを @code{cvs
 3186: tag} か@code{cvs rtag} に指定します。例えば、今書いた作業は以下のもの
 3187: で達成できます:
 3188: 
 3189: @example
 3190: cvs tag -r 1.6 -F stable backend.c
 3191: @end example
 3192: 
 3193: @cindex renaming tags
 3194: @cindex tags, renaming
 3195: タグの @dfn{改名} とは、違った名前を古いタグと同じリビジョンを指すよう
 3196: にすることです。例えば、タグ名の綴りを間違えて、修正したいと思っている
 3197: かもしれません (できれば他の人が古い綴りに頼る前に)。タグを改名するた
 3198: めには、まず @samp{-r} オプションを @code{cvs rtag} に与えて新しいタグ
 3199: を作り、それから古い名前を削除します。これは新しいタグを古いタグと全く
 3200: 同じファイルにつけることになります。例えば:
 3201: 
 3202: @example
 3203: cvs rtag -r old-name-0-4 rel-0-4 tc
 3204: cvs rtag -d old-name-0-4 tc
 3205: @end example
 3206: 
 3207: @node Tagging add/remove
 3208: @section タグ付けとファイルの追加、削除
 3209: 
 3210: タグ付けがどのようにファイルの追加と削除と関連して動作するかの正確な議
 3211: 題は少し複雑です。たいていの場合、@sc{cvs} はファイルが存在したかどう
 3212: かをたいして苦労することなく追い掛けることができます。既定では、タグは
 3213: タグ付けされたリビジョンに対応するファイルだけに適用されます。ファイル
 3214: がまだ存在していないか、既に削除されていると、単にタグを省略し、
 3215: @sc{cvs} はタグが無いものは、そのタグではファイルが存在しないという意
 3216: 味に扱うことを知っています。
 3217: 
 3218: ところが、これは少し情報を失います。例えば、ファイルが追加されて、それ
 3219: から削除されたとしましょう。そして、タグがそのファイルになければ、その
 3220: タグがファイルの追加前のときか、削除の後かどちらを参照するかを知る方法
 3221: はありません。@samp{-r} オプションを @code{cvs rtag} に指定すれば、
 3222: @sc{cvs} は削除されたファイルにタグを付け、この問題を回避することがで
 3223: きます。例えば、先頭のリビジョンにタグを付けるために @code{-r HEAD} を
 3224: 指定するかもしれません。
 3225: 
 3226: ファイルの追加と削除という題に関して、@code{cvs rtag} コマンドには他の
 3227: 方法ではタグ付けされない、削除されたファイルのタグを消去する @samp{-a} 
 3228: オプションがあります。例えば、タグを移動しているときに @samp{-F} と共
 3229: に指定するでしょう。@samp{-a} 無しでタグを移動すれば、削除されたファイ
 3230: ルはファイルが削除されたという事実を反映せずに、まだ古いリビジョンを参
 3231: 照しているでしょう。私は上に書いてあるように @samp{-r} が指定されてい
 3232: るときはこれは必要ではないと思います。
 3233: 
 3234: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3235: @node Sticky tags
 3236: @section 貼り付いたタグ
 3237: @cindex Sticky tags
 3238: @cindex Tags, sticky
 3239: 
 3240: @c A somewhat related issue is per-directory sticky
 3241: @c tags (see comment at CVS/Tag in node Working
 3242: @c directory storage); we probably want to say
 3243: @c something like "you can set a sticky tag for only
 3244: @c some files, but you don't want to" or some such.
 3245: 
 3246: 作業コピーのリビジョンには関連した追加のデータがあることがあります。例
 3247: えば、枝であったり (@pxref{Branching and merging})、@samp{checkout -D}
 3248: か @samp{update -D} によって特定の日時より前のバージョンに制限されてい
 3249: るかもしれません。このデータは永続しますので -- すなわち、作業コピーの
 3250: 残りのコマンドに適用されます -- 我々はそれを @dfn{貼り付けられた} と表
 3251: 現しました。
 3252: 
 3253: たいていの場合、貼り付きは考える必要のない @sc{cvs} の隠れた側面です。
 3254: しかし、この機能を使いたくないとしても、貼り付けられたタグに関して 
 3255: @emph{何か} 知る必要があるかもしれません (例えば、それを避ける方法!).
 3256: 
 3257: @dfn{貼り付いたタグ} (@dfn{sticky tag}) や日付を調べるには、
 3258: @code{status} コマンドを使用します:
 3259: 
 3260: @example
 3261: $ cvs status driver.c
 3262: ===================================================================
 3263: File: driver.c          Status: Up-to-date
 3264: 
 3265:     Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
 3266:     RCS Version:        1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
 3267:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3268:     Sticky Date:        (none)
 3269:     Sticky Options:     (none)
 3270: 
 3271: @end example
 3272: 
 3273: @cindex Resetting sticky tags
 3274: @cindex Sticky tags, resetting
 3275: @cindex Deleting sticky tags
 3276: 作業ファイルに貼り付いたタグは、
 3277: @samp{cvs update -A} を使って削除するまで残ります。
 3278: オプション @samp{-A} は、ファイルを幹の先頭のバージョンに戻し、
 3279: 貼り付いたタグ, 日付, オプションを全て剥します。
 3280: 
 3281: @cindex sticky date
 3282: 貼り付けられたタグの一番普通の使用法は、@ref{Accessing branches} で説
 3283: 明されているようにどの枝で作業しているかを確認することです。しかし、枝
 3284: でない貼り付きタグにも利用法はあります。
 3285: ここでは、他人の変更が安定しているかどうか分らないので、
 3286: 作業ディレクトリを更新したくない場合を例に挙げて考えます。
 3287: もちろんこの場合、@code{cvs update} の実行を控えれば済みます。
 3288: しかし、更新したくないのが大きなツリー構造の一部分だけならば、
 3289: そこにリビジョンを貼り付ければ良いのです。
 3290: ソースを取り出す際に (1.4 などと) リビジョンを指定すれば、
 3291: そのリビジョンを貼り付けることができます。
 3292: 以後、@samp{cvs update -A} によってタグを剥がすまで、
 3293: @code{cvs update} を実行しても
 3294: 最新リビジョンに更新されることはありません。
 3295: 同様にオプション @samp{-D} を @code{update} や @code{checkout} に使うと、
 3296: @dfn{貼り付いた日付} (@dfn{sticky date}) が設定され、
 3297: これ以降のコマンドにその日付が与えられます。
 3298: 
 3299: 古いバージョンのファイルを取り出す際に、
 3300: タグを貼り付けたくない場合も多いと思います。
 3301: @code{checkout} や @code{update} にオプション @samp{-p} を付けると、
 3302: ファイルの内容が標準出力に送られるので、これを利用します。
 3303: 例えば:
 3304: 
 3305: @example
 3306: $ cvs update -p -r 1.1 file1 >file1
 3307: ===================================================================
 3308: Checking out file1
 3309: RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
 3310: VERS: 1.1
 3311: ***************
 3312: $
 3313: @end example
 3314: 
 3315: しかし、あなたの尋ねていることが前の格納に戻す (この例では、
 3316: @file{file1} をリビジョン1.1であったときに戻す) 方法なら、これが一番簡
 3317: 単な方法ではありません。その場合は @code{update -j} オプションを
 3318: @code{update} に付けるのが良いでしょう。さらなる議論は、@ref{Merging
 3319: two revisions} 参照。
 3320: 
 3321: @c ---------------------------------------------------------------------
 3322: @node Branching and merging
 3323: @chapter 枝とマージ
 3324: @cindex Branching
 3325: @cindex Merging
 3326: @cindex Copying changes
 3327: @cindex Main trunk and branches
 3328: @cindex Revision tree, making branches
 3329: @cindex Branches, copying changes between
 3330: @cindex Changes, copying between branches
 3331: @cindex Modifications, copying between branches
 3332: 
 3333: CVS では変更を @dfn{枝} (@dfn{branch}) として知られる別の開発ラインに
 3334: 分けることができます。枝のファイルを変更しても、その変更は幹や他の枝に
 3335: は現れません。
 3336: 
 3337: 後程、@dfn{マージ} (@dfn{merging}) によって変更をある枝から別の枝 (も
 3338: しくは幹) に移動することができます。マージはまず @code{cvs update -j}
 3339: を実行して、変更を作業ディレクトリに混ぜることから始まります。それから
 3340: そのリビジョンを格納することができ、こうして効果的に変更を別の枝にコピー
 3341: することができます。
 3342: 
 3343: @menu
 3344: * Branches motivation::         枝は何の役に立つか
 3345: * Creating a branch::           枝の作成
 3346: * Accessing branches::          枝の更新と取り出し
 3347: * Branches and revisions::      枝はリビジョン番号に反映される
 3348: * Magic branch numbers::        魔法の枝番号
 3349: * Merging a branch::            枝全体をマージする
 3350: * Merging more than once::      枝から何度もマージする
 3351: * Merging two revisions::       二つのリビジョン間の差分をマージする
 3352: * Merging adds and removals::   ファイルが追加/削除された場合はどうか?
 3353: @end menu
 3354: 
 3355: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3356: @node Branches motivation
 3357: @section 枝は何の役に立つか
 3358: @cindex Branches motivation
 3359: @cindex What branches are good for
 3360: @cindex Motivation for branches
 3361: 
 3362: @c FIXME: this node mentions one way to use branches,
 3363: @c but it is by no means the only way.  For example,
 3364: @c the technique of committing a new feature on a branch,
 3365: @c until it is ready for the main trunk.  The whole
 3366: @c thing is generally speaking more akin to the
 3367: @c "Revision management" node although it isn't clear to
 3368: @c me whether policy matters should be centralized or
 3369: @c distributed throughout the relevant sections.
 3370: tc のリリース 1.0 ができたとしましょう。tc の開発を継続していて、数ヶ
 3371: 月の間にリリース 1.1 を作成する計画を立てています。しばらくして、顧客
 3372: が致命的なバグについて文句を言ってくるようになりました。リリース 1.0を
 3373: 取り出し (@pxref{Tags})、バグを見つけました (結局些細な修正に終わりま
 3374: した)。しかし、ソースの現在のリビジョンは流動的で、少くとも1ヶ月は安定
 3375: しない状態です。最新のソースに基づくバグ修正リリースはとても作成できま
 3376: せん。
 3377: 
 3378: この様な状況でするべきことは tc のリリース 1.0 の全てのファイルのリビ
 3379: ジョンツリーに基づく @dfn{枝} (@dfn{branch}) を作成することです。そう
 3380: すれば幹の邪魔をすることなく枝に修正を加えることができます。修正が終わっ
 3381: たときに、幹に取り込むか、枝に残しておくかを選択することができます。
 3382: 
 3383: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3384: @node Creating a branch
 3385: @section 枝の作成
 3386: @cindex Creating a branch
 3387: @cindex Branch, creating a
 3388: @cindex tag, creating a branch using
 3389: @cindex rtag, creating a branch using
 3390: 
 3391: @code{tag -b} で枝を作成することができます。例えば、作業コピーのところ
 3392: にいるとしましょう:
 3393: 
 3394: @example
 3395: $ cvs tag -b rel-1-0-patches
 3396: @end example
 3397: 
 3398: @c FIXME: we should be more explicit about the value of
 3399: @c having a tag on the branchpoint.  For example
 3400: @c "cvs tag rel-1-0-patches-branchpoint" before
 3401: @c the "cvs tag -b".  This points out that
 3402: @c rel-1-0-patches is a pretty awkward name for
 3403: @c this example (more so than for the rtag example
 3404: @c below).
 3405: 
 3406: これは作業コピーの現在のリビジョンに基づいた枝を別に作成し、その枝に名
 3407: 前 @samp{rel-1-0-patches} を割当てます。
 3408: 
 3409: 枝はリポジトリに作成されているのであって、作業コピーに作成されているの
 3410: ではないということを理解することは重要です。上記の例の様に、現在のリビ
 3411: ジョンに基づいた枝を作成することは、自動的に作業コピーを新しい枝に切り
 3412: 換えることは @emph{しません}。それをする方法に関する情報は 
 3413: @ref{Accessing branches} を参照してください。
 3414: 
 3415: @code{rtag} を使って、作業コピーへの参照無しに枝を作ることもできます:
 3416: 
 3417: @example
 3418: $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
 3419: @end example
 3420: 
 3421: @samp{-r rel-1-0} はこの枝がタグ @samp{rel-1-0} に対応するリビジョンを
 3422: 根とするということを指定します。最新のリビジョンである必要はありません 
 3423: -- 古いリビジョンから枝を生やすことが役に立つことがしばしばあります
 3424: (例えば、他の部分は安定していることが知られている過去のリリースのバグ
 3425: を修正するとき)。
 3426: 
 3427: @samp{tag} と同様に @samp{-b} フラグは @code{rtag} に枝を作成するよう
 3428: に指示します (単なるリビジョン名ではなく)。@samp{rel-1-0} に対応する数
 3429: 字リビジョン番号はファイル毎に違うことを注意してください。
 3430: 
 3431: ですから、命令の完全な効果は新しい枝を作成することです -- モジュール 
 3432: @samp{tc} で、@samp{rel-1-0} でタグ付けされたリビジョンツリーを根元と
 3433: する -- @samp{rel-1-0-patches} という名前のものを。
 3434: 
 3435: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3436: @node Accessing branches
 3437: @section 枝のアクセス
 3438: @cindex Check out a branch
 3439: @cindex Retrieve a branch
 3440: @cindex Access a branch
 3441: @cindex Identifying a branch
 3442: @cindex Branch, check out
 3443: @cindex Branch, retrieving
 3444: @cindex Branch, accessing
 3445: @cindex Branch, identifying
 3446: 
 3447: 2 つの方法のどちらかで枝を取得することができます: リポジトリから新しく
 3448: 取り出すか、存在する作業コピーをその枝に切り換える方法です。
 3449: 
 3450: リポジトリから枝を取り出すには @samp{checkout} をフラグ @samp{-r} と、
 3451: その後に枝のタグ名を続けて起動します (@pxref{Creating a branch})。
 3452: 
 3453: @example
 3454: $ cvs checkout -r rel-1-0-patches tc
 3455: @end example
 3456: 
 3457: もしくは、既に作業コピーを持っていれば、@samp{update -r} で任意の枝に
 3458: 切り換えることができます:
 3459: 
 3460: @example
 3461: $ cvs update -r rel-1-0-patches tc
 3462: @end example
 3463: 
 3464: もしくは、それと等価な:
 3465: 
 3466: @example
 3467: $ cd tc
 3468: $ cvs update -r rel-1-0-patches
 3469: @end example
 3470: 
 3471: 作業コピーが元々幹にあったか他の枝にあったかは関係ありません -- 上のコ
 3472: マンドはそれを指定された名前の枝に切り換えます。普通の @samp{update}
 3473: コマンドと同様に、@samp{update -r} は全ての変更をマージし、衝突がどこ
 3474: で起こったかを知らせます。
 3475: 
 3476: 一度特定の枝に結び付けられた作業コピーを手に入れると、指示しない限りそ
 3477: こに残り続けます。これは、作業コピーから格納された変更はその枝に新しい
 3478: リビジョンを加えますが、幹と他の枝には影響を及ぼさないということです。
 3479: 
 3480: @cindex Branches, sticky
 3481: 作業コピーがどの枝であるかを知るために、コマンド @samp{status} を使う
 3482: ことができます。その出力で、@samp{Sticky tag} という名前の場所を探して
 3483: ください (@pxref{Sticky tags}) -- それは現在の作業ファイルに、もし枝が
 3484: あれば、それを教える @sc{cvs} の方法です:
 3485: 
 3486: @example
 3487: $ cvs status -v driver.c backend.c
 3488: ===================================================================
 3489: File: driver.c          Status: Up-to-date
 3490: 
 3491:     Version:            1.7     Sat Dec  5 18:25:54 1992
 3492:     RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
 3493:     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
 3494:     Sticky Date:        (none)
 3495:     Sticky Options:     (none)
 3496: 
 3497:     Existing Tags:
 3498:         rel-1-0-patches             (branch: 1.7.2)
 3499:         rel-1-0                     (revision: 1.7)
 3500: 
 3501: ===================================================================
 3502: File: backend.c         Status: Up-to-date
 3503: 
 3504:     Version:            1.4     Tue Dec  1 14:39:01 1992
 3505:     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
 3506:     Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
 3507:     Sticky Date:        (none)
 3508:     Sticky Options:     (none)
 3509: 
 3510:     Existing Tags:
 3511:         rel-1-0-patches             (branch: 1.4.2)
 3512:         rel-1-0                     (revision: 1.4)
 3513:         rel-0-4                     (revision: 1.4)
 3514: 
 3515: @end example
 3516: 
 3517: それぞれのファイルの枝番号が違うという事実に混乱しないでください 
 3518: (それぞれ @samp{1.7.1} と @samp{1.4.2} です)。枝タグは同じ 
 3519: @samp{rel-1-0-patches} で、ファイルは実際に同じ枝にあります。番号は単
 3520: に枝が作られたときのそれぞれのファイルのリビジョン履歴を反映しています。
 3521: 上の例では、この枝が作成される前に、@samp{driver.c} が 
 3522: @samp{backend.c} よりも多くの変更が成されたということを導き出すことが
 3523: できます。
 3524: 
 3525: 枝番号が作成される方法の詳細は @ref{Branches and revisions} を参照して
 3526: ください。
 3527: 
 3528: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3529: @node Branches and revisions
 3530: @section 枝とリビジョン
 3531: @cindex Branch number
 3532: @cindex Number, branch
 3533: @cindex Revision numbers (branches)
 3534: 
 3535: 普通はファイルのリビジョン履歴は線形増加です (@pxref{Revision
 3536: numbers}):
 3537: 
 3538: @example
 3539:        +-----+    +-----+    +-----+    +-----+    +-----+
 3540:        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 3541:        +-----+    +-----+    +-----+    +-----+    +-----+
 3542: @end example
 3543: 
 3544: しかし、@sc{cvs} は線形の開発に限られているわけではありません。@dfn{リ
 3545: ビジョン・ツリー} は @dfn{枝} に分割することができ、それぞれの枝は別に
 3546: 維持された開発ラインです。枝になされた変更は簡単に幹に戻すことができま
 3547: す。
 3548: 
 3549: それぞれの枝には @dfn{枝番号} があり、ピリオドで分けられた奇数個の10進
 3550: 整数から成ります。枝番号は枝が分岐した元の枝に対応するリビジョン番号に
 3551: 整数を追加することによって作成されます。枝番号により、特定のリビジョン
 3552: から 1 つ以上の枝を枝分かれすることができます。
 3553: 
 3554: @need 3500
 3555: 枝の全てのリビジョンは枝番号に普通の数字を追加することで形成されます。
 3556: 下図に、前述の例から枝が発展した例を示します。
 3557: 
 3558: @example
 3559: @c This example used to have a 1.2.2.4 revision, which
 3560: @c might help clarify that development can continue on
 3561: @c 1.2.2.  Might be worth reinstating if it can be done
 3562: @c without overfull hboxes.
 3563: @group
 3564:                                                       +-------------+
 3565:                            Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
 3566:                                                     / +-------------+
 3567:                                                    /
 3568:                                                   /
 3569:                  +---------+    +---------+    +---------+
 3570: Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3571:                / +---------+    +---------+    +---------+
 3572:               /
 3573:              /
 3574: +-----+    +-----+    +-----+    +-----+    +-----+
 3575: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
 3576: +-----+    +-----+    +-----+    +-----+    +-----+
 3577:                 !
 3578:                 !
 3579:                 !   +---------+    +---------+    +---------+
 3580: Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
 3581:                     +---------+    +---------+    +---------+
 3582: 
 3583: @end group
 3584: @end example
 3585: 
 3586: @c --   However, at least for me the figure is not enough.  I suggest more
 3587: @c --   text to accompany it.  "A picture is worth a thousand words", so you
 3588: @c --   have to make sure the reader notices the couple of hundred words
 3589: @c --   *you* had in mind more than the others!
 3590: 
 3591: @c --   Why an even number of segments?  This section implies that this is
 3592: @c --   how the main trunk is distinguished from branch roots, but you never
 3593: @c --   explicitly say that this is the purpose of the [by itself rather
 3594: @c --   surprising] restriction to an even number of segments.
 3595: 
 3596: 枝番号が作成される厳密な詳細は普通は気にしなくて良いのですが、以下が動
 3597: 作の方法です: @sc{cvs} が枝番号を作成するときは、2 から始まる最初の未
 3598: 使用の偶数を選びます。ですから、リビジョン 6.4 から枝を作成したいとき
 3599: は、それは 6.4.2 という番号になるでしょう。零で終わる全ての枝番号 
 3600: (6.4.0 のように) は @sc{cvs} の内部で使用されます (@pxref{Magic branch
 3601: numbers})。枝 1.1.1 は特別な意味を持ちます。@xref{Tracking sources}.
 3602: 
 3603: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3604: @node Magic branch numbers
 3605: @section 魔法の枝番号
 3606: 
 3607: @c Want xref to here from "log"?
 3608: 
 3609: この部分は @dfn{魔法の枝} (@dfn{magic brandh}) と呼ばれる @sc{cvs} の
 3610: 機能を説明します。たいていの目的のためには魔法の枝を心配する必要はあり
 3611: ません。@sc{cvs} が代わりに扱ってくれます。しかし、特定の状況ではそれ
 3612: が見えていることもありますので、いくらか動作の仕方を知っていると役に立
 3613: つかもしれません。
 3614: 
 3615: 表面的には、枝番号はドットで分けられた奇数個の10進の整数です。 
 3616: @xref{Revision numbers}.  しかし、これは真実の姿ではありません。
 3617: @sc{cvs} は能率のために、余分な 0 を右から2番目の位置に挿入することが
 3618: あります(1.2.3 は 1.2.0.3 となり、8.9.10.11.12 は 8.9.10.11.0.12 にな
 3619: ります)。
 3620: 
 3621: この魔法の枝と呼ばれるものを、@sc{cvs} はうまく隠しています。しかし、
 3622: 完璧に隠し切れていないところも数ヶ所あります。
 3623: 
 3624: @itemize @bullet
 3625: @ignore
 3626: @c This is in ignore as I'm taking their word for it,
 3627: @c that this was fixed
 3628: @c a long time ago.  But before deleting this
 3629: @c entirely, I'd rather verify it (and add a test
 3630: @c case to the testsuite).
 3631: @item
 3632: @sc{cvs} 1.3 で、
 3633: 魔法の枝番号が @code{cvs status} の出力に現われてしまう。
 3634: これは @sc{cvs} 1.3-s2 では修復されました。
 3635: 
 3636: @end ignore
 3637: @item
 3638: 魔法の枝番号が @code{cvs log} の出力に現われてしまう。
 3639: @c What output should appear instead?
 3640: 
 3641: @item
 3642: @code{cvs admin} で枝のタグ名が指定できない。
 3643: 
 3644: @end itemize
 3645: 
 3646: @c Can CVS do this automatically the first time
 3647: @c you check something in to that branch?  Should
 3648: @c it?
 3649: @code{admin} コマンドを使用して、
 3650: @sc{rcs} が枝のタグ名を理解できるように再設定する方法があります。
 3651: @code{R4patches} というタグ名が、
 3652: ファイル @file{number.c} の枝 1.4.2 に付けられている場合
 3653: (魔法の枝番号は 1.4.0.2 です)、
 3654: 次のようにします:
 3655: 
 3656: @example
 3657: $ cvs admin -NR4patches:1.4.2 numbers.c
 3658: @end example
 3659: 
 3660: この方法を用いる場合は、1つ以上のリビジョンが、
 3661: 既に枝に格納されている必要があります。
 3662: タグに間違った番号を設定しないように、注意しなくてはいけません。
 3663: (実行以前にタグがどう設定されていたかを調べる方法はありません)。
 3664: 
 3665: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3666: @node Merging a branch
 3667: @section 枝全体をマージする
 3668: @cindex Merging a branch
 3669: @cindex -j (merging branches)
 3670: 
 3671: @code{update} コマンドに @samp{-j @var{branch}} フラグを付けると、
 3672: 枝に加えられた変更を作業コピーに反映することができます。
 3673: @samp{-j @var{branch}} オプションが1つだけだと、
 3674: 枝の分岐点と枝の最新リビジョン間の違いを 
 3675: (あなたの作業コピーに) マージします。
 3676: 
 3677: @cindex Join
 3678: @samp{-j} は、``join'' の略です。
 3679: 
 3680: @cindex Branch merge example
 3681: @cindex Example, branch merge
 3682: @cindex Merge, branch example
 3683: 次のリビジョン・ツリーを考えます。
 3684: 
 3685: @example
 3686: +-----+    +-----+    +-----+    +-----+
 3687: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
 3688: +-----+    +-----+    +-----+    +-----+
 3689:                 !
 3690:                 !
 3691:                 !   +---------+    +---------+
 3692: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3693:                     +---------+    +---------+
 3694: @end example
 3695: 
 3696: @noindent
 3697: 枝 1.2.2 には @samp{R1fix} というタグ (文字列) が付けられています。次
 3698: は @file{m.c} というファイル1つを含むモジュール @samp{mod} の例です。
 3699: 
 3700: @example
 3701: $ cvs checkout mod               # @r{最新のリビジョン 1.4 を取り出す}
 3702: 
 3703: $ cvs update -j R1fix m.c        # @r{枝で行なわれた変更(リビジョン 1.2}
 3704:                                  # @r{と 1.2.2.2 の差分)を作業コピーに追加}
 3705: 
 3706: $ cvs commit -m "Included R1fix" # @r{リビジョン 1.5 を作成}
 3707: @end example
 3708: 
 3709: マージ作業で衝突が起きることもありますが、衝突が起きた場合は、それを解
 3710: 決してから新しいリビジョンを格納して下さい。 @xref{Conflicts example}.
 3711: 
 3712: @code{checkout} コマンドでもフラグ @samp{-j @var{branch}} を使用できます。
 3713: 以下の様にして上記と同じ効果を得ることができます:
 3714: 
 3715: @example
 3716: $ cvs checkout -j R1fix mod
 3717: $ cvs commit -m "Included R1fix"
 3718: @end example
 3719: 
 3720: @node Merging more than once
 3721: @section 枝から何度もマージする
 3722: 
 3723: 前節の例を続けると、
 3724: 現在のリビジョン・ツリーは次の様になっています:
 3725: 
 3726: @example
 3727: +-----+    +-----+    +-----+    +-----+    +-----+
 3728: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3729: +-----+    +-----+    +-----+    +-----+    +-----+
 3730:                 !                           *
 3731:                 !                          *
 3732:                 !   +---------+    +---------+
 3733: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 3734:                     +---------+    +---------+
 3735: @end example
 3736: 
 3737: 前節で枝 @samp{R1fix} を幹にマージした事を、ここでは星線で表します。
 3738: 
 3739: 次に、枝 @samp{R1fix} で開発が続けられたと仮定します:
 3740: 
 3741: @example
 3742: +-----+    +-----+    +-----+    +-----+    +-----+
 3743: ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
 3744: +-----+    +-----+    +-----+    +-----+    +-----+
 3745:                 !                           *
 3746:                 !                          *
 3747:                 !   +---------+    +---------+    +---------+
 3748: Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 3749:                     +---------+    +---------+    +---------+
 3750: @end example
 3751: 
 3752: そしてこの新しい変更を幹にマージしたくなりました。
 3753: ここで再び @code{cvs update -j R1fix m.c} コマンドを用いた場合、
 3754: @sc{cvs} は既にマージされた変更点を重ねてマージしようとして、
 3755: 望ましくない結果をもたらします。
 3756: 
 3757: そこで、
 3758: 未だ幹にマージされてない変更点だけマージしたい旨を、
 3759: 明示する必要があります。
 3760: これには、@samp{-j} オプションで二つのリビジョンを指定します。
 3761: @sc{cvs} は、
 3762: 最初のリビジョンから次のリビジョンまでの変更をマージします。
 3763: 例えば、この場合、最も簡単な方法は次の様になります。
 3764: 
 3765: @example
 3766: cvs update -j 1.2.2.2 -j R1fix m.c    # @r{1.2.2.2 から、枝 R1fix の}
 3767:                                       # @r{先頭までの変更をマージする}
 3768: @end example
 3769: 
 3770: この方法の問題点は、リビジョン 1.2.2.2 を自分で指定する必要がある事です。
 3771: 最後にマージが行われた日時を使用する方が、少しましでしょう:
 3772: 
 3773: @example
 3774: cvs update -j R1fix:yesterday -j R1fix m.c
 3775: @end example
 3776: 
 3777: さらに良いのは、
 3778: 変更点を幹にマージする度に、
 3779: 枝 @samp{R1fix} にタグを振っておき、
 3780: 後でマージする時にそのタグを用いる方法です:
 3781: 
 3782: @example
 3783: cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
 3784: @end example
 3785: 
 3786: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 3787: @node Merging two revisions
 3788: @section 二つのリビジョン間の差分をマージする
 3789: @cindex Merging two revisions
 3790: @cindex Revisions, merging differences between
 3791: @cindex Differences, merging
 3792: 
 3793: @code{update} (と @code{checkout}) コマンドに @samp{-j @var{revision}} 
 3794: フラグを二つ付けることで、任意の二つのリビジョン間の違いをあなたの作業
 3795: コピーに加えることができます。
 3796: 
 3797: @cindex Undoing a change
 3798: @cindex Removing a change
 3799: @example
 3800: $ cvs update -j 1.5 -j 1.3 backend.c
 3801: @end example
 3802: 
 3803: @noindent
 3804: このようにするとリビジョン 1.3 と 1.5 間の変更を
 3805: 全て@emph{元に戻す}ことになります。
 3806: リビジョンを指定する順序に十分注意して下さい!
 3807: 
 3808: 複数のファイルに対してこのオプションを指定する場合は、
 3809: ファイルごとにリビジョン番号が全く異なるであろうことを思い出して下さい。
 3810: 複数のファイルを操作する場合には、
 3811: リビジョン番号ではなく、
 3812: 必ずタグ名を用いるようにして下さい。
 3813: 
 3814: @cindex Restoring old version of removed file
 3815: @cindex Resurrecting old version of dead file
 3816: 2つ @samp{-j} オプションを指定すると、追加や削除を元に戻すこともできま
 3817: す。例えば、リビジョン1.1として存在していた @file{file1} という名前の
 3818: ファイルがあり、それを消去した (つまり、死んだリビジョン1.2を追加しま
 3819: した) としましょう。今、またそれを以前と同じ内容で追加したいと思ったと
 3820: しましょう。これがそれをする方法です:
 3821: 
 3822: @example
 3823: $ cvs update -j 1.2 -j 1.1 file1
 3824: U file1
 3825: $ cvs commit -m test
 3826: Checking in file1;
 3827: /tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
 3828: new revision: 1.3; previous revision: 1.2
 3829: done
 3830: $
 3831: @end example
 3832: 
 3833: @node Merging adds and removals
 3834: @section ファイルの追加や削除もマージできる
 3835: 
 3836: マージする変更点に、ファイルの削除や追加が伴なう場合でも、
 3837: @code{update -j} は削除や追加を反映します。
 3838: 
 3839: @c FIXME: This example needs a lot more explanation.
 3840: @c We also need other examples for some of the other
 3841: @c cases (not all--there are too many--as long as we present a
 3842: @c coherent general principle).
 3843: 実行例:
 3844: @example
 3845: cvs update -A
 3846: touch a b c
 3847: cvs add a b c ; cvs ci -m "added" a b c
 3848: cvs tag -b branchtag
 3849: cvs update -r branchtag
 3850: touch d ; cvs add d
 3851: rm a ; cvs rm a
 3852: cvs ci -m "added d, removed a"
 3853: cvs update -A
 3854: cvs update -jbranchtag
 3855: @end example
 3856: 
 3857: これらのコマンドが実行され、@samp{cvs commit} がなされた後、幹ではファ
 3858: イル @file{a} は削除され、ファイル@file{d} は追加されます
 3859: @c (which was determined by trying it)
 3860: 
 3861: @c ---------------------------------------------------------------------
 3862: @node Recursive behavior
 3863: @chapter 再帰的動作
 3864: @cindex Recursive (directory descending)
 3865: @cindex Directory, descending
 3866: @cindex Descending directories
 3867: @cindex Subdirectories
 3868: 
 3869: ほとんど全ての @sc{cvs} のコマンドは、
 3870: ディレクトリを引数に取ったときに再帰的に動作します。
 3871: 例えば、次のディレクトリ構造を考えます。
 3872: 
 3873: @example
 3874:       @code{$HOME}
 3875:         |
 3876:         +--@t{tc}
 3877:         |   |
 3878:             +--@t{CVS}
 3879:             |      (内部 @sc{cvs} ファイル)
 3880:             +--@t{Makefile}
 3881:             +--@t{backend.c}
 3882:             +--@t{driver.c}
 3883:             +--@t{frontend.c}
 3884:             +--@t{parser.c}
 3885:             +--@t{man}
 3886:             |    |
 3887:             |    +--@t{CVS}
 3888:             |    |  (内部 @sc{cvs} ファイル)
 3889:             |    +--@t{tc.1}
 3890:             |
 3891:             +--@t{testing}
 3892:                  |
 3893:                  +--@t{CVS}
 3894:                  |  (内部 @sc{cvs} ファイル)
 3895:                  +--@t{testpgm.t}
 3896:                  +--@t{test2.t}
 3897: @end example
 3898: 
 3899: @noindent
 3900: 現在のディレクトリが @samp{tc} であれば、
 3901: 以下が成立します:
 3902: 
 3903: @itemize @bullet
 3904: @item
 3905: @samp{cvs update testing} は
 3906: 
 3907: @example
 3908: cvs update testing/testpgm.t testing/test2.t
 3909: @end example
 3910: と等価です。
 3911: 
 3912: @item
 3913: @samp{cvs update testing man} は
 3914: サブディレクトリ中の全てのファイルを更新します。
 3915: 
 3916: @item
 3917: @samp{cvs update .} 又は @samp{cvs update} は、
 3918: ディレクトリ @code{tc} 中の全てのファイルを更新します。
 3919: @end itemize
 3920: 
 3921: 引数を付けない @code{update} コマンドは現在の作業ディレクトリと全ての
 3922: サブディレクトリを更新します。言い替えると、@file{.} は @code{update} 
 3923: の既定引数です。これは @code{update} コマンドだけではなく、たいていの 
 3924: @sc{cvs} のコマンドにも当てはまります。
 3925: 
 3926: @samp{-l} オプションを付けることによって、
 3927: @sc{cvs} の再帰的な動作を抑止することができます。
 3928: 逆に、@samp{-R} オプションは @file{~/.cvsrc} で @samp{-l} が指定されて
 3929: いるときに再帰的動作を強制するために使うことができます
 3930: (@pxref{~/.cvsrc})。
 3931: 
 3932: @example
 3933: $ cvs update -l         # @r{サブディレクトリのファイルは更新しない。}
 3934: @end example
 3935: 
 3936: @c ---------------------------------------------------------------------
 3937: @node Adding and removing
 3938: @chapter ファイルとディレクトリの追加、削除、改名
 3939: 
 3940: プロジェクトの最中では、よく新しいファイルを追加します。削除や改名、も
 3941: しくはディレクトリも同様です。心に留めておく総合的な概念は、元に戻せな
 3942: い変更をする代わりに、存在するファイルの修正のように、@sc{cvs} に変更
 3943: が発生したという事実を記録させたい、ということです。@sc{cvs} でこれを
 3944: する厳密な機構は状況に依り異ります。
 3945: 
 3946: @menu
 3947: * Adding files::                ファイルの追加
 3948: * Removing files::              ファイルの削除
 3949: * Removing directories::        ディレクトリの削除
 3950: * Moving files::                ファイルの移動と改名
 3951: * Moving directories::          ディレクトリの移動と改名
 3952: @end menu
 3953: 
 3954: @node Adding files
 3955: @section ディレクトリにファイルを加える
 3956: @cindex Adding files
 3957: 
 3958: ディレクトリにファイルを加える手順を説明します。
 3959: 
 3960: @itemize @bullet
 3961: @item
 3962: ディレクトリの作業コピーが必要です。@xref{Getting the source}.
 3963: 
 3964: @item
 3965: ディレクトリの作業コピーの中に、
 3966: 新しいファイルを作ります。
 3967: 
 3968: @item
 3969: @samp{cvs add @var{filename}} を用いて、
 3970: バージョン管理に加えたいファイルを @sc{cvs} に伝えます。
 3971: ファイルがバイナリ・データを含んでいる場合には、
 3972: @samp{-kb} を指定して下さい (@pxref{Binary files})。
 3973: 
 3974: @item
 3975: @samp{cvs commit @var{filename}} を用いて、
 3976: 実際にリポジトリにファイルを格納します。
 3977: この手順を行なうまでは、他の開発者はファイルを見ることができません。
 3978: @end itemize
 3979: 
 3980: @code{add} コマンドは、
 3981: 新しいディレクトリを加える場合にも使用します。
 3982: @c FIXCVS and/or FIXME: Adding a directory doesn't
 3983: @c require the commit step.  This probably can be
 3984: @c considered a CVS bug, but it is possible we should
 3985: @c warn people since this behavior probably won't be
 3986: @c changing right away.
 3987: 
 3988: 他のほとんどのコマンドと異なり、
 3989: @code{add} コマンドは再帰的に動作しません。
 3990: @samp{cvs add foo/bar} とタイプすることさえできません。
 3991: 代りに、
 3992: 次のようにする必要があります。
 3993: @c FIXCVS: This is, of course, not a feature.  It is
 3994: @c just that no one has gotten around to fixing "cvs add
 3995: @c foo/bar".
 3996: 
 3997: @example
 3998: $ cd foo
 3999: $ cvs add bar
 4000: @end example
 4001: 
 4002: @cindex add (subcommand)
 4003: @deffn コマンド {cvs add} [@code{-k} kflag] [@code{-m} message] files @dots{}
 4004: 
 4005: @var{files} が加えられた事をリポジトリに伝えます。
 4006: @code{add} で指定するファイルやディレクトリは、
 4007: 現在のディレクトリに存在している必要があります。
 4008: 新しいディレクトリ階層の全てをリポジトリに加える場合は 
 4009: (例えばサード・パーティーからのファイル等)、
 4010: 代りに @code{import} コマンドを使用した方が良いでしょう。@xref{import}.
 4011: 
 4012: 内容を @code{commit} で格納するまで、
 4013: ここで加えたファイルは実際にはリポジトリに置かれません。
 4014: @code{remove} コマンドで削除されたファイルに対して、
 4015: @code{commit} を発行する前に @code{add} を実行した場合、
 4016: @code{remove} が無効になります。
 4017: 例は @xref{Removing files}.
 4018: 
 4019: オプション @samp{-k} には、
 4020: このファイルを取り出すときの置換モードを指定します。
 4021: 詳細は @ref{Substitution modes} 参照。
 4022: 
 4023: @c As noted in BUGS, -m is broken client/server (Nov
 4024: @c 96).  Also see testsuite log2-* tests.
 4025: @samp{-m} オプションには、ファイルの説明文を記述します。
 4026: (ログ情報を記録する設定ならば)この説明文が
 4027: ファイル @file{history} に記録されます (@pxref{history file})。
 4028: またファイルを格納する際、リポジトリの履歴ファイルにも記録されます。
 4029: この説明文は @code{log} コマンドの出力で確認できます。
 4030: 変更するには @samp{admin -t} を用います。@xref{admin}.
 4031: フラグ @samp{-m @var{description}} を省略した場合、
 4032: 空の文字列が使用され、説明を記述するように促されることはありません。
 4033: @end deffn
 4034: 
 4035: 例えば、以下のコマンドでファイル @file{backend.c} が
 4036: リポジトリに加えられます:
 4037: 
 4038: @c This example used to specify
 4039: @c     -m "Optimizer and code generation passes."
 4040: @c to the cvs add command, but that doesn't work
 4041: @c client/server (see log2 in sanity.sh).  Should fix CVS,
 4042: @c but also seems strange to document things which
 4043: @c don't work...
 4044: @example
 4045: $ cvs add backend.c
 4046: $ cvs commit -m "Early version. Not yet compilable." backend.c
 4047: @end example
 4048: 
 4049: 加えたファイルは、作業中の枝だけに加えられます 
 4050: (@pxref{Branching and merging})。
 4051: 他の枝にも加えたい場合は、後でマージすることができます 
 4052: (@pxref{Merging adds and removals})。
 4053: @c Should we mention that earlier versions of CVS
 4054: @c lacked this feature (1.3) or implemented it in a buggy
 4055: @c way (well, 1.8 had many bugs in cvs update -j)?
 4056: @c Should we mention the bug/limitation regarding a
 4057: @c file being a regular file on one branch and a directory
 4058: @c on another?
 4059: @c FIXME: This needs an example, or several, here or
 4060: @c elsewhere, for it to make much sense.
 4061: @c Somewhere we need to discuss the aspects of death
 4062: @c support which don't involve branching, I guess.
 4063: @c Like the ability to re-create a release from a tag.
 4064: 
 4065: @c ---------------------------------------------------------------------
 4066: @node Removing files
 4067: @section ファイルを削除する
 4068: @cindex Removing files
 4069: @cindex Deleting files
 4070: 
 4071: @c FIXME: this node wants to be split into several
 4072: @c smaller nodes.  Could make these children of
 4073: @c "Adding and removing", probably (death support could
 4074: @c be its own section, for example, as could the
 4075: @c various bits about undoing mistakes in adding and
 4076: @c removing).
 4077: ディレクトリは変わります。
 4078: 新しいファイルが加えられ、古いファイルが削除されます。
 4079: しかし、モジュールの古いバージョンの、
 4080: 正確なコピーを復元できるようにしておきたいと思うでしょう。
 4081: 
 4082: ここでは、モジュールからファイルを削除した後も、
 4083: 古いバージョンの復元を可能にする手順を説明します:
 4084: 
 4085: @itemize @bullet
 4086: @c FIXME: should probably be saying something about
 4087: @c having a working directory in the first place.
 4088: @item
 4089: 未格納の修正がファイルに残ってないことを確認する必要があります。
 4090: 確認方法は @xref{Viewing differences}.
 4091: また @code{status} や @code{update} といった
 4092: コマンドを使用しても確認できます。
 4093: 修正を格納せずにファイルを消した場合、
 4094: 当然ですが以前の状態に復元することはできません。
 4095: 
 4096: @item
 4097: モジュールの作業コピーからファイルを削除します。
 4098: 例えば、@code{rm} などを使っても良いでしょう。
 4099: 
 4100: @item
 4101: ファイルを本当に削除するという意思を @sc{cvs} に伝えるために、
 4102: @samp{cvs remove @var{filename}} を使います。
 4103: 
 4104: @item
 4105: リポジトリからファイルを実際に削除するために、
 4106: @samp{cvs commit @var{filename}} を使います。
 4107: @end itemize
 4108: 
 4109: @c FIXME: Somehow this should be linked in with a more
 4110: @c general discussion of death support.  I don't know
 4111: @c whether we want to use the term "death support" or
 4112: @c not (we can perhaps get by without it), but we do
 4113: @c need to discuss the "dead" state in "cvs log" and
 4114: @c related subjects.  The current discussion is
 4115: @c scattered around, and not xref'd to each other.
 4116: @c FIXME: I think this paragraph wants to be moved
 4117: @c later down, at least after the first example.
 4118: ファイルの削除を格納する場合、@sc{cvs} は、
 4119: ファイルがもう無いという事実を記録します。
 4120: ファイルが他の枝に存在していても良いし、
 4121: 後で別のファイルを同じ名前で加えても構いません。
 4122: @code{checkout} や @code{update} に指定する
 4123: オプション @samp{-r} や @samp{-D} に応じて、
 4124: @sc{cvs} が正しくファイルを作成したり、しなかったりします。
 4125: 
 4126: @c FIXME: This style seems to clash with how we
 4127: @c document things in general.
 4128: @cindex Remove (subcommand)
 4129: @deffn コマンド {cvs remove} [options] files @dots{}
 4130: 
 4131: ファイルが削除された事実をリポジトリに伝えます 
 4132: (作業ディレクトリから未削除のファイルは処理されません)。
 4133: このコマンドを実行しても、リポジトリのファイルは、
 4134: 削除が格納されるまで実際には削除されません。
 4135: オプションの完全な一覧は @ref{Invoking CVS} を参照してください。
 4136: @end deffn
 4137: 
 4138: 以下に、幾つかファイルを削除する例を挙げます:
 4139: 
 4140: @example
 4141: $ cd test
 4142: $ rm *.c
 4143: $ cvs remove
 4144: cvs remove: Removing .
 4145: cvs remove: scheduling a.c for removal
 4146: cvs remove: scheduling b.c for removal
 4147: cvs remove: use 'cvs commit' to remove these files permanently
 4148: $ cvs ci -m "Removed unneeded files"
 4149: cvs commit: Examining .
 4150: cvs commit: Committing .
 4151: @end example
 4152: 
 4153: 利便性のために、@samp{-f} オプションを指定することでファイルの削除と 
 4154: @code{cvs remove} を一度に行うことができます。例えば、上の例はこのよう
 4155: にすることもできます:
 4156: 
 4157: @example
 4158: $ cd test
 4159: $ cvs remove -f *.c
 4160: cvs remove: scheduling a.c for removal
 4161: cvs remove: scheduling b.c for removal
 4162: cvs remove: use 'cvs commit' to remove these files permanently
 4163: $ cvs ci -m "Removed unneeded files"
 4164: cvs commit: Examining .
 4165: cvs commit: Committing .
 4166: @end example
 4167: 
 4168: ファイルに @code{remove} を実行したけれど、
 4169: 格納前に気が変わったのなら、@code{add} コマンドを用いて、
 4170: 簡単にファイルを復活させることができます。
 4171: @ignore
 4172: @c is this worth saying or not?  Somehow it seems
 4173: @c confusing to me.
 4174: もちろん、作業ディレクトリからファイルのコピーを削除しましたので、
 4175: @sc{cvs} は必ずしも @code{remove} を実行する前のファイルの内容に戻すわ
 4176: けではありません。代わりにリポジトリからもう一度ファイルを取得します。
 4177: @end ignore
 4178: 
 4179: @c FIXME: what if you change your mind after you commit
 4180: @c it?  (answer is also "cvs add" but we don't say that...).
 4181: @c We need some index entries for thinks like "undoing
 4182: @c removal" too.
 4183: 
 4184: @example
 4185: $ ls
 4186: CVS   ja.h  oj.c
 4187: $ rm oj.c
 4188: $ cvs remove oj.c
 4189: cvs remove: scheduling oj.c for removal
 4190: cvs remove: use 'cvs commit' to remove this file permanently
 4191: $ cvs add oj.c
 4192: U oj.c
 4193: cvs add: oj.c, version 1.1.1.1, resurrected
 4194: @end example
 4195: 
 4196: @code{remove} コマンドを実行する前に失敗に気付いた場合、
 4197: @code{update} コマンドを用いてファイルを復活できます:
 4198: 
 4199: @example
 4200: $ rm oj.c
 4201: $ cvs update oj.c
 4202: cvs update: warning: oj.c was lost
 4203: U oj.c
 4204: @end example
 4205: 
 4206: 削除したファイルは、作業中の枝だけから削除されます 
 4207: (@pxref{Branching and merging})。
 4208: 他の枝からも削除したい場合は、後でマージすることができます 
 4209: (@pxref{Merging adds and removals})。
 4210: 
 4211: @node Removing directories
 4212: @section ディレクトリを削除する
 4213: @cindex removing directories
 4214: @cindex directories, removing
 4215: 
 4216: 概念上では、ディレクトリの削除はファイルの削除と似ています---現在の作
 4217: 業ディレクトリからそのディレクトリを消したいけれど、ディレクトリが存在
 4218: した古いリリースも取得できるようにしたい、と思うでしょう。
 4219: 
 4220: ディレクトリを削除する方法は、その中の全てのファイルを削除することです。
 4221: ディレクトリ自身は削除しません。そうする方法はありません。代わりに、
 4222: @code{cvs update}, @code{cvs checkout}, @code{cvs export} に @samp{-P} 
 4223: オプションを指定して、作業ディレクトリから空のディレクトリを削除するよ
 4224: うにします。おそらく最良の方法は常に @samp{-P} を指定することです。空
 4225: のディレクトリが欲しければ、削除されないように、ダミーファイルを作って
 4226: ください (例えば、 @file{.keepme})。
 4227: 
 4228: @c I'd try to give a rationale for this, but I'm not
 4229: @c sure there is a particularly convincing one.  What
 4230: @c we would _like_ is for CVS to do a better job of version
 4231: @c controlling whether directories exist, to eliminate the
 4232: @c need for -P and so that a file can be a directory in
 4233: @c one revision and a regular file in another.
 4234: @code{checkout} と @code{export} の @samp{-r} と @samp{-D} のオプショ
 4235: ンでは @samp{-P} が暗黙に含まれていることに注意してください。この方法
 4236: により @sc{cvs} は正しくディレクトリを作ることができ、又、取り出した特
 4237: 定のバージョンのそのディレクトリにファイルがあるかどうかに左右されなく
 4238: なります。
 4239: 
 4240: @c ---------------------------------------------------------------------
 4241: @node Moving files
 4242: @section ファイルの改名と移動
 4243: @cindex Moving files
 4244: @cindex Renaming files
 4245: @cindex Files, moving
 4246: 
 4247: ファイルを他のディレクトリに移動したり、改名したりするのは、
 4248: 難しくはありません。
 4249: しかし、難解な方法でこれを実現するものがあります。
 4250: (ディレクトリの移動と改名は、
 4251: より困難です。@xref{Moving directories}.)。
 4252: 
 4253: 以降の例では、
 4254: @var{old} というファイルを @var{new} に改名します。
 4255: 
 4256: @menu
 4257: * Outside::                     通常の改名方法
 4258: * Inside::                      小技を使った別の方法
 4259: * Rename by copying::           別の小技を使った方法
 4260: @end menu
 4261: 
 4262: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4263: @node Outside
 4264: @subsection 通常の改名方法
 4265: 
 4266: @c More rename issues.  Not sure whether these are
 4267: @c worth documenting; I'm putting them here because
 4268: @c it seems to be as good a place as any to try to
 4269: @c set down the issues.
 4270: @c * "cvs annotate" will annotate either the new
 4271: @c file or the old file; it cannot annotate _each
 4272: @c line_ based on whether it was last changed in the
 4273: @c new or old file.  Unlike "cvs log", where the
 4274: @c consequences of having to select either the new
 4275: @c or old name seem fairly benign, this may be a
 4276: @c real advantage to having CVS know about renames
 4277: @c other than as a deletion and an addition.
 4278: 
 4279: ファイルを移動する通常の方法は、
 4280: @var{old} を @var{new} にコピーして、
 4281: 普通の @sc{cvs} コマンドで @var{old} をリポジトリから削除し、
 4282: @var{new} を加えることです。
 4283: @c The following sentence is not true: one must cd into
 4284: @c the directory to run "cvs add".
 4285: @c  (Both @var{old} and @var{new} could
 4286: @c contain relative paths, for example @file{foo/bar.c}).
 4287: 
 4288: @example
 4289: $ mv @var{old} @var{new}
 4290: $ cvs remove @var{old}
 4291: $ cvs add @var{new}
 4292: $ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new}
 4293: @end example
 4294: 
 4295: これがファイルを移動する最も単純な方法であり、
 4296: 間違いがなく、この操作の履歴も記録されます。
 4297: このファイルの履歴を利用する際、
 4298: 古い名前か、新しい名前のどちらかを指定して、
 4299: 履歴のどの部分が欲しいのか知らせなくてはいけません。
 4300: 例えば、@code{cvs log @var{old}} を実行しても、
 4301: 改名が行なわれた時までのログ情報しか得られません。
 4302: 
 4303: @var{new} が格納される場合には、
 4304: リビジョン番号は普通は 1.1 から再び始まります。
 4305: それが嫌ならば、格納時にオプション @samp{-r rev}
 4306: を用いると良いでしょう。詳しい情報は @ref{Assigning revisions} を参照
 4307: してください。
 4308: 
 4309: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4310: @node Inside
 4311: @subsection 履歴ファイルを移動する
 4312: 
 4313: この方法は、リポジトリ中のファイルの移動を含むため、
 4314: さらに危険です。
 4315: この節を全部読んでから実行して下さい。
 4316: 
 4317: @example
 4318: $ cd $CVSROOT/@var{dir}
 4319: $ mv @var{old},v @var{new},v
 4320: @end example
 4321: 
 4322: @noindent
 4323: 利点:
 4324: 
 4325: @itemize @bullet
 4326: @item
 4327: 変更の記録が完全に保たれる。
 4328: 
 4329: @item
 4330: リビジョン番号に影響がない。
 4331: @end itemize
 4332: 
 4333: @noindent
 4334: 欠点:
 4335: 
 4336: @itemize @bullet
 4337: @item
 4338: リポジトリから、古いリリースを簡単に復元できない。
 4339: (改名される以前のリビジョンでもファイルの名前が @var{new} になる。)
 4340: 
 4341: @item
 4342: ファイルがいつ改名されたかの記録がない。
 4343: 
 4344: @item
 4345: ファイルの移動の最中に、
 4346: 誰かが履歴ファイルにアクセスした場合、酷いことが起きる。
 4347: あなたがファイルを移動させている間は、
 4348: 誰にも @sc{cvs} コマンドを発行させてはいけません。
 4349: @end itemize
 4350: 
 4351: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4352: @node Rename by copying
 4353: @subsection 履歴ファイルをコピーする
 4354: 
 4355: この方法も、リポジトリ中のファイルの移動を含みます。
 4356: 欠点が無い訳ではありませんが、安全です。
 4357: 
 4358: @example
 4359: # @r{リポジトリ中の @sc{rcs} ファイルをコピーする}
 4360: $ cd $CVSROOT/@var{dir}
 4361: $ cp @var{old},v @var{new},v
 4362: # @r{以前のファイルを削除する}
 4363: $ cd ~/@var{dir}
 4364: $ rm @var{old}
 4365: $ cvs remove @var{old}
 4366: $ cvs commit @var{old}
 4367: # @r{@var{new} の全てのタグを削除する}
 4368: $ cvs update @var{new}
 4369: $ cvs log @var{new}             # @r{枝でないタグ名を思い出す}
 4370: $ cvs tag -d @var{tag1} @var{new}
 4371: $ cvs tag -d @var{tag2} @var{new}
 4372: @dots{}
 4373: @end example
 4374: 
 4375: タグを削除することで、
 4376: 以前のリビジョンを復元することができます。
 4377: 
 4378: @noindent
 4379: 利点:
 4380: 
 4381: @itemize @bullet
 4382: @item
 4383: @c FIXME: Is this true about -D now that we have death
 4384: @c support?  See 5B.3 in the FAQ.
 4385: リビジョンの取得に @samp{-D@var{date}} を使わないで、
 4386: @samp{-r@var{tag}} を使う限り、以前のリビジョンのファイルを正しく復元
 4387: できる。
 4388: 
 4389: @item
 4390: 変更の記録を完全に維持できる。
 4391: 
 4392: @item
 4393: リビジョン番号に影響しない。
 4394: @end itemize
 4395: 
 4396: @noindent
 4397: 欠点:
 4398: 
 4399: @itemize @bullet
 4400: @item
 4401: 改名の前後で履歴を辿ることが困難である。
 4402: 
 4403: @ignore
 4404: @c Is this true?  I don't see how the revision numbers
 4405: @c _could_ start over, when new,v is just old,v with
 4406: @c the tags deleted.
 4407: @c If there is some need to reinstate this text,
 4408: @c it is "usually 1.1", not "1.0" and it needs an
 4409: @c xref to Assigning revisions
 4410: @item
 4411: @samp{-r rev} フラグを付けて @code{commit} しないと、
 4412: @var{new} のリビジョン番号はまた 1.0 から始まる
 4413: (@pxref{commit options})。
 4414: @end ignore
 4415: @end itemize
 4416: 
 4417: @c ---------------------------------------------------------------------
 4418: @node Moving directories
 4419: @section ディレクトリの改名と移動
 4420: @cindex Moving directories
 4421: @cindex Renaming directories
 4422: @cindex Directories, moving
 4423: 
 4424: ディレクトリの改名と移動の普通の方法は @ref{Outside} で説明されている
 4425: ようにその中のそれぞれのファイルを改名もしくは移動することです。それか
 4426: ら @ref{Removing directories} に説明されているように @samp{-P} オプショ
 4427: ンを付けて取り出します。
 4428: 
 4429: 本当にリポジトリの中身を変更してディレクトリを改名したり削除したければ、
 4430: 次のようにしてください:
 4431: 
 4432: @enumerate
 4433: @item
 4434: ディレクトリを改名する前に、
 4435: ディレクトリの作業コピーを取り出している全ての人に、
 4436: その旨を知らせます。
 4437: 次のステップに進む前に、彼等全員が変更内容を格納し、
 4438: 作業コピーを削除しなければなりません。
 4439: 
 4440: @item
 4441: リポジトリ中のディレクトリを改名します。
 4442: 
 4443: @example
 4444: $ cd $CVSROOT/@var{parent-dir}
 4445: $ mv @var{old-dir} @var{new-dir}
 4446: @end example
 4447: 
 4448: @item
 4449: @sc{cvs} の管理用ファイルを修正します。
 4450: (例えばモジュール名を改名する場合等)。
 4451: 
 4452: @item
 4453: 再び取り出して作業を続けられることを、
 4454: 全員に知らせます。
 4455: 
 4456: @end enumerate
 4457: 
 4458: 誰かが作業コピーを消さずに持っていた場合、
 4459: 彼がリポジトリから消されたディレクトリを削除するまで、
 4460: 彼の発行する @sc{cvs} コマンドは無視されます。
 4461: 
 4462: ディレクトリを移動させるよりは、
 4463: ディレクトリ中のファイルを移動させる方を推奨します。
 4464: ディレクトリを移動させれば、
 4465: ディレクトリ名に依存している古いリリースを正確に復元する事は、
 4466: ほとんど不可能になります。
 4467: 
 4468: @c ---------------------------------------------------------------------
 4469: @node History browsing
 4470: @chapter 履歴の閲覧
 4471: @cindex History browsing
 4472: @cindex Traceability
 4473: @cindex Isolation
 4474: 
 4475: @ignore
 4476: @c This is too long for an introduction (goal is
 4477: @c one 20x80 character screen), and also mixes up a
 4478: @c variety of issues (parallel development, history,
 4479: @c maybe even touches on process control).
 4480: 
 4481: @c -- @quote{To lose ones history is to lose ones soul.}
 4482: @c -- ///
 4483: @c -- ///Those who cannot remember the past are condemned to repeat it.
 4484: @c -- ///               -- George Santayana
 4485: @c -- ///
 4486: 
 4487: @sc{cvs} tries to make it easy for a group of people to work
 4488: together.  This is done in two ways:
 4489: 
 4490: @itemize @bullet
 4491: @item
 4492: Isolation---You have your own working copy of the
 4493: source.  You are not affected by modifications made by
 4494: others until you decide to incorporate those changes
 4495: (via the @code{update} command---@pxref{update}).
 4496: 
 4497: @item 
 4498: Traceability---When something has changed, you can
 4499: always see @emph{exactly} what changed.
 4500: @end itemize
 4501: 
 4502: There are several features of @sc{cvs} that together lead
 4503: to traceability:
 4504: 
 4505: @itemize @bullet
 4506: @item
 4507: Each revision of a file has an accompanying log
 4508: message.
 4509: 
 4510: @item
 4511: All commits are optionally logged to a central history
 4512: database.
 4513: 
 4514: @item
 4515: Logging information can be sent to a user-defined
 4516: program (@pxref{loginfo}).
 4517: @end itemize
 4518: 
 4519: @c -- More text here.
 4520: 
 4521: This chapter should talk about the history file, the
 4522: @code{log} command, the usefulness of ChangeLogs
 4523: even when you run @sc{cvs}, and things like that.
 4524: 
 4525: @end ignore
 4526: 
 4527: @c kind of lame, in a lot of ways the above text inside
 4528: @c the @ignore motivates this chapter better
 4529: 何時、誰が、どのように、どのファイルを変更したか、
 4530: といったバージョン管理の履歴を @sc{cvs} を使って保存してきたならば、
 4531: 様々な機構を用いてこの履歴を調べることができます。
 4532: 
 4533: @c FIXME: should also be talking about how you look at
 4534: @c old revisions (e.g. "cvs update -p -r 1.2 foo.c").
 4535: @menu
 4536: * log messages::                ログ・メッセージ
 4537: * history database::            履歴データベース
 4538: * user-defined logging::        ログ方法を使用者自身が設定する
 4539: * annotate::                    各行がどのリビジョンで変更されたか?
 4540: @end menu
 4541: 
 4542: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4543: @node log messages
 4544: @section ログ・メッセージ
 4545: 
 4546: @c FIXME: @xref to place where we talk about how to
 4547: @c specify message to commit.
 4548: ファイルを格納する時には、必ずログ・メッセージを記述します。
 4549: 
 4550: @c FIXME: bring the information here, and get rid of or
 4551: @c greatly shrink the "log" node.
 4552: 各リビジョンの格納時に記述されたログ・メッセージを調べる場合、
 4553: @code{cvs log} コマンドを使用します (@pxref{log})。
 4554: 
 4555: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4556: @node history database
 4557: @section 履歴データベース
 4558: 
 4559: @c FIXME: bring the information from the history file
 4560: @c and history nodes here.  Rewrite it to be motivated
 4561: @c better (start out by clearly explaining what gets
 4562: @c logged in history, for example).
 4563: 様々な @sc{cvs} の実行履歴を記録するために、
 4564: ファイル @file{history} が使用できます (@pxref{history file})。
 4565: ファイル @file{history} の情報を検索するには、
 4566: @code{cvs history} コマンドを使用して下さい (@pxref{history})。
 4567: @c
 4568: @c The history database has many problems:
 4569: @c * It is very unclear what field means what.  This
 4570: @c could be improved greatly by better documentation,
 4571: @c but there are still non-orthogonalities (for
 4572: @c example, tag does not record the "repository"
 4573: @c field but most records do).
 4574: @c * Confusion about files, directories, and modules.
 4575: @c Some commands record one, some record others.
 4576: @c * File removal is not logged.  There is an 'R'
 4577: @c record type documented, but CVS never uses it.
 4578: @c * Tags are only logged for the "cvs rtag" command,
 4579: @c not "cvs tag".  The fix for this is not completely
 4580: @c clear (see above about modules vs. files).
 4581: @c * Are there other cases of operations that are not
 4582: @c logged?  One would hope for all changes to the
 4583: @c repository to be logged somehow (particularly
 4584: @c operations like tagging, "cvs admin -k", and other
 4585: @c operations which do not record a history that one
 4586: @c can get with "cvs log").  Operations on the working
 4587: @c directory, like export, get, and release, are a
 4588: @c second category also covered by the current "cvs
 4589: @c history".
 4590: @c * The history file does not record the options given
 4591: @c to a command.  The most serious manifestation of
 4592: @c this is perhaps that it doesn't record whether a command
 4593: @c was recursive.  It is not clear to me whether one
 4594: @c wants to log at a level very close to the command
 4595: @c line, as a sort of way of logging each command
 4596: @c (more or less), or whether one wants
 4597: @c to log more at the level of what was changed (or
 4598: @c something in between), but either way the current
 4599: @c information has pretty big gaps.
 4600: @c * Further details about a tag--like whether it is a
 4601: @c branch tag or, if a non-branch tag, which branch it
 4602: @c is on.  One can find out this information about the
 4603: @c tag as it exists _now_, but if the tag has been
 4604: @c moved, one doesn't know what it was like at the time
 4605: @c the history record was written.
 4606: @c * Whether operating on a particular tag, date, or
 4607: @c options was implicit (sticky) or explicit.
 4608: @c
 4609: @c Another item, only somewhat related to the above, is a
 4610: @c way to control what is logged in the history file.
 4611: @c This is probably the only good way to handle
 4612: @c different people having different ideas about
 4613: @c information/space tradeoffs.
 4614: @c
 4615: @c It isn't really clear that it makes sense to try to
 4616: @c patch up the history file format as it exists now to
 4617: @c include all that stuff.  It might be better to
 4618: @c design a whole new CVSROOT/nhistory file and "cvs
 4619: @c nhistory" command, or some such, or in some other
 4620: @c way trying to come up with a clean break from the
 4621: @c past, which can address the above concerns.  Another
 4622: @c open question is how/whether this relates to
 4623: @c taginfo/loginfo/etc.
 4624: 
 4625: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 4626: @node user-defined logging
 4627: @section ログ方法を使用者自身が設定する
 4628: 
 4629: @c FIXME: should probably also mention the fact the -l
 4630: @c global option can disable most of the mechanisms
 4631: @c discussed here (why?  What is the -l global option for?).
 4632: @c
 4633: @c FIXME: probably should centralize this information
 4634: @c here, at least to some extent.  Maybe by moving the
 4635: @c loginfo, etc., nodes here and replacing
 4636: @c the "user-defined logging" node with one node for
 4637: @c each method.
 4638: @sc{cvs} を用いた様々な作業の履歴は、
 4639: 利用者自身が選択する方法で記録されます。
 4640: @sc{cvs} は、様々な場面でスクリプトを実行し、
 4641: この機構を実現します。
 4642: これらのスクリプトには、
 4643: ログ・ファイルに情報を追記したり、
 4644: 開発者グループにメールを送ったり、
 4645: 特定のニュース・グループに記事を投稿したりするものがあります。
 4646: 格納時のログ方法は @file{loginfo} で設定します(@pxref{loginfo})。
 4647: @c FIXME: What is difference between doing it in the
 4648: @c modules file and using loginfo/taginfo?  Why should
 4649: @c user use one or the other?
 4650: commit, checkout, export, tag
 4651: 等を実行した時のログ方法は、
 4652: 各々オプション @samp{-i}, @samp{-o}, @samp{-e}, @samp{-t} を用いて、
 4653: modules ファイルに設定できます。
 4654: これらのスクリプトほどのものは必要としない使用者にも、
 4655: @code{cvs watch add} コマンドを使用して、
 4656: 様々な告知をする弾力的な方法を提供します(@pxref{Getting Notified})。
 4657: この方法は @code{cvs watch on} を使用していない場合でも利用できます。
 4658: 
 4659: @cindex taginfo
 4660: @cindex exit status, of taginfo
 4661: 誰かが @code{tag} か @code{rtag} コマンドを実行した時に
 4662: 実行されるプログラムを、@file{taginfo} ファイルに設定します。
 4663: 管理用ファイルの標準書式に従い(@pxref{Administrative files})、
 4664: @file{taginfo} の各行には、
 4665: 正規表現に続いて実行されるコマンドが記述されます。
 4666: コマンドに渡される引数を順に挙げると、
 4667: @var{タグ名}, @var{操作}(@code{tag} なら @code{add},
 4668: @code{tag -F} なら @code{mov}, @code{tag -d} なら @code{del}),
 4669: @var{リポジトリ}, 残りは全て @var{ファイル名} と @var{リビジョン} の組
 4670: です。
 4671: フィルタ・プログラムが非零で終了した場合は、
 4672: タグ処理が中止されます。
 4673: 
 4674: これは taginfo を使って tag と rtag コマンドのログを取る例です。
 4675: taginfo ファイルには以下のものを入れます:
 4676: 
 4677: @example
 4678: ALL /usr/local/cvsroot/CVSROOT/loggit
 4679: @end example
 4680: 
 4681: @file{/usr/local/cvsroot/CVSROOT/loggit} は以下のスクリプトになってい
 4682: ます:
 4683: 
 4684: @example
 4685: #!/bin/sh
 4686: echo "$@@" >>/home/kingdon/cvsroot/CVSROOT/taglog
 4687: @end example
 4688: 
 4689: @node annotate
 4690: @section コマンド annotate
 4691: @cindex annotate (subcommand)
 4692: 
 4693: @deffn コマンド {cvs annotate} [@code{-flR}] [@code{-r rev}|@code{-D date}] files @dots{}
 4694: 
 4695: @var{files} で指定された各ファイルについて、
 4696: 幹の先頭リビジョンの内容と、各行が最後に修正された時の情報を、
 4697: 併せて表示します。
 4698: 以下に例示します:
 4699: 
 4700: @example
 4701: $ cvs annotate ssfile
 4702: Annotations for ssfile
 4703: ***************
 4704: 1.1          (mary     27-Mar-96): ssfile line 1
 4705: 1.2          (joe      28-Mar-96): ssfile line 2
 4706: @end example
 4707: 
 4708: ファイル @file{ssfile} は現在 2行から成り、
 4709: @code{ssfile line 1} という行は 3月 27日に @code{mary} が格納しました。
 4710: そして 3月 28日に @code{joe} が、
 4711: @code{ssfile line 1} という行を修正せずに、
 4712: @code{ssfile line 2} という行を格納しました。
 4713: この報告では、削除されたり修正された行については何も分らないので、
 4714: @code{cvs diff} を用いる必要があるでしょう(@pxref{diff})。
 4715: 
 4716: @end deffn
 4717: 
 4718: @code{cvs annotate} へのオプションは @ref{Invoking CVS} で一覧にされて
 4719: ていて、annotate するファイルとリビジョンを選択するために使うことがで
 4720: きます。オプションは @ref{Common options} でより詳しく説明されています。
 4721: 
 4722: @c FIXME: maybe an example using the options?  Just
 4723: @c what it means to select a revision might be worth a
 4724: @c few words of explanation ("you want to see who
 4725: @c changed this line *before* 1.4"...).
 4726: 
 4727: @c ---------------------------------------------------------------------
 4728: @node Binary files
 4729: @chapter バイナリ・ファイルの扱い
 4730: @cindex Binary files
 4731: 
 4732: 最も普通の @sc{cvs} の使用はテキスト・ファイルの保管です。テキスト・ファ
 4733: イルでは、@sc{cvs} はリビジョンをマージしたり、リビジョン間の違いを人
 4734: 間が読める形式で表示したり、他の似たような操作をすることができます。し
 4735: かし、これらの中のいくつかの機能を諦めることで、@sc{cvs} はバイナリ・
 4736: ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ
 4737: 画像の両方からなるウェブサイトを @sc{cvs} で保管するかもしれません。
 4738: 
 4739: @menu
 4740: * Binary why::     バイナリ・ファイルの問題の詳細
 4741: * Binary howto::   保管方法
 4742: @end menu
 4743: 
 4744: @node Binary why
 4745: @section バイナリ・ファイルの問題
 4746: 
 4747: 普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必
 4748: 要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ
 4749: せます。
 4750: 
 4751: バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。
 4752: 例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して
 4753: いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ
 4754: イルには、@sc{cvs} は @code{cvs diff} コマンドでこの機能を提供します。
 4755: バイナリ・ファイルには、2つのリビジョンを取り出して、@sc{cvs} の外部に
 4756: あるプログラムで比較することができるでしょう (例えば、ワープロにはよく
 4757: そのような機能があります)。もしそのようなツールがなければ、人に良いロ
 4758: グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実
 4759: 際にした変更が本当にそうしたいと思っている変更そのものであることを期待
 4760: しなければなりません。
 4761: 
 4762: バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。
 4763: @sc{cvs} ではこれは2つの文脈で発生します。1つめは使用者が分離された作
 4764: 業ディレクトリで変更をしたときです (@pxref{Multiple developers})。2つ
 4765: 目は @samp{update -j} コマンドで明示的にマージしたときです 
 4766: (@pxref{Branching and merging})。
 4767: 
 4768: テキスト・ファイルの場合は、@sc{cvs} は独立になされた変更をマージでき、
 4769: 変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、
 4770: @sc{cvs} にできることは、せいぜい2つの違ったファイルのコピーを出して、
 4771: 使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー
 4772: を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール
 4773: があればそれを実行するかもしれません。使用者にマージをさせることは、主
 4774: に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して
 4775: おり、エラーが発生する可能性が高いということに注意してください。
 4776: 
 4777: この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別
 4778: の作業ディレクトリによるマージを避けるためには、@ref{Multiple
 4779: developers} の独占取得 (ファイル占有) の議論を参照してください。枝によ
 4780: るマージを避けるためには、枝の使用を制限してください。
 4781: 
 4782: @node Binary howto
 4783: @section バイナリ・ファイルを保管する方法
 4784: 
 4785: @sc{cvs} でバイナリ・ファイルを保管する際の問題点が二つあります。
 4786: 一つ目は、@sc{cvs} がファイルを取り出す際に、
 4787: リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、
 4788: クライアント側のオペレーティングシステムに適した形式に変換する事です 
 4789: (例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり
 4790: ます)。
 4791: 
 4792: 二つ目の問題点は、キーワードと同じデータが
 4793: 偶然バイナリ・ファイルに含まれる可能性がある事です 
 4794: (@pxref{Keyword substitution})。
 4795: そのためキーワード展開を無効にする必要があります。
 4796: 
 4797: @c FIXME: the third is that one can't do merges with
 4798: @c binary files.  xref to Multiple Developers and the
 4799: @c reserved checkout issues.
 4800: 
 4801: 幾つかの @sc{cvs} コマンドで @samp{-kb} オプションを用いれば、
 4802: 確実に行末変換とキーワード展開を止めることができます。
 4803: 
 4804: @samp{-kb} フラグを用いて新しいファイルを登録する方法を、
 4805: 以下に例示します:
 4806: 
 4807: @example
 4808: $ echo '$@asis{}Id$' > kotest
 4809: $ cvs add -kb -m"A test file" kotest
 4810: $ cvs ci -m"First checkin; contains a keyword" kotest
 4811: @end example
 4812: 
 4813: ふと油断して @samp{-kb} 無しでファイルを加えてしまった場合、
 4814: @code{cvs admin} コマンドを使用して正常な状態に戻す必要があります。
 4815: 以下に例示します:
 4816: 
 4817: @example
 4818: $ echo '$@asis{}Id$' > kotest
 4819: $ cvs add -m"A test file" kotest
 4820: $ cvs ci -m"First checkin; contains a keyword" kotest
 4821: $ cvs admin -kb kotest
 4822: $ cvs update -A kotest
 4823: # @r{For non-unix systems:}
 4824: # @r{Copy in a good copy of the file from outside CVS}
 4825: $ cvs commit -m "make it binary" kotest
 4826: @end example
 4827: 
 4828: @c Trying to describe this for both unix and non-unix
 4829: @c in the same description is very confusing.  Might
 4830: @c want to split the two, or just ditch the unix "shortcut"
 4831: @c (unixheads don't do much with binary files, anyway).
 4832: @c This used to say "(Try the above example, and do a
 4833: @c @code{cat kotest} after every command)".  But that
 4834: @c only really makes sense for the unix case.
 4835: ファイル @file{kotest} を格納した時はファイルはバイナリ・ファイルとし
 4836: ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ
 4837: たからです。
 4838: @samp{cvs admin -kb} コマンドでファイルの置換モードを設定しますが、
 4839: 既にある作業コピーは変更してくれません。
 4840: 行末を適切に処理する必要がある場合 (@sc{cvs} のクライアントとして 
 4841: unix 以外のシステムを使用している場合) は、
 4842: 上記の例に示した @code{cvs commit} コマンドのように、
 4843: 新たにファイルのコピーを格納する必要があります。
 4844: Unix では、@samp{cvs update -A} で十分です。
 4845: @c FIXME: should also describe what the *other users*
 4846: @c need to do, if they have checked out copies which
 4847: @c have been corrupted by lack of -kb.  I think maybe
 4848: @c "cvs update -kb" or "cvs
 4849: @c update -A" would suffice, although the user who
 4850: @c reported this suggested removing the file, manually
 4851: @c removing it from CVS/Entries, and then "cvs update"
 4852: 
 4853: ここで、@samp{cvs admin -k} を用いて置換モードを変更しても、
 4854: この置換モードはバージョン管理されないことを認識しておいて下さい。
 4855: これは例えば古いリリースにテキスト・ファイルがあり、
 4856: 新しいリリースに同じ名前のバイナリ・ファイルがあった場合、
 4857: バージョンによってテキストとバイナリを区別して取り出す方法を、
 4858: @sc{cvs} が備えていないことを意味しています。
 4859: この問題を解決する方法は今のところありません。
 4860: 
 4861: @code{cvs add} や @code{cvs import} を実行する際、
 4862: 既定でバイナリとして扱うかどうかを、
 4863: ファイルの名前によって判断するように設定もできます。
 4864: 例えば、ファイル名が @samp{.exe} で終わるファイルを
 4865: バイナリと判断するように設定できます。@xref{Wrappers}.
 4866: 現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ
 4867: ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの
 4868: 区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに
 4869: 応じてかなり異なるであろうということです。
 4870: @c For example, it would be good on MS-DOS-family OSes
 4871: @c for anything containing ^Z to be binary.  Having
 4872: @c characters with the 8th bit set imply binary is almost
 4873: @c surely a bad idea in the context of ISO-8859-* and
 4874: @c other such character sets.  On VMS or the Mac, we
 4875: @c could use the OS's file typing.  This is a
 4876: @c commonly-desired feature, and something of this sort
 4877: @c may make sense.  But there are a lot of pitfalls here.
 4878: @c
 4879: @c Another, probably better, way to tell is to read the
 4880: @c file in text mode, write it to a temp file in text
 4881: @c mode, and then do a binary mode compare of the two
 4882: @c files.  If they differ, it is a binary file.  This
 4883: @c might have problems on VMS (or some other system
 4884: @c with several different text modes), but in general
 4885: @c should be relatively portable.  The only other
 4886: @c downside I can think of is that it would be fairly
 4887: @c slow, but that is perhaps a small price to pay for
 4888: @c not having your files corrupted.  Another issue is
 4889: @c what happens if you import a text file with bare
 4890: @c linefeeds on Windows.  Such files will show up on
 4891: @c Windows sometimes (I think some native windows
 4892: @c programs even write them, on occasion).  Perhaps it
 4893: @c is reasonable to treat such files as binary; after
 4894: @c all it is something of a presumption to assume that
 4895: @c the user would want the linefeeds converted to CRLF.
 4896: 
 4897: @c ---------------------------------------------------------------------
 4898: @node Multiple developers
 4899: @chapter 複数の開発者
 4900: @cindex Multiple developers
 4901: @cindex Team of developers
 4902: @cindex File locking
 4903: @cindex Locking files
 4904: @cindex Working copy
 4905: @cindex reserved checkouts
 4906: @cindex unreserved checkouts
 4907: @cindex RCS-style locking
 4908: 
 4909: 複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。
 4910: 例えば二人の人物が、
 4911: 同じファイルを同時に編集しようとすることがよくあります。
 4912: 解決策の一つは、
 4913: @dfn{ファイル占有} (@dfn{file locking}) または @dfn{独占取得} 
 4914: (@dfn{reserved checkouts}) と呼ばれるもので、
 4915: 同時にファイルを編集できる人数を一人に制限するものです。
 4916: @sc{rcs} や @sc{sccs} 等の履歴管理システムでは、
 4917: これが唯一の方法です。
 4918: 現時点では @sc{cvs} で独占取得をする普通の方法は @code{cvs admin -l}
 4919: コマンドです (@pxref{admin options})。これは後述する監視機能のように 
 4920: @sc{cvs} によく実装されてはいませんが、独占取得を必要なほとんどの人は
 4921: 十分だと思うでしょう。
 4922: @c Or "find it better than worrying about implementing
 4923: @c nicely integrated reserved checkouts" or ...?
 4924: また後述する監視機構を適切な手順を踏んで用いることでも (ソフトウェアか
 4925: らは強制されません)、同時編集を避けることが可能でしょう。
 4926: 
 4927: @c Our unreserved checkout model might not
 4928: @c be quite the same as others.  For example, I
 4929: @c think that some systems will tend to create a branch
 4930: @c in the case where CVS prints "up-to-date check failed".
 4931: @c It isn't clear to me whether we should try to
 4932: @c explore these subtleties; it could easily just
 4933: @c confuse people.
 4934: @sc{cvs} の既定モデルは@dfn{無条件取得} 
 4935: (@dfn{unreserved checkouts}) と呼ばれるものです。
 4936: このモデルでは、
 4937: 開発者がそれぞれ自分の @dfn{作業コピー} 
 4938: (@dfn{working copy}) のファイルを同時に編集できます。
 4939: 最初に変更を格納した人物は、
 4940: 他の人物が編集を始めたことが自動的には分りません。
 4941: 二番目の人物が格納する時にはエラー表示を受けますから、
 4942: @sc{cvs} コマンドを用いて、
 4943: 自分の作業コピーをリポジトリのリビジョンの最新のものにする
 4944: 必要があります。
 4945: この手順はほぼ自動化されています。
 4946: 
 4947: @c FIXME? should probably use the word "watch" here, to
 4948: @c tie this into the text below and above.
 4949: @sc{cvs} は、独占取得がするような規則を強制することなく、
 4950: 種々の意志疎通を容易にする仕組みを用意しています。
 4951: 
 4952: この章の残りでは、色々なモデルの動作方法と、
 4953: 各モデルの選択に伴なう問題点について述べます。
 4954: 
 4955: @ignore
 4956: Here is a draft reserved checkout design or discussion
 4957: of the issues.  This seems like as good a place as any
 4958: for this.
 4959: 
 4960: Might want a cvs lock/cvs unlock--in which the names
 4961: differ from edit/unedit because the network must be up
 4962: for these to work.  unedit gives an error if there is a
 4963: reserved checkout in place (so that people don't
 4964: accidentally leave locks around); unlock gives an error
 4965: if one is not in place (this is more arguable; perhaps
 4966: it should act like unedit in that case).
 4967: 
 4968: On the other hand, might want it so that emacs,
 4969: scripts, etc., can get ready to edit a file without
 4970: having to know which model is in use.  In that case we
 4971: would have a "cvs watch lock" (or .cvsrc?) (that is,
 4972: three settings, "on", "off", and "lock").  Having cvs
 4973: watch lock set would cause a get to record in the CVS
 4974: directory which model is in use, and cause "cvs edit"
 4975: to change behaviors.  We'd want a way to query which
 4976: setting is in effect (this would be handy even if it is
 4977: only "on" or "off" as presently).  If lock is in
 4978: effect, then commit would require a lock before
 4979: allowing a checkin; chmod wouldn't suffice (might be
 4980: debatable--see chmod comment below, in watches--but it
 4981: is the way people expect RCS to work and I can't think
 4982: of any significant downside.  On the other hand, maybe
 4983: it isn't worth bothering, because people who are used
 4984: to RCS wouldn't think to use chmod anyway).
 4985: 
 4986: Implementation: use file attributes or use RCS
 4987: locking.  The former avoids more dependence on RCS
 4988: behaviors we will need to reimplement as we librarify
 4989: RCS, and makes it easier to import/export RCS files (in
 4990: that context, want to ignore the locker field).  But
 4991: note that RCS locks are per-branch, which is the
 4992: correct behavior (this is also an issue for the "watch
 4993: on" features; they should be per-branch too).
 4994: 
 4995: Here are a few more random notes about implementation
 4996: details, assuming "cvs watch lock" and
 4997: 
 4998: CVS/Watched file?  Or try to fit this into CVS/Entries somehow?
 4999: Cases: (1) file is checked out (unreserved or with watch on) by old
 5000: version of CVS, now we do something with new one, (2) file is checked
 5001: out by new version, now we do something with old one.
 5002: 
 5003: Remote protocol would have a "Watched" analogous to "Mode".  Of course
 5004: it would apply to all Updated-like requests.  How do we keep this
 5005: setting up to date?  I guess that there wants to be a Watched request,
 5006: and the server would send a new one if it isn't up to date? (Ugh--hard
 5007: to implement and slows down "cvs -q update"--is there an easier way?)
 5008: 
 5009: "cvs edit"--checks CVS/Watched, and if watch lock, then sends
 5010: "edit-lock" request.  Which comes back with a Checked-in with
 5011: appropriate Watched (off, on, lock, locked, or some such?), or error
 5012: message if already locked.
 5013: 
 5014: "cvs commit"--only will commit if off/on/locked.  lock is not OK.
 5015: 
 5016: Doc:
 5017: note that "cvs edit" must be connected to network if watch lock is in
 5018: effect.
 5019: 
 5020: Talk about what to do if someone has locked a file and you want to
 5021: edit that file.  (breaking locks, or lack thereof).
 5022: 
 5023: 
 5024: One other idea (which could work along with the
 5025: existing "cvs admin -l" reserved checkouts, as well as
 5026: the above):
 5027: 
 5028: "cvs editors" could show who has the file locked, if
 5029: someone does.
 5030: 
 5031: @end ignore
 5032: 
 5033: @menu
 5034: * File status::                 ファイルは幾つかの状態を取る
 5035: * Updating a file::             ファイルを最新にする
 5036: * Conflicts example::           有益な実行例
 5037: * Informing others::            協力のために他の人にお知らせする
 5038: * Concurrency::                 リポジトリの同時利用
 5039: * Watches::                     ファイル編集者の追跡機構
 5040: * Choosing a model::            独占取得か無条件取得か?
 5041: @end menu
 5042: 
 5043: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5044: @node File status
 5045: @section ファイル状態
 5046: @cindex File status
 5047: @cindex Status of a file
 5048: 
 5049: @c Shouldn't this start with an example or something,
 5050: @c introducing the unreserved checkout model?  Before we
 5051: @c dive into listing states?
 5052: 取り出した後にあなたが加えた操作や、
 5053: 他の人物がリポジトリに加えた操作によって、
 5054: ファイルを幾つかの状態に分類します。
 5055: @code{status} コマンドによって報告される状態を以下に挙げます:
 5056: 
 5057: @c The order of items is chosen to group logically
 5058: @c similar outputs together.
 5059: @c People who want alphabetical can use the index...
 5060: @table @asis
 5061: @cindex Up-to-date
 5062: @item Up-to-date
 5063: このファイルが、
 5064: 使用している枝の最新リビジョンと同じであることを示します。
 5065: @c FIXME: should we clarify "in use"?  The answer is
 5066: @c sticky tags, and trying to distinguish branch sticky
 5067: @c tags from non-branch sticky tags seems rather awkward
 5068: @c here.
 5069: @c FIXME: What happens with non-branch sticky tags?  Is
 5070: @c a stuck file "Up-to-date" or "Needs checkout" or what?
 5071: 
 5072: @item Locally Modified
 5073: @cindex Locally Modified
 5074: このファイルを修正したが、まだ変更内容を格納してないことを示します。
 5075: 
 5076: @item Locally Added
 5077: @cindex Locally Added
 5078: @code{add} コマンドによりファイルを加えたが、
 5079: まだその内容を格納してないことを示します。
 5080: @c There are many cases involving the file being
 5081: @c added/removed/modified in the working directory, and
 5082: @c added/removed/modified in the repository, which we
 5083: @c don't try to describe here.  I'm not sure that "cvs
 5084: @c status" produces a non-confusing output in most of
 5085: @c those cases.
 5086: 
 5087: @item Locally Removed
 5088: @cindex Locally Removed
 5089: @code{remove} コマンドによりファイルを削除したが、
 5090: まだその変更を格納してないことを示します。
 5091: 
 5092: @item Needs Checkout
 5093: @cindex Needs Checkout
 5094: 他の人物が新しいリビジョンをリポジトリに格納したことを示します。
 5095: この表示は少し紛らわしいのですが、
 5096: 新しいリビジョンを取り出す際には、@code{checkout} ではなく、
 5097: @code{update} を使用するのが普通です。
 5098: 
 5099: @item Needs Patch
 5100: @cindex Needs Patch
 5101: @c See also newb-123j0 in sanity.sh (although that case
 5102: @c should probably be changed rather than documented).
 5103: Needs Checkout と似たようなものですが、
 5104: @sc{cvs} のサーバは、ファイル全てではなく差分を送ります。
 5105: 差分を送る場合も、ファイル全てを送る場合と結果は同じです。
 5106: 
 5107: @item Needs Merge
 5108: @cindex Needs Merge
 5109: 他の人物が新しいリビジョンをリポジトリに格納したが、
 5110: 作業ファイルも修正されていたため、マージする必要があることを示します。
 5111: 
 5112: @item File had conflicts on merge
 5113: @cindex File had conflicts on merge
 5114: @c is it worth saying that this message was "Unresolved
 5115: @c Conflict" in CVS 1.9 and earlier?  I'm inclined to
 5116: @c think that is unnecessarily confusing to new users.
 5117: Locally Modified と似ていますが、先の @code{update} コマンドの結果、
 5118: 変更点の衝突が発見されたことを示します。
 5119: 衝突を解消する方法は @ref{Conflicts example} 参照。
 5120: 
 5121: @item Unknown
 5122: @cindex Unknown
 5123: このファイルについて @sc{cvs} が何も知らないことを示します。
 5124: 例えば新たなファイルを作成したが、@code{add} を実行していない場合などです。
 5125: @c
 5126: @c "Entry Invalid" and "Classify Error" are also in the
 5127: @c status.c.  The latter definitely indicates a CVS bug
 5128: @c (should it be worded more like "internal error" so
 5129: @c people submit bug reports if they see it?).  The former
 5130: @c I'm not as sure; I haven't tracked down whether/when it
 5131: @c appears in "cvs status" output.
 5132: 
 5133: @end table
 5134: 
 5135: @code{status} は、ファイル状態を分類する際の補助として、
 5136: 作業中のファイルの由来となるリビジョン
 5137: を示す @samp{Working revision} と、
 5138: 使用中の枝のリポジトリにおける最新リビジョン
 5139: を示す @samp{Repository revision} とも報告します。
 5140: @c FIXME: should we clarify "in use"?  The answer is
 5141: @c sticky tags, and trying to distinguish branch sticky
 5142: @c tags from non-branch sticky tags seems rather awkward
 5143: @c here.
 5144: @c FIXME: What happens with non-branch sticky tags?
 5145: @c What is the Repository Revision there?  See the
 5146: @c comment at vn_rcs in cvs.h, which is kind of
 5147: @c confused--we really need to document better what this
 5148: @c field contains.
 5149: @c Q: Should we document "New file!" and other such
 5150: @c outputs or are they self-explanatory?
 5151: @c FIXME: what about the date to the right of "Working
 5152: @c revision"?  It doesn't appear with client/server and
 5153: @c seems unnecessary (redundant with "ls -l") so
 5154: @c perhaps it should be removed for non-client/server too?
 5155: @c FIXME: Need some examples.
 5156: @c FIXME: Working revision can also be something like
 5157: @c "-1.3" for a locally removed file.  Not at all
 5158: @c self-explanatory (and it is possible that CVS should
 5159: @c be changed rather than documenting this).
 5160: 
 5161: @c Would be nice to have an @example showing output
 5162: @c from cvs status, with comments showing the xref
 5163: @c where each part of the output is described.  This
 5164: @c might fit in nicely if it is desirable to split this
 5165: @c node in two; one to introduce "cvs status" and one
 5166: @c to list each of the states.
 5167: @code{status} コマンドのオプションについての情報は、@ref{Invoking CVS}
 5168: 参照。
 5169: @samp{Sticky tag} と @samp{Sticky date} についての
 5170: 情報は、@ref{Sticky tags} 参照。
 5171: @samp{Sticky options} の情報は、@ref{update options} 
 5172: の @samp{-k} オプションを参照して下さい。
 5173: 
 5174: @code{status} と @code{update} コマンドは補完するようなものとして考え
 5175: ることができます。ファイルを最新にするためには @code{update} を使い、
 5176: @code{status} で @code{update} が何をするかをある程度知ることができま
 5177: す (もちろん、リポジトリの状態は実際に @code{update} を実行するまでに
 5178: 変化するかもしれません)。実際は、@code{status} コマンドで表示されるよ
 5179: り短い形式でコマンドに表示させたければ、次を実行することができます
 5180: 
 5181: @cindex update, to display file status
 5182: @example
 5183: $ cvs -n -q update
 5184: @end example
 5185: 
 5186: @samp{-n} オプションは実際に update をしないが、状態を表示するだけであ
 5187: る、ということです。@samp{-q} オプションはそれぞれのディレクトリ名の印
 5188: 字を避けます。@code{update} コマンドとこれらのオプションの情報は、
 5189: @ref{Invoking CVS} を参照してください。
 5190: 
 5191: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5192: @node Updating a file
 5193: @section ファイルを最新にする
 5194: @cindex Bringing a file up to date
 5195: @cindex Updating a file
 5196: @cindex Merging a file
 5197: @cindex update, introduction
 5198: 
 5199: ファイルを更新もしくはマージしたい場合には、
 5200: @code{update} コマンドを使用します。
 5201: これは最新でないファイルに対しては @code{checkout} コマンドとほとんど
 5202: 等価です。
 5203: つまり、ファイルの最新リビジョンをリポジトリから取り出して、
 5204: 作業ディレクトリに置きます。
 5205: 
 5206: @code{update} コマンドを使用しても、
 5207: あなたの修正が失なわれることはありません。
 5208: より新しいバージョンが無い場合には、@code{update} は何もしません。
 5209: 新しいバージョンが存在し、かつ作業ファイルが修正されている場合、
 5210: @sc{cvs} は全ての変更を作業コピーにマージします。
 5211: 
 5212: 例えばリビジョン 1.4 を取り出して、編集を始めたとします。
 5213: その合間に他の人物がバージョン 1.5 を格納し、
 5214: またすぐに 1.6 になったとします。
 5215: ここで @code{update} コマンドを使用した場合、
 5216: @sc{cvs} は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。
 5217: 
 5218: @cindex Overlap
 5219: 1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、
 5220: @dfn{重複} (@dfn{overlap}) が起きます。
 5221: そして警告が表示され、ファイルには重複した行が両方並記されて、
 5222: 特別なマークで囲まれます。
 5223: @code{update} コマンドの詳細は @xref{update}.
 5224: 
 5225: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5226: @node Conflicts example
 5227: @section 衝突の例
 5228: @cindex Merge, an example
 5229: @cindex Example of merge
 5230: @cindex driver.c (merge example)
 5231: 
 5232: リビジョン 1.4 の @file{drive.c} は次のような内容とします:
 5233: 
 5234: @example
 5235: #include <stdio.h>
 5236: 
 5237: void main()
 5238: @{
 5239:     parse();
 5240:     if (nerr == 0)
 5241:         gencode();
 5242:     else
 5243:         fprintf(stderr, "No code generated.\n");
 5244:     exit(nerr == 0 ? 0 : 1);
 5245: @}
 5246: @end example
 5247: 
 5248: @noindent
 5249: リビジョン 1.6 では @file{drive.c} は次のようになっています:
 5250: 
 5251: @example
 5252: #include <stdio.h>
 5253: 
 5254: int main(int argc,
 5255:          char **argv)
 5256: @{
 5257:     parse();
 5258:     if (argc != 1)
 5259:     @{
 5260:         fprintf(stderr, "tc: No args expected.\n");
 5261:         exit(1);
 5262:     @}
 5263:     if (nerr == 0)
 5264:         gencode();
 5265:     else
 5266:         fprintf(stderr, "No code generated.\n");
 5267:     exit(!!nerr);
 5268: @}
 5269: @end example
 5270: 
 5271: @noindent
 5272: リビジョン 1.4 を元にしたあなたの @file{driver.c} の作業コピーは、
 5273: @samp{cvs update} の前に次ようになっています:
 5274: @c -- Really include "cvs"?
 5275: 
 5276: @example
 5277: #include <stdlib.h>
 5278: #include <stdio.h>
 5279: 
 5280: void main()
 5281: @{
 5282:     init_scanner();
 5283:     parse();
 5284:     if (nerr == 0)
 5285:         gencode();
 5286:     else
 5287:         fprintf(stderr, "No code generated.\n");
 5288:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5289: @}
 5290: @end example
 5291: 
 5292: @noindent
 5293: この時 @samp{cvs update} を実行してみます:
 5294: @c -- Really include "cvs"?
 5295: 
 5296: @example
 5297: $ cvs update driver.c
 5298: RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
 5299: retrieving revision 1.4
 5300: retrieving revision 1.6
 5301: Merging differences between 1.4 and 1.6 into driver.c
 5302: rcsmerge warning: overlaps during merge
 5303: cvs update: conflicts found in driver.c
 5304: C driver.c
 5305: @end example
 5306: 
 5307: @noindent
 5308: @cindex Conflicts (merge example)
 5309: @sc{cvs} は上記のように、衝突が起きたことが報告します。
 5310: あなたが編集したオリジナルのファイルは、
 5311: 無修正で @file{.#driver.c.1.4} という名前で保存されます。
 5312: @file{driver.c} の新しいバージョンは次のようになります:
 5313: 
 5314: @example
 5315: #include <stdlib.h>
 5316: #include <stdio.h>
 5317: 
 5318: int main(int argc,
 5319:          char **argv)
 5320: @{
 5321:     init_scanner();
 5322:     parse();
 5323:     if (argc != 1)
 5324:     @{
 5325:         fprintf(stderr, "tc: No args expected.\n");
 5326:         exit(1);
 5327:     @}
 5328:     if (nerr == 0)
 5329:         gencode();
 5330:     else
 5331:         fprintf(stderr, "No code generated.\n");
 5332: @asis{}<<<<<<< driver.c
 5333:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5334: @asis{}=======
 5335:     exit(!!nerr);
 5336: @asis{}>>>>>>> 1.6
 5337: @}
 5338: @end example
 5339: 
 5340: @noindent
 5341: @cindex Markers, conflict
 5342: @cindex Conflict markers
 5343: @cindex <<<<<<<
 5344: @cindex >>>>>>>
 5345: @cindex =======
 5346: 
 5347: 重複しなかった修正がどの様に作業コピーに組み込まれているか注意して下さ
 5348: い。
 5349: 重複した部分は
 5350: @samp{<<<<<<<}, @samp{=======} 及び @samp{>>>>>>>} 
 5351: ではっきりと囲まれています。
 5352: 
 5353: @cindex Resolving a conflict
 5354: @cindex Conflict resolution
 5355: ファイルを編集して衝突が起きた部分を解決し、
 5356: マークと間違った行を消します。
 5357: 最終的に次のようになったとします:
 5358: @c -- Add xref to the pcl-cvs manual when it talks
 5359: @c -- about this.
 5360: @example
 5361: #include <stdlib.h>
 5362: #include <stdio.h>
 5363: 
 5364: int main(int argc,
 5365:          char **argv)
 5366: @{
 5367:     init_scanner();
 5368:     parse();
 5369:     if (argc != 1)
 5370:     @{
 5371:         fprintf(stderr, "tc: No args expected.\n");
 5372:         exit(1);
 5373:     @}
 5374:     if (nerr == 0)
 5375:         gencode();
 5376:     else
 5377:         fprintf(stderr, "No code generated.\n");
 5378:     exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
 5379: @}
 5380: @end example
 5381: 
 5382: @noindent
 5383: 今やこのファイルを格納してリビジョン 1.7 とすることができます。
 5384: 
 5385: @example
 5386: $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
 5387: Checking in driver.c;
 5388: /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
 5389: new revision: 1.7; previous revision: 1.6
 5390: done
 5391: @end example
 5392: 
 5393: 衝突が起きたが未解決であるファイルは、安全を考慮して、
 5394: @sc{cvs} が格納することを拒否します。
 5395: 衝突を解決するとき、ファイルの編集時間を変更する必要があります。
 5396: 前のバージョンの @sc{cvs} では、ファイルに衝突マークがないことを確認す
 5397: る必要もありました。ファイルには正しく衝突マークがあるかもしれませんの
 5398: で (すなわち、行頭にある @samp{>>>>>>> } は衝突の印ではありません)、現
 5399: 在のバージョンの @sc{cvs} は警告を印字してファイルの格納を実行します。
 5400: @c The old behavior was really icky; the only way out
 5401: @c was to start hacking on
 5402: @c the @code{CVS/Entries} file or other such workarounds.
 5403: @c
 5404: @c If the timestamp thing isn't considered nice enough,
 5405: @c maybe there should be a "cvs resolved" command
 5406: @c which clears the conflict indication.  For a nice user
 5407: @c interface, this should be invoked by an interactive
 5408: @c merge tool like emerge rather than by the user
 5409: @c directly--such a tool can verify that the user has
 5410: @c really dealt with each conflict.
 5411: 
 5412: @cindex emerge
 5413: もしあなたが pcl-cvs (@sc{gnu} Emacs 用 @sc{cvs} フロントエンド) の、
 5414: 1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに 
 5415: emerge という Emacs パッケージが利用できます。
 5416: pcl-cvs の文書を見て下さい。
 5417: 
 5418: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5419: @node Informing others
 5420: @section 格納したことを他の人に知らせる
 5421: @cindex Informing others
 5422: @cindex Spreading information
 5423: @cindex Mail, automatic mail on commit
 5424: 
 5425: 新しいリビジョンが格納されたときに、
 5426: それを開発者全員に通知するようにしておくと便利でしょう。
 5427: @file{moduels} か @file{loginfo} ファイルの 
 5428: @samp{-i} オプションにより、この手順を自動化することができます 
 5429: @xref{modules}. @xref{loginfo}.
 5430: この機構により、例えば全ての開発者にメールを出したり、
 5431: ニュースに記事を投稿したりすることができます。
 5432: @c -- More text would be nice here.
 5433: 
 5434: @node Concurrency
 5435: @section 同時に CVS の実行を試みる複数の開発者
 5436: 
 5437: @cindex locks, cvs, introduction
 5438: @c For a discussion of *why* CVS creates locks, see
 5439: @c the comment at the start of src/lock.c
 5440: 複数の開発者が同時に @sc{cvs} を実行しようとした場合、
 5441: 次のようなメッセージが表示されます:
 5442: 
 5443: @example
 5444: [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
 5445: @end example
 5446: 
 5447: @cindex #cvs.rfl, removing
 5448: @cindex #cvs.wfl, removing
 5449: @cindex #cvs.lock, removing
 5450: @sc{cvs} は 30秒毎に実行を試み、
 5451: まだ待つ必要があれば再度メッセージを表示し、
 5452: そうでなければ処理を続けます。
 5453: 不適当な程長く待ち続けているようならば、
 5454: ロックさせている人物を見付けて、
 5455: 実行中の cvs コマンドを訊いてみて下さい。
 5456: cvs コマンドが実行されてないのならば、メッセージで書かれているリポジト
 5457: リディレクトリを見て、彼等が所有している 
 5458: @file{#cvs.tfl}, @file{#cvs.rfl}, @file{#cvs.wfl} 
 5459: という名前で始まるファイルを捜して、削除して下さい。
 5460: 
 5461: このロックは @sc{cvs} の内部データ構造を保護するもので、
 5462: @sc{rcs} で使用される@dfn{ロック} (@dfn{lock}) 
 5463: という言葉とは全く何の関係もないことに注意してください。
 5464: @sc{rcs} のロックについては、
 5465: 独占取得についての記述を参照して下さい (@pxref{Multiple developers})。
 5466: 
 5467: 任意のリポジトリから何人でも、
 5468: 同時に読み出すことが可能です。
 5469: 誰かが書き込み中の場合にだけ、
 5470: 他の人の読み出しや書き込みが禁止されます。
 5471: 
 5472: @cindex Atomic transactions, lack of
 5473: @cindex Transactions, atomic, lack of
 5474: @c the following talks about what one might call commit/update
 5475: @c atomicity.
 5476: @c Probably also should say something about
 5477: @c commit/commit atomicity, that is, "An update will
 5478: @c not get partial versions of more than one commit".
 5479: @c CVS currently has this property and I guess we can
 5480: @c make it a documented feature.
 5481: @c For example one person commits
 5482: @c a/one.c and b/four.c and another commits a/two.c and
 5483: @c b/three.c.  Then an update cannot get the new a/one.c
 5484: @c and a/two.c and the old b/four.c and b/three.c.
 5485: 次に示すような動作を望む人がいるでしょう
 5486: 
 5487: @example
 5488: ある人物が一つの cvs コマンドで複数のファイルに対する変更点を
 5489: 格納した時、他の誰かが同時に update を実行すると、全てのファイルが
 5490: 更新されるか、全く更新されないかのどちらかである。
 5491: @end example
 5492: 
 5493: が、@sc{cvs} はこのように動作@emph{しません}。
 5494: 例えば以下のファイルがあるとして、
 5495: 
 5496: @example
 5497: a/one.c
 5498: a/two.c
 5499: b/three.c
 5500: b/four.c
 5501: @end example
 5502: 
 5503: ある人物が次のコマンドを実行した時、
 5504: 
 5505: @example
 5506: cvs ci a/two.c b/three.c
 5507: @end example
 5508: 
 5509: 同時に他の誰かが @code{cvs update} を実行した場合、
 5510: @code{update} を実行している人は @file{b/three.c} の変更点のみが更新さ
 5511: れ、
 5512: @file{a/two.c} の変更点は更新されないでしょう。
 5513: 
 5514: @node Watches
 5515: @section ファイル編集者の追跡機構
 5516: @cindex Watches
 5517: 
 5518: 多くのグループが @sc{cvs} を既定状態で使用していますが、
 5519: ほぼ完全に満足しているようです。
 5520: しかし時には、自分と他人の修正点が重複する事があり、
 5521: この重複を処理して再び格納しなくてはいけません。
 5522: あるグループでは、
 5523: 誰がどのファイルを編集中か分るようにしています。
 5524: 従って、二人で同じファイルを編集する場合、
 5525: 誰が何時何をするのか相談できるため、
 5526: 格納時に驚かされずに済みます。
 5527: この節では、
 5528: このような調整作業を行なう機能について説明しますが、
 5529: 二人の開発者が同時に同じファイルを編集する能力は維持されます。
 5530: 
 5531: @c Some people might ask why CVS does not enforce the
 5532: @c rule on chmod, by requiring a cvs edit before a cvs
 5533: @c commit.  The main reason is that it could always be
 5534: @c circumvented--one could edit the file, and
 5535: @c then when ready to check it in, do the cvs edit and put
 5536: @c in the new contents and do the cvs commit.  One
 5537: @c implementation note: if we _do_ want to have cvs commit
 5538: @c require a cvs edit, we should store the state on
 5539: @c whether the cvs edit has occurred in the working
 5540: @c directory, rather than having the server try to keep
 5541: @c track of what working directories exist.
 5542: @c FIXME: should the above discussion be part of the
 5543: @c manual proper, somewhere, not just in a comment?
 5544: 開発者は、
 5545: 編集するファイルを読み書き可能にする時に、
 5546: (@code{chmod} でなく) @code{cvs edit} を使用し、
 5547: もう使用しない作業ディレクトリを処分する時に、
 5548: (@code{rm} でなく) @code{cvs release} を使用することが推奨されます。
 5549: しかし、@sc{cvs} はこれらの手順を強制する事は出来ません。
 5550: 
 5551: @c I'm a little dissatisfied with this presentation,
 5552: @c because "watch on"/"edit"/"editors" are one set of
 5553: @c functionality, and "watch add"/"watchers" is another
 5554: @c which is somewhat orthogonal even though they interact in
 5555: @c various ways.  But I think it might be
 5556: @c confusing to describe them separately (e.g. "watch
 5557: @c add" with loginfo).  I don't know.
 5558: 
 5559: @menu
 5560: * Setting a watch::             監視するファイルを CVS に教える
 5561: * Getting Notified::            誰に通知するか CVS に教える
 5562: * Editing files::               監視下にあるファイルの編集方法
 5563: * Watch information::           誰が監視や編集をしているか
 5564: * Watches Compatibility::       監視は CVS 1.6 以前と上手く協調しない
 5565: @end menu
 5566: 
 5567: @node Setting a watch
 5568: @subsection 監視するファイルを CVS に教える
 5569: 
 5570: 監視機能を有効にするには、
 5571: まずそのファイルを監視するように指示する必要があります。
 5572: 
 5573: @cindex watch on (subcommand)
 5574: @deffn コマンド {cvs watch on} [@code{-lR}] files @dots{}
 5575: 
 5576: @cindex read-only files, and watches
 5577: この指定以降、@var{files} を編集しようとする開発者は 
 5578: @code{cvs edit} を実行する必要があります。
 5579: 開発者が編集前に @code{cvs edit} の実行を忘れない様に、
 5580: @sc{cvs} は @var{files} の読み込みだけを許可します。
 5581: 
 5582: @var{files} がディレクトリを含む場合、
 5583: リポジトリの対応するディレクトリ内の全てのファイルに加えて、
 5584: 将来ディレクトリに追加されるファイル全てが 
 5585: @sc{cvs} の監視対象になります。
 5586: この動作を利用して、ディレクトリ毎に通知方針を設定することができます。
 5587: またオプション @samp{-l} を指定しない場合、
 5588: ディレクトリ以下が再帰的に処理されます。
 5589: @code{-l} オプションが @file{~/.cvsrc} で設定されている場合は 
 5590: @code{-R} オプションを使って再帰を強制することができます 
 5591: (@pxref{~/.cvsrc})。
 5592: 
 5593: @var{files} を省略した場合、
 5594: 現在のディレクトリが指定されたと解釈します。
 5595: 
 5596: @cindex watch off (subcommand)
 5597: @end deffn
 5598: 
 5599: @deffn コマンド {cvs watch off} [@code{-lR}] files @dots{}
 5600: 
 5601: @var{files} が編集された時の通知を行ないません。
 5602: @sc{cvs} は @var{files} の作業コピーを読み書き可能にします。
 5603: 
 5604: @var{files} や引数指定時の振舞いは、
 5605: @code{cvs watch on} の場合と同じです。
 5606: 
 5607: @end deffn
 5608: 
 5609: @node Getting Notified
 5610: @subsection 誰に通知するか CVS に教える
 5611: 
 5612: あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、
 5613: その旨を @sc{cvs} に知らせます。
 5614: そのファイルに対して @code{cvs watch on} を用いなくても、
 5615: 通知の要求は可能です。
 5616: しかし、開発者がコマンド @code{cvs edit} を用いるとは限らないため、
 5617: 通常は @code{cvs watch on} を用いた方が良いでしょう。
 5618: 
 5619: @cindex watch add (subcommand)
 5620: @deffn コマンド {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{}
 5621: 
 5622: 現在の使用者を、 @var{files} に対して操作が行なわれた時に
 5623: 通知を受けとる人の一覧に追加します。
 5624: 
 5625: オプション @samp{-a} には、
 5626: 通知して欲しい操作の種類を指定します。
 5627: @var{action} は次のうちのどれかです:
 5628: 
 5629: @table @code
 5630: 
 5631: @item edit
 5632: あなた以外の人物が、
 5633: ファイルに対してコマンド @code{cvs edit} (後述) を適用した場合。
 5634: 
 5635: @item unedit
 5636: あなた以外の人物が、
 5637: ファイルに対してコマンド @code{cvs unedit} (後述) または 
 5638: @code{cvs release} を適用した場合。
 5639: また、ファイルが消されて @code{cvs update} により再度生成された場合。
 5640: 
 5641: @item commit
 5642: あなた以外の人物が、ファイルに対する変更を格納した場合。
 5643: 
 5644: @item all
 5645: 上記全て。
 5646: 
 5647: @item none
 5648: 上記以外。
 5649: (これは後述の @code{cvs edit} で使用すると便利です。)
 5650: 
 5651: @end table
 5652: 
 5653: オプション @samp{-a} は何度指定しても良いし、
 5654: 全く指定しなくても構いません。
 5655: 省略した場合には、@code{all} が指定されたと解釈します。
 5656: 
 5657: @var{files} や引数指定時の振舞いは、
 5658: @code{cvs watch on} の場合と同じです。
 5659: 
 5660: @end deffn
 5661: 
 5662: 
 5663: @cindex watch remove (subcommand)
 5664: @deffn コマンド {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{}
 5665: 
 5666: @code{cvs watch add} で設定した通知要求を取り下げます。
 5667: 引数は同じです。
 5668: オプション @samp{-a} を用いた場合、
 5669: 指定された事項に対する通知のみを停止します。
 5670: 
 5671: @end deffn
 5672: 
 5673: @cindex notify (admin file)
 5674: 通知すべき状態が発生した時、
 5675: @sc{cvs} は管理用ファイル @file{notify} を見ます。
 5676: @file{notify} は他の管理用ファイルと同じように編集して下さい。
 5677: (@pxref{Intro administrative files})。
 5678: 管理用ファイルの慣例に従って (@pxref{syntax})、このファイルの各行には、
 5679: 正規表現に続けて実行したいコマンドを記述します。
 5680: コマンドの引数には、(通知すべき使用者に置換される) 
 5681: @samp{%s} という文字列を一つだけ指定する必要があり、
 5682: 通知内容はコマンドの標準入力に与えられます。
 5683: ファイル @code{notify} に書く標準のものは次の一行です:
 5684: 
 5685: @example
 5686: ALL mail %s -s \"CVS notification\"
 5687: @end example
 5688: 
 5689: この記述により、使用者に電子メールで通知が行なわれます。
 5690: @c FIXME: should it be this hard to set up this
 5691: @c behavior (and the result when one fails to do so,
 5692: @c silent failure to notify, so non-obvious)?  Should
 5693: @c CVS give a warning if no line in notify matches (and
 5694: @c document the use of "DEFAULT :" for the case where
 5695: @c skipping the notification is indeed desired)?
 5696: 
 5697: @cindex users (admin file)
 5698: 上記の行をそのまま記述した場合、
 5699: 使用者はサーバ上で通知を受ける事に注意して下さい。
 5700: 他の場所に通知したい場合には、
 5701: もちろん @file{notify} に記述しても良いのですが、
 5702: @sc{cvs} ではもっと簡単に各使用者の通知先を設定できます。
 5703: @file{CVSROOT} に @file{users} というファイルを作成し、
 5704: @var{user}:@var{value} という書式で、
 5705: 各使用者について一行ずつ記述して下さい。
 5706: @sc{cvs} は、@file{notify} に記述された @var{user} の代りに、
 5707: @var{value} (通常は別のマシンのメールアドレス) に通知します。
 5708: 
 5709: @sc{Cvs} はあなた自身の変更は通知しません。現時点では、この照合は通知
 5710: を発生させる動作をしている人の使用者名が通知を受ける人の使用者名と合う
 5711: かどうかに基づいてなされています。実際のところ、一般的に、監視機構はそ
 5712: れぞれの使用者の一つの編集だけを追跡します。おそらく、監視がそれぞれの
 5713: 作業ディレクトリを別に追跡するとより便利なので、この振舞いは変更する
 5714: 価値があるでしょう。
 5715: @c "behavior might be worth changing" is an effort to
 5716: @c point to future directions while also not promising
 5717: @c that "they" (as in "why don't they fix CVS to....")
 5718: @c will do this.
 5719: @c one implementation issue is identifying whether a
 5720: @c working directory is same or different.  Comparing
 5721: @c pathnames/hostnames is hopeless, but having the server
 5722: @c supply a serial number which the client stores in the
 5723: @c CVS directory as a magic cookie should work.
 5724: 
 5725: @node Editing files
 5726: @subsection 監視下にあるファイルの編集方法
 5727: 
 5728: @cindex checkout, as term for getting ready to edit
 5729: 監視下にあるファイルを取り出した場合、
 5730: 読み込みだけが許可されるため、単純に編集はできません。
 5731: 読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、
 5732: @code{cvs edit} コマンドを使用して下さい。
 5733: 上記の作業を @dfn{checkout} と呼ぶシステムもありますが、
 5734: @sc{cvs} ではこの用語をソースのコピーを得る (@dfn{取り出す}) 
 5735: という意味で用います (@pxref{Getting the source})。
 5736: 他のシステムでは、この操作は @dfn{get} とか @dfn{fetch} と呼ばれます。
 5737: @c Issue to think about: should we transition CVS
 5738: @c towards the "get" terminology?  "cvs get" is already a
 5739: @c synonym for "cvs checkout" and that section of the
 5740: @c manual refers to "Getting the source".  If this is
 5741: @c done, needs to be done gingerly (for example, we should
 5742: @c still accept "checkout" in .cvsrc files indefinitely
 5743: @c even if the CVS's messages are changed from "cvs checkout: "
 5744: @c to "cvs get: ").
 5745: @c There is a concern about whether "get" is not as
 5746: @c good for novices because it is a more general term
 5747: @c than "checkout" (and thus arguably harder to assign
 5748: @c a technical meaning for).
 5749: 
 5750: @cindex edit (subcommand)
 5751: @deffn コマンド {cvs edit} [options] files @dots{}
 5752: 
 5753: 作業ファイル @var{files} を編集する準備をします。
 5754: @sc{cvs} は @var{files} の読み書きを許可し、
 5755: @var{files} に対する @code{edit} 通知を求める使用者に通知します。
 5756: 
 5757: @code{cvs edit} コマンドに、
 5758: @code{cvs watch add} コマンドと同じ @var{options} を使用すれば、
 5759: 一時的に @var{files} を監視することができます。
 5760: @sc{cvs} は、
 5761: @var{files} が @code{unedit} もしくは @code{commit} されたときに、
 5762: 監視を止めます。
 5763: 通知を受けたくない場合には、@samp{-a none} を指定して下さい。
 5764: 
 5765: @var{files} や引数指定時の振舞いは、
 5766: @code{cvs watch} の場合と同じです。
 5767: 
 5768: @strong{注意:} @code{PreservePermissions} オプションがリポジトリで使用
 5769: 可になっていると (@pxref{config})、CVS はどの @var{files} の使用許可も
 5770: 変更しません。この変更の理由は @samp{cvs edit} の使用が CVS リポジトリ
 5771: のファイル使用許可を保管する機能と干渉しないようにするということです。
 5772: 
 5773: @end deffn
 5774: 
 5775: 変更を全て終了したら、通常は @code{cvs commit} を用いて、
 5776: 監視下にあるファイルの変更点を格納し、
 5777: 読み込みだけが許可された状態に戻します。
 5778: しかし、途中で変更を止めたり、何も変更しないと決めた場合には、
 5779: @code{cvs unedit} コマンドを使用します。
 5780: 
 5781: @cindex unedit (subcommand)
 5782: @cindex abandoning work
 5783: @cindex reverting to repository version
 5784: @deffn コマンド {cvs unedit} [@code{-lR}] files @dots{}
 5785: 
 5786: 作業ファイル @var{files} に加えた変更を捨て、
 5787: 変更前のリポジトリのバージョンに戻します。
 5788: @var{files} に対して、@code{cvs watch on} による通知要求がある場合、
 5789: @sc{cvs} は @var{files} の読み込みだけを許可します。
 5790: また @var{files} に対する @code{unedit} 通知を求める使用者に通知します。
 5791: 
 5792: @var{files} や引数指定時の振舞いは、
 5793: @code{cvs watch} の場合と同じです。
 5794: 
 5795: ファイルが監視されてないときにはおそらく 
 5796: @code{unedit} コマンドが動作しないため、
 5797: リポジトリのバージョンに戻したい場合は、ファイルを削除してから 
 5798: @code{cvs update} で新たにコピーを取得して下さい。
 5799: これは厳密には同じ意味ではなく、削除して更新した場合には、
 5800: あなたが最後に更新した後にリポジトリに加えられた変更も付随します。
 5801: @c It would be a useful enhancement to CVS to make
 5802: @c unedit work in the non-watch case as well.
 5803: @end deffn
 5804: 
 5805: @sc{cvs} のクライアント/サーバを使用していて、
 5806: サーバとうまく接続できなかった場合でも、
 5807: @code{cvs edit} や @code{cvs unedit} コマンドが使用できます。
 5808: 次に @sc{cvs} コマンドが成功した時に、
 5809: 一緒に通知が行なわれます。
 5810: 
 5811: @node Watch information
 5812: @subsection 誰が監視や編集をしているか
 5813: 
 5814: @cindex watchers (subcommand)
 5815: @deffn コマンド {cvs watchers} [@code{-lR}] files @dots{}
 5816: 
 5817: 現在、@var{files} の変更を監視している人物の一覧を表示します。
 5818: 監視されているファイルと、各監視者のメールアドレスを報告します。
 5819: 
 5820: @var{files} や引数指定時の振舞いは、
 5821: @code{cvs watch} の場合と同じです。
 5822: 
 5823: @end deffn
 5824: 
 5825: 
 5826: @cindex editors (subcommand)
 5827: @deffn コマンド {cvs editors} [@code{-lR}] files @dots{}
 5828: 
 5829: 現在、@var{files} を編集している人物の一覧を表示します。
 5830: 各編集者のメールアドレス、編集作業を開始した時間、
 5831: ファイルが置かれた作業ディレクトリのパス名とホスト名を報告します。
 5832: 
 5833: @var{files} や引数指定時の振舞いは、
 5834: @code{cvs watch} の場合と同じです。
 5835: 
 5836: @end deffn
 5837: 
 5838: @node Watches Compatibility
 5839: @subsection 古いバージョンの CVS と監視機能
 5840: 
 5841: @cindex CVS 1.6, and watches
 5842: 監視機能を使用している場合、
 5843: リポジトリに @file{CVS} というディレクトリが作成され、
 5844: このディレクトリに監視情報が格納されます。
 5845: このリポジトリに対して @sc{cvs} 1.6 以前のものを使用した場合には、
 5846: 以下のエラー・メッセージが出力されます (全て一行にでます):
 5847: 
 5848: @example
 5849: cvs update: cannot open CVS/Entries for reading:
 5850: No such file or directory
 5851: @end example
 5852: 
 5853: そして、操作が途中で終了します。
 5854: 監視機能を使用するためには、
 5855: このリポジトリを利用するクライアント/サーバ両方で、
 5856: @sc{cvs} を新しいものと交換する必要があります。
 5857: もし新しいものと交換できない場合には、
 5858: @code{watch off} と @code{watch remove} コマンドを用いて
 5859: 監視を全て停止すれば、
 5860: リポジトリを @sc{cvs} 1.6 が利用できる状態に再構築できます。
 5861: 
 5862: @node Choosing a model
 5863: @section 独占取得と無条件取得の選択
 5864: @cindex choosing, reserved or unreserved checkouts
 5865: 
 5866: 独占取得、無条件取得それぞれに一長一短があります。
 5867: ここでは、この問題を簡単に説明しますが、
 5868: 残りの多くは個人的な見解の相違や、
 5869: 各グループの作業スタイルの相違だと思います。
 5870: 開発者チームを構成するには様々な方法があります。
 5871: @sc{cvs} は特定の構成を強制せず、
 5872: 各々を実現する機能を提供するだけです。
 5873: 
 5874: 独占取得には、非常に非生産的な部分があります。
 5875: 二人が同じファイルを編集する場合でも、編集部分が異なる場合には、
 5876: どちらか一方の編集を禁止する必要は全くありません。
 5877: また、ファイルを編集するためにロックした後、
 5878: ロック解除を忘れてしまうことが、普通に起こり得ます。
 5879: 
 5880: @c "many groups"?  specifics?  cites to papers on this?
 5881: @c some way to weasel-word it a bit more so we don't
 5882: @c need facts :-)?
 5883: 独占取得に特別な安心感を持つ人々は、
 5884: 無条件取得を用いた場合の衝突の多さや、
 5885: それを解決する困難さをよく訴えます。
 5886: しかし多くのグループの経験から言うと、
 5887: 衝突は稀であり、解決も普通は比較的簡単なものです。
 5888: 
 5889: 衝突は2人の開発者がコードの与えられた部分の適切な設計について
 5890: 意見が食い違っているときにのみ起こることを理解するまで、
 5891: 深刻な衝突の発生の少なさは驚きでしょう。
 5892: このような衝突は、そもそもチーム内での意思疎通が上手く行っていないこと
 5893: を示しています。
 5894: @emph{どのような}ソース管理方法を採るにしても、
 5895: 開発者が共同で作業する際には、
 5896: システム全体の設計方針に従わなければいけません。
 5897: きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。
 5898: 
 5899: 無条件取得が、全く不適当な場合があります。
 5900: 管理下にあるファイルの形式をマージする道具が無く 
 5901: (例えばワード・プロセッサによるファイルや、
 5902: CAD プログラムで編集されたファイル等)、
 5903: マージ可能なデータ書式を使用するようにプログラムを変更できない場合、
 5904: 悪夢のような衝突解決をするよりは、
 5905: 普通は独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。
 5906: 
 5907: 上の @ref{Watches} で記述された監視機構は、
 5908: 独占取得と無条件取得の中間的なものと考えられます。
 5909: ファイルを編集する前に、
 5910: 他の誰がファイルを編集中なのか調べることができます。
 5911: これは単純に双方の同時編集を禁止するのではなく、
 5912: 現況を報告し、それが問題かどうかは自分で判断してもらいます。
 5913: これを適切に使用すれば、
 5914: 独占取得と無条件取得の中でも最善の選択となるでしょう。
 5915: 
 5916: @c ---------------------------------------------------------------------
 5917: @node Revision management
 5918: @chapter リビジョン管理
 5919: @cindex Revision management
 5920: 
 5921: @c -- This chapter could be expanded a lot.
 5922: @c -- Experiences are very welcome!
 5923: 
 5924: ここまで読んだあなたは、
 5925: @sc{cvs} を使って何ができるかを、もう随分理解しているでしょう。
 5926: ここでは、あなたが決めるべき事柄について少し説明します。
 5927: 
 5928: あなたが一人で @sc{cvs} を使用して開発しているならば、
 5929: ここは読み飛ばして結構です。
 5930: 複数の人物が同じリポジトリを使って作業する場合に、
 5931: ここで説明する問題が重要になってきます。
 5932: 
 5933: @menu
 5934: * When to commit::              この問題の論議
 5935: @end menu
 5936: 
 5937: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 5938: @node When to commit
 5939: @section いつ格納すべきか?
 5940: @cindex When to commit
 5941: @cindex Commit, when to
 5942: @cindex Policy
 5943: 
 5944: あなたのグループは、格納の時期に関して、
 5945: どのような方針を採るか決めておく必要があります。
 5946: 幾つかの方針が可能であり、@sc{cvs} での経験を重ねることによって、
 5947: 独自の方法を見付けることができるでしょう。
 5948: 
 5949: とにかく早く格納することにして、
 5950: コンパイルもせずに格納してしまったとします。
 5951: あなたの同僚が、作業ソースを更新して
 5952: あなたのバギーなファイルを取り込んだ場合、
 5953: 彼はコンパイルができません。
 5954: 逆にめったに格納しない場合、
 5955: 同僚はあなたがコードに加えた改良の利益を得ることができず、
 5956: 衝突がより多くなるでしょう。
 5957: 
 5958: コンパイルできるかどうか確認したファイルだけを
 5959: 格納する方法がよく採られます。
 5960: あるサイトでは、ファイルが検査に合格することを要求します。
 5961: @file{commitinfo} ファイルを使用して (@pxref{commitinfo})、
 5962: このような方針を強制できますが、その前によく考えなくてはいけません。
 5963: 十分過ぎる程管理された開発環境を作ると、
 5964: 厳格になり過ぎて、非生産的になり、
 5965: ソフトウェアを書くという目的が果たせなくなります。
 5966: 
 5967: @c ---------------------------------------------------------------------
 5968: @node Keyword substitution
 5969: @chapter キーワード置換
 5970: @cindex Keyword substitution
 5971: @cindex Keyword expansion
 5972: @cindex Identifying files
 5973: 
 5974: @comment   この章を編集する場合には十分注意して下さい。
 5975: @comment   このファイルはバージョン管理されており、
 5976: @comment   有効なキーワードが、文中に含まれないように
 5977: @comment   注意しなくてはいけません。
 5978: 
 5979: 作業ファイルを編集している間は、
 5980: いつでも @samp{cvs status} や @samp{cvs log} を使って
 5981: そのファイルの状態を調べることができます。
 5982: しかし開発環境から取り出した場合は、
 5983: 各ファイルのリビジョンを識別するのが難しくなります。
 5984: 
 5985: CVSは、@dfn{キーワード置換} (@dfn{keyword substitution}) 
 5986: (もしくは@dfn{キーワード展開} (@dfn{keyword expansion}))
 5987: と呼ばれる機構により、ファイルの識別を補助します。
 5988: ファイル中に @code{$@var{keyword}$}, 
 5989: @code{$@var{keyword}:@dots{}$} といった書式で
 5990: 埋め込まれた文字列を、ファイルを取り出すときに 
 5991: @code{$@var{keyword}:@var{value}$} といった書式の文字列に置き換えます。
 5992: 
 5993: @menu
 5994: * Keyword list::                キーワード
 5995: * Using keywords::              キーワードの使用
 5996: * Avoiding substitution::       置換を止めるには
 5997: * Substitution modes::          置換モード
 5998: * Log keyword::                 キーワード $@asis{}Log$ の問題点
 5999: @end menu
 6000: 
 6001: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6002: @node Keyword list
 6003: @section キーワード一覧
 6004: @cindex Keyword List
 6005: 
 6006: @c FIXME: need some kind of example here I think,
 6007: @c perhaps in a
 6008: @c "Keyword intro" node.  The intro in the "Keyword
 6009: @c substitution" node itself seems OK, but to launch
 6010: @c into a list of the keywords somehow seems too abrupt.
 6011: 
 6012: これはキーワードの利用の一覧です:
 6013: 
 6014: @table @code
 6015: @cindex Author keyword
 6016: @item $@asis{Author}$
 6017: そのリビジョンを格納したユーザのログイン名。
 6018: 
 6019: @cindex Date keyword
 6020: @item $@asis{Date}$
 6021: そのリビジョンを格納した日付と時間 (UTC)。
 6022: 
 6023: @cindex Header keyword
 6024: @item $@asis{Header}$
 6025: 標準のヘッダは、@sc{rcs} ファイルのフルパス名, 
 6026: リビジョン番号, 日付 (UTC), 最終変更者, ファイル状態, 
 6027: (ロックされているならば) ロックしている人物という情報で
 6028: 構成されます。
 6029: @sc{cvs} を使用する場合、普通ファイルはロックされません。
 6030: 
 6031: @cindex Id keyword
 6032: @item $@asis{Id}$
 6033: @sc{rcs} ファイル名がフルパスでないことを除けば、
 6034: @code{$@asis{Header}$} と同じです。
 6035: 
 6036: @cindex Name keyword
 6037: @item $@asis{Name}$
 6038: このファイルを取り出すときに使用したタグ名。キーワードは明示的なタグ名
 6039: で取り出したときにのみ展開されます。例えば、コマンド @code{cvs co -r
 6040: first} を実行すると、キーワードを @samp{Name: first} に展開します。
 6041: 
 6042: @cindex Locker keyword
 6043: @item $@asis{Locker}$
 6044: そのリビジョンをロックしている人物のログイン名。
 6045: (ロックされていなければ空で、@code{cvs admin -l} が使われていなければ
 6046: それが普通です。)
 6047: 
 6048: @cindex Log keyword
 6049: @item $@asis{Log}$
 6050: @sc{rcs} ファイル名, リビジョン番号, 最終変更者, 
 6051: 日付 (UTC) から構成されるヘッダ行に続けて、
 6052: 格納時のログ・メッセージを挿入します。
 6053: 以前に挿入されたログ・メッセージを置き換えるのでは@emph{なく}、
 6054: 新しいメッセージを @code{$@asis{Log:@dots{}}$} の次の行に挿入します。
 6055: それぞれの新しい行には @code{$Log} キーワードの前にあるものと
 6056: 同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。
 6057: 
 6058: @example
 6059:   /* Here is what people have been up to:
 6060:    *
 6061:    * $@asis{}Log: frob.c,v $
 6062:    * Revision 1.1  1997/01/03 14:23:51  joe
 6063:    * Add the superfrobnicate option
 6064:    *
 6065:    */
 6066: @end example
 6067: 
 6068: @noindent
 6069: そうすると、@code{$Log} を展開するときに追加される行はその前に 
 6070: @samp{  * } が付きます。以前のバージョンの @sc{cvs}、@sc{rcs} と違って、
 6071: @sc{rcs} ファイル の @dfn{註釈符} (@dfn{comment leader}) は使用されま
 6072: せん。
 6073: @code{$Log} キーワードは、
 6074: ソース・ファイルに全てのログを残したい場合には便利ですが、
 6075: 問題点も幾つかあります (@pxref{Log keyword})。
 6076: 
 6077: @cindex RCSfile keyword
 6078: @item $@asis{RCSfile}$
 6079: パスを含まない @sc{rcs} ファイル名。
 6080: 
 6081: @cindex Revision keyword
 6082: @item $@asis{Revision}$
 6083: そのリビジョンを表わすリビジョン番号。
 6084: 
 6085: @cindex Source keyword
 6086: @item $@asis{Source}$
 6087: RCS ファイルのフルパス名。
 6088: 
 6089: @cindex State keyword
 6090: @item $@asis{State}$
 6091: そのリビジョンの状態。
 6092: 各リビジョンの状態は、@samp{cvs admin -s} で割り当てることができます---
 6093: @ref{admin options} 参照。
 6094: 
 6095: @end table
 6096: 
 6097: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6098: @node Using keywords
 6099: @section キーワードの使用
 6100: 
 6101: キーワードを使いたい場合は、@code{$@asis{Id}$} などの適当な文字列を
 6102: ファイルに記述してから格納するだけです。
 6103: @sc{cvs} は格納操作の一環として自動的に文字列を展開します。
 6104: 
 6105: @code{$@asis{}Id$} 文字列をソースファイルに入れて、生成されるファイル
 6106: にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
 6107: ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
 6108: れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために 
 6109: @code{#pragma ident} 命令が使用できるコンパイラもあります。もしくは、
 6110: 文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
 6111: れません。
 6112: 
 6113: @c Would be nice to give an example, but doing this in
 6114: @c portable C is not possible and the problem with
 6115: @c picking any one language (VMS HELP files, Ada,
 6116: @c troff, whatever) is that people use CVS for all
 6117: @c kinds of files.
 6118: 
 6119: @cindex Ident (shell command)
 6120: @code{ident} コマンド (@sc{rcs} パッケージの一部) を使用して、
 6121: ファイルからキーワードとその値を抜き出すことができます。
 6122: もちろんテキスト・ファイルにも使えますが、
 6123: バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。
 6124: 
 6125: @example
 6126: $ ident samp.c
 6127: samp.c:
 6128:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 6129: $ gcc samp.c
 6130: $ ident a.out
 6131: a.out:
 6132:      $@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
 6133: @end example
 6134: 
 6135: @cindex What (shell command)
 6136: 別のリビジョン管理システムとして有名なものに @sc{sccs} があります。
 6137: @sc{sccs} には、@code{ident} と非常によく似た
 6138: 同じ用途のコマンド @code{what} が含まれます。
 6139: @sc{rcs} を持たないサイトの多くは @sc{sccs} を使っています。
 6140: @code{what} コマンドは @code{@@(#)} という文字列を探すため、
 6141: 両方のコマンドに対応するキーワードを含めるのは簡単です。
 6142: @sc{rcs} のキーワードの前に、
 6143: 簡単な @sc{sccs} の魔法の呪文を唱えるだけで良いのです:
 6144: 
 6145: @example
 6146: static char *id="@@(#) $@asis{}Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
 6147: @end example
 6148: 
 6149: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6150: @node Avoiding substitution
 6151: @section 置換を止めるには
 6152: 
 6153: キーワード置換にも欠点があります。
 6154: ファイル中に表われる文字列 @samp{$@asis{}Author$} は、
 6155: @sc{rcs} によってキーワードと見倣されます。
 6156: この文字列を @samp{$@asis{}Author: ceder $} などと解釈させずに、
 6157: そのまま使いたい事があるでしょう。
 6158: 
 6159: 不幸なことに、選択的にキーワード置換を止めることはできません。
 6160: @samp{-ko} によって完全にキーワード置換を止めることができます 
 6161: (@pxref{Substitution modes})。
 6162: 
 6163: @sc{rcs} キーワードが最終製品に現われるとしても、
 6164: ソース・ファイル中には使いたくない場合が多くあります。
 6165: 例えばこのマニュアルのソースには @samp{$@asis{}Author$} ではなく、
 6166: @samp{$@@asis@{@}Author$} と記述しています。
 6167: @code{nroff} や @code{troff} であれば、
 6168: ヌル文字である @code{\&} をキーワード中に埋め込めば
 6169: 同様の効果を発揮します。
 6170: 
 6171: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6172: @node Substitution modes
 6173: @section 置換モード
 6174: @cindex -k (keyword substitution)
 6175: @cindex Kflag
 6176: 
 6177: @c FIXME: This could be made more coherent, by expanding it
 6178: @c with more examples or something.
 6179: 各ファイルには既定の置換モードが設定されており、
 6180: 作業ディレクトリの各ファイルの置換モードも別々に設定できます。
 6181: 前者は @code{cvs add} や @code{cvs admin} に
 6182: オプション @samp{-k} を付けて設定します。
 6183: 後者は @code{cvs checkout} や @code{cvs update} に
 6184: オプション @samp{-k} や @samp{-A} を付けて設定します。
 6185: @code{cvs diff} にも @samp{-k} オプションがあります。
 6186: 例が幾つかありますので、@ref{Binary files} 参照。
 6187: @c The fact that -A is overloaded to mean both reset
 6188: @c sticky options and reset sticky tags/dates is
 6189: @c somewhat questionable.  Perhaps there should be
 6190: @c separate options to reset sticky options (e.g. -k
 6191: @c A") and tags/dates (someone suggested -r HEAD could
 6192: @c do this instead of setting a sticky tag of "HEAD"
 6193: @c as in the status quo but I haven't thought much
 6194: @c about that idea.  Of course -r .reset or something
 6195: @c could be coined if this needs to be a new option).
 6196: @c On the other hand, having -A mean "get things back
 6197: @c into the state after a fresh checkout" has a certain
 6198: @c appeal, and maybe there is no sufficient reason for
 6199: @c creeping featurism in this area.
 6200: 
 6201: 利用できるモードを以下に示します:
 6202: 
 6203: @table @samp
 6204: @item -kkv
 6205: 既定形式でキーワード文字列を生成します。
 6206: 例えば、キーワード @code{Revision} に対して 
 6207: @code{$@asis{}Revision: 5.7 $} が生成されます。
 6208: 
 6209: @item -kkvl
 6210: @samp{-kkv} とほぼ同様ですが、
 6211: 指定されたリビジョンがロックされていれば、
 6212: ロックしている人物の名前を挿入します。
 6213: ロックしている人物名は @code{cvs admin -l} が使用されているときだけ関
 6214: 係があります。
 6215: 
 6216: @item -kk
 6217: キーワード文字列からキーワードのみを生成し、その値は省略されます。
 6218: 例えば、キーワード @code{Revision} に対して、
 6219: @code{$@asis{}Revision: 5.7 $} ではなく、
 6220: @code{$@asis{}Revision$} が生成されます。
 6221: このオプションは、リビジョン間の違いを比較する時、
 6222: キーワードによる違いを無視するのに便利です。
 6223: 
 6224: @item -ko
 6225: そのファイルが格納される前の、
 6226: 古いキーワード文字列を生成します。
 6227: 例えば、キーワード @code{Revision} に対して、
 6228: @code{$@asis{}Revision: 5.7 $} ではなく、
 6229: ファイルが格納された時の文字列である 
 6230: @code{$@asis{}Revision: 1.1 $} が生成されます。
 6231: 
 6232: @item -kb
 6233: @samp{-ko} と同様ですが、
 6234: リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、
 6235: クライアント側のオペレーティングシステムに適した形式へ変換しません。
 6236: 行端にラインフィードのみが使用されるシステム (unix 等) では、
 6237: このオプションは @samp{-ko} と同じです。
 6238: バイナリ・ファイルの詳細情報は @ref{Binary files} 参照。
 6239: 
 6240: @item -kv
 6241: キーワードの値のみを生成します。
 6242: 例えば、キーワード @code{Revision} に対して、
 6243: @code{$@asis{}Revision: 5.7 $} ではなく、
 6244: @code{5.7} が生成されます。
 6245: これは、@code{$@asis{}Revision: $} といった、
 6246: キーワード識別子を除くのが困難な
 6247: プログラミング言語のファイルを生成する時に便利です。
 6248: しかし、キーワード名が削除されてしまうために、
 6249: これ以後はキーワード置換を行うことができません。
 6250: 従って使用には注意が必要です。
 6251: 
 6252: オプション @samp{-kv} は、@code{cvs export} で使用される事が
 6253: 多くあります---@pxref{export}。
 6254: しかしモジュールがバイナリ・ファイルを含む場合は、
 6255: うまく処理できないので使用しない方が賢明です。
 6256: 
 6257: @end table
 6258: 
 6259: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6260: @node Log keyword
 6261: @section キーワード $@asis{}Log$ の問題点
 6262: 
 6263: キーワード @code{$@asis{}Log$} にはちょっと問題があります。
 6264: 開発環境で作業をしているならば、
 6265: キーワード @code{$@asis{}Log$} を使用しなくても、
 6266: @code{cvs log} を使えば同じ情報が簡単に手に入ります。
 6267: いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。
 6268: 
 6269: さらに重要な問題は、枝を幹にマージするときに、
 6270: @sc{rcs} が @code{$@asis{}Log$} の項目をうまく扱えないことです。
 6271: このマージ操作の結果、衝突が起きることがよくあります。
 6272: @c Might want to check whether the CVS implementation
 6273: @c of RCS_merge has this problem the same way rcsmerge
 6274: @c does.  I would assume so....
 6275: 
 6276: またファイル中のログ・メッセージは、@emph{修復}される傾向にあります。
 6277: (綴の間違いやほんとの間違い等)。
 6278: しかしこの結果、
 6279: @code{cvs log} の情報とファイルの中身が一致しないことになります。
 6280: これも問題といえば問題でしょう。
 6281: 
 6282: どうしてもキーワード @code{$@asis{}Log$} を使うのならば、
 6283: ファイルの先頭ではなく、
 6284: ファイルの @emph{最後} に挿入することを推奨します。
 6285: この方法ならば、
 6286: 長い変更メッセージを毎日眺めなくて済みます。
 6287: 
 6288: @c ---------------------------------------------------------------------
 6289: @node Tracking sources
 6290: @chapter サード・パーティーのソースの追っかけ
 6291: @cindex Third-party sources
 6292: @cindex Tracking sources
 6293: 
 6294: @c FIXME: Need discussion of added and removed files.
 6295: @c FIXME: This doesn't really adequately introduce the
 6296: @c concepts of "vendor" and "you".  They don't *have*
 6297: @c to be separate organizations or separate people.
 6298: @c We want a description which is somewhat more based on
 6299: @c the technical issues of which sources go where, but
 6300: @c also with enough examples of how this relates to
 6301: @c relationships like customer-supplier, developer-QA,
 6302: @c maintainer-contributor, or whatever, to make it
 6303: @c seem concrete.
 6304: あなたのサイトに合わせてプログラムを修正した場合、
 6305: そのプログラムの次のリリースにも同じ修正を加えたいでしょう。
 6306: @sc{cvs} を用いてこの作業を自動化することができます。
 6307: 
 6308: @cindex Vendor
 6309: @cindex Vendor branch
 6310: @cindex Branch, vendor-
 6311: @sc{cvs} の用語では、プログラムの開発元を@dfn{ベンダー} 
 6312: (@dfn{vendor}) と呼びます。
 6313: ベンダーの配布物は、
 6314: 修正を加えずに @dfn{ベンダー枝} (@dfn{vendor branch}) という枝に格納します。
 6315: @sc{cvs} はこの為に 1.1.1 という番号を予約しています。
 6316: 
 6317: あなたがソースを修正して格納した場合、
 6318: そのリビジョンは幹に入ります。
 6319: ベンダーから新しいリリースが届いたら、
 6320: それをベンダー枝に加えて、修正を幹にコピーします。
 6321: 
 6322: ベンダー枝を作り、更新するには、
 6323: @code{import} コマンドを使用します。
 6324: 新しいファイルを import すると、
 6325: ベンダー枝に `最初' のリビジョンが作られ、
 6326: @code{checkout} する人は誰でもそのリビジョンを取得します。
 6327: 格納されたローカルな修正は幹に置かれ、
 6328: `最初' のリビジョンが作られます。
 6329: 
 6330: @menu
 6331: * First import::                初めて持ち込む
 6332: * Update imports::              import コマンドで更新する
 6333: * Reverting local changes::     最新のベンダーリリースに戻す
 6334: * Binary files in imports::     バイナリ・ファイルには特別な操作が必要
 6335: * Keywords in imports::         キーワード置換は望ましくない
 6336: * Multiple vendor branches::    複数の場所からソースを取得すると?
 6337: @end menu
 6338: 
 6339: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6340: @node First import
 6341: @section 初めて持ち込む
 6342: @cindex Importing modules
 6343: 
 6344: @c Should mention naming conventions for vendor tags,
 6345: @c release tags, and perhaps directory names.
 6346: まず最初に、@code{import} コマンドを使ってソースを登録します。
 6347: @code{import} コマンドでサード・パーティーの追っかけをする場合には、
 6348: @dfn{ベンダー・タグ} (@dfn{vendor tag}) と
 6349: @dfn{リリース・タグ} (@dfn{release tag}) を用いると良いでしょう。
 6350: @dfn{ベンダー・タグ}は枝のタグ名です 
 6351: (@samp{-b @var{branch}} フラグを使用しなければ、
 6352: 枝のリビジョンは常に 1.1.1 です---@xref{Multiple vendor branches}.)。
 6353: @dfn{リリース・タグ}は特定のリリースを指すタグ名で、
 6354: ここでは @samp{FSF_0_04} とします。
 6355: 
 6356: @c I'm not completely sure this belongs here.  But
 6357: @c we need to say it _somewhere_ reasonably obvious; it
 6358: @c is a common misconception among people first learning CVS
 6359: @code{import} は起動されたディレクトリを変更 @emph{しない} ことに注意
 6360: してください。特に、そのディレクトリが @sc{cvs} の作業ディレクトリとし
 6361: て設定されることはありません。ソースに作業をしたいなら、まずそれを持ち
 6362: 込んで、それから違うディレクトリに取り出してください (@pxref{Getting
 6363: the source})。
 6364: 
 6365: @cindex Wdiff (import example)
 6366: ディレクトリ @file{wdiff-0.04} に @code{wdiff} というプログラムのソー
 6367: スがあるとします。将来に新しいリリースがなされたときでも適用したい個人
 6368: 的な修正を加えようとしています。まず、リポジトリに @code{wdiff} のソー
 6369: スを加えることから始めましょう:
 6370: 
 6371: @example
 6372: $ cd wdiff-0.04
 6373: $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
 6374: @end example
 6375: 
 6376: 上の例では、ベンダー・タグを @samp{FSF_DIST} とし、
 6377: 唯一のリリース・タグを @samp{WDIFF_0_04} としています。
 6378: @c FIXME: Need to say where fsf/wdiff comes from.
 6379: 
 6380: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6381: @node Update imports
 6382: @section import コマンドで更新する
 6383: 
 6384: 新しいリリースのソースが届いたら、
 6385: それを最初と同じく @code{import} コマンドでリポジトリに加えます。
 6386: 違いは、最初と異なるリリース・タグを用いることだけです。
 6387: 
 6388: @example
 6389: $ tar xfz wdiff-0.05.tar.gz
 6390: $ cd wdiff-0.05
 6391: $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
 6392: @end example
 6393: 
 6394: ファイルがローカルな修正を受けてなければ、
 6395: 今加えたものが最初のリビジョンになります。
 6396: ローカルな変更を加えていれば、
 6397: @code{import} コマンドは変更を幹にマージするように警告を出し、
 6398: @samp{checkout -j} を使うように促します。
 6399: 
 6400: @c FIXME: why "wdiff" here and "fsf/wdiff" in the
 6401: @c "import"?  I think the assumption is that one has
 6402: @c "wdiff fsf/wdiff" or some such in modules, but it
 6403: @c would be better to not use modules in this example.
 6404: @example
 6405: $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
 6406: @end example
 6407: 
 6408: @noindent
 6409: このコマンドで @samp{wdiff} の最新のリビジョンが取り出され、
 6410: @samp{yesterday} 以降にベンダー枝 @samp{FSF_DIST} に加えられた変更を、
 6411: 作業コピーにマージします。
 6412: マージの過程で衝突が起きれば、通常の方法で解決して下さい 
 6413: (@pxref{Conflicts example})。
 6414: その後、変更したファイルを格納します。
 6415: 
 6416: 上記の実行例のように日時を使用する場合、
 6417: 一日に一つ以上のリリースを @code{import} しないと仮定しています。
 6418: この仮定に反するならば、次のようにして下さい:
 6419: 
 6420: @example
 6421: $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
 6422: @end example
 6423: 
 6424: @noindent
 6425: 今の例では、上の二つのコマンドは等価です。
 6426: 
 6427: @node Reverting local changes
 6428: @section 最新のベンダーリリースに戻す
 6429: 
 6430: 全てのファイルで `先頭' のリビジョンを変更してベンダー枝に戻すことで
 6431: ローカルの変更を完全に復旧し、最新のベンダーリリースに戻ることができま
 6432: す。例えば、ソースの取り出したコピーを @file{~/work.d/wdiff} に置いて
 6433: いて、そのディレクトリの全てのファイルをベンダーのバージョンに戻したい
 6434: のなら、次のように入力します:
 6435: 
 6436: @example
 6437: $ cd ~/work.d/wdiff
 6438: $ cvs admin -bWDIFF .
 6439: @end example
 6440: 
 6441: @noindent
 6442: @samp{-bWDIFF} は @samp{-b} の後空白を入れないで指定しなければなりませ
 6443: ん。@xref{admin options}.
 6444: 
 6445: @node Binary files in imports
 6446: @section cvs import でバイナリ・ファイルを扱う方法
 6447: 
 6448: @samp{-k} wrapper 機能オプションを使って、どのファイルがバイナリである
 6449: かを教えます。@xref{Wrappers}.
 6450: 
 6451: @node Keywords in imports
 6452: @section cvs import でキーワード置換を扱う方法
 6453: 
 6454: 持ち込んでいるソースにキーワードがある場合があります (@pxref{Keyword
 6455: substitution})。例えば、ベンダーは @sc{cvs} や他の似たキーワード展開構
 6456: 文を使うシステムを使っているかもしれません。既定の方法でファイルを持ち
 6457: 込んだだけでは、ベンダーのキーワード展開があなた自身の @sc{cvs} コピー
 6458: でも行われます。この情報はベンダーから持ち込んだソースの情報であること
 6459: がありますから、ベンダーの展開を維持した方がより便利でしょう。
 6460: 
 6461: ベンダーのキーワード展開を維持するためには、最初にファイルを持ち込むと
 6462: きに @code{cvs import} に @samp{-ko} オプションを付けます。こうすると、
 6463: そのファイルのキーワード展開を完全に止めます。もっと選択的な方法を望む
 6464: 場合は、@code{cvs update} や @code{cvs admin} に適切に @samp{-k} オプ
 6465: ションを使用します。
 6466: @c Supplying -ko to import if the file already existed
 6467: @c has no effect.  Not clear to me whether it should
 6468: @c or not.
 6469: 
 6470: @node Multiple vendor branches
 6471: @section 複数のベンダー枝
 6472: 
 6473: 今までの例はソースを取得しているベンダーは一つだけだと仮定しています。
 6474: いろいろな場所からソースを得るような場合もあります。例えば、多くの違っ
 6475: た人やチームがソフトウェアを修正しているプロジェクトに関係しているとし
 6476: ます。これを扱う方法はいろいろありますが、たくさんのソースツリーが散ら
 6477: ばっていて、とりあえずやりたいことはそれら全てを CVS に放り込んで少な
 6478: くとも一箇所にまとめることだ、ということがあります。
 6479: 
 6480: 複数のベンダーがある状況を扱うために、@code{cvs import} に @samp{-b}
 6481: オプションを指定できます。その引数は持ち込むベンダー枝です。既定値は
 6482: @samp{-b 1.1.1} です。
 6483: 
 6484: 例えば、赤チームと青チームの2つのチームがあり、あなたにソースを送って
 6485: くるとします。赤チームが努力したものを枝 1.1.1 に持ち込んで、ベンダー
 6486: タグ RED を使いたいと思っています。青チームが努力したものは枝 1.1.3 に
 6487: 持ち込んで、ベンダータグ BLUE を使おうとしています。使用するコマンドは
 6488: 以下のようになります。
 6489: 
 6490: @example
 6491: $ cvs import dir RED RED_1-0
 6492: $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
 6493: @end example
 6494: 
 6495: ベンダータグ が @samp{-b} オプションと合わなくても、CVS は発見しないこ
 6496: とに注意してください。例えば、
 6497: 
 6498: @example
 6499: $ cvs import -b 1.1.3 dir RED RED_1-0
 6500: @end example
 6501: 
 6502: @noindent
 6503: 慎重に; この種類の不適当な組合せは混乱や、よりひどいことへの種になりま
 6504: す。不釣合いを指定することでの便利な使用をここでは考え付きません。もし
 6505: そのような使用を発見しても、使わないでください。CVS は将来のリリースで
 6506: はそれをエラーにするでしょう。
 6507: 
 6508: @c Probably should say more about the semantics of
 6509: @c multiple branches.  What about the default branch?
 6510: @c What about joining (perhaps not as useful with
 6511: @c multiple branches, or perhaps it is.  Either way
 6512: @c should be mentioned).
 6513: 
 6514: @c I'm not sure about the best location for this.  In
 6515: @c one sense, it might belong right after we've introduced
 6516: @c CVS's basic version control model, because people need
 6517: @c to figure out builds right away.  The current location
 6518: @c is based on the theory that it kind of akin to the
 6519: @c "Revision management" section.
 6520: @node Builds
 6521: @chapter 構築システムと CVS の関係方法
 6522: @cindex builds
 6523: @cindex make
 6524: 
 6525: 紹介で書かれているように、@sc{cvs} にはソースコードからソフトウェアを
 6526: 構築するためのソフトウェアはありません。この部分は構築システムが
 6527: @sc{cvs} と協調するかもしれない種々の側面を説明します。
 6528: 
 6529: @c Is there a way to discuss this without reference to
 6530: @c tools other than CVS?  I'm not sure there is; I
 6531: @c wouldn't think that people who learn CVS first would
 6532: @c even have this concern.
 6533: @sc{rcs} に慣れている人からの特に多い、よくある質問は、どうすれば構築
 6534: 機構が最新のソースのコピーを手に入れることができるか、ということです。
 6535: @sc{cvs} では2重になります。まず最初に、@sc{cvs} はディレクトリを再帰
 6536: 的に辿ることができますので、各ファイルが最新であることを確認するために 
 6537: @file{Makefile} (もしくは、構築ツールが使う設定ファイルの名前) を修正
 6538: する必要はありません。その代わりに、まず @code{cvs -q update} として、
 6539: それから @code{make} や構築ツールを起動するコマンドを実行するという2つ
 6540: のコマンドだけを使います。2番目に、あなた自身の作業が終わるまで、誰か
 6541: の変更したコピーを取得@emph{したい} と思わないかもしれません。1つの方
 6542: 法はまずソースを更新して、それから実装、構築し、考えていた変更を試して
 6543: からソースを格納する (必要ならまず更新します) というものです。定期的に
 6544: (変更の合間に、さっき書いた方法で) 木全体を更新することで、ソースが十
 6545: 分に新しいことを保証できます。
 6546: 
 6547: @cindex bill of materials
 6548: よくある要求は、どのソースファイルのどのリビジョンが特定の構築に相当す
 6549: るかを記録することです。このような種類の機能は @dfn{bill of materials} 
 6550: などと呼ばれることがあります。@sc{cvs} で実現する最良の方法は 
 6551: @code{tag}コマンドがどのバージョンが与えられた構築に相当するかを記録す
 6552: ることです (@pxref{Tags})。
 6553: 
 6554: @sc{cvs} を一番素直な方法で使うと、それぞれの開発者は特定の構築に使わ
 6555: れるソースツリー全体のコピーを持っています。ソースツリーが小さかったり、
 6556: 開発者が地理的に離れたところにいるのなら、これが好ましい解決方法です。
 6557: 実のところ、大きなプロジェクトを遂行する手段の一つはプロジェクトを小さ
 6558: な分割してコンパイルされるサブシステムに分け、開発者に必要なことは主に
 6559: 作業しているサブシステムだけを取り出すだけにするように、内部でリリース
 6560: する方法を作ることです。
 6561: @c I say subsystem instead of module because they may or
 6562: @c may not use the modules file.
 6563: 
 6564: 別の手段は、開発者にいくつかのファイルのコピーだけの所有をして、他のファ
 6565: イルには中央管理下のソースファイルを見に行くことができるようにする機構
 6566: を設定することです。多くの人は、大部分のオペレーティング・システムにあ
 6567: るシンボリックリンクや、@code{make} の多くのバージョンにある 
 6568: @code{VPATH} 機能を使う様な解決法に到達しました。
 6569: @c two such people are paul@sander.cupertino.ca.us (for
 6570: @c a previous employer)
 6571: @c and gtornblo@senet.abb.se (spicm and related tools),
 6572: @c but as far as I know
 6573: @c no one has nicely packaged or released such a system (or
 6574: @c instructions for constructing one).
 6575: このような種類のものを助けるために設計された構築ツールに Odin というも
 6576: のがあります (@code{ftp://ftp.cs.colorado.edu/pub/distribs/odin} 参照)。
 6577: @c Should we be saying more about Odin?  Or how you use
 6578: @c it with CVS?  Also, the Prime Time Freeware for Unix
 6579: @c disk (see http://www.ptf.com/) has Odin (with a nice
 6580: @c paragraph summarizing it on the web), so that might be a
 6581: @c semi-"official" place to point people.
 6582: @c
 6583: @c Of course, many non-CVS systems have this kind of
 6584: @c functionality, for example OSF's ODE
 6585: @c (http://www.osf.org/ode/) or mk
 6586: @c (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
 6587: @c He has changed providers in the past; a search engine search
 6588: @c for "Peter Ziobrzynski" probably won't get too many
 6589: @c spurious hits :-).  A more stable URL might be
 6590: @c ftp://ftp.uu.net/pub/cmvc/mk).  But I'm not sure
 6591: @c there is any point in mentioning them here unless they
 6592: @c can work with CVS.
 6593: 
 6594: @c ---------------------------------------------------------------------
 6595: @node Special Files
 6596: @chapter 特別なファイル
 6597: 
 6598: @cindex special files
 6599: @cindex device nodes
 6600: @cindex ownership, saving in CVS
 6601: @cindex permissions, saving in CVS
 6602: @cindex hard links
 6603: @cindex symbolic links
 6604: 
 6605: 普通の環境では、CVS は普通のファイルでのみ動作します。プロジェクトの全
 6606: てのファイルは永続すると仮定されています。開き、読み込み、閉じるという
 6607: 操作などが可能でなければなりません。また、CVS はファイルの使用許可と所
 6608: 有権を無視します。そのような問題はインストール時に開発者によって解決さ
 6609: れる必要があります。言い換えれば、デバイスを "格納" することは不可能で
 6610: す。デバイスファイルを開けなければ、CVS はそれを扱うことを拒否します。
 6611: ファイルはリポジトリの取り扱い中にも所有権や使用許可を失います。
 6612: 
 6613: リポジトリで設定変数 @code{PreservePermissions} (@pxref{config}) が設
 6614: 定されていると、CVS は以下のファイルの特性をリポジトリに記録します:
 6615: 
 6616: @itemize @bullet
 6617: @item 使用者とグループの所有権
 6618: @item 使用許可
 6619: @item 主・副デバイス番号
 6620: @item シンボリックリンク
 6621: @item ハードリンク機構
 6622: @end itemize
 6623: 
 6624: @code{PreservePermissions} オプションを使うと CVS の振舞いにいくつか影
 6625: 響します。まず、CVS で使用可能になった新しい操作の中に、全ての使用者に
 6626: は使用可能でないものができます。特に、ファイルの所有権と特別なファイル
 6627: の特性とはスーパーユーザにだけ変更できるものでしょう。ですから、
 6628: @code{PreservePermissions} 設定変数が設定されていると、使用者は CVS の
 6629: 操作をうるために `root' になる必要があるでしょう。
 6630: 
 6631: @code{PreservePermissions} が使用されていると、CVS の操作の中には 
 6632: (@samp{cvs status} のように) ファイルのハードリンク構造を認識せず、合っ
 6633: ていないハードリンクに関して見せかけの警告を出力します。これは CVS の
 6634: 内部構造がハードリンクに必要なデータ全てを集めるのを難しくしており、そ
 6635: のために不正確なデータでファイルの衝突を調べるからです。
 6636: 
 6637: CVS はファイルの内容が変更されたときのみ、それが変更されたと考えること
 6638: による、より微妙な違いがあります (特に、作業ファイルの修正時刻がリポジ
 6639: トリのそのファイルと合わないとき)。ですから、使用許可、所有権、ハード
 6640: リンクが変わったり、デバイスの主、副番号が変わったとしても、CVS は報告
 6641: しません。そのような変更をリポジトリに格納するためには、@samp{cvs
 6642: commit -f} で格納を強制する必要があります。これは、ファイルの使用許可
 6643: が変わっていて、リポジトリのファイルが作業コピーより新しいと、
 6644: @samp{cvs update} の実行は、知らない間に作業コピーの使用許可を変更して
 6645: いるということでもあります。
 6646: 
 6647: CVS リポジトリでのハードリンクの変更は特に慎重な扱いが必要です。
 6648: @file{foo} がファイル @file{old} にリンクされていたけれど、後でファイ
 6649: ル @file{new} にリンクされ直したとしましょう。@file{foo}, @file{old},
 6650: @file{new} は全て中のリンクパターンは変更されているけれど、@file{foo} 
 6651: と @file{new} だけが修正されていて、そのために @file{old} は格納の候補
 6652: としてみなされない、という変な状況になることがあります。このような方法
 6653: により整合しない結果は非常に簡単に作られます。ですから、ハードリンクを
 6654: リポジトリに保存するのが重要なときは、賢明な動作方法は最後の格納からリ
 6655: ンクや状態が変わったファイル全てに @code{touch} することです。実際、複
 6656: 雑なハードリンク構造のディレクトリを格納する前には @code{touch *} をす
 6657: るのが賢いかもしれません。
 6658: 
 6659: おそらく明らかである理由により、普通のファイルだけがマージできるという
 6660: ことを書いておくのも意味のあることでしょう。もし @samp{cvs update} や 
 6661: @samp{cvs checkout -j} がシンボリックリンクを普通のファイルとマージし
 6662: ようとしたり、2つのデバイスファイルが違った種類のデバイスのためのもの
 6663: であったりすると、CVS は衝突を報告して、マージの実行を拒否します。また、
 6664: テキストがないファイル上でのテキスト比較は無意味なので、@samp{cvs
 6665: diff} はこれらのファイル間の相違を報告しません。
 6666: 
 6667: @code{PreservePermissions} 機能はクライアント/サーバの @sc{cvs} では動
 6668: 作しません。別の制限に、ハードリンクは同じディレクトリの他のファイルへ
 6669: のリンクでなければならない、というものがあります。ディレクトリをまたい
 6670: だハードリンクは使用できません。
 6671: 
 6672: @c ---------------------------------------------------------------------
 6673: @node CVS commands
 6674: @appendix CVS のコマンド便覧
 6675: 
 6676: この付録は @sc{cvs} コマンドの全体構造の説明をし、いくつかのコマンドは
 6677: 詳しく説明します (他のものは別のところで説明されています。@sc{cvs} コ
 6678: マンドの簡単な便覧は、@pxref{Invoking CVS})。
 6679: @c The idea is that we want to move the commands which
 6680: @c are described here into the main body of the manual,
 6681: @c in the process reorganizing the manual to be
 6682: @c organized around what the user wants to do, not
 6683: @c organized around CVS commands.
 6684: @c
 6685: @c Note that many users do expect a manual which is
 6686: @c organized by command.  At least some users do.
 6687: @c One good addition to the "organized by command"
 6688: @c section (if any) would be "see also" links.
 6689: @c The awk manual might be a good example; it has a
 6690: @c reference manual which is more verbose than Invoking
 6691: @c CVS but probably somewhat less verbose than CVS
 6692: @c Commands.
 6693: 
 6694: @menu
 6695: * Structure::                   CVS コマンド構造の全て
 6696: * Exit status::                 CVS の成功か失敗を示す
 6697: * ~/.cvsrc::                    既定オプションと ~/.cvsrc ファイル
 6698: * Global options::              cvs_command の左側に付けるオプション
 6699: * Common options::              cvs_command の右側に付けるオプション
 6700: * admin::                       管理
 6701: * checkout::                    編集の為にソースを取り出す
 6702: * commit::                      ファイルをリポジトリに格納する
 6703: * diff::                        リビジョン間の差分を見る
 6704: * export::                      CVS からソースを取り出す, checkout に類似
 6705: * history::                     ファイルと使用者の状態を表示
 6706: * import::                      CVS にソースを取り込む, ベンダー枝を使用
 6707: * log::                         ファイルのログ情報を表示
 6708: * rdiff::                       リリース間の `patch' 形式の差分
 6709: * release::                     ディレクトリの放棄を表明する
 6710: * update::                      作業コピーをリポジトリと一致させる
 6711: @end menu
 6712: 
 6713: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6714: @node Structure
 6715: @appendixsec CVS コマンド構造の全て
 6716: @cindex Structure
 6717: @cindex CVS command structure
 6718: @cindex Command structure
 6719: @cindex Format of CVS commands
 6720: 
 6721: @sc{cvs} のコマンド全体の書式を示します:
 6722: 
 6723: @example
 6724: cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
 6725: @end example
 6726: 
 6727: @table @code
 6728: @item cvs
 6729: @sc{cvs} プログラムの名前です。
 6730: 
 6731: @item cvs_options
 6732: @sc{cvs} のサブコマンド全体に適用されるオプションです。以下で説明され
 6733: ています。
 6734: 
 6735: @item cvs_command
 6736: いくつかの違ったサブコマンドの一つです。
 6737: 幾つかのコマンドでは別名が使用できます。別名はそのコマンドの便覧マニュ
 6738: アルのところで書かれています。
 6739: 次の二つの場合にだけ @samp{cvs_command} を省略できます。
 6740: つまり @samp{cvs -H} として利用可能なコマンドのリストを得る場合か、
 6741: @samp{cvs -v} として @sc{cvs} 自身のバージョン情報を得る場合です。
 6742: 
 6743: @item command_options
 6744: コマンド固有のオプションです。
 6745: 
 6746: @item command_args
 6747: コマンドの引数です。
 6748: @end table
 6749: 
 6750: 不幸な事に、
 6751: @code{cvs_options} と @code{command_options} の間で幾つか混乱があります。
 6752: @samp{-l} は @code{cvs_option} として使われたときいくつかのコマンドに
 6753: 影響します。@code{command_option} として使されたときは、より多くのコマ
 6754: ンドで意味を持ちます。つまり、上の分類をあまり深刻に受けとめないでくだ
 6755: さい。代わりに文書を見るようにしましょう。
 6756: 
 6757: @node Exit status
 6758: @appendixsec CVS の終了状態
 6759: @cindex exit status, of CVS
 6760: 
 6761: CVS はそれ呼んだ環境に @dfn{終了状態} (@dfn{exit status}) を設定するこ
 6762: とで、成功したか失敗したかを示すことができます。
 6763: 終了状態を調べる正確な方法はオペレーティング・システムごとに異なります。
 6764: 例えば、unix のシェルスクリプトでは、最後のコマンドが成功終了状態を返
 6765: せば変数 @samp{$?} は0で、終了状態が失敗を示していれば、0より大きくな
 6766: ります。
 6767: 
 6768: CVS が成功した場合は、成功状態を返します。エラーがあれば、エラーメッセー
 6769: ジを印字して、失敗状態を返します。@code{cvs diff} コマンドはこの例外で
 6770: す。違いが見つからなければ成功状態を返し、違いが見つかるか、エラーが発
 6771: 生したときに失敗状態を返します。この振舞いはエラーの検知には良くないの
 6772: で、将来では @code{cvs diff} が他の @sc{cvs} コマンドと同じように振舞
 6773: うように変更される可能性があります。
 6774: @c It might seem like checking whether cvs -q diff
 6775: @c produces empty or non-empty output can tell whether
 6776: @c there were differences or not.  But it seems like
 6777: @c there are cases with output but no differences
 6778: @c (testsuite basica-8b).  It is not clear to me how
 6779: @c useful it is for a script to be able to check
 6780: @c whether there were differences.
 6781: @c FIXCVS? In previous versions of CVS, cvs diff
 6782: @c returned 0 for no differences, 1 for differences, or
 6783: @c 2 for errors.  Is this behavior worth trying to
 6784: @c bring back (but what does it mean for VMS?)?
 6785: 
 6786: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6787: @node ~/.cvsrc
 6788: @appendixsec 既定オプションと ~/.cvsrc ファイル
 6789: @cindex .cvsrc file
 6790: @cindex option defaults
 6791: 
 6792: よく使用する @code{command_option} が幾つかあり、
 6793: そのオプションを必ず指定するように設定したいことがあります。
 6794: 例えば (実際に .cvsrc を実装した要因の一つですが) 
 6795: 多くの人には @samp{diff} の既定出力は大変読みにくく、
 6796: context 形式か unidiff 形式のほうが遥かに分かりやすいでしょう。
 6797: 
 6798: シェル・スクリプトやエイリアスに頼らなくても、
 6799: @file{~/.cvsrc} ファイルを用いて @code{cvs_commands} 各々に
 6800: 既定のオプションを加えることができます。
 6801: 
 6802: @file{~/.cvsrc} の書式は簡単です。
 6803: 実行された @code{cvs_command} と同じ名前で始まる行が検索されます。
 6804: 一致した行を発見したら、行の残りの部分をオプションに分割し (空白のとこ
 6805: ろで)、
 6806: コマンド行からのオプションを与える@emph{前に}、
 6807: 得られたオプションをコマンドの引数として与えます。
 6808: コマンドが別名を持つ場合 (例えば、@code{checkout} と @code{co})、
 6809: コマンド行で使われるものとは限りませんが、公的な名前がファイルとの
 6810: 合致時に使用されます。
 6811: 例えば @file{~/.cvsrc} の内容が次の様であった場合:
 6812: 
 6813: @example
 6814: log -N
 6815: diff -u
 6816: update -P
 6817: checkout -P
 6818: @end example
 6819: 
 6820: @noindent
 6821: @samp{cvs co foo} も、コマンド @samp{cvs checkout foo} と同様に 
 6822: @samp{-P} が引数として与えられます。
 6823: 
 6824: 上記の例では @samp{cvs diff foobar} の出力は unidiff 形式になります。
 6825: @samp{cvs diff -c foobar} だと指定通り context 形式になります。
 6826: @samp{diff} には "古い" 形式で出力するためのオプションが無いため、
 6827: "古い" 形式を使いたい場合には少し面倒ですが 
 6828: @samp{cvs -f diff foobar} とする必要があります。
 6829: 
 6830: コマンド名の部分に @code{cvs} と記述すれば、
 6831: 広域オプションを指定することができます (@pxref{Global options})。
 6832: 例えば @file{.cvsrc} 中の以下の行は、
 6833: 
 6834: @example
 6835: cvs -z6
 6836: @end example
 6837: 
 6838: @sc{cvs} が圧縮レベル 6 を用いるように指定しています。
 6839: 
 6840: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6841: @node Global options
 6842: @appendixsec 広域オプション
 6843: @cindex Options, global
 6844: @cindex Global options
 6845: @cindex Left-hand options
 6846: 
 6847: @samp{cvs_options} (@samp{cvs_command} の左側に与えられる) 
 6848: として利用できるものを以下に示します:
 6849: 
 6850: @table @code
 6851: @item --allow-root=@var{rootdir}
 6852: 正しい @sc{cvsroot} ディレクトリを指定します。@ref{Password
 6853: authentication server} 参照。
 6854: 
 6855: @cindex authentication, stream
 6856: @cindex stream authentication
 6857: @item -a
 6858: クライアントとサーバの全ての通信を認証します。@sc{cvs} クライアントで
 6859: だけ意味をもちます。これを書いている時点では、GSSAPI 接続を行う場合だ
 6860: けに実装されています (@pxref{GSSAPI authenticated})。認証は流れている 
 6861: @sc{tcp} 接続のハイジャックというような攻撃から身を守ることができます。
 6862: 認証を使用しても暗号化は使用されません。
 6863: 
 6864: @cindex RCSBIN, overriding
 6865: @cindex Overriding RCSBIN
 6866: @item -b @var{bindir}
 6867: @sc{cvs} 1.9.18 以前では、これは @sc{rcs} プログラムが @var{bindir} ディ
 6868: レクトリにあることを指定していました。現在のバージョンの @sc{cvs} は 
 6869: @sc{rcs} プログラムを実行しません。互換性のためにこのオプションがあり
 6870: ますが、指定しても何もしません。
 6871: 
 6872: @cindex TMPDIR, overriding
 6873: @cindex Overriding TMPDIR
 6874: @item -T @var{tempdir}
 6875: 一時ファイルが置かれるディレクトリを @var{tempdir} とします。
 6876: 環境変数 @code{$TMPDIR} の設定や、
 6877: コンパイル時のディレクトリ設定よりも優先されます。
 6878: この値は絶対パス名で指定して下さい。
 6879: 
 6880: @cindex CVSROOT, overriding
 6881: @cindex Overriding CVSROOT
 6882: @item -d @var{cvs_root_directory}
 6883: リポジトリのルートディレクトリのパス名を @var{cvs_root_directory} とし
 6884: ます。
 6885: 環境変数 @code{$CVSROOT} よりも優先します。@xref{Repository}.
 6886: 
 6887: @cindex EDITOR, overriding
 6888: @cindex Overriding EDITOR
 6889: @item -e @var{editor}
 6890: リビジョンのログ情報の入力に @var{editor} を使用します。
 6891: 環境変数 @code{$CVSEDITOR} や @code{$EDITOR} よりも優先します。
 6892: 詳しい情報は @ref{Committing your changes} 参照。
 6893: 
 6894: @item -f
 6895: @file{~/.cvsrc} を読みません。
 6896: このオプションが最も良く使われるのは、
 6897: @sc{cvs} のオプション設定に直交性がない時です。
 6898: 例えば @samp{cvs log} のオプション @samp{-N} (タグの表示を抑制します)
 6899: に対応する表示を行なうオプションはありません。
 6900: 従って、@file{~/.cvsrc} の @samp{log} エントリに @samp{-N} があったとき、
 6901: タグを表示するには @samp{-f} を使用する他ありません。
 6902: 
 6903: @item -H
 6904: @itemx --help
 6905: 指定された @samp{cvs_command} の使用法を表示します 
 6906: (コマンドが実際に実行されることはありません)。
 6907: コマンド名を指定しない場合には、
 6908: @samp{cvs -H} は他のヘルプオプションの一覧などを含む、@sc{cvs} の全体
 6909: のヘルプを表示します。
 6910: @c It seems to me it is better to document it this way
 6911: @c rather than trying to update this documentation
 6912: @c every time that we add a --help-foo option.  But
 6913: @c perhaps that is confusing...
 6914: 
 6915: @item -l
 6916: @samp{cvs_command} をコマンド履歴に記録しません 
 6917: (しかしコマンドは実行されます)。
 6918: コマンド履歴の情報は @xref{history}.
 6919: 
 6920: @cindex Read-only mode
 6921: @item -n
 6922: ファイルを更新しません。
 6923: @samp{cvs_command} を実行した場合の表示だけが行なわれます。
 6924: 既存のファイルを削除, 更新, マージしたり、
 6925: 新しいファイルを作成することはありません。
 6926: 
 6927: @sc{cvs} は必ずしも @samp{-n} を付けなかったときと全く同じ出力をするわ
 6928: けではないことに注意してください。ときどき、出力が同じ場合がありますが、
 6929: 他の場合では、@sc{cvs} は正確に同じ出力をするために必要な実行を飛ばし
 6930: ます。
 6931: 
 6932: @item -Q
 6933: コマンドの出力が完全に抑止され、
 6934: 重大な問題が発生した場合にのみ出力が行なわれます。
 6935: 
 6936: @item -q
 6937: コマンドの出力を減らします。
 6938: 再帰的にサブディレクトリを辿る時の報告などの補助情報は抑止されます。
 6939: 
 6940: @cindex read-only files, and -r
 6941: @item -r
 6942: 新たな作業ファイルを読み込み専用にします。
 6943: 環境変数 @code{$CVSREAD} を設定するのと同じ効果があります 
 6944: (@pxref{Environment variables})。
 6945: 既定では、そのファイルが監視されてない限り作業ファイルへの書き込みが許
 6946: 可されます (@pxref{Watches})。
 6947: 
 6948: @item -s @var{variable}=@var{value}
 6949: ユーザ変数を設定します (@pxref{Variables})。
 6950: 
 6951: @cindex Trace
 6952: @item -t
 6953: プログラムの実行状態をトレースします。
 6954: @sc{cvs} が実行する各ステップの情報を表示します。
 6955: @samp{-n} オプションと共に使用し、
 6956: 不慣れなコマンドの潜在的な影響を調べるのに便利です。
 6957: 
 6958: @item -v
 6959: @item --version
 6960: @sc{cvs} のバージョンと著作権情報を表示します。
 6961: 
 6962: @cindex CVSREAD, overriding
 6963: @cindex Overriding CVSREAD
 6964: @item -w
 6965: 新しい作業ファイルを読み書き可能にします。
 6966: 環境変数 @code{$CVSREAD} の設定を無効にします。
 6967: @code{$CVSREAD} が設定されておらず、
 6968: @samp{-r} オプションも無い場合には、
 6969: 作成されるファイルは読み書き可能とされます。
 6970: @c Note that -w only overrides -r and CVSREAD; it has
 6971: @c no effect on files which are readonly because of
 6972: @c "cvs watch on".  My guess is that is the way it
 6973: @c should be (or should "cvs -w get" on a watched file
 6974: @c be the same as a get and a cvs edit?), but I'm not
 6975: @c completely sure whether to document it this way.
 6976: 
 6977: @cindex encryption
 6978: @item -x
 6979: クライアントとサーバ間の全ての通信を暗号化します。これは @sc{cvs} クラ
 6980: イアントでだけ意味を持ち、また現時点では GSSAPI 接続を用いる場合 
 6981: (@pxref{GSSAPI authenticated}) かケルベロス接続 (@pxref{Kerberos
 6982: authenticated}) を用いる場合にしか実装されていません。暗号化を使用する
 6983: ということは送信されるメッセージも認証されるということです。既定状態で
 6984: は暗号化機能は使用できません。特別に @file{--enable-encryption} を指定
 6985: して @sc{cvs} を構築する必要があります。
 6986: 
 6987: @item -z @var{gzip-level}
 6988: 圧縮レベルを設定します。
 6989: @sc{cvs} クライアントでだけ意味を持ちます。
 6990: 
 6991: @end table
 6992: 
 6993: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 6994: @node Common options
 6995: @appendixsec 共通のコマンド・オプション
 6996: @cindex Common options
 6997: @cindex Right-hand options
 6998: 
 6999: ここでは、複数の @sc{cvs} コマンドで共通に使用できる 
 7000: @samp{command_options} について説明します。
 7001: これらのオプションは、
 7002: 必ず @samp{cvs_command} の右側に付けられます。
 7003: 以下に示すオプションは、全てのコマンドで使えるわけではありません。
 7004: 各オプションは、それが意味をなすコマンドにおいてのみ使用可能です。
 7005: しかし以下のオプションを持つコマンドがあるならば、
 7006: そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。
 7007: (各コマンドの固有オプションのほとんどは、
 7008: 他の @sc{cvs} コマンドのものとは異なる意味を持っています。)
 7009: 
 7010:  @strong{警告:} @samp{history} コマンドは例外です。このコマンドには、
 7011: ここに示す標準オプションと重複する固有オプションが多くあります。
 7012: 
 7013: @table @code
 7014: @cindex Dates
 7015: @cindex Time
 7016: @cindex Specifying dates
 7017: @item -D @var{date_spec}
 7018: @var{date_spec} 以前のリビジョンのうち、最新のものを使用します。
 7019: @var{date_spec} には、過去の日付を示すものを一つだけ指定します。
 7020: 
 7021: このオプションを用いて作業ファイルを取り出すと、
 7022: 指定した日付が@dfn{貼り付け}られます。
 7023: つまり @samp{-D} オプションの引数が記録され、
 7024: これ以後の @code{update} の際に同じ日付が用いられます 
 7025: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 7026: @samp{-D} は以下のコマンドで利用できます:
 7027: @code{checkout}, @code{diff}, @code{export}, @code{history},
 7028: @code{rdiff}, @code{rtag}, @code{update}.
 7029: (@code{history} コマンドはこのオプションを少し違った方法で使用します。
 7030: @pxref{history options}).
 7031: 
 7032: @c What other formats should we accept?  I don't want
 7033: @c to start accepting a whole mess of non-standard
 7034: @c new formats (there are a lot which are in wide use in
 7035: @c one context or another), but practicality does
 7036: @c dictate some level of flexibility.
 7037: @c * POSIX.2 (e.g. touch, ls output, date) and other
 7038: @c POSIX and/or de facto unix standards (e.g. at).  The
 7039: @c practice here is too inconsistent to be of any use.
 7040: @c * VMS dates.  This is not a formal standard, but
 7041: @c there is a published specification (see SYS$ASCTIM
 7042: @c and SYS$BINTIM in the _VMS System Services Reference
 7043: @c Manual_), it is implemented consistently in VMS
 7044: @c utilities, and VMS users will expect CVS running on
 7045: @c VMS to support this format (and if we're going to do
 7046: @c that, better to make CVS support it on all
 7047: @c platforms.  Maybe).
 7048: @c
 7049: @c NOTE: The tar manual has some documentation for
 7050: @c getdate.y (just for our info; we don't want to
 7051: @c attempt to document all the formats accepted by
 7052: @c getdate.y).
 7053: @c
 7054: @c One more note: In output, CVS should consistently
 7055: @c use one date format, and that format should be one that
 7056: @c it accepts in input as well.  The former isn't
 7057: @c really true (see survey below), and I'm not
 7058: @c sure that either of those formats is accepted in
 7059: @c input.
 7060: @c
 7061: @c cvs log
 7062: @c   current 1996/01/02 13:45:31
 7063: @c   Internet 02 Jan 1996 13:45:31 UT
 7064: @c   ISO 1996-01-02 13:45:31
 7065: @c cvs ann
 7066: @c   current 02-Jan-96
 7067: @c   Internet-like 02 Jan 96
 7068: @c   ISO 96-01-02
 7069: @c cvs status
 7070: @c   current Tue Jun 11 02:54:53 1996
 7071: @c   Internet [Tue,] 11 Jun 1996 02:54:53
 7072: @c   ISO 1996-06-11 02:54:53
 7073: @c   note: date possibly should be omitted entirely for
 7074: @c   other reasons.
 7075: @c cvs editors
 7076: @c   current Tue Jun 11 02:54:53 1996 GMT
 7077: @c cvs history
 7078: @c   current 06/11 02:54 +0000
 7079: @c any others?
 7080: @c There is a good chance the proper solution has to
 7081: @c involve at least some level of letting the user
 7082: @c decide which format (with the default being the
 7083: @c formats CVS has always used; changing these might be
 7084: @c _very_ disruptive since scripts may very well be
 7085: @c parsing them).
 7086: @c
 7087: @c Another random bit of prior art concerning dates is
 7088: @c the strptime function which takes templates such as
 7089: @c "%m/%d/%y", and apparent a variant of getdate()
 7090: @c which also honors them.  See
 7091: @c X/Open CAE Specification, System Interfaces and
 7092: @c Headers Issue 4, Version 2 (September 1994), in the
 7093: @c entry for getdate() on page 231
 7094: 
 7095: @cindex timezone, in input
 7096: @cindex zone, time, in input
 7097: @sc{cvs} では、様々な形式で日付を指定できます。
 7098: 最も標準的なものは (International Standards Organization による) 
 7099: ISO8601 と (RFC 822 で規定され、RFC1123 で修正された) Internet e-mail
 7100: の標準です。
 7101: 
 7102: @c Probably should be doing more to spell out just what
 7103: @c the rules are, rather than just giving examples.
 7104: @c But I want to keep this simple too.
 7105: @c So I don't know....
 7106: @c A few specific issues: (1) Maybe should reassure
 7107: @c people that years after 2000
 7108: @c work (they are in the testsuite, so they do indeed
 7109: @c work).  (2) What do two digit years
 7110: @c mean?  Where do we accept them?  (3) Local times can
 7111: @c be ambiguous or nonexistent if they fall during the
 7112: @c hour when daylight savings time goes into or out of
 7113: @c effect.  Pretty obscure, so I'm not at all sure we
 7114: @c should be documenting the behavior in that case.
 7115: ISO8601 はいろんな異種があります。すこし例を挙げます:
 7116: 
 7117: @example
 7118: 1972-09-24
 7119: 1972-09-24 20:05
 7120: @end example
 7121: @c I doubt we really accept all ISO8601 format dates
 7122: @c (for example, decimal hours like 1972-09-24 20,2)
 7123: @c I'm not sure we should, many of them are pretty
 7124: @c bizarre and it has lots of gratuitous multiple ways
 7125: @c to specify the same thing.
 7126: 
 7127: ISO8601 の日付様式にはいろいろなものがあり、CVS はそれらの多くを受け付
 7128: けますが、おそらくながーい話し@emph{全部}を聞きたいとは思わないでしょ
 7129: う :-)。
 7130: 
 7131: @c Citing a URL here is kind of problematic given how
 7132: @c much they change and people who have old versions of
 7133: @c this manual, but in case we want to reinstate an
 7134: @c ISO8601 URL, a few are:
 7135: @c http://www.saqqara.demon.co.uk/datefmt.htm
 7136: @c http://www.cl.cam.ac.uk/~mgk25/iso-time.html
 7137: @c Citing some other ISO8601 source is probably even
 7138: @c worse :-).
 7139: 
 7140: Internet e-mail で使用が認められている日付に加えて、
 7141: @sc{cvs} では、いくつかのフィールドが省略されたものも使えます。
 7142: 例えば、以下のようなものです:
 7143: @c FIXME: Need to figure out better, and document,
 7144: @c what we want to allow the user to omit.
 7145: @c NOTE: "omit" does not imply "reorder".
 7146: @c FIXME: Need to cite a web page describing how to get
 7147: @c RFC's.
 7148: 
 7149: @example
 7150: 24 Sep 1972 20:05
 7151: 24 Sep
 7152: @end example
 7153: 
 7154: 特定の標準時が指定されていない場合は、日付はローカルの標準時として解釈
 7155: されます。
 7156: 
 7157: この2つの書式の使用が好まれます。しかし、@sc{cvs} は今は他の日付の書式
 7158: を幅広く受け付けます。それらはここでは故意に詳しくは説明されておらず、
 7159: @sc{cvs} の将来のバージョンはそれら全ては受け付けないかもしれません。
 7160: @c We should document and testsuite "now" and
 7161: @c "yesterday".  "now" is mentioned in the FAQ and
 7162: @c "yesterday" is mentioned in this document (and the
 7163: @c message from "cvs import" suggesting a merge
 7164: @c command).  What else?  Probably some/all of the "3
 7165: @c weeks ago" family.
 7166: @c
 7167: @c Maybe at
 7168: @c some point have CVS start give warnings on "unofficial"
 7169: @c formats (many of which might be typos or user
 7170: @c misunderstandings, and/or formats people never/rarely
 7171: @c use to specify dates)?
 7172: 
 7173: そのような書式の中に
 7174: @code{@var{月}/@var{日}/@var{年}}.  というものがあります。
 7175: これは月と日が逆の順番になっているものに慣れている人を混乱させます。
 7176: @samp{1/4/96} は1月4日であり、4月1日ではありません。
 7177: 
 7178: シェルは空白を引数の区切りにするので、
 7179: @samp{-D} の引数を引用符で囲むのを忘れてはいけません。
 7180: @samp{-D} オプションを付けたコマンド行は、次の様になるでしょう:
 7181: 
 7182: @example
 7183: $ cvs diff -D "1 hour ago" cvs.texinfo
 7184: @end example
 7185: 
 7186: @cindex Forcing a tag match
 7187: @item -f
 7188: 日付やタグ名を指定して @sc{cvs} コマンドを用いた場合、
 7189: そのタグ名を持たない (その時には存在しなかった) ファイルは、
 7190: 普通は無視されます。
 7191: タグでも日付でも引っ掛からなかったファイルを復元したい場合に、
 7192: @samp{-f} オプションを使用します 
 7193: (そのファイルの最新のリビジョンが取り出されます)。
 7194: 
 7195: @need 800
 7196: @samp{-f} は以下のコマンドで利用できます: 
 7197: @code{annotate}, @code{checkout}, 
 7198: @code{export}, @code{rdiff}, @code{rtag}, @code{update}.
 7199: 
 7200: @strong{警告:} @code{commit} と @code{remove} コマンドにも @samp{-f} 
 7201: オプションがありますが、異なる動作をします。@xref{commit options}, 
 7202: @ref{Removing files} 参照。
 7203: 
 7204: @item -k @var{kflag}
 7205: 既定のキーワード置換モードを変更します。
 7206: @var{kflag} の詳細は @ref{Substitution modes} 参照。
 7207: 
 7208: このオプションを用いて作業ファイルを取り出すと、
 7209: @var{kflag} が@dfn{貼り付け}られます。
 7210: つまり、このオプションを @code{checkout} や @code{update} コマンドに
 7211: 用いた場合、@sc{cvs} は指定した @var{kflag} をそのファイルに結合します。
 7212: これ以後、同ファイルに対する @code{update} コマンドには 
 7213: @var{kflag} が使用され続けます。
 7214: この効果は別の指定を行なうまで止みません。
 7215: 
 7216: @samp{-k} オプションは以下のコマンドで利用できます: @code{add}, 
 7217: @code{checkout}, @code{diff}, @code{import}, @code{update}.
 7218: 
 7219: @item -l
 7220: Local の頭文字です。再帰的にサブディレクトリを辿らず、
 7221: カレントディレクトリでのみコマンドを実行します。
 7222: 
 7223: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7224: @samp{cvs -l} と混同しないようにして下さい。
 7225: 
 7226: 以下のコマンドで利用できます: @code{annotate}, @code{checkout},
 7227: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7228: @code{export}, @code{log}, @code{rdiff}, @code{remove}, @code{rtag},
 7229: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7230: and @code{watchers}.
 7231: 
 7232: @cindex Editor, avoiding invocation of
 7233: @cindex Avoiding editor invocation
 7234: @item -m @var{message}
 7235: @item -m @var{message}
 7236: エディタを起動せず、ログ情報を @var{message} に記述します。
 7237: 
 7238: 以下のコマンドで利用できます: @code{add}, 
 7239: @code{commit}, @code{import}.
 7240: 
 7241: @item -n
 7242: @code{checkout}/@code{commit}/@code{rtag} コマンド実行時に、
 7243: 常には実行されるプログラムを実行しません。
 7244: 各コマンド実行時のプログラムは、
 7245: 管理用ファイル @file{modules} に記述されます 
 7246: (@pxref{modules})。
 7247: つまり、このオプションは @file{modules} の記述を無効にします。
 7248: 
 7249: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7250: @samp{cvs -n} と混同しないようにして下さい。
 7251: 
 7252: 以下のコマンドで利用できます:
 7253: @code{checkout}, @code{commit}, @code{export}, 
 7254: @code{rtag}.
 7255: 
 7256: @item -P
 7257: 空のディレクトリを削除 (prune) します。@ref{Removing directories} 参照。
 7258: 
 7259: @item -p
 7260: リポジトリから取得したファイルを、カレントディレクトリに置かず、
 7261: 標準出力に送り (pipe) ます。
 7262: 
 7263: 以下のコマンドで利用できます: @code{checkout}, @code{update}.
 7264: 
 7265: @item -R
 7266: 再帰的にディレクトリを辿って実行します。これは指定しなくても実行されま
 7267: す。
 7268: 
 7269: 以下のコマンドで使用可能です: @code{annotate}, @code{checkout},
 7270: @code{commit}, @code{diff}, @code{edit}, @code{editors},
 7271: @code{export}, @code{rdiff}, @code{remove}, @code{rtag},
 7272: @code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
 7273: @code{watchers}.
 7274: 
 7275: @item -r @var{tag}
 7276: @cindex HEAD, special tag
 7277: @cindex BASE, special tag
 7278: 既定の@dfn{先頭} (@dfn{head}) リビジョンの代りに、
 7279: 引数 @var{tag} で指定されたリビジョンを使用します。
 7280: @code{tag} か @code{rtag} コマンドで任意に定義されたタグの他に、
 7281: 二つの特別なタグ @samp{HEAD} と @samp{BASE} が常に利用できます。
 7282: @samp{HEAD} は、リポジトリにある最新のリビジョンを参照します。
 7283: @samp{BASE} は、作業コピーの由来となるリビジョンを参照します。
 7284: 
 7285: @c FIXME: What does HEAD really mean?  I believe that
 7286: @c the current answer is the head of the default branch
 7287: @c for all cvs commands except diff.  For diff, it
 7288: @c seems to be (a) the head of the trunk (or the default
 7289: @c branch?) if there is no sticky tag, (b) the head of the
 7290: @c branch for the sticky tag, if there is a sticky tag.
 7291: @c (b) is ugly as it differs
 7292: @c from what HEAD means for other commands, but people
 7293: @c and/or scripts are quite possibly used to it.
 7294: @c See "head" tests in sanity.sh.
 7295: @c Probably the best fix is to introduce two new
 7296: @c special tags, ".thead" for the head of the trunk,
 7297: @c and ".bhead" for the head of the current branch.
 7298: @c Then deprecate HEAD.  This has the advantage of
 7299: @c not suprising people with a change to HEAD, and a
 7300: @c side benefit of also phasing out the poorly-named
 7301: @c HEAD (see discussion of reserved tag names in node
 7302: @c "Tags").  Of course, .thead and .bhead should be
 7303: @c carefully implemented (with the implementation the
 7304: @c same for "diff" as for everyone else), test cases
 7305: @c written (similar to the ones in "head"), new tests
 7306: @c cases written for things like default branches, &c.
 7307: 
 7308: タグを指定して @code{checkout} や @code{update} コマンドを実行し、
 7309: 自分の作業ファイルを作った場合、そのタグは貼り付けられます。
 7310: つまりこのタグが記録され、以後他のものを指定するまで 
 7311: @code{update} に同じタグが使われ続けます 
 7312: (貼り付いたタグ/日付についての詳細は @pxref{Sticky tags})。
 7313: @var{tag} には、文字列と数字のどちらを指定しても構いません。
 7314: @xref{Tags}.
 7315: 
 7316: コマンド・オプション @samp{-r} と一緒に
 7317: 広域オプション @samp{-q} を指定すると、
 7318: @sc{rcs} ファイルが指定したタグを含まない場合に、
 7319: 警告出力が抑止されるので便利です。
 7320: 
 7321: @strong{警告:} @samp{cvs_command} の左側に指定する 
 7322: @samp{cvs -r} と混同しないようにして下さい!
 7323: 
 7324: @samp{-r} は以下のコマンドで利用できます :@code{checkout},
 7325: @code{commit}, @code{diff}, @code{history}, @code{export},
 7326: @code{rdiff}, @code{rtag}, @code{update}.
 7327: 
 7328: @item -W
 7329: フィルタを適用したいファイルを指定します。
 7330: フィルタを適用したいファイルが複数あるときは、
 7331: このオプションを何個並べても構いません。
 7332: ファイル @file{.cvswrappers} での指定方法と同じ形式で指定します。
 7333: 
 7334: 以下のコマンドで利用できます: @code{import}, @code{update}.
 7335: 
 7336: @end table
 7337: 
 7338: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7339: @node admin
 7340: @appendixsec admin---管理
 7341: @cindex Admin (subcommand)
 7342: 
 7343: @itemize @bullet
 7344: @item
 7345: 必須: リポジトリ, 作業ディレクトリ
 7346: @item
 7347: 変更: リポジトリ
 7348: @item
 7349: 別名: rcs
 7350: @end itemize
 7351: 
 7352: これは雑多な管理機構への @sc{cvs} のインターフェースです。@sc{cvs} で
 7353: は役に立つか疑わしいようなものもありますが、歴史的な互換性の目的のため
 7354: に存在しています。このコマンドは@emph{必ず}再帰的に動作するため、使用
 7355: の際には細心の注意を払って下さい。
 7356: 
 7357: Unix ではグループ名 @code{cvsadmin} が存在する場合、
 7358: そのグループの一員だけが @code{cvs admin} を利用できます。
 7359: このグループはサーバ側か、非クライアント/サーバの @sc{cvs} を実行してい
 7360: る全てのシステムで存在している必要があります。
 7361: その名前で無人のグループを作成すれば、
 7362: @code{cvs admin} の使用を全面的に禁止できます。
 7363: NT では、@code{cvsadmin} 機能は存在せず、全ての使用者が @code{cvs
 7364: admin} を実行できます。
 7365: 
 7366: @menu
 7367: * admin options::               admin のオプション
 7368: @end menu
 7369: 
 7370: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7371: @node admin options
 7372: @appendixsubsec admin のオプション
 7373: 
 7374: これらのオプションの中には @sc{cvs} での有用性に疑問符が付くものもあり
 7375: ますが、歴史的な互換性のために存在しています。中には、効果を解除するま
 7376: で、@sc{cvs} を使えなくなるものもあります!
 7377: 
 7378: @table @code
 7379: @item -A@var{oldfile}
 7380: @sc{cvs} では使用されません。@var{oldfile} の利用者一覧を、
 7381: 指定した @sc{rcs} ファイルの利用者一覧に追加します。
 7382: 
 7383: @item -a@var{logins}
 7384: @sc{cvs} では使用されません。@sc{rcs} ファイルの利用者一覧に、
 7385: @var{logins} で指定された利用者を追加します。
 7386: @var{logins} はカンマで区切った利用者の一覧です。
 7387: 
 7388: @item -b[@var{rev}]
 7389: 既定の枝を @var{rev} に設定します。@sc{cvs} では、普通は既定の枝は操作
 7390: しません。貼り付いたタグ (@pxref{Sticky tags}) を使うのがどの枝で作業
 7391: をするかを決める良い方法です。@code{cvs admin -b} を実行する理由は一つ
 7392: だけあります: ベンダー枝を使用しているときに、ベンダーのバージョンに戻
 7393: すため、です (@pxref{Reverting local changes})。@samp{-b} と引数の間に
 7394: 空白があってはいけません。
 7395: @c Hmm, we don't document the usage where rev is
 7396: @c omitted.  Maybe that usage can/should be deprecated
 7397: @c (and replaced with -bHEAD or something?) (so we can toss
 7398: @c the optional argument).  Note that -bHEAD does not
 7399: @c work, as of 17 Sep 1997, but probably will once "cvs
 7400: @c admin" is internal to CVS.
 7401: 
 7402: @cindex comment leader
 7403: @item -c@var{string}
 7404: 註釈符を @var{string} にします。註釈符は現在のバージョンの @sc{cvs} で
 7405: も、@sc{rcs} 5.7 でも使用されていません。ですから、心配する必要は全く
 7406: ありません。@xref{Keyword substitution}.
 7407: 
 7408: @item -e[@var{logins}]
 7409: @sc{cvs} では使用されません。@var{logins} に含まれる利用者を、
 7410: @sc{rcs} ファイルの利用者一覧から削除します。
 7411: @var{logins} が省略された場合は、利用者一覧を全て削除します。
 7412: 
 7413: @item -I
 7414: 標準入力が端末でない場合でも対話的に動作します。
 7415: このオプションはクライアント/サーバの @sc{cvs} では動作せず、将来の
 7416: @sc{cvs} のリリースからは消えるでしょう。
 7417: 
 7418: @item -i
 7419: @sc{cvs} では無意味です。これはリビジョンを作成することなく、新しい 
 7420: @sc{rcs} ファイルを作成して、初期化します。@sc{cvs} では、@code{cvs
 7421: add} コマンドでファイルを加えてください (@pxref{Adding files})。
 7422: 
 7423: @item -k@var{subst}
 7424: 既定のキーワード置換モードを 
 7425: @var{subst} にします。@xref{Substitution modes}.
 7426: ここで既定とした方法よりも、
 7427: @code{cvs update}, @code{cvs export}, @code{cvs checkout}
 7428: での @samp{-k} オプションが優先されます。
 7429: 
 7430: @item -l[@var{rev}]
 7431: リビジョン @var{rev} をロックします。
 7432: 枝番号が与えられた場合、その枝の最新リビジョンをロックします。
 7433: @var{rev} が省略された場合は、
 7434: 既定の枝の最新リビジョンをロックします。
 7435: 引数 と @samp{-l} の間にスペースがあってはいけません。
 7436: 
 7437: @sc{cvs} のソース配布物の中の @file{contrib} ディレクトリの中に、
 7438: @file{rcslock.pl} という名前のスクリプトがあります。
 7439: これを用いて上記のロック状態を、
 7440: @sc{cvs} における独占取得 (一時に一人だけがファイル編集可能な状態) 
 7441: に置き換えることができます。
 7442: 詳細はスクリプトの註釈を参照して下さい 
 7443: (寄贈物の支援と権利の放棄声明文が書かれたファイル @file{README} 
 7444: も一読して下さい)。
 7445: その註釈によれば、厳格ロックモード (既定) に設定しておく必要があります。
 7446: 
 7447: @item -L
 7448: 厳格にロックを求める設定 (厳格ロックモード) にします。
 7449: 厳格ロックモードだと、@sc{rcs} ファイルの所有者であっても、
 7450: ロックしていないファイルは格納できません。
 7451: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7452: 上記 @samp{-l} オプションの説明も参照して下さい。
 7453: 
 7454: @cindex Changing a log message
 7455: @cindex Replacing a log message
 7456: @cindex Correcting a log message
 7457: @cindex Fixing a log message
 7458: @cindex Log message, correcting
 7459: @item -m@var{rev}:@var{msg}
 7460: リビジョン @var{rev} のログ・メッセージを @var{msg} に替えます。
 7461: 
 7462: @c The rcs -M option, to suppress sending mail, has never been
 7463: @c documented as a cvs admin option.
 7464: 
 7465: @item -N@var{name}[:[@var{rev}]]
 7466: これ以前の @var{name} の設定を無効にすることを除けば、
 7467: @samp{-n} と同じように働きます。
 7468: 魔法の枝での使用法は @ref{Magic branch numbers} を参照してください。
 7469: 
 7470: @item -n@var{name}[:[@var{rev}]]
 7471: 枝またはリビジョン @var{rev} にタグ名 @var{name} を付けます。
 7472: 通常は @samp{cvs tag} か @samp{cvs rtag} を代わりに用いると良いでしょう。
 7473: @samp{:} と @var{rev} の両方を省略すると、タグ名が削除されます。
 7474: また @var{name} が既に使用されていた場合は、
 7475: エラー・メッセージが出力されます。
 7476: @var{rev} がタグ名のときは、相当する番号に置換されます。
 7477: 枝番号の後に @samp{.} を付けて @var{rev} に指定した場合、
 7478: その枝の現時点での最新リビジョンになります。
 7479: @samp{:} だけで @var{rev} を指定しなかった場合、
 7480: 既定の枝 (通常は幹) の現時点での最新リビジョンになります。
 7481: 例えば @samp{cvs admin -n@var{name}: RCS/*} は、
 7482: 指定された全ての RCS ファイルの、
 7483: 現時点での最新リビジョンに @var{name} というタグ名を付けます。
 7484: 一方 @samp{cvs admin -n@var{name}:$ RCS/*} では、
 7485: 各作業ファイルのキーワード文字列に含まれる
 7486: リビジョンに @var{name} というタグ名を付けます。
 7487: 
 7488: @cindex Deleting revisions
 7489: @cindex Outdating revisions
 7490: @cindex Saving space
 7491: @item -o@var{range}
 7492: 
 7493: @var{range} の範囲のリビジョンを消去 (@dfn{過去のものにする}) します。
 7494: 
 7495: このコマンドは何をしているかを @emph{正確に} 知っていないと非常に危険
 7496: であることに注意してください (例えば、以下の @var{rev1:}@var{rev2} と
 7497: いう構文がいかに間違いやすいかという警告を読んでください)。
 7498: 
 7499: ディスクの容量が少ないなら、このオプションは役に立つかもしれません。し
 7500: かし、使う前によく考えてください---このコマンドを取り消すためには最後
 7501: のバックアップで復元するしかありません! 不注意や、(天が禁止している) 
 7502: CVS のバグによって、計画していたものと違うリビジョンを消してしまったら、
 7503: リビジョンが消去される前のエラーを修正する機会はありません。おそらく、
 7504: まずリポジトリのコピーで試すというのは良い考えでしょう。
 7505: 
 7506: 以下のどれかで @var{range} を指定します:
 7507: 
 7508: @table @code
 7509: @item @var{rev1}::@var{rev2}
 7510: CVS が rev1 から rev2 に関連付けられた差分だけを保存し、間の段階を保存
 7511: しないように、rev1 と rev2 間の全てのリビジョンを壊します。例えば、
 7512: @samp{-o 1.3::1.5} の後では、リビジョン 1.3, リビジョン 1.5, 1.3 から 
 7513: 1.5 の差分を取得することができますが、リビジョン 1.4 や 1.3 と 1.4 の
 7514: 差分を取得することはできません。他の例です: @samp{-o 1.3::1.4} と
 7515: @samp{-o 1.3::1.3} は間に消去するリビジョンが無いので、何の効果もあり
 7516: ません。
 7517: 
 7518: @item ::@var{rev}
 7519: @var{rev} のある枝と @var{rev} 自身の間のリビジョンを壊します。枝の始
 7520: 点と @var{rev} はそのまま残ります。例えば、@samp{-o ::1.3.2.6} はリビ
 7521: ジョン 1.3.2.1, リビジョン 1.3.2.5, とその間の全てのものを消去しますが、
 7522: 1.3 と 1.3.2.6 はそのまま残します。
 7523: 
 7524: @item @var{rev}::
 7525: @var{rev} と @var{rev} のある枝の最後との間のリビジョンを壊します。リ
 7526: ビジョン @var{rev} はそのまま残りますが、先頭のリビジョンは消去されま
 7527: す。
 7528: 
 7529: @item @var{rev}
 7530: リビジョン @var{rev} を消去します。例えば、@samp{-o 1.3} は @samp{-o
 7531: 1.2::1.4} と等価です。
 7532: 
 7533: @item @var{rev1}:@var{rev2}
 7534: 同じ枝の @var{rev1} から @var{rev2} のリビジョンを、それを含めて消去し
 7535: ます。@var{rev1} や @var{rev2} やその間の全てのリビジョンを取得するこ
 7536: とはできなくなります。例えば、コマンド @samp{cvs admin -oR_1_01:R_1_02
 7537: .} はほとんど役に立ちません。それは、タグ R_1_02 までのリビジョンを、
 7538: それを含めて消去するということです。でも注意してください! R_1_02 と 
 7539: R_1_03 で変更されていないファイルがあれば、そのファイルはタグ R_1_02 
 7540: と R_1_03 で@emph{同じ}数値リビジョン番号になっています。ですから、
 7541: R_1_02 を取得できなるだけではありません。R_1_03 もテープから復元しなけ
 7542: ればならなくなります! たいていの場合、代わりに @var{rev}::@var{rev2}
 7543: と指定しようと思うでしょう。
 7544: 
 7545: @item :@var{rev}
 7546: @var{rev} のある枝の最初から、@var{rev} までのリビジョンを、それを含め
 7547: て消去します。
 7548: 
 7549: @item @var{rev}:
 7550: @var{rev} のある枝の最後から、@var{rev} までのリビジョンを、それを含め
 7551: て消去します。
 7552: @end table
 7553: 
 7554: 消去されるべきリビジョンは全て枝やロックを持っていてはいけません。
 7555: 
 7556: 消去されるべきリビジョンにタグ名があり、@samp{::} 構文のどれかを指定
 7557: すると、@sc{cvs} はエラーを出して、どのリビジョンも消去されません。タ
 7558: グ名とリビジョンの両方を消去したいなら、まず @code{cvs tag -d} でタグ
 7559: 名を消去し、それから @code{cvs admin -o} を実行します。@samp{::} でな
 7560: い構文をいてい すると、@sc{cvs} はリビジョンを消去しますが、タグ名を存
 7561: 在しないリビジョン指すタグ名として残します。この振舞いは @sc{cvs} の以
 7562: 前のバージョンとの互換性のために残されています。しかし、これは便利では
 7563: ありませんので、将来は @samp{::} の場合と同様の振舞いに変更されるかも
 7564: しれません。
 7565: 
 7566: @sc{cvs} が枝を扱う方法のために、@var{rev} は、もし枝であれば名前で指
 7567: 定することはできません。説明は、@xref{Magic branch numbers}.
 7568: @c FIXME: is this still true?  I suspect not.
 7569: 
 7570: だれも壊したリビジョンのコピーを取り出していないことを確認してください。
 7571: 誰かがそれを編集して、格納し直そうとすると、変なことが起こります。この
 7572: ため、このオプションは無駄な格納を戻すためには良い方法ではありません。
 7573: 代わりにその変更を元に戻すための新しいリビジョンを格納してください 
 7574: (@pxref{Merging two revisions})。
 7575: 
 7576: @item -q
 7577: 簡素な (quiet) 表示、つまり実行時に診断情報を表示しません。
 7578: 
 7579: @item -s@var{state}[:@var{rev}]
 7580: @sc{cvs} でも使用します。
 7581: リビジョン @var{rev} の状態を識別する文字列を @var{state} にします。
 7582: @var{rev} が枝番号の場合、その枝の最新リビジョンの状態を変更します。
 7583: @var{rev} を省略すると、既定の枝の最新リビジョンを変更します。
 7584: @var{state} には、どのような文字列を用いても構いません。
 7585: 通常使用されるのは、@samp{Exp} (実験段階), @samp{Stab} (安定動作), 
 7586: @samp{Rel} (出荷済) といった組み合わせです。
 7587: 既定では、新しく作成されたリビジョンの状態は @samp{Exp} にされます。
 7588: 各リビジョンの状態は、@samp{cvs log} (@pxref{log}) の出力や、
 7589: キーワード @samp{$@asis{}Log$}, @samp{$@asis{}State$}
 7590: (@pxref{Keyword substitution}) の内容で確認できます。
 7591: ここで、@sc{cvs} が @code{dead} という状態を
 7592: 独自の目的で用いることに注意して下さい。
 7593: @code{dead} 状態を扱う際には、@code{cvs remove} 
 7594: や @code{cvs add} といったコマンドを使用し、
 7595: @samp{cvs admin -s} を使用してはいけません。
 7596: 
 7597: @item -t[@var{file}]
 7598: @sc{cvs} でも使用します。
 7599: @sc{rcs} ファイルの説明文を @var{file} の内容に書き換えます。
 7600: @var{file} のパス名は @samp{-} で始まってはいけません。
 7601: 各ファイルの説明文は @samp{cvs log} (@pxref{log}) の出力で確認できます。
 7602: @samp{-t} と引数の間に空白があってはいけません。
 7603: 
 7604: @var{file} が省略された場合、標準入力が用いられ、
 7605: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7606: 対話的動作が可能なら入力促進も可能です。@samp{-I} を参照してださい。
 7607: クライアント/サーバの @sc{cvs} では標準入力からの読み込みは動作せず、
 7608: 将来の @sc{cvs} のリリースでは変更されるかもしれません。
 7609: @c Changing it to doeditor() is the most obvious thing
 7610: @c (but with a different syntax, as we would like to
 7611: @c phase out optional arguments).  I don't know.  I'm
 7612: @c tempted to say the whole concept is unnecessary.
 7613: 
 7614: @item -t-@var{string}
 7615: @samp{-t@var{file}} と同様です。
 7616: @sc{rcs} ファイルの説明文を @var{string} に書き換えます。
 7617: @samp{-t} と引数の間に空白があってはいけません。
 7618: 
 7619: @c The rcs -T option, do not update last-mod time for
 7620: @c minor changes, has never been documented as a
 7621: @c cvs admin option.
 7622: 
 7623: @item -U
 7624: 厳格にはロックしない設定 (非厳格ロックモード) にします。
 7625: 非厳格ロックモードだと、@sc{rcs} ファイルの所有者ならば、
 7626: ロックしていないファイルも格納できます。
 7627: @sc{cvs} で使用する場合は、厳格ロックモードにする必要があります。
 7628: 上記 @samp{-l} オプションの説明も参照して下さい。
 7629: 
 7630: @item -u[@var{rev}]
 7631: このオプションを @sc{cvs} で使用する際の説明は、
 7632: 上記 @samp{-l} オプションを参照して下さい。
 7633: リビジョン @var{rev} のロックを解除します。
 7634: 枝を指定した場合、その枝の最新リビジョンのロックを解除します。
 7635: @var{rev} を省略すると、その人物が行なった最後のロックを解除します。
 7636: 通常は、ロックを掛けた人物だけがロックを解除できます。
 7637: 誰か他の人物がロックを解除した場合には、
 7638: ロックを掛けた人物にメールが送信されます。
 7639: このメールにはロックを解除した理由等が書き添えられます。
 7640: 連絡文はロックを解除した人物が入力し、
 7641: ファイル終端 (EOF) もしくは @samp{.} のみの行で終了します。
 7642: @samp{-u} とその引数の間に空白があってはいけません。
 7643: @c In the future "send mail" probably will go via the
 7644: @c CVSROOT/notify mechanism.  But for now it means
 7645: @c whatever it means to "rcs".
 7646: 
 7647: @item -V@var{n}
 7648: 前のバージョンの @sc{cvs} ではこのオプションはバージョン @var{n} の 
 7649: @sc{rcs} ファイルが認識できる @sc{rcs} ファイルを書くことを意味してい
 7650: ましたが、今は旧式となり、それを指定するとエラーを起こします。
 7651: @c Note that -V without an argument has never been
 7652: @c documented as a cvs admin option.
 7653: 
 7654: @item -x@var{suffixes}
 7655: 前のバージョンの @sc{cvs} では、これは @sc{rcs} ファイルの名前を指定す
 7656: るための方法として説明されていました。しかし、@sc{cvs} は常に @sc{cvs} 
 7657: で使用される @sc{rcs} ファイルは @samp{,v} で終わることを要求してきま
 7658: したので、このオプションは今まで役に立ったことはありません。
 7659: 
 7660: @c The rcs -z option, to specify the timezone, has
 7661: @c never been documented as a cvs admin option.
 7662: @end table
 7663: 
 7664: 
 7665: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7666: @node checkout
 7667: @appendixsec checkout---編集の為にソースを取り出す
 7668: @cindex Checkout (subcommand)
 7669: @cindex Co (subcommand)
 7670: 
 7671: @itemize @bullet
 7672: @item
 7673: 書式: checkout [options] modules@dots{}
 7674: @item
 7675: 必須: リポジトリ
 7676: @item
 7677: 変更: 作業ディレクトリ
 7678: @item
 7679: 別名: co, get
 7680: @end itemize
 7681: 
 7682: @var{modules} で指定されたモジュールの作業ディレクトリを作成、
 7683: もしくは更新し、
 7684: その中にソース・ファイルをコピーします。
 7685: @sc{cvs} のほとんどのコマンドは作業ディレクトリを扱うものなので、
 7686: まず @code{checkout} を実行しておく必要があります。
 7687: 
 7688: @var{modules} は、
 7689: リポジトリ中のディレクトリやファイルへの相対パスだけでなく、
 7690: ディレクトリやファイルの集合に対する別名でも構いません。
 7691: 別名は管理用ファイル @file{modules} で定義します 
 7692: @xref{modules}.
 7693: @c Needs an example, particularly of the non-"modules"
 7694: @c case but probably of both.
 7695: 
 7696: @c FIXME: this seems like a very odd place to introduce
 7697: @c people to how CVS works.  The bit about unreserved
 7698: @c checkouts is also misleading as it depends on how
 7699: @c things are set up.
 7700: 指定したモジュールにもよりますが、
 7701: @code{checkout} は再帰的にディレクトリを作成し、
 7702: そこに適切なソース・ファイルを入れていきます。
 7703: そして (他の開発者が各自のコピーを編集しているかどうかに関わらず)、
 7704: 好きなときに自分のソース・ファイルを編集し、
 7705: 他人の変更を取り入れるために更新したり、
 7706: 自分の変更をリポジトリに反映するために格納したりします。
 7707: 
 7708: @code{checkout} で作成されるディレクトリに注意して下さい。
 7709: 最上位のディレクトリは、
 7710: 必ず @code{checkout} を実行したディレクトリに追加され、
 7711: 通常は指定したモジュールと同じ名前になります。
 7712: モジュールに別名が定義されている場合、
 7713: サブディレクトリは違う名前になりますが心配は要りません。
 7714: @code{checkout} の処理中、各ファイルを作業領域に展開したと同時に
 7715: その相対パスが表示されますから、
 7716: この表示でサブディレクトリを確認して下さい 
 7717: (広域オプション @samp{-Q} を付けた場合は表示がありません)。
 7718: 
 7719: @sc{cvs} にオプション @samp{-r} が付けられた場合 
 7720: (@pxref{Global options})、
 7721: 環境変数 @code{CVSREAD} が設定されていた場合 
 7722: (@pxref{Environment variables})、
 7723: ファイルが監視されていた場合 
 7724: (@pxref{Watches}) を除いて、
 7725: @code{checkout} が作成するファイルは読み書き可能な状態になります。
 7726: 
 7727: @code{checkout} で作成したディレクトリの上で、
 7728: 再度 @code{checkout} を実行しても構わないということに注意してください。
 7729: これはリポジトリに作成された新しいディレクトリが作業領域に現れるという
 7730: 点で、@code{update} コマンドに @samp{-d} オプションを付けるのと同様の
 7731: 効果があります。しかし、@code{update} は引数にディレクトリ名を取ります
 7732: が、@code{checkout} は引数にモジュール名を取ります。@code{checkout} を
 7733: この様に使うためには、最上位のディレクトリから実行しなければなりません
 7734: ので (普段 @code{checkout} を実行する場所です)、存在するディレクトリを
 7735: 更新するために @code{checkout} を実行する前に、ディレクトリを最上位の
 7736: ディレクトリに変更することを忘れないでください。
 7737: 
 7738: @code{checkout} コマンドの出力は @ref{update output} を参照して下さい。
 7739: 
 7740: @menu
 7741: * checkout options::            checkout のオプション
 7742: * checkout examples::           checkout の使用例
 7743: @end menu
 7744: 
 7745: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7746: @node checkout options
 7747: @appendixsubsec checkout のオプション
 7748: 
 7749: @code{checkout} では、以下の標準オプションが利用できます 
 7750: (完全な記述は @pxref{Common options}):
 7751: 
 7752: @table @code
 7753: @item -D @var{date}
 7754: @var{date} 以前の最も新しいリビジョンを取り出します。
 7755: このオプションは貼り付けられ、
 7756: 勝手に @samp{-P} オプションも実行されます。
 7757: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 7758: 
 7759: @item -f
 7760: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 7761: 指定したリビジョンが見付からなかった場合、
 7762: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 7763: 
 7764: @item -k @var{kflag}
 7765: キーワード置換モードを @var{kflag} に指定します。
 7766: 詳細は @ref{Substitution modes} を参照。
 7767: このオプションは貼り付けられます。つまりこれ以後、
 7768: この作業ディレクトリでファイルが更新されるときには、
 7769: 同じ @var{kflag} が使用され続けます。
 7770: @code{status} コマンドを用いて
 7771: 貼り付いたオプションを見ることができます。
 7772: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 7773: 
 7774: @item -l
 7775: Local、つまり現在の作業ディレクトリでのみコマンドが
 7776: 実行されます。
 7777: 
 7778: @item -n
 7779: ファイルを取り出したとき、普段は実行されるプログラムを実行しません。
 7780: このプログラムは管理用ファイル @file{modules} の
 7781: オプション @samp{-o} で指定されます (@pxref{modules})。
 7782: 
 7783: @item -P
 7784: 空になったディレクトリを削除 (prune) します。@ref{Moving directories}
 7785: を参照してください。
 7786: 
 7787: @item -p
 7788: ファイルを標準出力に送り (pipe) ます。
 7789: 
 7790: @item -R
 7791: ディレクトリを再帰的に取り出します。このオプションは指定しなくても実行
 7792: されます。
 7793: 
 7794: @item -r @var{tag}
 7795: @var{tag} で指定されたリビジョンを取り出します。
 7796: このオプションは貼り付けられ、
 7797: @samp{-P} オプションも勝手に実行されます。
 7798: 貼り付いたタグ/日付についての詳細は @xref{Sticky tags}.
 7799: @end table
 7800: 
 7801: さらに @code{checkout} では次の固有オプションも使用可能です:
 7802: 
 7803: @table @code
 7804: @item -A
 7805: 全ての貼り付いたタグや日付、
 7806: また @samp{-k} オプションの指定を剥がします。
 7807: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags} を参照してくだ
 7808: さい。
 7809: 
 7810: @item -c
 7811: 管理用ファイル @file{modules} の内容を、
 7812: アルファベット順に並べて標準出力に出します。
 7813: 作業ディレクトリは全く変更されません。
 7814: 
 7815: @item -d @var{dir}
 7816: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 7817: 一般的に、このフラグは @samp{mkdir @var{dir}; cd @var{dir}} の後に 
 7818: @samp{-d} フラグ無しで checkout コマンドを実行することと同じです。
 7819: 
 7820: しかし、重要な例外があります。単独の項目を取り出しているときには、出力
 7821: に間に空のディレクトリが無いディレクトリが現れた方がとても便利です。こ
 7822: の場合@emph{のみ}、CVS は空のディレクトリを避けるためにパス名を ``短く'' 
 7823: します。
 7824: 
 7825: 例えば、ファイル @samp{bar.c} がある @samp{foo} というモジュールがある
 7826: とすると、コマンド @samp{cvs co -d dir foo} はディレクトリ @samp{dir}
 7827: を作成し、中に @samp{bar.c} を置きます。同様に、サブディレクトリ 
 7828: @samp{baz} があり、その中に @samp{quux.c} のあるモジュール @samp{bar} 
 7829: があるとすると、コマンド @samp{cvs -d dir co bar/baz} はディレクトリ 
 7830: @samp{dir} 作成し、その中に @samp{quux.c} を置きます。
 7831: 
 7832: @samp{-N} フラグを使うと、この振舞いは抑制されます。上と同じモジュール
 7833: の定義で、@samp{cvs co -N -d dir foo} はディレクトリ @samp{dir/foo} を
 7834: 作成してその中に @samp{bar.c} を置き、@samp{cvs co -N -d dir bar/baz}
 7835: はディクトリ @samp{dir/bar/baz} を作成してその中に @samp{quux.c} を置
 7836: きます。
 7837: 
 7838: @item -j @var{tag}
 7839: @samp{-j} オプションを二つ指定した場合、
 7840: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 7841: 作業ディレクトリにマージします。
 7842: 
 7843: @samp{-j} オプションが一つの場合、
 7844: その分岐リビジョンから指定したリビジョンへの変更を、
 7845: 作業ディレクトリにマージします。
 7846: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 7847: @samp{-j} で指定したリビジョンとの共通の祖先です。
 7848: 
 7849: @samp{-j} オプションに枝を指定する場合、
 7850: 日付の指定を付加することができます。
 7851: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 7852: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 7853: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 7854: 
 7855: @xref{Branching and merging}.
 7856: 
 7857: @item -N
 7858: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 7859: このオプションを指定した場合、
 7860: 単独モジュールを取り出したときに、
 7861: 作業ディレクトリのモジュールパスを ``短く'' しません。例と説明は 
 7862: @samp{-d} フラグを参照してください。
 7863: 
 7864: @item -s
 7865: @samp{-c} と同様ですが、全てのモジュールの状態を
 7866: アルファベット順に並べて標準出力に出します。
 7867: モジュールの状態を設定するために管理用ファイル @file{modules} の中で使
 7868: われるオプション @samp{-s} の情報は、@xref{modules}.
 7869: @end table
 7870: 
 7871: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7872: @node checkout examples
 7873: @appendixsubsec checkout の使用例
 7874: 
 7875: モジュール @samp{tc} のコピーを取り出します:
 7876: 
 7877: @example
 7878: $ cvs checkout tc
 7879: @end example
 7880: 
 7881: モジュール @samp{tc} を昨日の状態で取り出します:
 7882: 
 7883: @example
 7884: $ cvs checkout -D yesterday tc
 7885: @end example
 7886: 
 7887: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 7888: @node commit
 7889: @appendixsec commit---ファイルをリポジトリに格納する
 7890: @cindex Commit (subcommand)
 7891: 
 7892: @itemize @bullet
 7893: @item
 7894: 書式: commit [-lnRf] [-m 'log_message' |
 7895: -F file] [-r revision] [files@dots{}]
 7896: @item
 7897: 必須: 作業ディレクトリ, リポジトリ
 7898: @item
 7899: 変更: リポジトリ
 7900: @item
 7901: 別名: ci
 7902: @end itemize
 7903: 
 7904: @code{commit} は、作業ファイルに対する変更を
 7905: リポジトリに組み入れる際に使用します。
 7906: 
 7907: 格納するファイルを特に指定しなければ、
 7908: 現在の作業ディレクトリの全ファイルが調査され、
 7909: 変更が加えられたファイルだけがリポジトリに格納されます。
 7910: 既定 (もしくは明示的にオプション @samp{-R} が指定された場合) では、
 7911: サブディレクトリのファイルも調査され、変更されていれば格納されます。
 7912: オプション @samp{-l} を指定して、
 7913: @code{commit} の動作を現在のディレクトリだけに留めることも可能です。
 7914: 
 7915: @code{commit} は、選択されたファイルが
 7916: リポジトリの最新リビジョンであるかどうか確認します。
 7917: 指定されたファイルの中に @code{update} (@pxref{update}) 
 7918: が必要なものが一つでもあれば、その旨が表示され、
 7919: 格納せずに終了します。
 7920: @code{commit} はあえて @code{update} コマンドを呼び出さず、
 7921: 開発者自身に適切な時期を判断してもらいます。
 7922: 
 7923: 全てが正常ならば、ログ・メッセージを記すためにエディタが起動されます。
 7924: ログ・メッセージは幾つかの処理プログラムに送られると同時に 
 7925: (@ref{modules} と @ref{loginfo} を参照)、
 7926: リポジトリ中の @sc{rcs} ファイルにも記録されます。
 7927: このログ・メッセージを参照するには @code{log} コマンドを
 7928: 用いて下さい。@ref{log} 参照。
 7929: オプション @samp{-m @var{message}} で
 7930: コマンド行にログ・メッセージを記述したり、
 7931: オプション @samp{-F @var{file}} で
 7932: ログ・メッセージを記述したファイルを指定すれば、
 7933: エディタを起動しなくて済みます。
 7934: 
 7935: @menu
 7936: * commit options::              commit のオプション
 7937: * commit examples::             commit の使用例
 7938: @end menu
 7939: 
 7940: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 7941: @node commit options
 7942: @appendixsubsec commit のオプション
 7943: 
 7944: @code{commit} では、以下の標準オプションが利用できます 
 7945: (完全な記述は @pxref{Common options}):
 7946: 
 7947: @table @code
 7948: @item -l
 7949: Local、つまり現在の作業ディレクトリでのみコマンドが
 7950: 実行されます。
 7951: 
 7952: @item -n
 7953: モジュールのプログラムを実行しません。
 7954: 
 7955: @item -R
 7956: ディレクトリを再帰的に格納します。
 7957: このオプションは指定しなくても実行されます。
 7958: 
 7959: @item -r @var{revision}
 7960: @var{revision} に格納します。
 7961: @var{revision} には、枝もしくは、
 7962: 既存の全てのリビジョン番号よりも大きい番号を持つ
 7963: 幹上のリビジョンを指定しなくてはいけません 
 7964: (@pxref{Assigning revisions})。
 7965: 枝上のリビジョンを指定して格納することはできません。
 7966: @c FIXME: Need xref for branch case.
 7967: @end table
 7968: 
 7969: さらに @code{commit} では以下のオプションも使用可能です:
 7970: 
 7971: @table @code
 7972: @item -F @var{file}
 7973: エディタを起動せず @var{file} からログ・メッセージを読み込みます。
 7974: 
 7975: @item -f
 7976: これは @ref{Common options} のオプション @samp{-f} に記述される
 7977: 標準的な動作とは異なることに注意して下さい。
 7978: 
 7979: 作業ファイルに何も変更を加えていない場合でも、
 7980: 無理矢理新しいリビジョンとして格納します。
 7981: 現在の @var{file} のリビジョンを 1.7 と仮定したとき、
 7982: 次の二つのコマンドの実行結果は同じになります:
 7983: 
 7984: @example
 7985: $ cvs commit -f @var{file}
 7986: $ cvs commit -r 1.8 @var{file}
 7987: @end example
 7988: 
 7989: @c This is odd, but it's how CVS has worked for some
 7990: @c time.
 7991: @samp{-f} オプションは再帰を使いません (すなわち、@samp{-l} を含んでい
 7992: ます)。全てのサブディレクトリの全てのファイルの新しいリビジョンの格納
 7993: を @sc{cvs} 強制するには、@samp{-f -R} を使用する必要があります。
 7994: 
 7995: @item -m @var{message}
 7996: エディタを起動せず、@var{message} をログ・メッセージとします。
 7997: @end table
 7998: 
 7999: @need 2000
 8000: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8001: @node commit examples
 8002: @appendixsubsec commit の使用例
 8003: 
 8004: @c FIXME: this material wants to be somewhere
 8005: @c in "Branching and merging".
 8006: 
 8007: @appendixsubsubsec 枝に対して格納する
 8008: 
 8009: オプション @samp{-r} を用いて、枝リビジョン (リビジョン番号が
 8010: 偶数個のドットを含むもの) に格納することができます。
 8011: 枝リビジョンは @code{rtag} か @code{tag} コマンドに
 8012: オプション @samp{-b} を指定して作成します 
 8013: (@pxref{Branching and merging})。
 8014: そして @code{checkout} か @code{update} で、
 8015: 新しく作成した枝からソースを取り出します。
 8016: その結果、この作業ソースに対する変更を @code{commit} すると、
 8017: 全て自動的に枝リビジョンの方に追加され、
 8018: 幹の開発系統は全く影響を受けません。
 8019: 例えば、バージョン 1.2 の製品に対するパッチを作成する必要があるけれど、
 8020: 既にバージョン 2.0 の開発が始まっているような場合、
 8021: 以下のようにします:
 8022: 
 8023: @example
 8024: $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
 8025: $ cvs checkout -r FCS1_2_Patch product_module
 8026: $ cd product_module
 8027: [[ hack away ]]
 8028: $ cvs commit
 8029: @end example
 8030: 
 8031: @noindent
 8032: オプション @samp{-r} は作業ディレクトリに貼り付けられるため、
 8033: これを指定する必要はありません。
 8034: 
 8035: @appendixsubsubsec 編集後に枝を作成する
 8036: 
 8037: 例えば、先週取り出したリビジョンを元にして、
 8038: 極めて実験的な変更をソフトウェアに加えてきたとします。
 8039: ここで実験に他の開発者を加えたいけれど、
 8040: 幹の開発系統を妨げたくない場合は、
 8041: その変更点を新しい枝に格納すれば良いでしょう。
 8042: すると他の開発者も実験中のコードを取り出して、
 8043: @sc{cvs} の衝突解決の恩恵を全て受けることができます。
 8044: このシナリオは次のようになるでしょう:
 8045: 
 8046: @c FIXME: Should we be recommending tagging the branchpoint?
 8047: @example
 8048: [[ hacked sources are present ]]
 8049: $ cvs tag -b EXPR1
 8050: $ cvs update -r EXPR1
 8051: $ cvs commit
 8052: @end example
 8053: 
 8054: @code{update} コマンドで、全てのファイルに
 8055: オプション @samp{-r EXPR1} が貼り付けられます。
 8056: このとき、@code{update} コマンドでは
 8057: ファイルに対する変更が削除されないことに注意して下さい。
 8058: @samp{-r} が貼り付けられているため、
 8059: @code{commit} すれば自動的に正しい枝に変更が格納されます。
 8060: これは次の手順もあります:
 8061: 
 8062: @c FIXME: Should we be recommending tagging the branchpoint?
 8063: @example
 8064: [[ hacked sources are present ]]
 8065: $ cvs tag -b EXPR1
 8066: $ cvs commit -r EXPR1
 8067: @end example
 8068: 
 8069: @noindent
 8070: しかしこの場合、
 8071: 変更されていたファイルだけに @samp{-r EXPR1} が貼り付けられます。
 8072: 従って別のファイルを変更して、フラグ @samp{-r EXPR1} を付けずに
 8073: 格納した場合、誤って幹に格納されてしまいます。
 8074: 
 8075: 他の開発者が実験に参加する際には、
 8076: 単純に以下のようにして下さい:
 8077: 
 8078: @example
 8079: $ cvs checkout -r EXPR1 whatever_module
 8080: @end example
 8081: 
 8082: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8083: @node diff
 8084: @appendixsec diff---リビジョン間の差分の表示
 8085: @cindex Diff (subcommand)
 8086: 
 8087: @itemize @bullet
 8088: @item
 8089: 書式: diff [-lR] [format_options] [[-r rev1 | -D date1] [-r rev2 |  -D date2]] [files@dots{}]
 8090: @item
 8091: 必須: 作業ディレクトリ, リポジトリ
 8092: @item
 8093: 変更: なし
 8094: @end itemize
 8095: 
 8096: @code{diff} コマンドは、
 8097: 別々のリビジョン間の差異を比較するのに使用します。
 8098: 特にオプションを指定しない場合、
 8099: 作業ファイルをその由来となったリビジョンと比較し、
 8100: 検出された全ての差異を報告します。
 8101: 
 8102: ファイル名を指定した場合、そのファイルについてのみ比較します。
 8103: ディレクトリを指定した場合、その下の全てのファイルを比較します。
 8104: 
 8105: diff の終了状態は他の @sc{cvs} コマンドと違います。詳細は @ref{Exit
 8106: status} を参照してください。
 8107: 
 8108: @menu
 8109: * diff options::                diff のオプション
 8110: * diff examples::               diff の使用例
 8111: @end menu
 8112: 
 8113: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8114: @node diff options
 8115: @appendixsubsec diff のオプション
 8116: 
 8117: @code{diff} では、以下の標準オプションが利用できます 
 8118: (完全な記述は @pxref{Common options}):
 8119: 
 8120: @table @code
 8121: @item -D @var{date}
 8122: @var{date} 以前の最も新しいリビジョンを利用します。
 8123: このオプションを比較に用いた時の効果は @samp{-r} を参照して下さい。
 8124: 
 8125: @item -k @var{kflag}
 8126: @var{kfalg} に従ってキーワード置換を行います。@ref{Keyword
 8127: substitution}, 参照。
 8128: 
 8129: @item -l
 8130: Local、つまり現在の作業ディレクトリでのみコマンドが
 8131: 実行されます。
 8132: 
 8133: @item -R
 8134: ディレクトリを再帰的に調べます。
 8135: このオプションは指定しなくても実行されます。
 8136: 
 8137: @item -r @var{tag}
 8138: リビジョン @var{tag} と比較します。
 8139: オプション @samp{-r} は最大二つまで使用できます。
 8140: オプション @samp{-r} を指定しない場合、
 8141: 作業ファイルをその由来となったリビジョンと比較します。
 8142: オプション @samp{-r} を一つ指定した場合、
 8143: 指定したリビジョンと作業ファイルとを比較します。
 8144: オプション @samp{-r} を二つ指定した場合、
 8145: 指定した二つのリビジョンを比較します 
 8146: (作業ファイルが結果に影響を与えることはありません)。
 8147: @c We should be a lot more explicit, with examples,
 8148: @c about the difference between "cvs diff" and "cvs
 8149: @c diff -r HEAD".  This often confuses new users.
 8150: 
 8151: 一つもしくは両方のオプション @samp{-r} を、前述の
 8152: オプション @samp{-D @var{date}} と交換することができます。
 8153: @end table
 8154: 
 8155: @c Conceptually, this is a disaster.  There are 3
 8156: @c zillion diff formats that we support via the diff
 8157: @c library.  It is not obvious to me that we should
 8158: @c document them all.  Maybe just the most common ones
 8159: @c like -c and -u, and think about phasing out the
 8160: @c obscure ones.
 8161: @c FIXCVS: also should be a way to specify an external
 8162: @c diff program (which can be different for different
 8163: @c file types) and pass through
 8164: @c arbitrary options, so that the user can do
 8165: @c "--pass=-Z --pass=foo" or something even if CVS
 8166: @c doesn't know about the "-Z foo" option to diff.
 8167: @c This would fit nicely with deprecating/eliminating
 8168: @c the obscure options of the diff library, because it
 8169: @c would let people specify an external GNU diff if
 8170: @c they are into that sort of thing.
 8171: 以下のオプションは出力の書式を指定します。
 8172: 意味は GNU diff と同じです。
 8173: 
 8174: @example
 8175: -0 -1 -2 -3 -4 -5 -6 -7 -8 -9
 8176: --binary
 8177: --brief
 8178: --changed-group-format=@var{arg}
 8179: -c
 8180:   -C @var{nlines}
 8181:   --context[=@var{lines}]
 8182: -e --ed
 8183: -t --expand-tabs
 8184: -f --forward-ed
 8185: --horizon-lines=@var{arg}
 8186: --ifdef=@var{arg}
 8187: -w --ignore-all-space
 8188: -B --ignore-blank-lines
 8189: -i --ignore-case
 8190: -I @var{regexp}
 8191:    --ignore-matching-lines=@var{regexp}
 8192: -h
 8193: -b --ignore-space-change
 8194: -T --initial-tab
 8195: -L @var{label}
 8196:   --label=@var{label}
 8197: --left-column
 8198: -d --minimal
 8199: -N --new-file
 8200: --new-line-format=@var{arg}
 8201: --old-line-format=@var{arg}
 8202: --paginate
 8203: -n --rcs
 8204: -s --report-identical-files
 8205: -p
 8206: --show-c-function
 8207: -y --side-by-side
 8208: -F @var{regexp}
 8209: --show-function-line=@var{regexp}
 8210: -H --speed-large-files
 8211: --suppress-common-lines
 8212: -a --text
 8213: --unchanged-group-format=@var{arg}
 8214: -u
 8215:   -U @var{nlines}
 8216:   --unified[=@var{lines}]
 8217: @c FIXCVS: This option is accepted by src/diff.c but
 8218: @c not diff/diff.c; it would appear that any attempt to
 8219: @c use it would get an error.
 8220: -V @var{arg}
 8221: -W @var{columns}
 8222:   --width=@var{columns}
 8223: @end example
 8224: 
 8225: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8226: @node diff examples
 8227: @appendixsubsec diff の使用例
 8228: 
 8229: 次の実行例は、@file{backend.c} のリビジョン 1.14 と 1.19 間の差分を、
 8230: unidiff 形式 (フラグ @samp{-u}) で出力します。
 8231: またキーワード置換を止めるために @samp{-kk} を指定し、
 8232: キーワード置換による差分を無視します。
 8233: 
 8234: @example
 8235: $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
 8236: @end example
 8237: 
 8238: タグ RELEASE_1_0 が付けられたファイルの集合から、
 8239: 実験用の枝 EXPR1 が派生していると仮定します。
 8240: この枝に加えられた変更を見るには、次のようにします:
 8241: 
 8242: @example
 8243: $ cvs diff -r RELEASE_1_0 -r EXPR1
 8244: @end example
 8245: 
 8246: 次の実行例では、二つのリリース間の差分を context 形式で出力します:
 8247: 
 8248: @example
 8249: $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
 8250: @end example
 8251: 
 8252: ChangeLogs を運用している場合、
 8253: 変更を格納する前に次の行のようなコマンドを実行すると、
 8254: ChangeLogs の記載事項を入力するのに役立つでしょう。
 8255: 作業ファイルに加えた変更点のうち、格納していないもの全てを表示します。
 8256: 
 8257: @example
 8258: $ cvs diff -u | less
 8259: @end example
 8260: 
 8261: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8262: @node export
 8263: @appendixsec export---CVS からソースを取り出す, checkout に類似
 8264: @cindex Export (subcommand)
 8265: 
 8266: @itemize @bullet
 8267: @item
 8268: 書式: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
 8269: @item
 8270: 必須: リポジトリ
 8271: @item
 8272: 変更: 現在のディレクトリ
 8273: @end itemize
 8274: 
 8275: このコマンドは @code{checkout} の変形で、
 8276: @var{module} のソースのコピーを、
 8277: @sc{cvs} の管理用ディレクトリを除いた状態で取り出します。
 8278: 例えば出荷用のソースを準備するときなどに @code{export} を使います。
 8279: 出荷したソースを後で再現できることを確認するため、使用の際には 
 8280: (@samp{-D} か @samp{-r} による) 日付かタグの指定が要求されます。
 8281: 
 8282: @code{cvs export} に @samp{-kv} を指定すると便利です。
 8283: この指定で全てのキーワードが展開されるため、
 8284: 出荷先で @code{import} されても
 8285: キーワードによるリビジョン情報が失われません。
 8286: しかしモジュールがバイナリ・ファイルを含む場合は、
 8287: 正しく処理されない可能性があるので注意が必要です。
 8288: また @samp{-kv} を使用した後では、@code{ident} コマンド (@sc{rcs} を
 8289: 構成するコマンドの一つです---@samp{ident(1)} を参照) を使用して、
 8290: キーワード文字列を抜き出すことができません。
 8291: 従って @code{ident} を使用するつもりなら、
 8292: @samp{-kv} を指定してはいけません。
 8293: 
 8294: @menu
 8295: * export options::              export のオプション
 8296: @end menu
 8297: 
 8298: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8299: @node export options
 8300: @appendixsubsec export のオプション
 8301: 
 8302: @code{export} では、以下の標準オプションが利用できます 
 8303: (完全な記述は @pxref{Common options}):
 8304: 
 8305: @table @code
 8306: @item -D @var{date}
 8307: @var{date} 以前の最も新しいリビジョンを取り出します。
 8308: 
 8309: @item -f
 8310: 指定したリビジョンが見付からなかった場合、
 8311: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 8312: 
 8313: @item -l
 8314: Local、つまり現在の作業ディレクトリでのみコマンドが
 8315: 実行されます。
 8316: 
 8317: @item -n
 8318: ファイルを取り出したとき、通常実行されるプログラムを実行しません。
 8319: 
 8320: @item -R
 8321: ディレクトリを再帰的に取り出します。
 8322: このオプションは指定しなくても実行されます。
 8323: 
 8324: @item -r @var{tag}
 8325: @var{tag} で指定されたリビジョンを取り出します。
 8326: @end table
 8327: 
 8328: さらに (@code{checkout} と @code{export} で共通な) 
 8329: 以下のオプションも使用可能です:
 8330: 
 8331: @table @code
 8332: @item -d @var{dir}
 8333: モジュール名を使用する代りに @var{dir} というディレクトリを作成します。
 8334: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8335: 
 8336: @item -k @var{subst}
 8337: キーワード置換モードを設定します (@pxref{Substitution modes})。
 8338: 
 8339: @item -N
 8340: @samp{-d @var{dir}} と併用した場合にのみ有効です。
 8341: @sc{cvs} がこのフラグを扱う方法の完全な詳細は @xref{checkout options}.
 8342: @end table
 8343: 
 8344: @ignore
 8345: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8346: @c @node export examples
 8347: @appendixsubsec export examples
 8348: 
 8349: Contributed examples are gratefully accepted.
 8350: @c -- Examples here!!
 8351: @end ignore
 8352: 
 8353: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8354: @node history
 8355: @appendixsec history---ファイルと使用者の状態を表示
 8356: @cindex History (subcommand)
 8357: 
 8358: @itemize @bullet
 8359: @item
 8360: 書式:     history [-report] [-flags] [-options args] [files@dots{}]
 8361: @item
 8362: 必須: ファイル @file{$CVSROOT/CVSROOT/history}
 8363: @item
 8364: 変更: なし
 8365: @end itemize
 8366: 
 8367: @sc{cvs} は、@code{checkout}, @code{commit}, @code{rtag}, 
 8368: @code{update}, @code{release} コマンドの実行履歴を、
 8369: ファイル @file{history} に記録しています。
 8370: @code{history} を使って、様々な形式で
 8371: この情報を表示することができます。
 8372: 
 8373: ログを記録したい場合は、ファイル @file{$CVSROOT/CVSROOT/history} を
 8374: 作成する必要があります。
 8375: 
 8376: @strong{警告:} @code{history} は、@samp{-f}, @samp{-l}, @samp{-n}, 
 8377: @samp{-p} を通常の @sc{cvs} コマンドで用いられるものとは
 8378: 異なる意味で使用しています (@pxref{Common options})。
 8379: 
 8380: @menu
 8381: * history options::             history のオプション
 8382: @end menu
 8383: 
 8384: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8385: @node history options
 8386: @appendixsubsec history のオプション
 8387: 
 8388: 次のオプション (コマンド書式で @samp{-report} の部分) によって、
 8389: 生成する報告の種類を決定します:
 8390: 
 8391: @table @code
 8392: @item -c
 8393: 現在までに使用された @code{commit} (つまりリポジトリの変更) 
 8394: について報告します。
 8395: 
 8396: @item -e
 8397: 全て (全記録種別) を報告します。全ての記録種別に @samp{-x} を指定する
 8398: ことと等価です。もちろん、@samp{-e} は将来のバージョンの @sc{cvs} に加
 8399: えられた記録種別も含みます。特定の記録種別だけを扱うことのできるスクリ
 8400: プトを書いているなら、@samp{-x} を指定する方が良いでしょう。
 8401: 
 8402: @item -m @var{module}
 8403: 特定のモジュールについて報告します 
 8404: (必要ならば複数の @samp{-m} をコマンド行に並べても構いません)。
 8405: 
 8406: @item -o
 8407: 取り出されたモジュールについて報告します。
 8408: 
 8409: @item -T
 8410: 全てのタグについて報告します。
 8411: 
 8412: @item -x @var{type}
 8413: 報告を受けたい記録種別の組を @var{type} に指定して、
 8414: @sc{cvs} の実行履歴から取り出します。
 8415: 種別は各々一文字で表され、これを組み合わせて指定します。
 8416: 
 8417: 以下のコマンドには、各々一つの記録種別を割り当てています:
 8418: 
 8419: @table @code
 8420: @item F
 8421: release
 8422: @item O
 8423: checkout
 8424: @item E
 8425: export
 8426: @item T
 8427: rtag
 8428: @end table
 8429: 
 8430: @noindent
 8431: 更新の結果は、以下の四つの記録種別のうちのどれかになります:
 8432: 
 8433: @table @code
 8434: @item C
 8435: マージを実行した結果、衝突が検出された場合 (手動でのマージが必要)。
 8436: @item G
 8437: マージを実行して成功した場合。
 8438: @item U
 8439: 作業ファイルがリポジトリからコピーされた場合。
 8440: @item W
 8441: (リポジトリから相当するファイルが削除されたため) 
 8442: 更新の際に作業ファイルが削除された場合。
 8443: @end table
 8444: 
 8445: @noindent
 8446: 格納の結果は、以下の三つの記録種別のうちのどれかになります:
 8447: 
 8448: @table @code
 8449: @item A
 8450: ファイルが初めて追加された場合。
 8451: @item M
 8452: ファイルが修正された場合。
 8453: @item R
 8454: ファイルが削除された場合。
 8455: @end table
 8456: @end table
 8457: 
 8458: 次のオプション (コマンド書式で @samp{-flags} の部分) によって、
 8459: 報告の範囲を限定もしくは拡大します。引数はありません:
 8460: 
 8461: @table @code
 8462: @item -a
 8463: 全ての使用者の情報を表示します 
 8464: (既定では @code{history} を実行した人物の情報のみを表示します)。
 8465: 
 8466: @item -l
 8467: 最後の変更のみを表示します。
 8468: 
 8469: @item -w
 8470: @code{history} を実行したのと同じ作業ディレクトリから行われた
 8471: 変更に関する記録のみを表示します。
 8472: @end table
 8473: 
 8474: 次のオプション (コマンド書式で @samp{-options @var{args}} の部分) は、
 8475: 引数に基づいて報告の範囲を限定します:
 8476: 
 8477: @table @code
 8478: @item -b @var{str}
 8479: モジュール名, ファイル名, リポジトリのパスのいずれかに、
 8480: 文字列 @var{str} が含まれる記録のみを表示します。
 8481: 
 8482: @item -D @var{date}
 8483: @var{date} 以降のデータを表示します。
 8484: 普通の @samp{-D @var{date}} は @var{date} 以前の
 8485: 最新リビジョンを選択しますから、少し意味が違います。
 8486: 
 8487: @item -p @var{repository}
 8488: 指定したリポジトリのデータを表示します 
 8489: (必要ならば複数の @samp{-p} をコマンド行に並べても構いません。)
 8490: 
 8491: @item -r @var{rev}
 8492: リビジョンもしくはタグを @var{rev} に指定して、
 8493: このリビジョン以降の記録を表示します。
 8494: 実行時に全ての @sc{rcs} ファイルについて @var{rev} を検索します。
 8495: 
 8496: @item -t @var{tag}
 8497: 履歴ファイルにタグ @var{tag} が
 8498: 追加された後の記録を表示します。
 8499: このオプションを指定した場合、@sc{rcs} ファイルを検索せず、
 8500: 履歴ファイルのみを参照するため、
 8501: オプション @samp{-r} の場合よりもかなり高速です。
 8502: 
 8503: @item -u @var{name}
 8504: @var{name} で指定された使用者の記録を表示します。
 8505: @end table
 8506: 
 8507: @ignore
 8508: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8509: @c @node history examples
 8510: @appendixsubsec history examples
 8511: 
 8512: Contributed examples will gratefully be accepted.
 8513: @c -- Examples here!
 8514: @end ignore
 8515: 
 8516: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8517: @node import
 8518: @appendixsec import---CVS にソースを取り込む, ベンダー枝を使用
 8519: @cindex Import (subcommand)
 8520: 
 8521: @c FIXME: This node is way too long for one which has subnodes.
 8522: 
 8523: @itemize @bullet
 8524: @item
 8525: 書式: import [-options] repository vendortag releasetag@dots{}
 8526: @item
 8527: 必須: リポジトリ, ソースの配布ディレクトリ
 8528: @item
 8529: 変更: リポジトリ
 8530: @end itemize
 8531: 
 8532: @code{import} を用いて、外部の供給元 (例えばソース・ベンダー) 
 8533: からのソース配布物全体を、自分のリポジトリに取り入れることができます。
 8534: リポジトリを最初に作成する場合と、外部の供給元がモジュールを
 8535: 大幅に更新した場合の両方でこのコマンドを用います。
 8536: この件については @xref{Tracking sources}.
 8537: 
 8538: @var{repository} には、リポジトリにするディレクトリの名前 
 8539: (もしくは、ディレクトリへのパス) を、
 8540: @sc{cvs} のルート・ディレクトリからの相対パス名で指定します。
 8541: 指定したディレクトリが存在しなくても自動的に作成されます。
 8542: 
 8543: (前回の import から) ずっと変更を加えてきたリポジトリに対し、
 8544: ソースを更新するために import を用いると、
 8545: 互いの開発系統間で衝突が発生したファイル全てが報告されます。
 8546: この時 import から具体的な指示がありますので、
 8547: それを参考にしながら @samp{checkout -j} を使って変更点を取り入れて下さい。
 8548: 
 8549: @sc{cvs} は無視するように設定されたファイルは (@pxref{cvsignore})、
 8550: 取り込まず、無視したことを示すため 
 8551: @samp{I } に続けてファイル名を表示します 
 8552: (出力に関する完全な説明は @pxref{import output})。
 8553: 
 8554: @file{$CVSROOT/CVSROOT/cvswrappers} が存在する場合、
 8555: このファイルの記述に合致するファイルやディレクトリは
 8556: 各々一括して扱われ、リポジトリに取り込まれる前に、
 8557: 適切なフィルタが適用されます。@xref{Wrappers}.
 8558: 
 8559: 外部からのソースは第一層の枝、既定だと 1.1.1 に保存されます。
 8560: 以降の更新は全てこの枝の葉となります。
 8561: 例えば最初に取り込んだソース集合のファイルは
 8562: リビジョン 1.1.1.1 になり、次の取り込みで
 8563: そのファイルが更新された場合には 1.1.1.2 となり、以下同様に続きます。
 8564: 
 8565: 少なくとも次の三つの引数を指定する必要があります。
 8566: まずソース集合を識別するために @var{repository} が必要です。
 8567: 次の @var{vendortag} は枝全体 (例えば 1.1.1) を示すタグ名です。
 8568: そして @code{import} を実行する度に作成される葉のうち、
 8569: どの葉のファイルかを識別するため、
 8570: 最低一つの @var{releasetag} を指定しなくてはいけません。
 8571: 
 8572: @c I'm not completely sure this belongs here.  But
 8573: @c we need to say it _somewhere_ reasonably obvious; it
 8574: @c is a common misconception among people first learning CVS
 8575: @code{import} はそれを起動したディレクトリを変更 @emph{しない} という
 8576: ことに注意してください。特に、ディレクトリを @sc{cvs} の作業ディレクト
 8577: リとして設定しないことに注意してください。もし作業をしたいなら、まずソー
 8578: スを取り込んで、それから違うディレクトリに取り出してください 
 8579: (@pxref{Getting the source})。
 8580: 
 8581: @menu
 8582: * import options::              import のオプション
 8583: * import output::               import の出力
 8584: * import examples::             import の使用例
 8585: @end menu
 8586: 
 8587: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8588: @node import options
 8589: @appendixsubsec import のオプション
 8590: 
 8591: @code{import} では、以下の標準オプションが利用できます 
 8592: (完全な記述は @pxref{Common options}):
 8593: 
 8594: @table @code
 8595: @item -m @var{message}
 8596: エディタを立ち上げる代りに、@var{message} をログ情報に指定します。
 8597: @end table
 8598: 
 8599: 以下のような追加の特別なオプションがあります。
 8600: 
 8601: @table @code
 8602: @item -b @var{branch}
 8603: @ref{Multiple vendor branches} 参照。
 8604: 
 8605: @item -k @var{subst}
 8606: 希望するキーワード置換モードを指定します。
 8607: この設定は、新たに取り入れる全てのファイルに適用されますが、
 8608: リポジトリに既に存在するファイルには適用されません。
 8609: @samp{-k} に使用できる設定の一覧は @ref{Substitution modes} 参照。
 8610: 
 8611: @item -I @var{name}
 8612: 取り込む際に無視するファイル名を指定します。
 8613: 無視したいファイルが複数あるときは、
 8614: このオプションを何個並べても構いません。
 8615: 全てのファイルを無視したくない場合は、
 8616: (それらは既定では無視されるとしても) `-I !' と指定して下さい。
 8617: 
 8618: @var{name} には、ファイル @file{.cvsignore} と同じ
 8619: ファイル名形式が使用できます。@xref{cvsignore}.
 8620: @c -- Is this really true?
 8621: 
 8622: @item -W @var{spec}
 8623: 取り込む際に、
 8624: フィルタを適用したいファイル名を指定します。
 8625: フィルタを適用したいファイルが複数あるときは、
 8626: このオプションを何個並べても構いません。
 8627: 
 8628: @var{spec} には、ファイル @file{.cvswrappers} と同じ
 8629: ファイル名形式が使用できます。@xref{Wrappers}.
 8630: @end table
 8631: 
 8632: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8633: @node import output
 8634: @appendixsubsec import の出力
 8635: 
 8636: @code{import} の進行状況を知らせるために、
 8637: 処理中のファイル名が一行ずつ表示され、
 8638: 行頭にはファイルの状態を示す文字が付加されます:
 8639: 
 8640: @table @code
 8641: @item U @var{file}
 8642: このファイルが既にリポジトリに存在し、かつ変更されてないことを示します。
 8643: (必要ならば) 新しいリビジョンが作成されます。
 8644: 
 8645: @item N @var{file}
 8646: このファイルが新規であり、リポジトリに追加されたことを示します。
 8647: 
 8648: @item C @var{file}
 8649: このファイルが既にリポジトリに存在し、かつ変更されていて、
 8650: マージが必要であることを示します。
 8651: 
 8652: @item I @var{file}
 8653: このファイルが無視されることを示します (@pxref{cvsignore})。
 8654: 
 8655: @cindex symbolic link, importing
 8656: @cindex link, symbolic, importing
 8657: @c FIXME: also (somewhere else) probably
 8658: @c should be documenting what happens if you "cvs add"
 8659: @c a symbolic link.  Also maybe what happens if
 8660: @c you manually create symbolic links within the
 8661: @c repository (? - not sure why we'd want to suggest
 8662: @c doing that).
 8663: @item L @var{file}
 8664: このファイルがシンボリック・リンクであることを示します。
 8665: @code{cvs import} はシンボリック・リンクを無視します。いろんな人が定期
 8666: 的にこの振舞いは変更されるべきだと提案しますが、どれに変更されるべきか
 8667: についての同意があるとすれば、それは明らかでないように思われます。
 8668: (管理用ファイル @file{modules} の各種オプションを checkout や update
 8669: 等でシンボリック・リンクを再生成するために使うことができます。
 8670: @pxref{modules}。)
 8671: @end table
 8672: 
 8673: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8674: @node import examples
 8675: @appendixsubsec import の使用例
 8676: 
 8677: @ref{Tracking sources} と @ref{From files} を参照して下さい。
 8678: 
 8679: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8680: @node log
 8681: @appendixsec log---ファイルのログ情報を表示
 8682: @cindex Log (subcommand)
 8683: 
 8684: @itemize @bullet
 8685: @item
 8686: 書式: log [options] [files@dots{}]
 8687: @item
 8688: 必須: リポジトリ, 作業ディレクトリ
 8689: @item
 8690: 変更: なし
 8691: @end itemize
 8692: 
 8693: ファイルのログ情報を表示します。以前の @code{log} は 
 8694: @sc{rcs} のコマンド @code{rlog} を呼び出していましたが、
 8695: 現在はそうではありません。しかしこのような経緯から、
 8696: このコマンドの出力やオプションは、
 8697: 他の @sc{cvs} コマンドとは異なったものになっています。
 8698: 
 8699: @cindex timezone, in output
 8700: @cindex zone, time, in output
 8701: @c Kind of a funny place to document the timezone used
 8702: @c in output from commands other than @code{log}.
 8703: @c There is also more we need to say about this,
 8704: @c including what happens in a client/server environment.
 8705: このコマンドの出力には、@sc{rcs} ファイルの所在、
 8706: @dfn{先頭}リビジョン (幹の最新リビジョン)、
 8707: 全てのタグ名などが含まれます。
 8708: 各リビジョンに対しては、リビジョン番号、格納者、
 8709: 追加/削除された行数、ログ・メッセージが表示されます。
 8710: また時間は全て協定世界時 (UTC) で表示されます。
 8711: (@sc{cvs} の他の部分では地方時間帯による時刻を表示します。)
 8712: @c FIXCVS: need a better way to control the timezone
 8713: @c used in output.  Previous/current versions of CVS did/do
 8714: @c sometimes support -z in RCSINIT, and/or an
 8715: @c undocumented (except by reference to 'rlog') -z option
 8716: @c to cvs log, but this has not been a consistent,
 8717: @c documented feature.  Perhaps a new global option,
 8718: @c where LT means the client's timezone, which the
 8719: @c client then communicates to the server, is the
 8720: @c right solution.
 8721: 
 8722: @strong{警告:} @code{log} は @samp{-R} を @sc{cvs} 普通の使用と衝突す
 8723: る方法で使います (@pxref{Common options})。
 8724: 
 8725: @menu
 8726: * log options::                 log のオプション
 8727: * log examples::                log の例
 8728: @end menu
 8729: 
 8730: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8731: @node log options
 8732: @appendixsubsec log のオプション
 8733: 
 8734: オプションを指定しなければ、@code{log} は利用できる全ての
 8735: 情報を表示します。つまりオプションは全て出力を制限するものです。
 8736: 
 8737: @table @code
 8738: @item -b
 8739: 既定の枝 (通常は幹で最も大きな番号の枝) に関する情報を表示します。
 8740: 
 8741: @item -d @var{dates}
 8742: @var{dates} に示されたリビジョンの情報を表示します。
 8743: @var{dates} には格納日時の範囲をセミコロンで区切って記述します。
 8744: 日時の表現形式は他の @sc{cvs} コマンドの 
 8745: @samp{-D} オプションと同じです (@pxref{Common options})。
 8746: それを次のように組み合わせて、格納日時の範囲を表現します:
 8747: 
 8748: @c Should we be thinking about accepting ISO8601
 8749: @c ranges?  For example "1972-09-10/1972-09-12".
 8750: @table @code
 8751: @item @var{d1}<@var{d2}
 8752: @itemx @var{d2}>@var{d1}
 8753: @var{d1} から @var{d2} までの間に格納されたリビジョンを選択します。
 8754: 
 8755: @item <@var{d}
 8756: @itemx @var{d}>
 8757: @var{d} より前に格納された全てのリビジョンを選択します。
 8758: 
 8759: @item @var{d}<
 8760: @itemx >@var{d}
 8761: @var{d} より後に格納された全てのリビジョンを選択します。
 8762: 
 8763: @item @var{d}
 8764: @var{d} 以前の最新のリビジョンを一つ選択します。
 8765: @end table
 8766: 
 8767: @samp{>} や @samp{<} の後に @samp{=} を付ければ、端を含まない
 8768: 範囲指定ではなく、端を含むような範囲指定が可能です。
 8769: 
 8770: 要素の区切りがセミコロン @samp{;} であることに注意して下さい。
 8771: 
 8772: @item -h
 8773: @sc{rcs} ファイルの名前, 作業ディレクトリのファイル名, 先頭リビジョン,
 8774: 既定の枝, 利用者一覧, ロックモード, タグ名, 拡張子を表示します。
 8775: 
 8776: @item -l
 8777: Local、つまり現在の作業ディレクトリでのみコマンドが
 8778: 実行されます。(これを指定しない場合再帰的に実行されます)。
 8779: 
 8780: @item -N
 8781: このファイルではタグ名の一覧を表示しません。
 8782: タグ名を多く使用していると、その表示だけで3ページ以上のタグ情報を 
 8783: "more" することになります。
 8784: タグ名を省略したログ情報でも構わないときは、
 8785: このオプションを指定すると便利です。
 8786: 
 8787: @item -R
 8788: @sc{rcs} ファイルの名前だけを表示します。
 8789: 
 8790: @c Note that using a bare revision (in addition to not
 8791: @c being explicitly documented here) is potentially
 8792: @c confusing; it shows the log message to get from the
 8793: @c previous revision to that revision.  "-r1.3 -r1.6"
 8794: @c (equivalent to "-r1.3,1.6") is even worse; it
 8795: @c prints the messages to get from 1.2 to 1.3 and 1.5
 8796: @c to 1.6.  By analogy with "cvs diff", users might
 8797: @c expect that it is more like specifying a range.
 8798: @c It is not 100% clear to me how much of this should
 8799: @c be documented (for example, multiple -r options
 8800: @c perhaps could/should be deprecated given the false
 8801: @c analogy with "cvs diff").
 8802: @c In general, this section should be rewritten to talk
 8803: @c about messages to get from revision rev1 to rev2,
 8804: @c rather than messages for revision rev2 (that is, the
 8805: @c messages are associated with a change not a static
 8806: @c revision and failing to make this distinction causes
 8807: @c much confusion).
 8808: @item -r@var{revisions}
 8809: @var{revisions} に示されたリビジョンの情報を表示します。
 8810: @var{revisions} にはリビジョンの範囲をカンマで区切って記述します。
 8811: 利用可能な範囲指定の書式を次に示します:
 8812: 
 8813: @table @code
 8814: @item @var{rev1}:@var{rev2}
 8815: @var{rev1} から @var{rev2} までのリビジョンを選択します (同じ枝である
 8816: 必要があります)。
 8817: 
 8818: @item :@var{rev}
 8819: 枝の最初から @var{rev} までのリビジョンを選択します。
 8820: 
 8821: @item @var{rev}:
 8822: @var{rev} から同じ枝の最後のリビジョンまでを選択します。
 8823: 
 8824: @item @var{branch}
 8825: 枝 @var{branch} にある全てのリビジョンを選択します。
 8826: 
 8827: @item @var{branch1}:@var{branch2}
 8828: この範囲内の枝にある全てのリビジョンを選択します。
 8829: 
 8830: @item @var{branch}.
 8831: 枝 @var{branch} の最新リビジョンを選択します。
 8832: @end table
 8833: 
 8834: リビジョンを指定せず @samp{-r} だけを指定した場合、
 8835: 既定の枝、通常は幹の最新リビジョンを選択します。
 8836: 従って @samp{-r} と引数との間に空白を入れないようにして下さい。
 8837: 
 8838: @item -s @var{states}
 8839: @var{states} と状態が一致するリビジョンの情報を表示します。
 8840: @var{states} にはファイルの状態をカンマで区切って記述します。
 8841: 
 8842: @item -t
 8843: @samp{-h} の情報に、ファイルの説明文を追加して表示します。
 8844: 
 8845: @item -w@var{logins}
 8846: @var{logins} に示された使用者が格納したリビジョンの情報を表示します。
 8847: @var{logins} には使用者名をカンマで区切って記述します。
 8848: @var{logins} を省略した場合、コマンドを起動した人物の
 8849: 使用者名が用いられます。
 8850: 従って @samp{-w} と引数との間に空白を入れないようにして下さい。
 8851: @end table
 8852: 
 8853: @code{log} は、オプション @samp{-d}, @samp{-s}, @samp{-w} の
 8854: 全てに適合し、かつ @samp{-b}, @samp{-r} のいずれかに適合した
 8855: リビジョンに関する情報を表示します。
 8856: 
 8857: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8858: @node log examples
 8859: @appendixsubsec log の使用例
 8860: 
 8861: 使用例を募集しています。
 8862: 
 8863: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8864: @node rdiff
 8865: @appendixsec rdiff---リリース間の `patch' 形式の差分
 8866: @cindex Rdiff (subcommand)
 8867: 
 8868: @itemize @bullet
 8869: @item
 8870: 書式: rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules@dots{}
 8871: @item
 8872: 必須: リポジトリ
 8873: @item
 8874: 変更: なし
 8875: @item
 8876: 別名: patch
 8877: @end itemize
 8878: 
 8879: 二つのリリース間の差分を、
 8880: Larry Wall の @samp{patch(1)} ファイル形式で生成します。
 8881: この出力を直接 @code{patch} プログラムに食わせて、
 8882: 古いリリースを新しいリリースに更新できます。
 8883: (これは作業ディレクトリを必要とせず、直接リポジトリを操作する
 8884: 数少ない @sc{cvs} コマンドの一つです。) 
 8885: このコマンドの実行結果は標準出力に送られます。
 8886: 
 8887: 一つないし二つのリビジョンか日付の組み合わせを 
 8888: (標準オプション @samp{-r} や @samp{-D} を用いて) 
 8889: 指定することができます。
 8890: リビジョンか日付を一つだけ指定した場合、
 8891: 指定したものと @sc{rcs} ファイルの先頭リビジョンとの差分が
 8892: パッチ・ファイルとして出力されます。
 8893: 
 8894: ソフトウェア配布物が複数のディレクトリから構成される場合、
 8895: 別のディレクトリに置かれた古いソースを参照するために、
 8896: @code{patch} コマンドにオプション @samp{-p} を
 8897: 指定する必要があるかも知れません。
 8898: 
 8899: @menu
 8900: * rdiff options::               rdiff のオプション
 8901: * rdiff examples::              rdiff の使用例
 8902: @end menu
 8903: 
 8904: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8905: @node rdiff options
 8906: @appendixsubsec rdiff のオプション
 8907: 
 8908: @code{rdiff} では、以下の標準オプションが利用できます 
 8909: (完全な記述は @pxref{Common options}):
 8910: 
 8911: @table @code
 8912: @item -D @var{date}
 8913: @var{date} 以前の最も新しいリビジョンを利用します。
 8914: 
 8915: @item -f
 8916: 指定したリビジョンが見付からなかった場合、
 8917: (そのファイルを無視せずに) 最も新しいリビションを用います。
 8918: 
 8919: @item -l
 8920: Local、つまり現在の作業ディレクトリでのみコマンドが
 8921: 実行されます。
 8922: 
 8923: @item -R
 8924: ディレクトリを再帰的に検査します。
 8925: このオプションは指定しなくても実行されます。
 8926: 
 8927: @item -r @var{tag}
 8928: @var{tag} で指定されたリビジョンを用います。
 8929: @end table
 8930: 
 8931: さらに以下のオプションも使用可能です:
 8932: 
 8933: @table @code
 8934: @item -c
 8935: Context 形式で出力します。
 8936: これが既定形式なので指定する必要はありません。
 8937: 
 8938: @item -s
 8939: パッチの代りに変更要旨だけが報告されます。
 8940: 指定したリリース間で変更されたり追加されたファイルの情報が
 8941: 標準出力に送られます。
 8942: これは例えば、二つの日付やリビジョン間で変更された
 8943: ファイルを一覧するのに便利です。
 8944: 
 8945: @item -t
 8946: 先頭にある二つのリビジョン間の差分を標準出力に送ります。
 8947: これは、そのファイルの最新の変更点を見るときに使います。
 8948: 
 8949: @item -u
 8950: Context 形式ではなく、unidiff 形式を用います。
 8951: 古いバージョンの @code{patch} プログラムは unidiff 形式を扱えないので、
 8952: パッチをネットに投稿するつもりならば、
 8953: @samp{-u} を使用しない方が賢明でしょう。
 8954: 
 8955: @item -V @var{vn}
 8956: @sc{rcs} のバージョン @var{vn} における展開方法に従って、
 8957:  キーワードを展開します 
 8958: (@sc{rcs} のバージョン 5 で展開方法が変更されました)。
 8959: このオプションはもう使用できないことに注意してください。
 8960: CVS は @sc{rcs} バージョン 5 がするように常にキーワードを展開します。
 8961: @end table
 8962: 
 8963: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 8964: @node rdiff examples
 8965: @appendixsubsec rdiff の使用例
 8966: 
 8967: @t{foo@@example.net} から、
 8968: コンパイラ @samp{tc} をリリース 1.2 から 1.4 へ更新したい、
 8969: というメールを受け取ったと仮定します。
 8970: 手元にそんなパッチがない場合でも、
 8971: @sc{cvs} なら次のようなコマンドを使って簡単に対応できます:
 8972: 
 8973: @example
 8974: $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
 8975: $$ Mail -s 'The patches you asked for' foo@@example.net
 8976: @end example
 8977: 
 8978: リリース 1.3 のバグ修正用に枝 @samp{R_1_3fix} を作成し、
 8979: 修正後のリリース 1.3.1 にタグ @samp{R_1_3_1} を付けたと仮定します。
 8980: この枝に対して、修正版以降に加えられた開発の概略を知りたい場合は、
 8981: 次のようなコマンドを使います:
 8982: 
 8983: @example
 8984: $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
 8985: cvs rdiff: Diffing module-name
 8986: File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
 8987: File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
 8988: File bar.h,v changed from revision 1.29.2.1 to 1.2
 8989: @end example
 8990: 
 8991: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 8992: @node release
 8993: @appendixsec release---モジュールの放棄を表明する
 8994: @cindex Release (subcommand)
 8995: 
 8996: @itemize @bullet
 8997: @item
 8998: 書式: release [-d] directories@dots{}
 8999: @item
 9000: 必須: 作業ディレクトリ
 9001: @item
 9002: 変更: 作業ディレクトリ, history のログ情報
 9003: @end itemize
 9004: 
 9005: このコマンドは @samp{cvs checkout} の効果を安全に消し去ります。
 9006: @sc{cvs} はファイルをロックしないため、
 9007: このコマンドが絶対に必要なわけではありません。
 9008: 作業ディレクトリを単に削除したいなら、それでも構いません。
 9009: ただしこの場合、うっかりすると変更内容を失う恐れがあります。
 9010: またファイル @file{history} (@pxref{history file}) にも、
 9011: 作業ディレクトリを放棄したという情報が残りません。
 9012: 
 9013: これらの問題を避けるためにも @samp{cvs release} を使用して下さい。
 9014: このコマンドは、未格納の変更点が残ってないかどうか調べます。
 9015: 次に @sc{cvs} の作業ディレクトリのすぐ上で実行しているかどうか調べます。
 9016: さらに作業ディレクトリに記録されたリポジトリが、
 9017: モジュールに定義されているリポジトリと等しいかどうか調べます。
 9018: 
 9019: 上記全ての条件が満たされた場合にだけ、
 9020: (作業ディレクトリを故意に放棄した証拠として) 
 9021: @sc{cvs} の履歴ログ に @samp{cvs release} の実行記録が残されます。
 9022: 
 9023: @menu
 9024: * release options::             release のオプション
 9025: * release output::              release の出力
 9026: * release examples::            release の使用例
 9027: @end menu
 9028: 
 9029: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9030: @node release options
 9031: @appendixsubsec release のオプション
 9032: 
 9033: @code{release} ではオプションが一つだけ利用できます:
 9034: 
 9035: @table @code
 9036: @item -d
 9037: 放棄判定に成功したとき、作業ディレクトリを削除します。
 9038: このフラグを指定しない場合、
 9039: 作業ディレクトリはそのまま残されます。
 9040: 
 9041: @strong{警告:}  @code{release} コマンドは
 9042: 全てのディレクトリとファイルを再帰的に削除していきます。
 9043: これには重篤な副作用があり、作業ディレクトリに作成したけれど、
 9044: リポジトリには追加してないディレクトリ全てが、
 9045: (@code{add} コマンド使って。@pxref{Adding files})
 9046: 何の表示も無く削除されます---その中身が空でなくても!
 9047: @end table
 9048: 
 9049: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9050: @node release output
 9051: @appendixsubsec release の出力
 9052: 
 9053: @code{release} によって作業ディレクトリを放棄する前に、
 9054: 最新でないファイルそれぞれについて一行ずつ状態を表示します。
 9055: 
 9056: @strong{警告:}  作成はしたけれど、@code{add} コマンドを用いて 
 9057: (@pxref{Adding files}) @sc{cvs} のディレクトリ階層に
 9058: 加えてないディレクトリは、全て中身があっても完全に無視され 
 9059: (@samp{-d} が指定されていれば削除され) ます。
 9060: @c FIXCVS: This is a bug.  But is it true?  I think
 9061: @c maybe they print "? dir" now.
 9062: 
 9063: @table @code
 9064: @item U @var{file}
 9065: @itemx P @var{file}
 9066: より新しいリビジョンがリポジトリに存在し、
 9067: かつ作業ファイルが編集されてないことを示します。
 9068: (@samp{U} と @samp{P} は同じです。)
 9069: 
 9070: @item A @var{file}
 9071: 作業ディレクトリにファイルが追加されたけれど、
 9072: まだリポジトリには格納されてないことを示します。
 9073: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 9074: 
 9075: @item R @var{file}
 9076: 作業ファイルは削除されているけれど、まだこの変更が格納されてないため、
 9077: リポジトリからは削除されてないことを示します。@xref{commit}.
 9078: 
 9079: @item M @var{file}
 9080: 作業ディレクトでファイルが修正されています。リポジトリにも新しいリビジョ
 9081: ンがあるかもしれません。
 9082: 
 9083: @item ? @var{file}
 9084: 作業ディレクトリに @var{file} というファイルがあるが、
 9085: リポジトリには対応するファイルが無く、
 9086: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 9087: (@samp{-I} オプションの説明の参照と、@pxref{cvsignore})。
 9088: 作業ディレクトリを削除すれば、このファイルは失なわれます。
 9089: @end table
 9090: 
 9091: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9092: @node release examples
 9093: @appendixsubsec release の使用例
 9094: 
 9095: ディレクトリ @file{tc} の放棄判定をしてから作業ディレクトリを削除しま
 9096: す。
 9097: 
 9098: @example
 9099: $ cd ..         # @r{@samp{cvs release} は作業ディレクトリの}
 9100:                 # @r{すぐ上で実行しなくてはいけません。}
 9101: $ cvs release -d tc
 9102: You have [0] altered files in this repository.
 9103: Are you sure you want to release (and delete) directory `tc': y
 9104: $
 9105: @end example
 9106: 
 9107: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 9108: @node update
 9109: @appendixsec update---作業コピーをリポジトリと一致させる
 9110: @cindex Update (subcommand)
 9111: 
 9112: @itemize @bullet
 9113: @item
 9114: 書式: update [-AdflPpR] [-d] [-r tag|-D date] files@dots{}
 9115: @item
 9116: 必須: リポジトリ, 作業ディレクトリ
 9117: @item
 9118: 変更: 作業ディレクトリ
 9119: @end itemize
 9120: 
 9121: 共有するリポジトリから作業コピーを取り出した後でも、
 9122: 他の開発者はリポジトリのソースを変更し続けるでしょう。
 9123: 開発工程の然るべき時に @code{update} コマンドを使えば、
 9124: 最後の @code{checkout} や @code{update} 以降の、
 9125: どのリビジョンでも取り入れることができます。
 9126: 
 9127: @menu
 9128: * update options::              update のオプション
 9129: * update output::               update の出力
 9130: @end menu
 9131: 
 9132: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9133: @node update options
 9134: @appendixsubsec update のオプション
 9135: 
 9136: @code{update} では、以下の標準オプションが利用できます 
 9137: (完全な記述は @pxref{Common options}):
 9138: 
 9139: @table @code
 9140: @item -D date
 9141: @var{date} 以前の最も新しいリビジョンを利用します。
 9142: このオプションは貼り付けられ、
 9143: 勝手に @samp{-P} オプションも実行されます。
 9144: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9145: 
 9146: @item -f
 9147: @samp{-D @var{date}} や @samp{-r @var{tag}} と一緒に指定します。
 9148: 指定したリビジョンが見付からなかった場合、
 9149: (そのファイルを無視せずに) 最も新しいリビションを取り出します。
 9150: 
 9151: @item -k @var{kflag}
 9152: キーワード置換モードを @var{kflag} に指定します。
 9153: 詳細は @ref{Substitution modes} を参照。
 9154: このオプションは貼り付けられます。つまりこれ以後、
 9155: この作業ディレクトリでファイルが更新されるときには、
 9156: 同じ @var{kflag} が使用され続けます。
 9157: @code{status} コマンドを用いて
 9158: 貼り付いたオプションを見ることができます。
 9159: @code{status} コマンドの情報は @ref{Invoking CVS} を参照してください。
 9160: 
 9161: @item -l
 9162: Local、つまり現在の作業ディレクトリでのみコマンドが
 9163: 実行されます。@xref{Recursive behavior}.
 9164: 
 9165: @item -P
 9166: 空になったディレクトリを削除 (prune) します。
 9167: @ref{Moving directories} 参照。
 9168: 
 9169: @item -p
 9170: ファイルを標準出力に送り (pipe) ます。
 9171: 
 9172: @item -R
 9173: ディレクトリを再帰的に更新します (既定)。@xref{Recursive behavior}.
 9174: 
 9175: @item -r rev
 9176: @var{tag} で指定されたリビジョン/タグを取り出します。
 9177: このオプションは貼り付けられ、
 9178: @samp{-P} オプションも勝手に実行されます。
 9179: 貼り付いたタグ/日付についての詳細は @pxref{Sticky tags}.
 9180: @end table
 9181: 
 9182: @need 800
 9183: さらに @code{update} では次の固有オプションも使用可能です。
 9184: 
 9185: @table @code
 9186: @item -A
 9187: 貼り付いた全てのタグや日付、
 9188: また @samp{-k} オプションの指定を剥がします。
 9189: 貼り付いたタグ/日付についての詳細は @ref{Sticky tags}.
 9190: 
 9191: @item -d
 9192: リポジトリに存在し、
 9193: 作業ディレクトリに無いディレクトリを作成します。
 9194: 通常は作業ディレクトリに既に存在するものだけが、
 9195: @code{update} の対象となります。
 9196: 
 9197: 最初に @code{checkout} した後にリポジトリに作成された、
 9198: 新たなディレクトリを取り出すときに使用します。
 9199: しかし残念なことに副作用があります。
 9200: 作業ディレクトリを作成するときに、
 9201: (モジュール名を利用したり、
 9202: コマンド行で望みのファイルやディレクトリを明示したりして) 
 9203: 特定のディレクトリを故意に避けていた場合、
 9204: @samp{-d} を使用すると余計なディレクトリまで作成されてしまいます。
 9205: 
 9206: @item -I @var{name}
 9207: @code{update} の際に、
 9208: @var{name} と一致するファイル名が無視されます。
 9209: 無視したいファイルが複数あるときは、
 9210: コマンド行に @samp{-I} を必要なだけ並べても構いません。
 9211: 全てのファイルを無視したくない場合は、
 9212: @samp{-I !} と指定して下さい。
 9213: @sc{cvs} にファイルを無視させる他の方法は @xref{cvsignore}.
 9214: 
 9215: @item -W@var{spec}
 9216: @code{update} の際に、
 9217: フィルタを掛けるべきファイル名を指定します。
 9218: このオプションは繰り返し利用することができます。
 9219: 
 9220: @file{.cvswrappers} と同じ形式を用いて、
 9221: @var{spec} にファイル名を指定します。@xref{Wrappers}.
 9222: 
 9223: @item -j@var{revision}
 9224: @samp{-j} オプションを二つ指定した場合、
 9225: 最初に指定したリビションから次に指定したリビジョンへの変更を、
 9226: 作業ディレクトリにマージします。
 9227: 
 9228: @samp{-j} オプションが一つの場合、
 9229: その分岐リビジョンから指定したリビジョンへの変更を、
 9230: 作業ディレクトリにマージします。
 9231: 分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
 9232: @samp{-j} で指定したリビジョンとの共通の祖先です。
 9233: 
 9234: @samp{-j} オプションに枝を指定する場合、
 9235: 日付の指定を付加することができます。
 9236: このとき選択されるリビジョンは、指定日以前のものに制限されます。
 9237: 日付の指定は、タグ名の後のコロン (:) に続けて記述します: 
 9238: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}。
 9239: 
 9240: @xref{Branching and merging}.
 9241: 
 9242: @end table
 9243: 
 9244: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 9245: @node update output
 9246: @appendixsubsec update の出力
 9247: 
 9248: @code{update} や @code{checkout} の進行状況を知らせるために、
 9249: 処理中のファイル名が一行ずつ表示され、
 9250: 行頭にはファイルの状態を示す文字が付加されます:
 9251: 
 9252: @table @code
 9253: @item U @var{file}
 9254: リポジトリと一致するようにファイルが更新されたことを示します。
 9255: リポジトリに存在するファイルが作業ディレクトリに無かった場合や、
 9256: 修正していない作業コピーよりも新しいバージョンが
 9257: リポジトリに格納されていた場合の処理です。
 9258: 
 9259: @item P @var{file}
 9260: @samp{U} と同様ですが、@sc{cvs} サーバはファイル全体ではなく、パッチを
 9261: 送ります。2つ共結果は同じです。
 9262: 
 9263: @item A @var{file}
 9264: 作業ディレクトリにファイルが加えられ、それをリポジトリに
 9265: 反映するために @samp{commit} の実行が必要な状態を示します。
 9266: つまりファイルの格納を忘れないように注意を促しています。
 9267: 
 9268: @item R @var{file}
 9269: 作業ディレクトリからファイルが削除され、それをリポジトリに
 9270: 反映するために @samp{commit} の実行が必要な状態を示します。
 9271: つまりファイルの格納を忘れないように注意を促しています。
 9272: 
 9273: @item M @var{file}
 9274: 作業ディレクトリで修正されたファイルであることを示します。
 9275: 
 9276: @samp{M} は、ファイルに対する次の二つの修正状態のうちの一方を示します。
 9277: 一つ目は、リポジトリの当該ファイルが修正されていないため、
 9278: このファイルはあなたが最後に見たときと同じ状態にある場合です。
 9279: 二つ目は、作業コピーと同様に、
 9280: リポジトリの当該ファイルも修正されていたため、
 9281: これらを作業ディレクトリでマージした結果、
 9282: 衝突することなく正常に処理された場合です。
 9283: 
 9284: ファイルのマージが行われるとその旨が表示され、
 9285: (@code{update} が実行される前と同じ内容の) 
 9286: 作業ファイルのバックアップ・コピーが生成されます。
 9287: @code{update} の実行中にそのファイルの名前もちゃんと表示されます。
 9288: 
 9289: @item C @var{file}
 9290: @cindex .# files
 9291: @cindex __ files (VMS)
 9292: @var{file} の作業コピーへの変更とリポジトリでの変更をマージした際に、
 9293: 衝突が見つかったことを示します。
 9294: @var{file} (作業コピー) は
 9295: 2つのリビジョンをマージしようとした結果に置き換えられ、
 9296: 元のファイルは @file{.#@var{file}.@var{revision}} という名前で、
 9297: 作業ディレクトリに保存されます。ここで @var{revision} は、
 9298: ファイルの修正を開始した時点での @sc{rcs} 
 9299: リビジョンです。@ref{Conflicts example} の説明を参考にして
 9300: 衝突を解決して下さい。
 9301: @c "some systems" as in out-of-the-box OSes?  Not as
 9302: @c far as I know.  We need to advise sysadmins as well
 9303: @c as users how to set up this kind of purge, if that is
 9304: @c what they want.
 9305: @c We also might want to think about cleaner solutions,
 9306: @c like having CVS remove the .# file once the conflict
 9307: @c has been resolved or something like that.
 9308: (@file{.#} で始まるファイルを数日間利用しなかった場合、
 9309: 自動的に削除するシステムがあることに注意して下さい。
 9310: 元のファイルを保存したい場合は名前を変更すると良いでしょう。) 
 9311: @sc{vms} ではファイル名の先頭に、
 9312: @file{.#} ではなく @file{__} を使用します。
 9313: 
 9314: @item ? @var{file}
 9315: 作業ディレクトリに @var{file} というファイルがあるけれど、
 9316: リポジトリには対応するファイルが無く、
 9317: @sc{cvs} が無視するファイルの一覧にも入ってないことを示します 
 9318: (@samp{-I} オプションの説明及び @pxref{cvsignore} を参照)。
 9319: @end table
 9320: 
 9321: @node Invoking CVS
 9322: @appendix CVS コマンドの簡単な便覧
 9323: @cindex Command reference
 9324: @cindex Reference, commands
 9325: @cindex Invoking CVS
 9326: 
 9327: この付録は、それぞれのコマンドや機能が詳しく説明されているところへの参
 9328: 照とともに、@sc{cvs} の実行のしかたを説明します。他の参照は、@code{cvs
 9329: --help} コマンドを実行するか、@ref{Index} を参照してください。
 9330: 
 9331: @sc{cvs} コマンドは以下の様になります:
 9332: 
 9333: @example
 9334: cvs [ @var{global_options} ] @var{command} [ @var{command_options} ] [ @var{command_args} ]
 9335: @end example
 9336: 
 9337: 標準オプション:
 9338: 
 9339: @table @code
 9340: @item --allow-root=@var{rootdir}
 9341: 正しい @sc{cvsroot} ディレクトリを指定します (サーバのみ) (@sc{cvs} 
 9342: 1.9 以前にはありません)。 @ref{Password authentication server} 参照。
 9343: 
 9344: @item -a
 9345: 全ての通信を認証します (クライアントのみ) (@sc{cvs} 1.9 以前にはありま
 9346: せん)。@ref{Global options} 参照。
 9347: 
 9348: @item -b
 9349: RCS の位置を指定します (@sc{cvs} 1.9 以前)。@ref{Global options} 参照。
 9350: 
 9351: @item -d @var{root}
 9352: @sc{cvsroot} を指定します。@ref{Repository} 参照。
 9353: 
 9354: @item -e @var{editor}
 9355: @var{editor} でメッセージを編集します。@ref{Committing your changes} 
 9356: 参照。
 9357: 
 9358: @item -f
 9359: @file{~/.cvsrc} ファイルを読み込みません。@ref{Global options} 参照。
 9360: 
 9361: @item -H
 9362: @itemx --help
 9363: ヘルプメッセージを印字します。@ref{Global options} 参照。
 9364: 
 9365: @item -l
 9366: CVSROOT/history ファイルにログを残しません。@ref{Global options} 参照。
 9367: 
 9368: @item -n
 9369: どのファイルも変更しません。@ref{Global options} 参照。
 9370: 
 9371: @item -Q
 9372: 本当に出力を抑えます。@ref{Global options} 参照。
 9373: 
 9374: @item -q
 9375: 少しばかり出力を抑えます。@ref{Global options} 参照。
 9376: 
 9377: @item -r
 9378: 新しい作業ファイルを読み込み専用にします。@ref{Global options} 参照。
 9379: 
 9380: @item -s @var{variable}=@var{value}
 9381: 使用者変数を設定します。@ref{Variables} 参照。
 9382: 
 9383: @item -T @var{tempdir}
 9384: 一時ファイルを @var{tempdir} に置きます。@ref{Global options} 参照。
 9385: 
 9386: @item -t
 9387: @sc{cvs} の実行を追跡します。@ref{Global options} 参照。
 9388: 
 9389: @item -v
 9390: @item --version
 9391: @sc{cvs} のバージョンと著作権情報を表示します。
 9392: 
 9393: @item -w
 9394: 新しいファイルを読み込み書き込み可にします。@ref{Global options} 参照。
 9395: 
 9396: @item -x
 9397: 全ての通信を暗号化します (クライアントのみ)。@ref{Global options} 参照。
 9398: 
 9399: @item -z @var{gzip-level}
 9400: 圧縮の度合を設定します (クライアントのみ)。
 9401: @c FIXME: what are the valid values for gzip-level.
 9402: @c And shouldn't this be documented in at least a
 9403: @c little bit of detail somewhere?
 9404: 
 9405: @end table
 9406: 
 9407: キーワード展開モード (@pxref{Substitution modes}):
 9408: 
 9409: @example
 9410: -kkv  $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
 9411: -kkvl $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9412: -kk   $@asis{}Id$
 9413: -kv   file1,v 1.1 1993/12/09 03:21:13 joe Exp
 9414: -ko   @i{非展開}
 9415: -kb   @i{非展開、ファイルはバイナリ}
 9416: @end example
 9417: 
 9418: キーワード (@pxref{Keyword list}):
 9419: 
 9420: @example
 9421: $@asis{}Author: joe $
 9422: $@asis{}Date: 1993/12/09 03:21:13 $
 9423: $@asis{}Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9424: $@asis{}Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
 9425: $@asis{}Locker: harry $
 9426: $@asis{}Name: snapshot_1_14 $
 9427: $@asis{}RCSfile: file1,v $
 9428: $@asis{}Revision: 1.1 $
 9429: $@asis{}Source: /home/files/file1,v $
 9430: $@asis{}State: Exp $
 9431: $@asis{}Log: file1,v $
 9432: Revision 1.1  1993/12/09 03:30:17  joe
 9433: Initial revision
 9434: 
 9435: @end example
 9436: 
 9437: @c The idea behind this table is that we want each item
 9438: @c to be a sentence or two at most.  Preferably a
 9439: @c single line.
 9440: @c
 9441: @c In some cases refs to "foo options" are just to get
 9442: @c this thing written quickly, not because the "foo
 9443: @c options" node is really the best place to point.
 9444: コマンド、コマンドのオプション、コマンドの引数:
 9445: 
 9446: @table @code
 9447: @item add [@var{options}] [@var{files}@dots{}]
 9448: 新しいファイル/ディレクトリを加えます。@ref{Adding files} 参照。
 9449: 
 9450: @table @code
 9451: @item -k @var{kflag}
 9452: キーワード展開を設定します。
 9453: 
 9454: @item -m @var{msg}
 9455: ファイルの説明を設定します。
 9456: @end table
 9457: 
 9458: @item admin [@var{options}] [@var{files}@dots{}]
 9459: リポジトリの履歴ファイルの管理です。@ref{admin} 参照。
 9460: @c This list omits those options which are not
 9461: @c documented as being useful with CVS.  That might be
 9462: @c a mistake...
 9463: 
 9464: @table @code
 9465: @item -b[@var{rev}]
 9466: 既定枝を設定します。@ref{Reverting local changes} 参照。
 9467: 
 9468: @item -c@var{string}
 9469: 註釈符を設定します。
 9470: 
 9471: @item -k@var{subst}
 9472: キーワード置換を設定します。@ref{Keyword substitution} 参照。
 9473: 
 9474: @item -l[@var{rev}]
 9475: @var{rev} か、最新のリビジョンをロックします。
 9476: 
 9477: @item -m@var{rev}:@var{msg}
 9478: リビジョン @var{rev} のログメッセージを @var{msg} で置換します。
 9479: 
 9480: @item -o@var{range}
 9481: リポジトリからリビジョンを消去します。@ref{admin options} 参照。
 9482: 
 9483: @item -q
 9484: 静かに実行します。診断情報を印字しません。
 9485: 
 9486: @item -s@var{state}[:@var{rev}]
 9487: 状態を設定します。
 9488: 
 9489: @c Does not work for client/server CVS
 9490: @item -t
 9491: 標準入力からファイルの説明を設定します。
 9492: 
 9493: @item -t@var{file}
 9494: ファイルの説明を @var{file} から設定します。
 9495: 
 9496: @item -t-@var{string}
 9497: ファイルの説明を @var{string} にします。
 9498: 
 9499: @item -u[@var{rev}]
 9500: リビジョン @var{rev} か、最新のリビジョンのロックを外します。
 9501: @end table
 9502: 
 9503: @item annotate [@var{options}] [@var{files}@dots{}]
 9504: それぞれの行が修正された最新のリビジョンを表示します。@ref{annotate}
 9505: 参照。
 9506: 
 9507: @table @code
 9508: @item -D @var{date}
 9509: @var{date} 以前で一番新しいリビジョンを annotate します。@ref{Common
 9510: options} 参照。
 9511: 
 9512: @item -f
 9513: タグ/日付が見つからない場合は先頭のリビジョンを使います。@ref{Common
 9514: options} 参照。
 9515: 
 9516: @item -l
 9517: Local、つまり現在の作業ディレクトリでのみコマンドが
 9518: 実行されます。@xref{Recursive behavior}.
 9519: 
 9520: @item -R
 9521: 再帰的に動作します (既定動作)。@xref{Recursive behavior}.
 9522: 
 9523: @item -r @var{tag}
 9524: リビジョン @var{tag} を annotate します。@ref{Common options} 参照。
 9525: @end table
 9526: 
 9527: @item checkout [@var{options}] @var{modules}@dots{}
 9528: ソースのコピーを取得します。@ref{checkout} 参照。
 9529: 
 9530: @table @code
 9531: @item -A
 9532: 貼り付いたタグ/日付/オプションを元に戻します。@ref{Sticky tags} と 
 9533: @ref{Keyword substitution} 参照。
 9534: 
 9535: @item -c
 9536: モジュールデータベースを出力します。@ref{checkout options}.
 9537: 
 9538: @item -D @var{date}
 9539: @var{date} のリビジョンを取り出します (貼り付きます)。@ref{Common
 9540: options} 参照。
 9541: 
 9542: @item -d @var{dir}
 9543: @var{dir} に取り出します。@ref{checkout options} 参照。
 9544: 
 9545: @item -f
 9546: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9547: options} 参照。
 9548: 
 9549: @c Probably want to use rev1/rev2 style like for diff
 9550: @c -r.  Here and in on-line help.
 9551: @item -j @var{rev}
 9552: 変更をマージします。@ref{checkout options} 参照。
 9553: 
 9554: @item -k @var{kflag}
 9555: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9556: 
 9557: @item -l
 9558: Local、つまり現在の作業ディレクトリでのみコマンドが
 9559: 実行されます。@xref{Recursive behavior}.
 9560: 
 9561: @item -N
 9562: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{checkout
 9563: options} 参照。
 9564: 
 9565: @item -n
 9566: モジュールプログラム (もしあれば) を実行しません。@ref{checkout
 9567: options} 参照。
 9568: 
 9569: @item -P
 9570: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9571: 
 9572: @item -p
 9573: ファイルを標準出力に取り出します (貼り付きを避けます)。@ref{checkout
 9574: options}。
 9575: 
 9576: @item -R
 9577: 再帰的に動作します(既定動作です)。@xref{Recursive behavior}.
 9578: 
 9579: @item -r @var{tag}
 9580: リビジョン @var{tag} を取り出します。@ref{Common options} 参照。
 9581: 
 9582: @item -s
 9583: -c と似ていますが、モジュールの状態を含みます。@ref{checkout options} 
 9584: 参照。
 9585: @end table
 9586: 
 9587: @item commit [@var{options}] [@var{files}@dots{}]
 9588: 変更をリポジトリに格納します。@ref{commit} 参照。
 9589: 
 9590: @table @code
 9591: @item -F @var{file}
 9592: @var{file} からログメッセージを読み込みます。@ref{commit options} 参照。
 9593: 
 9594: @item -f
 9595: @c What is this "disables recursion"?  It is from the
 9596: @c on-line help; is it documented in this manual?
 9597: ファイルを強制的に格納します。再帰的動作を使用不可にします。
 9598: @ref{commit options} 参照。
 9599: 
 9600: @item -l
 9601: Local、つまり現在の作業ディレクトリでのみコマンドが
 9602: 実行されます。@xref{Recursive behavior}.
 9603: 
 9604: @item -m @var{msg}
 9605: @var{msg} をログメッセージとして使います。@ref{commit options} 参照。
 9606: 
 9607: @item -n
 9608: モジュールプログラム (もしあれば) を実行しません。@ref{commit options}
 9609: 参照。
 9610: 
 9611: @item -R
 9612: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9613: 
 9614: @item -r @var{rev}
 9615: @var{rev} に格納します。@ref{commit options} 参照。
 9616: @c FIXME: should be dragging over text from
 9617: @c commit options, especially if it can be cleaned up
 9618: @c and made concise enough.
 9619: @end table
 9620: 
 9621: @item diff [@var{options}] [@var{files}@dots{}]
 9622: リビジョン間の差分を表示します。@ref{diff} 参照。以下のオプションに加
 9623: えて、出力様式を変更するいろいろなオプションを受け付けます。例えば、
 9624: context diff のための @samp{-c} です。
 9625: 
 9626: @table @code
 9627: @item -D @var{date1}
 9628: 作業ディレクトと日付のリビジョンの差分を取ります。@ref{diff options}
 9629: 参照。
 9630: 
 9631: @item -D @var{date2}
 9632: @var{rev1}/@var{date1} と @var{date2} 間の差分を取ります。@ref{diff
 9633: options} 参照。
 9634: 
 9635: @item -l
 9636: Local、つまり現在の作業ディレクトリでのみコマンドが
 9637: 実行されます。@ref{Recursive behavior} 参照。
 9638: 
 9639: @item -N
 9640: 追加されたり削除されたりしたファイルの差分も含みます。@ref{diff
 9641: options} 参照。
 9642: 
 9643: @item -R
 9644: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9645: 
 9646: @item -r @var{rev1}
 9647: リビジョン @var{rev1} と作業ファイル間の差分を取ります。@ref{diff
 9648: options} 参照。
 9649: 
 9650: @item -r @var{rev2}
 9651: @var{rev1}/@var{date1} と @var{rev2} 間の差分を取ります。@ref{diff
 9652: options} 参照。
 9653: @end table
 9654: 
 9655: @item edit [@var{options}] [@var{files}@dots{}]
 9656: 監視下のファイルを編集する準備をします。@ref{Editing files} 参照。
 9657: 
 9658: @table @code
 9659: @item -a @var{actions}
 9660: 一時監視のための動作を指定します。引数は @code{actions}, @code{edit},
 9661: @code{unedit}, @code{commit}, @code{all}, @code{none} のどれかです。
 9662: @ref{Editing files} 参照。
 9663: 
 9664: @item -l
 9665: Local、つまり現在の作業ディレクトリでのみコマンドが
 9666: 実行されます。@xref{Recursive behavior}.
 9667: 
 9668: @item -R
 9669: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9670: @end table
 9671: 
 9672: @item editors [@var{options}] [@var{files}@dots{}]
 9673: 誰が監視下のファイルを編集しているを見ます。@ref{Watch information} 参
 9674: 照。
 9675: 
 9676: @table @code
 9677: @item -l
 9678: Local、つまり現在の作業ディレクトリでのみコマンドが
 9679: 実行されます。@ref{Recursive behavior} 参照。
 9680: 
 9681: @item -R
 9682: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9683: @end table
 9684: 
 9685: @item export [@var{options}] @var{modules}@dots{}
 9686: CVS からフィルを export するときに使います。@ref{export} 参照。
 9687: 
 9688: @table @code
 9689: @item -D @var{date}
 9690: @var{date} のリビジョンを取り出します。@ref{Common options} 参照。
 9691: 
 9692: @item -d @var{dir}
 9693: @var{dir} に取り出します。@ref{export options} 参照。
 9694: 
 9695: @item -f
 9696: タグ/日付が見つからないと、先頭のリビジョンを使います。@ref{Common
 9697: options} 参照。
 9698: 
 9699: @item -k @var{kflag}
 9700: @var{kflag} キーワード展開を使います。@ref{Substitution modes} 参照。
 9701: 
 9702: @item -l
 9703: Local、つまり現在の作業ディレクトリでのみコマンドが
 9704: 実行されます。@ref{Recursive behavior} 参照。
 9705: 
 9706: @item -N
 9707: -d が指定されたときにモジュールパスを ``短く'' しません。@ref{export
 9708: options} 参照。
 9709: 
 9710: @item -n
 9711: モジュールプログラム (もしあっても) を実行しません。@ref{export
 9712: options} 参照。
 9713: 
 9714: @item -P
 9715: 空のディレクトリを削除します。@ref{Moving directories} 参照。
 9716: 
 9717: @item -R
 9718: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9719: 
 9720: @item -r @var{tag}
 9721: リビジョン @var{tag} を取り出します (貼り付きます)。@ref{Common
 9722: options} 参照。
 9723: @end table
 9724: 
 9725: @item history [@var{options}] [@var{files}@dots{}]
 9726: リポジトリ接続履歴を表示します。@ref{history} 参照。
 9727: 
 9728: @table @code
 9729: @item -a
 9730: 全ての使用者にします (既定は自分自身です)。@ref{history options} 参照。
 9731: 
 9732: @item -b @var{str}
 9733: モジュール名, ファイル名, リポジトリのパスのいずれかに、
 9734: 文字列 @var{str} が含まれる記録のみを表示します。@ref{history options}
 9735: 参照。
 9736: 
 9737: @item -c
 9738: 格納された (修正された) ファイルについて報告します。@ref{history
 9739: options} 参照。
 9740: 
 9741: @item -D @var{date}
 9742: @var{date} から。@ref{history options} 参照。
 9743: 
 9744: @item -e
 9745: 全ての記録種別について報告します。@ref{history options} 参照。
 9746: 
 9747: @item -l
 9748: 最後に修正された (格納されたか、修正されたという報告) もの。
 9749: @ref{history options} 参照。
 9750: 
 9751: @item -m @var{module}
 9752: @var{module} について報告します (繰り返し可能)。@ref{history options}
 9753: 参照。
 9754: 
 9755: @item -n @var{module}
 9756: @var{module} だけ。@ref{history options} 参照。
 9757: 
 9758: @item -o
 9759: 取り出されたモジュールについて報告します。@ref{history options} 参照。
 9760: 
 9761: @item -r @var{rev}
 9762: リビジョン @var{rev} から。@ref{history options} 参照。
 9763: Since revision @var{rev}.  See @ref{history options}.
 9764: 
 9765: @item -T
 9766: @c What the @#$@# is a TAG?  Same as a tag?  This
 9767: @c wording is also in the online-line help.
 9768: 全てのタグについて報告します。@ref{history options} 参照。
 9769: 
 9770: @item -t @var{tag}
 9771: tag の記録が履歴ファイルに (誰かによって) 置かれてから。@ref{history
 9772: options} 参照。
 9773: 
 9774: @item -u @var{user}
 9775: 使用者 @var{user} (繰り返し可能)。@ref{history options} 参照。
 9776: 
 9777: @item -w
 9778: 作業ディレクトリが合わなくてはいけません。@ref{history options} 参照。
 9779: 
 9780: @item -x @var{types}
 9781: @var{types} について報告します。@code{TOEFWUCGMAR} から1つ以上指定しま
 9782: す。@ref{history options} 参照。
 9783: 
 9784: @item -z @var{zone}
 9785: 標準時間帯 @var{zone} で出力します。@ref{history options} 参照。
 9786: @end table
 9787: 
 9788: @item import [@var{options}] @var{repository} @var{vendor-tag} @var{release-tags}@dots{}
 9789: ベンダー枝を使用して CVS にファイルを持ち込みます。@ref{import} 参照。
 9790: 
 9791: @table @code
 9792: @item -b @var{bra}
 9793: ベンダー枝 @var{bra} に持ち込みます。@ref{Multiple vendor branches} 参
 9794: 照。
 9795: 
 9796: @item -d
 9797: ファイルの修正時刻を持ち込みの時間として使用します。@ref{import
 9798: options} 参照。
 9799: 
 9800: @item -k @var{kflag}
 9801: 既定のキーワード置換モードを設定します。@ref{import options} 参照。
 9802: 
 9803: @item -m @var{msg}
 9804: @var{msg} をログメッセージに使います。@ref{import options} 参照。
 9805: 
 9806: @item -I @var{ign}
 9807: 無視するファイルです (無効にするためには ! を使います)。@ref{import
 9808: options} 参照。
 9809: 
 9810: @item -W @var{spec}
 9811: ラッパーです。@ref{import options} 参照。
 9812: @end table
 9813: 
 9814: @item init
 9815: 存在しない場合は CVS リポジトリを作成します。@ref{Creating a
 9816: repository} 参照。
 9817: 
 9818: @item log [@var{options}] [@var{files}@dots{}]
 9819: ファイルの履歴情報を印字します。@ref{log} 参照。
 9820: 
 9821: @table @code
 9822: @item -b
 9823: 既定枝のリビジョンのみを一覧表示します。@ref{log options} 参照。
 9824: 
 9825: @item -d @var{dates}
 9826: 日付を指定します (範囲は @var{d1}<@var{d2} で、それ以前の最新は 
 9827: @var{d} で)。@ref{log options} 参照。
 9828: Specify dates (@var{d1}<@var{d2} for range, @var{d} for
 9829: latest before).  See @ref{log options}.
 9830: 
 9831: @item -h
 9832: ヘッダーのみを印字します。@ref{log options} 参照。
 9833: 
 9834: @item -l
 9835: Local、つまり現在の作業ディレクトリでのみコマンドが
 9836: 実行されます。@ref{Recursive behavior} 参照。
 9837: 
 9838: @item -N
 9839: タグを一覧表示しません。@ref{log options} 参照。
 9840: 
 9841: @item -R
 9842: RCS ファイルの名前のみを印字します。@ref{log options} 参照。
 9843: 
 9844: @item -r@var{revs}
 9845: リビジョン @var{revs} のみを一覧表示します。@ref{log options} 参照。
 9846: 
 9847: @item -s @var{states}
 9848: 指定された状態のリビジョンのみを一覧表示します。@ref{log options} 参照。
 9849: 
 9850: @item -t
 9851: ヘッダーと説明文のみを印字します。@ref{log options} 参照。
 9852: 
 9853: @item -w@var{logins}
 9854: logins で指定された使用者が格納したリビジョンのみを一覧表示します。
 9855: @ref{log options} 参照。
 9856: @end table
 9857: 
 9858: @item login
 9859: 認証サーバのパスワードの入力を促進します。@ref{Password authentication
 9860: client} 参照。
 9861: 
 9862: @item logout
 9863: 保存されている認証サーバのパスワードを消去します。
 9864: @ref{Password authentication client} 参照。
 9865: 
 9866: @item rdiff [@var{options}] @var{modules}@dots{}
 9867: リリース間の差分を表示します。@ref{rdiff} 参照。
 9868: 
 9869: @table @code
 9870: @item -c
 9871: Context diff 出力様式です (既定)。@ref{rdiff options} 参照。
 9872: 
 9873: @item -D @var{date}
 9874: @var{date} に基づいたリビジョンを選択します。@ref{Common options} 参照。
 9875: 
 9876: @item -f
 9877: タグ/日付が見つからない場合は先頭のリビジョンを使用します。@ref{Common
 9878: options} 参照。
 9879: 
 9880: @item -l
 9881: Local、つまり現在の作業ディレクトリでのみコマンドが
 9882: 実行されます。@ref{Recursive behavior} 参照。
 9883: 
 9884: @item -R
 9885: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9886: 
 9887: @item -r @var{rev}
 9888: @var{rev} に基づいたリビジョンを選択します。@ref{Common options} 参照。
 9889: 
 9890: @item -s
 9891: 短いパッチです - ファイルにつき一行です。@ref{rdiff options} 参照。
 9892: 
 9893: @item -t
 9894: 先頭の2つの差分です - ファイルへの最後の変更です。@ref{diff options}
 9895: 参照。
 9896: 
 9897: @item -u
 9898: Unidiff 出力様式です。@ref{rdiff options} 参照。
 9899: 
 9900: @item -V @var{vers}
 9901: RCS バージョン @var{vers} をキーワード展開に使用します (旧式)。
 9902: @ref{rdiff options} 参照。
 9903: @end table
 9904: 
 9905: @item release [@var{options}] @var{directory}
 9906: ディレクトリがもう使われていないことを示します。@ref{release} 参照。
 9907: 
 9908: @table @code
 9909: @item -d
 9910: 与えられたディレクトリを消去します。@ref{release options} 参照。
 9911: @end table
 9912: 
 9913: @item remove [@var{options}] [@var{files}@dots{}]
 9914: リポジトリから登録を消去します。@ref{Removing files} 参照。
 9915: 
 9916: @table @code
 9917: @item -f
 9918: 削除する前にファイルを消去します。@ref{Removing files} 参照。
 9919: 
 9920: @item -l
 9921: Local、つまり現在の作業ディレクトリでのみコマンドが
 9922: 実行されます。@ref{Recursive behavior} 参照。
 9923: 
 9924: @item -R
 9925: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9926: @end table
 9927: 
 9928: @item rtag [@var{options}] @var{tag} @var{modules}@dots{}
 9929: モジュールにタグ名を追加します。@ref{Revisions} と @ref{Branching and
 9930: merging} 参照。
 9931: 
 9932: @table @code
 9933: @item -a
 9934: 削除されたファイルからそうでない場合に付いているタグを消去します。
 9935: @ref{Tagging add/remove} 参照。
 9936: 
 9937: @item -b
 9938: @var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。
 9939: 
 9940: @item -D @var{date}
 9941: @var{date} のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。
 9942: 
 9943: @item -d
 9944: @var{タグ} を消去します。@ref{Modifying tags} 参照。
 9945: 
 9946: @item -F
 9947: 既に @var{タグ} が存在していれば移動します。@ref{Modifying tags} 参照。
 9948: 
 9949: @item -f
 9950: タグ/日付が見つからなければ、先頭のリビジョンとの合致を強制します。
 9951: @ref{Tagging by date/tag} 参照。
 9952: 
 9953: @item -l
 9954: Local、つまり現在の作業ディレクトリでのみコマンドが
 9955: 実行されます。@ref{Recursive behavior} 参照。
 9956: 
 9957: @item -n
 9958: タグプログラムを実行しません。@ref{Common options} 参照。
 9959: 
 9960: @item -R
 9961: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9962: 
 9963: @item -r @var{rev}
 9964: 存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参照。
 9965: @end table
 9966: 
 9967: @item status [@var{options}] @var{files}@dots{}
 9968: 作業ディレクトリの状態の情報を表示します。@ref{File status} 参照。
 9969: 
 9970: @table @code
 9971: @item -l
 9972: Local、つまり現在の作業ディレクトリでのみコマンドが
 9973: 実行されます。@ref{Recursive behavior} 参照。
 9974: 
 9975: @item -R
 9976: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
 9977: 
 9978: @item -v
 9979: ファイルにタグ情報を含めます。@ref{Tags} 参照。
 9980: @end table
 9981: 
 9982: @item tag [@var{options}] @var{tag} [@var{files}@dots{}]
 9983: ファイルの取り出されたリビジョンにタグ名を追加します。@ref{Revisions}
 9984: と @ref{Branching and merging} 参照。
 9985: 
 9986: @table @code
 9987: @item -b
 9988: @var{tag} という名前の枝を作成します。@ref{Branching and merging} 参照。
 9989: 
 9990: @item -c
 9991: 作業ファイルが無修正かどうかを調べます。@ref{Tagging the working
 9992: directory} 参照。
 9993: 
 9994: @item -D @var{date}
 9995: @var{date} の時点のリビジョンにタグを付けます。@ref{Tagging by date/tag} 参照。
 9996: 
 9997: @item -d
 9998: @var{タグ} を消去します。@ref{Modifying tags} 参照。
 9999: 
10000: @item -F
10001: タグが存在していればそれを移動します。@ref{Tagging by date/tag} 参照。
10002: 
10003: @item -f
10004: タグ/日付が見つからなければ先頭のリビジョンとの合致を強制します。
10005: @ref{Tagging by date/tag} 参照。
10006: 
10007: @item -l
10008: Local、つまり現在の作業ディレクトリでのみコマンドが
10009: 実行されます。@ref{Recursive behavior} 参照。
10010: 
10011: @item -R
10012: 再帰的に動作します (既定動作です)。@xref{Recursive behavior}.
10013: 
10014: @item -r @var{rev}
10015: 存在するタグ @var{rev} にタグを付けます。@ref{Tagging by date/tag} 参
10016: 照。
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 とは操作中のファイル名に基づいて設定を制御することを可能にする
10476: @sc{cvs} の機能のことです。設定は、バイナリ・ファイルには @samp{-k} で、
10477: マージできないテキスト・ファイルには @samp{-m} です。
10478: 
10479: @ignore
10480: Wrapper 機能を用いれば、ファイルを @sc{cvs} に取り込む/取り出す際に、
10481: 適切な方法で変換するように設定することができます。
10482: 
10483: 管理用ファイル @file{cvswrappers} には、
10484: ファイル名に合致する正規表現と、
10485: そのファイルに対して実行されるスクリプトが記述されます。
10486: 個々のファイルやディレクトリに対して、二つのスクリプトが記述できます。
10487: 各々リポジトリに格納する前 (@samp{-t} フラグが付けられます) と、
10488: リポジトリから取り出すとき (@samp{-f} フラグが付けられます) に
10489: 実行するものです。@samp{-t}/@samp{-f} 機能はクライアント/サーバの 
10490: @sc{cvs} では動作しません。
10491: @c I think maybe -t/-f works client/server if a single
10492: @c file converts to/from a single file, as opposed to
10493: @c the file<->directory case.  Could use more
10494: @c investigation...
10495: @end ignore
10496: 
10497: また、非バイナリ・ファイルを更新するときの
10498: マージ方針について記述するオプション @samp{-m} があります。
10499: @code{MERGE} は @sc{cvs} が通常用いる方法です:
10500: ファイルをマージしようとすることを意味します。@code{COPY} は @code{cvs
10501: update} はファイルのマージを拒否するという意味で、@samp{-kb} でバイナ
10502: リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
10503: されていれば、@samp{-m 'COPY'} を指定する必要はありません。
10504: CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
10505: ために使用者が @sc{cvs} の外の機構を使用することを要求します。
10506: @strong{警告}: @sc{cvs} 1.9 以前では @code{COPY} を使わないでくださ
10507: い---それらのバージョンの @sc{cvs} はあるバージョンを別の物の上にコピー
10508: し、以前の内容を消し去ってしまいます。
10509: @c Ordinarily we don't document the behavior of old
10510: @c versions.  But this one is so dangerous, I think we
10511: @c must.  I almost renamed it to -m 'NOMERGE' so we
10512: @c could say "never use -m 'COPY'".
10513: Wrapper オプション @samp{-m} は更新時のマージ方針にのみ影響し、
10514: ファイルの格納方法には影響しません。
10515: バイナリ・ファイルの詳細は @ref{Binary files} 参照。
10516: 
10517: 管理用ファイル @file{cvswrappers} の基本的な書式:
10518: 
10519: @c FIXME: @example is all wrong for this.  Use @deffn or
10520: @c something more sensible.
10521: @example
10522: ワイルドカード    [オプション 値][オプション 値]...
10523: 
10524: 利用できるオプションを以下に挙げます。
10525: @ignore
10526: -f                取得時のフィルタ        値: フィルタのパス
10527: -t                格納時のフィルタ        値: フィルタのパス
10528: @end ignore
10529: -m                マージ方針              値: MERGE か COPY
10530: -k                キーワード展開          値: 置換モード
10531: 
10532: 値は以下のように単引用符で囲みます。
10533: @end example
10534: 
10535: @ignore
10536: @example
10537: *.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
10538: *.c      -t 'indent %s %s'
10539: @end example
10540: @c When does the filter need to be an absolute pathname
10541: @c and when will something like the above work?  I
10542: @c suspect it relates to the PATH of the server (which
10543: @c in turn depends on all kinds of stuff, e.g. inetd
10544: @c for pserver).  I'm not sure whether/where to discuss
10545: @c this.
10546: @c FIXME: What do the %s's stand for?
10547: 
10548: @noindent
10549: @file{cvswrappers} の上側の例では、
10550: @samp{.nib} で終わる全てのファイル/ディレクトリを、
10551: リポジトリに格納する前に @file{wrap} プログラムで
10552: 整形することが記述されています。
10553: リポジトリから取り出す際には @file{unwrap} プログラムが用いられます。
10554: またファイルを更新する際には
10555: @code{COPY} する方針を採ることが記述されています 
10556: (すなわち、マージを行いません)。
10557: 
10558: @c What pitfalls arise when using indent this way?  Is
10559: @c it a winning thing to do?  Would be nice to at least
10560: @c hint at those issues; we want our examples to tell
10561: @c how to solve problems, not just to say that cvs can
10562: @c do certain things.
10563: 最後の行の例では、@samp{.c} で終わるファイル全てを、
10564: リポジトリに格納する前に @file{indent} で整形することが記述されています。
10565: 前の例とは異なり、リポジトリから取り出す際には整形されません。
10566: @noindent
10567: @samp{-t} に記述されるフィルタには二つの引数が与えられます。
10568: 最初は整形されるファイル/ディレクトリで、
10569: 次には整形された結果が出力されるファイルのパス名です。
10570: 
10571: @noindent
10572: @samp{-f} に記述されるフィルタには、
10573: 整形されるファイル名が引数として与えられます。
10574: 整形された結果は、作業ディレクトリにファイルとして置かれます。
10575: 
10576: @samp{-t}/@samp{-f} 機能は CVS の操作の一部分---ファ
10577: イルが修正されたとき---を便利に扱えません。CVS はまだファイル (もしく
10578: はディレクトリ) が存在することを望み、その修正時刻をファイルが修正され
10579: たかどうかを決定するために使います。もし CVS が間違ってファイルが未修
10580: 正であると考えれば (例えば、ディレクトリは無変更だけど、その中のファイ
10581: ルのどれかが変更されたとき)、@code{cvs commit} に @samp{-f} オプション
10582: を指定することでとにかくファイルの格納を強制できます (@pxref{commit
10583: options})。
10584: @c This is, of course, a serious design flaw in -t/-f.
10585: @c Probably the whole functionality needs to be
10586: @c redesigned (starting from requirements) to fix this.
10587: @end ignore
10588: 
10589: @c FIXME: We don't document -W or point to where it is
10590: @c documented.  Or .cvswrappers.
10591: 例えば、@samp{.exe} で終わるファイルをバイナリとして扱いながら、
10592: ディレクトリを取り入れます:
10593: 
10594: @example
10595: cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
10596: @end example
10597: 
10598: @c Another good example, would be storing files
10599: @c (e.g. binary files) compressed in the repository.
10600: @c 	::::::::::::::::::
10601: @c 	cvswrappers
10602: @c 	::::::::::::::::::
10603: @c 	*.t12 -m 'COPY'
10604: @c 	*.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
10605: @c
10606: @c	::::::::::::::::::
10607: @c	gunzipcp
10608: @c	::::::::::::::::::
10609: @c	:
10610: @c	[ -f $1 ] || exit 1
10611: @c	zcat $1 > /tmp/.#$1.$$
10612: @c	mv /tmp/.#$1.$$ $1
10613: @c
10614: @c	::::::::::::::::::
10615: @c	gzipcp
10616: @c	::::::::::::::::::
10617: @c	:
10618: @c	DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
10619: @c	if [ ! -d $DIRNAME ] ; then
10620: @c	      DIRNAME=`echo $1 | sed -e "s|.*/||g"`
10621: @c	fi
10622: @c	gzip -c  $DIRNAME  > $2
10623: @c One catch--"cvs diff" will not invoke the wrappers
10624: @c (probably a CVS bug, although I haven't thought it out).
10625: 
10626: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10627: @node commit files
10628: @appendixsec 格納を支援するファイル
10629: @cindex Commit files
10630: 
10631: ファイル @file{modules} 中の @samp{-i} フラグは、
10632: ファイルが格納された時に特定のプログラムを実行するのに用いられます 
10633: (@pxref{modules})。
10634: この節で説明するファイルは、
10635: ファイルの格納時にプログラムを実行するための、
10636: より柔軟な方法を提供します。
10637: 
10638: 格納時に実行できるプログラムは三種類に分けられます。
10639: これらのプログラムはリポジトリ中のファイルに記述されます。
10640: 次に示すのは、
10641: ファイル名と、対応するプログラムに必要な機能を示したものです。
10642: 
10643: @table @file
10644: @item commitinfo
10645: ここに記述されるプログラムは、
10646: 格納が許されるかどうか判断する責任を持ちます。
10647: このプログラムが正常終了しなければ、
10648: 格納が中止されます。
10649: 
10650: @item verifymsg
10651: 指定されたプログラムはログメッセージを評価するために使用され、それは全
10652: ての要求部分を備えているかを検証するかもしれません。これはログメッセー
10653: ジの雛型を保持することのできる @file{rcsinfo} ファイルと組合せて使うと
10654: とても役に立ちます (@pxref{rcsinfo})。
10655: 
10656: @item editinfo
10657: ここに記述されるプログラムは、
10658: ログ・メッセージを編集するのに用いられ、
10659: 全ての要求される項目が含まれるかどうか可能な限り確かめます。
10660: ログ・メッセージの雛型を記述する @file{rcsinfo} ファイルと
10661: 組み合せることで、より便利になります (@pxref{rcsinfo})。(旧式)
10662: 
10663: @item loginfo
10664: ここに記述されるプログラムは、
10665: 格納が完了した時点で呼び出されます。
10666: ログ・メッセージと追加情報とを受け取り、ファイルに格納するか、
10667: 特定の人物にメールとして出すか、またはニュース・グループに投稿するとか、
10668: または@dots{} あなたの想像力だけがその制限です。
10669: @end table
10670: 
10671: @menu
10672: * syntax::                      共通の構文
10673: @end menu
10674: 
10675: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10676: @node syntax
10677: @appendixsubsec 共通の構文
10678: @cindex Info files (syntax)
10679: @cindex Syntax of info files
10680: @cindex Common syntax of info files
10681: 
10682: @c FIXME: having this so totally separate from the
10683: @c Variables node is rather bogus.
10684: 
10685: @file{commitinfo}, @file{loginfo}, @file{rcsinfo}, @file{editinfo},
10686: @file{verifymsg}, などのような管理ファイルには共通の書式があります。
10687: 各ファイルの目的は後述します。
10688: ここでは共通の構文について説明します。
10689: 
10690: @cindex regular expression syntax
10691: 各行は次の要素から構成されます:
10692: @itemize @bullet
10693: @item
10694: @c Say anything about DEFAULT and ALL?  Right now we
10695: @c leave that to the description of each file (and in fact
10696: @c the practice is inconsistent which is really annoying).
10697: 正規表現。これは GNU emacs で使われる構文の基本正規表現です。
10698: @c FIXME: What we probably should be saying is "POSIX Basic
10699: @c Regular Expression with the following extensions (`\('
10700: @c `\|' '+' etc)"
10701: @c rather than define it with reference to emacs.
10702: @c The reference to emacs is not strictly speaking
10703: @c true, as we don't support \=, \s, or \S.  Also it isn't
10704: @c clear we should document and/or promise to continue to
10705: @c support all the obscure emacs extensions like \<.
10706: @c Also need to better cite (or include) full
10707: @c documentation for the syntax.
10708: @c Also see comment in configure.in about what happens to the
10709: @c syntax if we pick up a system-supplied regexp matcher.
10710: 
10711: @item
10712: 項目間の空白---一つ以上のスペース又はタブです。
10713: 
10714: @item
10715: ファイル名又はコマンド行の形式。
10716: @end itemize
10717: 
10718: @noindent
10719: 空白行は無視されます。
10720: また @samp{#} という文字で始まる行は註釈行として扱われます。
10721: 残念ながら、長い行を複数行に分割することは@emph{できません}。
10722: 
10723: リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。
10724: 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。
10725: 
10726: @c FIXME: need an example.  In particular, show what
10727: @c the regular expression is matched against (one
10728: @c ordinarily clueful person got confused about whether it
10729: @c includes the filename--"directory name" above should be
10730: @c unambiguous but there is nothing like an example to
10731: @c confirm people's understanding of this sort of thing).
10732: 
10733: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10734: @node commitinfo
10735: @appendixsec 管理用ファイル commitinfo
10736: @cindex Commitinfo
10737: @cindex Checking commits
10738: @cindex Precommit checking
10739: 
10740: @samp{cvs commit} を実行する直前に必ず実行したいプログラムを、
10741: ファイル @file{commitinfo} に記述します。
10742: 修正、追加、削除されたファイルを格納しても良いかどうか、
10743: このプログラムを用いて格納前に判断します。
10744: 例えば、変更されたファイルがあなたのサイトの
10745: コーディング・スタイルの標準に従っているか確かめることもできます。
10746: 
10747: 前に書いたように、@file{commitinfo} の各行は、第一項の正規表現、
10748: 残りの部分のコマンド行形式から構成されます。
10749: コマンド行の部分には、
10750: プログラム名と適切な数の引数とを記述することができます。
10751: また実行の際には、リポジトリのフルパスと
10752: 格納しようとするファイル名 (追加, 削除, 修正されたファイル名) 
10753: がコマンド行の最後に与えられます。
10754: 
10755: @cindex exit status, of commitinfo
10756: リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。
10757: そしてコマンドが非零で終了した場合は、格納が中止されます。
10758: @c FIXME: need example(s) of what "directory within the
10759: @c repository" means.
10760: 
10761: @cindex DEFAULT in commitinfo
10762: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
10763: ファイル中のどの正規表現にも合致しない場合に適用されます。
10764: 
10765: @cindex ALL in commitinfo
10766: 第一項が @samp{ALL} である行全てが、
10767: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
10768: 
10769: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
10770: @file{commitinfo} に記述された行は、
10771: クライアント側ではなく@emph{別のマシン} (サーバ) 側で実行されます 
10772: (@pxref{Remote repositories})。
10773: 
10774: @c FIXME: should discuss using commitinfo to control
10775: @c who has checkin access to what (e.g. Joe can check into
10776: @c directories a, b, and c, and Mary can check into
10777: @c directories b, c, and d--note this case cannot be
10778: @c conveniently handled with unix groups).  Of course,
10779: @c adding a new set of features to CVS might be a more
10780: @c natural way to fix this problem than telling people to
10781: @c use commitinfo.
10782: @c FIXME: Should make some reference, especially in
10783: @c the context of controlling who has access, to the fact
10784: @c that commitinfo can be circumvented.  Perhaps
10785: @c mention SETXID (but has it been carefully examined
10786: @c for holes?).  This fits in with the discussion of
10787: @c general CVS security in "Password authentication
10788: @c security" (the bit which is not pserver-specific).
10789: 
10790: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10791: @node verifymsg
10792: @appendixsec ログメッセージの検証
10793: @cindex verifymsg (admin file)
10794: @cindex log message, verifying
10795: 
10796: 一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために
10797: そのメッセージを評価することができます。ログメッセージを検証するための
10798: プログラムを指定するために @file{verifymsg} ファイルを使用することがで
10799: きます。このプログラムは入力されたメッセージに必要なフィールドがあるか
10800: どうかを調べる簡単なスプリプトでも良いでしょう。
10801: 
10802: @file{verifymsg} ファイルは、ログメッセージの雛型を指定するために使う
10803: ことのできる @file{rcsinfo} ファイルと一緒に使用されたときにとても役に
10804: 立つことが多いです。
10805: 
10806: @file{verifymsg} ファイルは正規表現とコマンド行の雛型から成ります。雛
10807: 型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで
10808: きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加
10809: されます。
10810: 
10811: 一つ注意しなければならないのは、@samp{ALL} キーワードは使えないという
10812: ことです。一行以上合致した場合、最初のものが使われます。これはディレク
10813: トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき
10814: に役に立ちます。
10815: 
10816: @cindex DEFAULT in verifymsg
10817: リポジトリ名がこのファイルのどの正規表現にも合致しなければ、
10818: @samp{DEFAULT} が指定されていると、それが使用されます。
10819: 
10820: @cindex exit status, of verifymsg
10821: 検証スクリプトが非零の値で終了すれば、格納は中止されます。
10822: 
10823: 検証スクリプトはログメセージを変更できないことに注意してください。単に
10824: 受け入れるか拒否するかのどちらかです。
10825: @c FIXME?  Is this an annoying limitation?  It would be
10826: @c relatively easy to fix (although it would *not* be a
10827: @c good idea for a verifymsg script to interact with the user
10828: @c at least in the client/server case because of locks
10829: @c and all that jazz).
10830: 
10831: 以下は、@file{verifymsg} ファイルのちょっとしたばかげた例と、それに対
10832: 応する @file{rcsinfo} ファイル、ログメッセージの雛型と検証スクリプトで
10833: す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの
10834: 最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの
10835: です。以下の雛型ファイルは @file{/usr/cvssupport/tc.template} にありま
10836: す。
10837: 
10838: @example
10839: BugId:
10840: @end example
10841: 
10842: スクリプト @file{/usr/cvssupoort/bugid.verify} はログメッセージの評価
10843: に使われます。
10844: 
10845: @example
10846: #!/bin/sh
10847: #
10848: #       bugid.verify filename
10849: #
10850: #  Verify that the log message contains a valid bugid
10851: #  on the first line.
10852: #
10853: if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
10854:     exit 0
10855: else
10856:     echo "No BugId found."
10857:     exit 1
10858: fi
10859: @end example
10860: 
10861: @file{verifymsg} ファイルには以下の行があります:
10862: 
10863: @example
10864: ^tc     /usr/cvssupport/bugid.verify
10865: @end example
10866: 
10867: @file{rcsinfo} ファイルには以下の行があります:
10868: 
10869: @example
10870: ^tc     /usr/cvssupport/tc.template
10871: @end example
10872: 
10873: 
10874: 
10875: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10876: @node editinfo
10877: @appendixsec Editinfo
10878: @cindex editinfo (admin file)
10879: @cindex Editor, specifying per module
10880: @cindex Per-module editor
10881: @cindex Log messages, editing
10882: 
10883: @emph{注意:} @file{editinfo} 機能は旧式になっています。ログメッセージ
10884: の既定のエディタを設定するためには、@code{EDITOR} 環境変数 
10885: (@pxref{Environment variables}) か @samp{-e} 広域オプション
10886: (@pxref{Global options}) を使用してください。ログメッセージを評価する
10887: ための @file{verifymsg} 機能を使うための情報は @ref{verifymsg} を参照
10888: してください。
10889: 
10890: いつも同じ形式でログ・メッセージを記録したい場合に、
10891: ログ・メッセージを編集するプログラムを @file{editinfo} に
10892: 指定することができます。
10893: 指定するプログラムは、
10894: ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、
10895: エディタを呼び出して、入力されたメッセージが必要項目を
10896: 満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。
10897: 
10898: 合致する行が @file{editinfo} になかった場合、
10899: 環境変数 @code{$CVSEDITOR} に指定されたエディタを使用します。
10900: この環境変数が設定されていない場合には、
10901: 環境変数 @code{$EDITOR} に指定されたエディタを代わりにします。
10902: そしてこの環境変数も設定されていない場合は、
10903: 既定のものが使われます。@ref{Committing your changes} 参照。
10904: 
10905: @file{rcsinfo} にログ・メッセージの雛型を指定すると、
10906: より効果的に @file{editinfo} を利用できるでしょう。
10907: 
10908: @file{editinfo} の各行は、第一項の正規表現、
10909: 残りの部分のコマンド行形式から構成されます。
10910: コマンド行の部分には、
10911: プログラム名と適切な数の引数とを記述することができます。
10912: また実行の際には、ログ・メッセージの雛型へのフルパス
10913: がコマンド行の最後に与えられます。
10914: 
10915: @samp{ALL} が利用できないことに注意して下さい。
10916: 合致する行が複数あった場合は、最初の行が実行されます。
10917: これは、モジュールの編集スクリプトが設定されていて、
10918: サブディレクトリでは別のものを使用したい場合を考慮しています。
10919: 
10920: @cindex DEFAULT in editinfo
10921: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
10922: ファイル中のどの正規表現にも合致しない場合に適用されます。
10923: 
10924: 編集スクリプトが非零で終了した場合は、格納が中止されます。
10925: 
10926: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合や、
10927: @code{cvs commit} の @samp{-m} または @samp{-F} オプションを
10928: 使用した場合、@file{editinfo} は参照されません。
10929: この問題を解決する良い方法は今のところありません。
10930: 代わりに @file{verifymsg} を使ってください。
10931: 
10932: @menu
10933: * editinfo example::            editinfo 記述例
10934: @end menu
10935: 
10936: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10937: @node editinfo example
10938: @appendixsubsec editinfo 記述例
10939: 
10940: 次に、ちょっとアホくさい @file{editinfo} の使用例を、
10941: 対応する @file{rcsinfo}、ログ・メッセージの雛型、
10942: エディタ・スクリプトと併わせて紹介します。
10943: まずログ・メッセージの雛型ですが、
10944: 最初の行に必ずバグ番号を記録するように促し、
10945: 残りは自由に記述してもらいます。
10946: この雛型は @file{/usr/cvssupport/tc.template} に置くことにします。
10947: 
10948: @example
10949: BugId:
10950: @end example
10951: 
10952: ログ・メッセージを編集するため、
10953: 次のスクリプト @file{/usr/cvssupport/bugid.edit} を使用します。
10954: 
10955: @example
10956: #!/bin/sh
10957: #
10958: #       bugid.edit filename
10959: #
10960: #  Call $EDITOR on FILENAME, and verify that the
10961: #  resulting file contains a valid bugid on the first
10962: #  line.
10963: if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
10964: if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
10965: $CVSEDITOR $1
10966: until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
10967: do  echo -n  "No BugId found.  Edit again? ([y]/n)"
10968:     read ans
10969:     case $@{ans@} in
10970:         n*) exit 1;;
10971:     esac
10972:     $CVSEDITOR $1
10973: done
10974: @end example
10975: 
10976: ファイル @file{editinfo} には次の行を記述します:
10977: 
10978: @example
10979: ^tc     /usr/cvssupport/bugid.edit
10980: @end example
10981: 
10982: ファイル @file{rcsinfo} には次の行を記述します:
10983: 
10984: @example
10985: ^tc     /usr/cvssupport/tc.template
10986: @end example
10987: 
10988: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10989: @node loginfo
10990: @appendixsec 管理用ファイル loginfo
10991: @cindex loginfo (admin file)
10992: @cindex Storing log messages
10993: @cindex Mailing log messages
10994: @cindex Distributing log messages
10995: @cindex Log messages
10996: 
10997: @c "cvs commit" is not quite right.  What we
10998: @c mean is "when the repository gets changed" which
10999: @c also includes "cvs import" and "cvs add" on a directory.
11000: @file{loginfo} を用いて、
11001: @samp{cvs commit} によるログ情報の送り先を管理します。
11002: 各行の第一項には正規表現が記述され、
11003: 行の残りの部分はフィルタでなくてはいけません。
11004: 変更を加えたディレクトリを 
11005: @code{$CVSROOT} からの相対パスで表わしたものと、
11006: 各行の正規表現が合致するかどうか試されます。
11007: 合致した場合は、
11008: その行の残りの部分であるフィルタ・プログラムの標準入力に、
11009: ログ情報を与えます。
11010: 
11011: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11012: ファイル中のどの正規表現にも合致しない場合に適用されます。
11013: 
11014: 第一項が @samp{ALL} である行全てが、
11015: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11016: 
11017: 正規表現が合致する最初の行が実行されます。
11018: 
11019: ファイル @file{loginfo} の構文についての記述は @xref{commit files}.
11020: 
11021: 使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は 
11022: @samp{%} の後に空白か、単独のフォーマット文字、もしくは分離器 
11023: @samp{@{} と @samp{@}} に囲まれたいくつかのフォーマット文字が続いた物
11024: です。フォーマット文字は:
11025: 
11026: @table @t
11027: @item s
11028: ファイル名
11029: @item V
11030: 古いバージョン番号 (格納前)
11031: @item v
11032: 新しいバージョン番号 (格納後)
11033: @end table
11034: 
11035: フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます
11036: (フィールドを分離するコンマはまだ提供されされています。)
11037: 
11038: 例えば、有効なフォーマット文字列は @samp{%}, @samp{%s}, @samp{%@{s@}}, 
11039: @samp{%@{sVv@}} などです。
11040: 
11041: 出力は空白で区切られた語からなる文字列になります。下位互換のために、最
11042: 初の語はリポジトリ名になります。残りの語はフォーマット文字列で要求され
11043: た情報をコンマで分けたリストです。例えば、@samp{/u/src/master} がリポ
11044: ジトリで @samp{%@{sVv@}} がフォーマット文字列、3つのファイル
11045: (@t{ChangeLog}, @t{Makefile}, @t{foo.c}) が修正されていると、出力は:
11046: 
11047: @example
11048: /u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
11049: @end example
11050: 
11051: 別の例として、@samp{%@{@}} ではリポジトリ名のみが作成されます。
11052: 
11053: 注意: @sc{cvs} が別のマシンのリポジトリを利用している場合、
11054: @file{loginfo} はクライアント側ではなく、@emph{別のマシン} 
11055: (サーバ) 側で実行されます 
11056: (@pxref{Remote repositories})。
11057: 
11058: @menu
11059: * loginfo example::             loginfo 記述例
11060: * Keeping a checked out copy::  格納毎にディレクトリを更新
11061: @end menu
11062: 
11063: @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11064: @node loginfo example
11065: @appendixsubsec loginfo 記述例
11066: 
11067: ここで示す @file{loginfo} ファイルと付属のシェル・スクリプトは、
11068: 格納時に次のような動作をします。
11069: まず全てのログ・メッセージを 
11070: @file{$CVSROOT/CVSROOT/commitlog} に追記します。
11071: 次に全ての管理用ファイル (@file{CVSROOT} 内) の
11072: 格納時のログを @file{/usr/adm/cvsroot-log} に追記します。
11073: @file{prog1} ディクトリへの格納は @t{ceder} にメールで送られます。
11074: 
11075: @c FIXME: is it a CVS feature or bug that only the
11076: @c first matching line is used?  It is documented
11077: @c above, but is it useful?  For example, if we wanted
11078: @c to run both "cvs-log" and "Mail" for the CVSROOT
11079: @c directory, it is kind of awkward if
11080: @c only the first matching line is used.
11081: @example
11082: ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
11083: ^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
11084: ^prog1          Mail -s %s ceder
11085: @end example
11086: 
11087: シェル・スクリプト @file{/usr/local/bin/cvs-log} の内容:
11088: 
11089: @example
11090: #!/bin/sh
11091: (echo "------------------------------------------------------";
11092:  echo -n $2"  ";
11093:  date;
11094:  echo;
11095:  cat) >> $1
11096: @end example
11097: 
11098: @node Keeping a checked out copy
11099: @appendixsubsec 取得済のコピーを最新に保つ
11100: 
11101: @c What other index entries?  It seems like
11102: @c people might want to use a lot of different
11103: @c words for this functionality.
11104: @cindex keeping a checked out copy
11105: @cindex checked out copy, keeping
11106: @cindex web pages, maintaining with CVS
11107: 
11108: あるディレクトリがリポジトリで管理されている場合、
11109: そのディレクトリを常に最新にしておきたい事があるでしょう。
11110: 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、
11111: @sc{cvs} で保守されたウェブ・サイトのファイルを
11112: 格納毎に更新したい場合などです。
11113: @c Can we offer more details on the web example?  Or
11114: @c point the user at how to figure it out?  This text
11115: @c strikes me as sufficient for someone who already has
11116: @c some idea of what we mean but not enough for the naive
11117: @c user/sysadmin to understand it and set it up.
11118: 
11119: これを実現するため、
11120: @code{cvs update} を実行するように @file{loginfo} を設定します。
11121: しかし単純に設定するとロックの問題が発生するので、
11122: @code{cvs update} をバックグラウンドで実行する必要があります。
11123: @c Should we try to describe the problem with locks?
11124: @c It seems like a digression for someone who just
11125: @c wants to know how to make it work.
11126: @c Another choice which might work for a single file
11127: @c is to use "cvs -n update -p" which doesn't take
11128: @c out locks (I think) but I don't see many advantages
11129: @c of that and we might as well document something which
11130: @c works for multiple files.
11131: Unix での例を以下に示します (実際は一行です):
11132: 
11133: @example
11134: ^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
11135:  cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
11136: @end example
11137: 
11138: リポジトリ中の @code{cyclic-pages} で始まるディレクトリに
11139: ファイルが格納された時、
11140: 取得済みのディレクトリ @file{/u/www/local-docs} を更新します。
11141: @c More info on some of the details?  The "sleep 2" is
11142: @c so if we are lucky the lock will be gone by the time
11143: @c we start and we can wait 2 seconds instead of 30.
11144: 
11145: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11146: @node rcsinfo
11147: @appendixsec 管理用ファイル rcsinfo
11148: @cindex rcsinfo (admin file)
11149: @cindex Form for log message
11150: @cindex Log message template
11151: @cindex Template for log message
11152: 
11153: @file{rcsinfo} には、格納時にログ・メッセージを
11154: 書き込むための書式を指定します。@file{rcsinfo} の
11155: 構文は @file{verifymsg}, @file{commitinfo}, @file{loginfo} 
11156: とほぼ同じです。@xref{syntax}.
11157: しかし他のファイルと異なり、
11158: 第二項はコマンド行形式では@emph{ありません}。
11159: 正規表現の次の部分は、ログ・メッセージの雛型を記した
11160: ファイルへのフルパス名でなくてはいけません。
11161: 
11162: 第一項が @samp{DEFAULT} である行の記述は、リポジトリ名が
11163: ファイル中のどの正規表現にも合致しない場合に適用されます。
11164: 
11165: 第一項が @samp{ALL} である行全てが、
11166: 最初に合致した正規表現または @samp{DEFAULT} に加えて適用されます。
11167: 
11168: @c FIXME: should be offering advice, somewhere around
11169: @c here, about where to put the template file.  The
11170: @c verifymsg example uses /usr/cvssupport but doesn't
11171: @c say anything about what that directory is for or
11172: @c whether it is hardwired into CVS or who creates
11173: @c it or anything.  In particular we should say
11174: @c how to version control the template file.  A
11175: @c probably better answer than the /usr/cvssupport
11176: @c stuff is to use checkoutlist (with xref to the
11177: @c checkoutlist doc).
11178: @c Also I am starting to see a connection between
11179: @c this and the Keeping a checked out copy node.
11180: @c Probably want to say something about that.
11181: ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。
11182: しかし、@samp{cvs commit -m @var{message}} や @samp{cvs commit -f
11183: @var{file}} によってログ・メッセージを指定した場合、
11184: こちらが優先されます。
11185: 
11186: @file{rcsinfo} ファイルの記述例は @xref{verifymsg}.
11187: 
11188: @sc{CVS} が別のマシンのリポジトリを利用している場合、
11189: 最初に作業ディレクトリを取り出した時に @file{rcsinfo} に
11190: 記述されていた雛型が使用され、以後変更されません。
11191: @file{rcsinfo} や雛型を変更した場合には、
11192: 新たに作業ディレクトリを取り出す必要があります。
11193: @c Would be nice to fix CVS so this isn't needed.  For
11194: @c example, a mechanism analogous to CVS/Entries, where
11195: @c the client keeps track of what version of the template
11196: @c it has.
11197: 
11198: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11199: @node cvsignore
11200: @appendixsec cvsignore でファイルを無視する
11201: @cindex cvsignore (admin file), global
11202: @cindex Global cvsignore
11203: @cindex Ignoring files
11204: @c -- This chapter should maybe be moved to the
11205: @c tutorial part of the manual?
11206: 
11207: 作業コピーの中に、いつも決まった名前のファイルがあるけれど、
11208: @sc{cvs} の管理下には置きたくないという場合がよくあります。
11209: 例えば、ソースのコンパイル時に生成される
11210: オブジェクト・ファイルなどです。
11211: @samp{cvs update} を実行した場合には通常、
11212: これらのファイル各々に対して、
11213: 知らないファイルがあったと出力されます 
11214: (@pxref{update output})。
11215: 
11216: @sc{cvs} は、@code{update}, @code{import}, @code{release}
11217: @c -- 影響があるのはこの三つで全部か?
11218: の実行時に無視すべきファイルのリストを 
11219: (sh(1) のファイル名形式で) 保持します
11220: このリストは、以下の方法で構築されます。
11221: 
11222: @itemize @bullet
11223: @item
11224: リストは以下のファイル名形式で初期化されます: 
11225: これらは、@sc{cvs} の管理に関するものの他、
11226: 他のソース管理システムと共通のもの、
11227: 一般的なパッチ・ファイル名、オブジェクト・ファイル、
11228: 書庫ファイル、エディタのバックアップ・ファイル、
11229: 他のユーティリティの通常の生成ファイル名等から構成されます。
11230: 現在、既定で無視されるファイル名形式のリストを以下に挙げます:
11231: 
11232: @cindex Ignored files
11233: @cindex Automatically ignored files
11234: @example
11235:     RCS     SCCS    CVS     CVS.adm
11236:     RCSLOG  cvslog.*
11237:     tags    TAGS
11238:     .make.state     .nse_depinfo
11239:     *~      #*      .#*     ,*      _$*     *$
11240:     *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
11241:     *.a     *.olb   *.o     *.obj   *.so    *.exe
11242:     *.Z     *.elc   *.ln
11243:     core
11244: @end example
11245: 
11246: @item
11247: リポジトリ毎のリスト 
11248: @file{$CVSROOT/CVSROOT/cvsignore} が存在すれば、
11249: その内容がリストに付加されます。
11250: 
11251: @item
11252: 使用者毎のリスト @file{.cvsignore} が
11253: あなたのホーム・ディレクトリに存在すれば、
11254: その内容がリストに付加されます。
11255: 
11256: @item
11257: 環境変数 @code{$CVSIGNORE} の内容全てがリストに付加されます。
11258: 
11259: @item
11260: @samp{-I} オプションによって @sc{cvs} に与えられた内容が、
11261: リストに付加されます。
11262: 
11263: @item
11264: 作業ディレクトリを一通り見て @file{.cvsignore} があれば、
11265: その内容をリストに付加します。
11266: @file{.cvsignore} 内の形式は、
11267: それが含まれるディレクトリのみで有効であり、
11268: サブディレクトリに対しては効果を持ちません。
11269: @end itemize
11270: 
11271: 上記五つのファイル内で単感嘆符 (@samp{!}) を記述すると、
11272: 無視するファイルのリストが空になります。
11273: これは、通常は @sc{cvs} に無視されるファイルを、
11274: リポジトリに格納したい場合に使用します。
11275: 
11276: @code{cvs import} に @samp{-I !} を指定すると、全てを持ち込み、それは
11277: 素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
11278: でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
11279: るのがわかると思います。もし配布に @file{.cvsignore} ファイルがあると、
11280: そのファイルの形式は @samp{-I !} が指定されたとしても実行されます。唯
11281: 一の対策は持ち込むために、@file{.cvsigonre} ファイルを消去することです。
11282: これはやっかいなので、将来は @samp{-I !} はそれぞれのディレクトリの
11283: @file{.cvsignore} ファイルを上書きするように修正されるかもしれません。
11284: 
11285: 無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ
11286: れぞれの行が続いたものであることに注意してください。これは空白のある
11287: ファイル名を指定する綺麗な方法を提供しませんが、@file{foo bar} という
11288: 名前のファイルに合致させるために @file{foo?bar} のような対策を使うこと
11289: ができます (@file{fooxbar} などにも合致します)。また、現在は註釈を指定
11290: する方法が無いことにも注意してください。
11291: @c FIXCVS?  I don't _like_ this syntax at all, but
11292: @c changing it raises all the usual compatibility
11293: @c issues and I'm also not sure what to change it to.
11294: 
11295: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11296: @node history file
11297: @appendixsec ファイル history
11298: @cindex History file
11299: @cindex Log information, saving
11300: 
11301: ファイル @file{$CVSROOT/CVSROOT/history} は、
11302: @code{history} コマンドのためにログ情報を記録します 
11303: (@pxref{history})。
11304: ログを記録したい場合には、このファイルを作成する必要があります。
11305: @code{cvs init} でリポジトリを準備すると、
11306: 自動的に作成されます (@pxref{Creating a repository})。
11307: 
11308: @file{history} ファイルの書式を説明したものは、
11309: @sc{cvs} ソース・コード内の註釈しかありません。
11310: @sc{cvs} の将来のリリースで書式が変更されるかも知れないので、
11311: このファイルは必ず @code{cvs history} を通して利用して下さい。
11312: 
11313: @node Variables
11314: @appendixsec 管理用ファイルにおける変数展開
11315: 
11316: 管理用ファイルを記述するときに、@sc{cvs} の動作環境についての
11317: 色々な情報を利用したい場合があると思います。
11318: ここでは、その実現方法を幾つか紹介します。
11319: 
11320: @sc{cvs} を実行した人物のホーム・ディレクトリを 
11321: (環境変数 @code{HOME} から) 参照するには、
11322: @samp{/} または行端の直前に @samp{~} を記述します。
11323: 同様に @var{user} のホーム・ディレクトリは、
11324: @samp{~@var{user}} と記述します。
11325: これらの変数はサーバ側で展開されるため、@code{pserver} 
11326: (@pxref{Password authenticated}) を用いる場合には正しく展開されません。
11327: この場合、@sc{cvs} を実行する人物が動作を変更できるように、
11328: ユーザ変数 (下記参照) を用いると良いでしょう。
11329: @c Based on these limitations, should we deprecate ~?
11330: @c What is it good for?  Are people using it?
11331: 
11332: @sc{cvs} 内部の情報を参照したい場合もあると思います。
11333: @sc{cvs} の内部変数は @code{$@{@var{variable}@}} という書式で参照できます。
11334: この @var{variable} は文字で始まり、
11335: アルファベットと @samp{_} から構成されます。
11336: @var{variable} に続く文字がアルファベットや @samp{_} でない場合は、
11337: @samp{@{} と @samp{@}} とを省略しても構いません。
11338: 参照可能な @sc{cvs} の内部変数には次のようなものがあります:
11339: 
11340: @table @code
11341: @item CVSROOT
11342: @sc{cvs} が使用中のルート・ディレクトリを示します。
11343: ルート・ディレクトリの指定方法は、@xref{Repository}.
11344: 
11345: @item RCSBIN
11346: @sc{cvs} 1.9.18 以前では、これは @sc{cvs} が @sc{rcs} プログラムを探す
11347: 場所を指定していました。@sc{cvs} はもう @sc{rcs} プログラムを実行しま
11348: せんので、今はこの内部変数を指定するとエラーになります。
11349: 
11350: @item CVSEDITOR
11351: @itemx VISUAL
11352: @itemx EDITOR
11353: これらは @sc{cvs} が使用するエディタを示し、
11354: 全て同じ値に展開されます。
11355: 指定方法の説明は、@xref{Global options}.
11356: 
11357: @item USER
11358: @sc{cvs} を実行する人物の (@sc{cvs} サーバでの) 名前に展開されます。
11359: @end table
11360: 
11361: ユーザ変数を用いれば、@sc{cvs} を実行する人物が、
11362: 管理用ファイルで用いる値を自由に設定できます。
11363: ユーザ変数は、管理用ファイルに @code{$@{=@var{variable}@}} と記述します。
11364: ユーザ変数の設定は、@sc{cvs} の広域オプション @samp{-s} に、
11365: 引数 @code{@var{variable}=@var{value}} を続けます。
11366: このオプションは @file{.cvsrc} に記述しておくと良いでしょう 
11367: (@pxref{~/.cvsrc})。
11368: 
11369: 例として、実験用ディレクトリを管理用ファイルから参照するため、
11370: ユーザ変数 @code{TESTDIR} を用います。それから、以下のように @sc{cvs}
11371: を起動し、
11372: 
11373: @example
11374: cvs -s TESTDIR=/work/local/tests
11375: @end example
11376: 
11377: @noindent
11378: 管理ファイルに @code{sh $@{=TESTDIR@}/runtests} と書いてあれば、文字列
11379: は @code{sh /work/local/tests/runtests} に展開されます。
11380: 
11381: @samp{$} が上記以外の解釈を受けることはありません。
11382: また @samp{$} 自身を表現する別の方法も用意されてないため、
11383: @samp{$} という文字を引用することはできません。
11384: 
11385: @node config
11386: @appendixsec The CVSROOT/config configuration file
11387: 
11388: @cindex config, in CVSROOT
11389: @cindex CVSROOT/config
11390: 
11391: 管理ファイル @file{config} は @sc{cvs} の振舞いに影響するいろいろな雑
11392: 多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ
11393: れません。@samp{#} で始まる行は註釈と解釈されます。
11394: @c FIXME: where do we define comments for the other
11395: @c administrative files.
11396: 他の行はキーワード、@samp{=}、値からなります。この構文は厳密であること
11397: に注意してください。余分な空白やタブは使えません。
11398: @c See comments in parseinfo.c:parse_config for more
11399: @c discussion of this strictness.
11400: 
11401: 現在定義されているキーワードは:
11402: 
11403: @table @code
11404: @cindex RCSBIN, in CVSROOT/config
11405: @item RCSBIN=@var{bindir}
11406: @sc{cvs} 1.9.12 から 1.9.18 まで、この設定は @var{bindir} ディレクトリ
11407: にある @sc{rcs} プログラムを探すように @sc{cvs} に教えるために使われて
11408: いました。現在のバージョンの @sc{cvs} は @sc{rcs} プログラムを実行しま
11409: せん。互換性のためのこの設定は可能になってますが、何も起こりません。
11410: 
11411: @cindex SystemAuth, in CVSROOT/config
11412: @item SystemAuth=@var{value}
11413: @var{value} が @samp{yes} であれば、pserver は使用者を調べるときに、
11414: @file{CVSROOT/passwd} に見つからなければ、システムのデータベースを調べ
11415: にいきます。@samp{no} であれば、全ての使用者は @file{CVSROOT/passwd} 
11416: に存在している必要があります。既定値は @samp{yes} です。pserver につい
11417: ては、@ref{Password authenticated} を参照してください。
11418: 
11419: @cindex PreservePermissions, in CVSROOT/config
11420: @item PreservePermissions=@var{value}
11421: リポジトリでの、特別なデバイスファイル、シンボリック・リンク、ファイル
11422: 仕様許可、所有権に関する機能を使用可にします。既定値は @samp{no} です。
11423: このキーワード使用の完全な意味は @xref{Special Files}.
11424: 
11425: @cindex TopLevelAdmin, in CVSROOT/config
11426: @item TopLevelAdmin=@var{value}
11427: @samp{checkout} コマンドが取り出されたディレクトリ中に作成される 
11428: @samp{CVS} に加えて、新しい作業ディレクトリの最上位にも @samp{CVS} ディ
11429: レクトリを作成するように修正します。既定値は @samp{no} です。
11430: 
11431: このオプションは、取り出されたサブディレクトリではなく、最上位のディレ
11432: クトリで多くのコマンドを実行するときに便利です。そこに作成される
11433: @samp{CVS} ディレクトリにより、それぞれのコマンドに @samp{CVSROOT} を
11434: 指定する必要がなくなります。@samp{CVS/Template} ファイルの場所も提供し
11435: ます (@pxref{Working directory storage})。
11436: 
11437: @cindex LockDir, in CVSROOT/config
11438: @item LockDir=@var{directory}
11439: CVS ロックファイルをリポジトリ中のディレクトリでなく、@var{directory}
11440: に置きます。これは使用者にリポジトリから読み込みをさせたいけれど、リポ
11441: ジトリには書き込み許可を与えたくなく、@var{directory} ディレクトリのみ
11442: に書き込み許可を与えたいときに便利です。@var{directory} は作成する必要
11443: がありますが、必要ならば CVS は @var{directory} のサブディレクトリを作
11444: 成します。CVS のロックに関する情報は @ref{Concurrency} を参照してくだ
11445: さい。
11446: 
11447: @c Mention this in Compatibility section?
11448: LockDir オプションを使用可にする前に、CVS 1.9 やそれ以前のもののコピー
11449: を追跡して消去したことを確認してください。そのようなバージョンは
11450: LockDir をサポートしていませんし、それをサポートしていないというエラー
11451: を出すこともありません。結果として、もしこのようなことが起こってしまえ
11452: ば、CVS の何人かの使用者はある場所にロックを置き、他は別の場所に置くと
11453: いうことになり、リポジトリが壊れてしまう可能性があります。CVS 1.10 は
11454: LockDir をサポートしていませんが、LockDir が使用されているリポジトリで
11455: 実行されると警告を印字します。
11456: @end table
11457: 
11458: @c ---------------------------------------------------------------------
11459: @node Environment variables
11460: @appendix CVS に影響する全ての環境変数
11461: @cindex Environment variables
11462: @cindex Reference manual for variables
11463: 
11464: これは、@sc{cvs} に影響する全ての環境変数の
11465: 完全なリストです。
11466: 
11467: @table @code
11468: @cindex CVSIGNORE, environment variable
11469: @item $CVSIGNORE
11470: @sc{cvs} が無視するファイル名を、
11471: 空白で区切ったリストです。@xref{cvsignore}.
11472: 
11473: @cindex CVSWRAPPERS, environment variable
11474: @item $CVSWRAPPERS
11475: @sc{cvs} が wrapper として扱うファイル名形式を
11476: 空白で区切ったリストです。@xref{Wrappers}.
11477: 
11478: @cindex CVSREAD, environment variable
11479: @cindex read-only files, and CVSREAD
11480: @item $CVSREAD
11481: この変数が設定されていると、
11482: @code{checkout} と @code{update} により作成される作業コピーが、
11483: 強制的に読み込み専用となります。
11484: 設定しなければ、作業ファイルの修正許可が与えられます。
11485: 
11486: @item $CVSUMASK
11487: リポジトリのファイルの使用許可を制御します。@ref{File permissions} を
11488: 参照してください。
11489: 
11490: @item $CVSROOT
11491: (@sc{rcs} のファイルが置かれる) 
11492: @sc{cvs} のリポジトリのルート・ディレクトリを、
11493: 絶対パスで指定しなければいけません。
11494: @sc{cvs} の大部分のコマンドを実行するときに、
11495: この情報が利用されます。
11496: @code{$CVSROOT} が設定されていない場合や、
11497: 他のものを優先させたい場合には、
11498: コマンド行で @samp{cvs -d cvsroot cvs_command@dots{}} 
11499: としてリポジトリを指定することができます。
11500: 一旦作業ディレクトリを取り出した後は、
11501: @sc{cvs} が適切なリポジトリを (@file{CVS/Root} に) 記録します。
11502: 従って、最初に作業ディレクトリを取り出す時を除いて、
11503: 通常はこの値に注意する必要はありません。
11504: 
11505: @item $EDITOR
11506: @itemx $CVSEDITOR
11507: @itemx $VISUAL
11508: 格納時のログ・メッセージを記録する際に、使用するプログラムを指定します。
11509: @code{$CVSEDITOR} は @code{$EDITOR} よりも優先されます。
11510: @ref{Committing your changes} を参照してください。
11511: 
11512: @cindex PATH, environment variable
11513: @item $PATH
11514: @code{$RCSBIN} が設定されておらず、
11515: @sc{cvs} にパス名が埋め込まれていない場合、
11516: 使用する全てのプログラムを捜す時に @code{$PATH} が使用されます。
11517: 
11518: @cindex HOME, environment variable
11519: @item $HOME
11520: @cindex HOMEPATH, environment variable
11521: @item $HOMEPATH
11522: @cindex HOMEDRIVE, environment variable
11523: @item $HOMEDRIVE
11524: これを使用して、@file{.cvsrc} やそのような他のファイルが置かれたディレ
11525: クトリを捜します。Unix では、CVS は HOME だけを調べます。Windows NT で
11526: は、システムは HOMEDRIVE を例えば @samp{d:} に、HOMEPATH を例えば 
11527: @file{\joe} に設定します。Windows 95 ではおそらく自分自身で HOMEDRIVE
11528: と HOMEPATH を設定する必要があるでしょう。
11529: @c We are being vague about whether HOME works on
11530: @c Windows; see long comment in windows-NT/filesubr.c.
11531: 
11532: @cindex CVS_RSH, environment variable
11533: @item $CVS_RSH
11534: 接続経路に @code{:ext:} が指定された時、
11535: @sc{cvs} が接続に使用する外部プログラムを
11536: 指定します。@pxref{Connecting via rsh}。
11537: 
11538: @item $CVS_SERVER
11539: @sc{rsh} を用いたクライアント/サーバ・モードで、
11540: 別のマシンのリポジトリを利用する時に使用されます。
11541: @sc{rsh} を用いて別のマシンのリポジトリを利用する時に、
11542: サーバ側で起動するプログラムの名前を指定します。
11543: 既定値は @code{cvs} です。@pxref{Connecting via rsh}。
11544: 
11545: @item $CVS_PASSFILE
11546: クライアント/サーバ・モードで、
11547: @samp{cvs login @var{server}} が実行された時に使用されます。
11548: 既定値は @file{$HOME/.cvspass} です。
11549: @pxref{Password authentication client}。
11550: 
11551: @item $CVS_CLIENT_PORT
11552: ケルベロスを用いたクライアント/サーバ・モードで
11553: 使用されます。@pxref{Kerberos authenticated}。
11554: 
11555: @cindex CVS_RCMD_PORT, environment variable
11556: @item $CVS_RCMD_PORT
11557: クライアント/サーバ・モードで使用されます。
11558: これを設定した場合、サーバの @sc{rcmd} デーモンを利用する時に、
11559: ここで指定したポート番号が使用されます。
11560: (現在 @sc{unix} クライアントでは使用されません)。
11561: 
11562: @cindex CVS_CLIENT_LOG, environment variable
11563: @item $CVS_CLIENT_LOG
11564: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11565: これを設定した場合、
11566: サーバに送られた全てが @file{@code{$CVS_CLIENT_LOG}.in} に記録され、
11567: サーバから送られた全てが @file{@code{$CVS_CLIENT_LOG}.out} に
11568: 記録されます。
11569: 
11570: @cindex CVS_SERVER_SLEEP, environment variable
11571: @item $CVS_SERVER_SLEEP
11572: クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。
11573: これを設定して、子プロセスを起動する前に指定した秒数を待ち、
11574: デバッガを応答させます。
11575: 
11576: @cindex CVS_IGNORE_REMOTE_ROOT, environment variable
11577: @item $CVS_IGNORE_REMOTE_ROOT
11578: @sc{cvs} 1.10 以前では、この変数を設定すると、@samp{-d} 広域オプション
11579: が指定されているときに @file{CVS/Root} を上書きするのを抑制することが
11580: できました。後のバージョンの @sc{cvs} は @file{CVS/Root} を再書き込み
11581: しませんので、CVS_IGNORE_REMOTE_ROOT は効果はありません。
11582: 
11583: @cindex COMSPEC, environment variable
11584: @item $COMSPEC
11585: OS/2 だけで使用されます。コマンド解釈プログラムを指定します。
11586: 既定値は @sc{cmd.exe} です。
11587: 
11588: @cindex TMPDIR, environment variable
11589: @item $TMPDIR
11590: @cindex TMP, environment variable
11591: @itemx $TMP
11592: @cindex TEMP, environment variable
11593: @itemx $TEMP
11594: @cindex temporary files, location of
11595: @c This is quite nuts.  We don't talk about tempnam
11596: @c or mkstemp which we sometimes use.  The discussion
11597: @c of "Global options" is semi-incoherent.
11598: @c I'm not even sure those are the only inaccuracies.
11599: @c Furthermore, the conventions are
11600: @c pretty crazy and they should be simplified.
11601: 一時ファイルが置かれるディレクトリを指定します。
11602: @sc{cvs} サーバは @code{TMPDIR} を使用します。
11603: この指定方法は、@ref{Global options} 参照。
11604: @sc{cvs} には、(システムが提供する @code{_tmpnam} 関数経由で) 
11605: 常に @file{/tmp} を使用する部分があります。
11606: 
11607: Windows NT では (システムが提供する @code{_tempnam} 関数経由で)、
11608: @code{TMP} が使用されます。
11609: 
11610: @sc{cvs} のクライアントが用いる @code{patch} プログラムは、
11611: @code{TMPDIR} を使用します。
11612: 設定されていない場合、(少なくとも GNU patch 2.1 は) 
11613: @file{/tmp} を使用します。
11614: サーバとクライアントの両方共が @sc{cvs} 1.9.10 以降を実行しているなら、
11615: @sc{cvs} は外部の @code{patch} プログラムを呼び出しません。
11616: @end table
11617: 
11618: @node Compatibility
11619: @appendix CVS のバージョン間の互換性
11620: 
11621: @cindex CVS, versions of
11622: @cindex versions, of CVS
11623: @cindex compatibility, between CVS versions
11624: @c We don't mention versions older than CVS 1.3
11625: @c on the theory that it would clutter it up for the vast
11626: @c majority of people, who don't have anything that old.
11627: @c
11628: リポジトリの形式は @sc{cvs} 1.3 から互換です。@sc{cvs} 1.6 以前を使っ
11629: ていて、オプションの開発者間通信機能を使いたいときは、@ref{Watches
11630: Compatibility} を参照してください。
11631: @c If you "cvs rm" and commit using 1.3, then you'll
11632: @c want to run "rcs -sdead <file,v>" on each of the
11633: @c files in the Attic if you then want 1.5 and
11634: @c later to recognize those files as dead (I think the
11635: @c symptom if this is not done is that files reappear
11636: @c in joins).  (Wait: the above will work but really to
11637: @c be strictly correct we should suggest checking
11638: @c in a new revision rather than just changing the
11639: @c state of the head revision, shouldn't we?).
11640: @c The old convert.sh script was for this, but it never
11641: @c did get updated to reflect use of the RCS "dead"
11642: @c state.
11643: @c Note: this is tricky to document without confusing
11644: @c people--need to carefully say what CVS version we
11645: @c are talking about and keep in mind the distinction
11646: @c between a
11647: @c repository created with 1.3 and on which one now
11648: @c uses 1.5+, and a repository on which one wants to
11649: @c use both versions side by side (e.g. during a
11650: @c transition period).
11651: @c Wait, can't CVS just detect the case in which a file
11652: @c is in the Attic but the head revision is not dead?
11653: @c Not sure whether this should produce a warning or
11654: @c something, and probably needs further thought, but
11655: @c it would appear that the situation can be detected.
11656: @c
11657: @c We might want to separate out the 1.3 compatibility
11658: @c section (for repository & working directory) from the
11659: @c rest--that might help avoid confusing people who
11660: @c are upgrading (for example) from 1.6 to 1.8.
11661: @c
11662: @c A minor incompatibility is if a current version of CVS
11663: @c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
11664: @c see this as if there is no tag.  Seems to me this is
11665: @c too obscure to mention.
11666: 
11667: 作業ディレクトリ形式は @sc{cvs} 1.5 から互換です。@sc{cvs} 1.3 と 
11668: @sc{cvs} 1.5 の間で変更されました。@sc{cvs} 1.3 で取り出されたディレク
11669: トリで @sc{cvs} 1.5 か、それより新しいものを実行すると、@sc{cvs} はそ
11670: れを変換しますが、@sc{cvs} 1.3 に戻るためには、新しい作業ディレクトリ
11671: を @sc{cvs} 1.3 で取り出す必要があります。
11672: 
11673: 遠隔プロトコルは @sc{cvs} 1.5 から相互作用可能ですが、それ以前では無理
11674: です (1.5 が遠隔プロトコルのある最初の公的リリースですが、古いバージョ
11675: ンがまだあたりをうろついているかもしれません)。しかし、多くの場合、新
11676: しい機能とバグ修正の利点を得るためにクライアントとサーバの両方を更新す
11677: る必要があります。
11678: 
11679: @c Perhaps should be saying something here about the
11680: @c "D" lines in Entries (written by CVS 1.9; 1.8 and
11681: @c older don't use them).  These are supposed to be
11682: @c compatible in both directions, but I'm not sure
11683: @c they quite are 100%.  One common gripe is if you
11684: @c "rm -r" a directory and 1.9 gets confused, as it
11685: @c still sees it in Entries.  That one is fixed in
11686: @c (say) 1.9.6.  Someone else reported problems with
11687: @c starting with a directory which was checked out with
11688: @c an old version, and then using a new version, and
11689: @c some "D" lines appeared, but not for every
11690: @c directory, causing some directories to be skipped.
11691: @c They weren't sure how to reproduce this, though.
11692: 
11693: @c ---------------------------------------------------------------------
11694: @node Troubleshooting
11695: @appendix 問題の解決
11696: 
11697: @sc{cvs} の使用に問題があれば、この付録が役立つかもしれません。特定の
11698: エラーメッセージが出ているなら、そのメッセージをアルファベット順に探す
11699: ことができます。そうでない場合は、他の問題の章を眺めて説明されているか
11700: どうかを知ることができます。
11701: 
11702: @menu
11703: * Error messages::              CVS のエラーの部分的一覧
11704: * Connection::                  CVS サーバへの接続での問題
11705: * Other problems::              エラーメッセージで既に挙げられていない問題
11706: @end menu
11707: 
11708: @ignore
11709: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
11710: @c @node Bad administrative files
11711: @appendixsec Bad administrative files
11712: 
11713: @c -- Give hints on how to fix them
11714: @end ignore
11715: 
11716: @node Error messages
11717: @appendixsec エラーメッセージの部分的一覧
11718: 
11719: これは @sc{cvs} で起こるかもしれないエラー・メッセージの部分的な一覧で
11720: す。完全な一覧ではありません---@sc{cvs} はたくさん、たくさんのエラー・
11721: メッセージを印字する能力があり、しばしば一部分はオペレーティング・シス
11722: テムにより提供されます。しかし、ここでの意図はよくあるもの、混乱する可
11723: 能性のあるエラー・メッセージの、両方もしくはどちらかにあてはまるものの
11724: 一覧を挙げることです。
11725: 
11726: メッセージはアルファベット順ですが、@samp{cvs update: } のような前置き
11727: の文章は順番にするときには省かれています。
11728: 
11729: この一覧は古いバージョンの @sc{cvs} で印字されるメッセージがある場合も
11730: あります (使用者は特定の時にどのバージョンの @sc{cvs} を使用しているか
11731: を必ずしも知らないというのが理由の一つです)。
11732: @c If we want to start retiring messages, perhaps we
11733: @c should pick a cutoff version (for example, no more
11734: @c messages which are specific to versions before 1.9)
11735: @c and then move the old messages to an "old messages"
11736: @c node rather than deleting them completely.
11737: 
11738: @table @code
11739: @c FIXME: What is the correct way to format a multiline
11740: @c error message here?  Maybe @table is the wrong
11741: @c choice?  Texinfo gurus?
11742: @item cvs @var{command}: authorization failed: server @var{host} rejected access
11743: これは pserver のサーバに接続しようとして、それが特定の理由を教えるこ
11744: となく認証を拒否することを選んだときの一般的な反応です。指定された使用
11745: 者名とパスワードが正しいことと、指定された CVSROOT が inetd.conf の 
11746: --allow-root で使用可になっているこを確認してください。
11747: 
11748: @item @var{file}:@var{line}: Assertion '@var{text}' failed
11749: システムによってこのメッセージの正確な形式は異なります。これは 
11750: @sc{cvs} のバグを示し、@ref{BUGS} で説明されているように扱うことができ
11751: ます。
11752: 
11753: @item cvs @var{command}: conflict: removed @var{file} was modified by second party
11754: このメッセージは、あなたがファイルを消去し、誰か別の人がそれを修正した
11755: ということを示します。衝突を解消するために、まず @samp{cvs add
11756: @var{file}} を実行します。それが望まれていれば、他の人々の修正を見てま
11757: だそれを消したいかどうかを決定します。消したくなければ、ここで止めます。
11758: 消去したければ、 @samp{cvs remove @var{file}} を実行して、削除を格納し
11759: ます。
11760: @c Tests conflicts2-142b* in sanity.sh test for this.
11761: 
11762: @item cannot change permissions on temporary directory
11763: @example
11764: Operation not permitted
11765: @end example
11766: このメッセージは、Red Hat Linux 3.0.3 と 4.1 でクライアント/サーバのテ
11767: スト一式を実行しているときいに、再現不可能な方法でときどき発生しました。
11768: 我々は何がそれを起こしたのか、また linux (もしくは、このマシンそのもの!) 
11769: に特有かどうかも分かりません。他の unix でも問題が発生した場合は、おそ
11770: らく @samp{Operation not permitted} は @samp{Not owner} や当のシステム
11771: が unix の @code{EPERM} エラーで使用している他のものになっているでしょ
11772: う。追加の情報があれば、@ref{BUGS} で説明されているように我々に知らせ
11773: てください。もし @sc{cvs} を使用していてこのエラーを経験したときは、そ
11774: れを発生させた操作をもう一度繰り返すとちゃんと動作するでしょう。
11775: @c This has been seen in a variety of tests, including
11776: @c multibranch-2, multibranch-5, and basic1-24-rm-rm,
11777: @c so it doesn't seem particularly specific to any one
11778: @c test.
11779: 
11780: @c For one example see basica-1a10 in the testsuite
11781: @c For another example, "cvs co ." on NT; see comment
11782: @c at windows-NT/filesubr.c (expand_wild).
11783: @c For another example, "cvs co foo/bar" where foo exists.
11784: @item cannot open CVS/Entries for reading: No such file or directory
11785: これは一般的に @sc{cvs} の内部エラーを示し、他の @sc{cvs} のバグと同様
11786: に扱うことがきます (@pxref{BUGS})。たいていの場合、対策があります---正
11787: 確な方法は状況に依りますが、おそらく見付け出すことができるでしょう。
11788: 
11789: @c This is more obscure than it might sound; it only
11790: @c happens if you run "cvs init" from a directory which
11791: @c contains a CVS/Root file at the start.
11792: @item cvs [init aborted]: cannot open CVS/Root: No such file or directory
11793: このメッセージは無害です。もし他のエラーと一緒にでなければ、操作は成功
11794: しています。現在のバージョンの @sc{cvs} では出ないはずですが、@sc{cvs}
11795: 1.9 以前のために説明されています。
11796: 
11797: @item cvs [checkout aborted]: cannot rename file @var{file} to CVS/,,@var{file}: Invalid argument
11798: このメッセージは Solaris 2.5 上での CVS 1.9 でときどき発生することが報
11799: 告されています。原因は不明です。原因についてさらに知っていれば、
11800: @ref{BUGS} で説明されているように我々に知らせてください。
11801: 
11802: @item cvs [@var{command} aborted]: cannot start server via rcmd
11803: この残念ながらあまり詳しくないメッセージは、@sc{cvs} のクライアントを
11804: 実行していてサーバとの接続に問題があったときに @sc{cvs} 1.9 が印字しま
11805: す。現在のバージョンの @sc{cvs} はもっと詳しいエラーメッセージを印字す
11806: るようになっています。クライアントを実行しようとはしていないのにこのメッ
11807: セージが出たときは、おそらく @ref{Repository} で説明されている方法で 
11808: @code{:local:} を指定することを忘れたのでしょう。
11809: 
11810: @item ci: @var{file},v: bad diff output line: Binary files - and /tmp/T2a22651 differ
11811: CVS 1.9 以前は @sc{rcs} が正しくインストールされていないときにバイナリ
11812: ファイルを格納しようとしたときにこのメッセージを印字します。@sc{rcs} 
11813: の配布とともに取得している指示をもう一度読んで、@sc{cvs} 配布の 
11814: @sc{install} ファイルを読んでください。代替法として、@sc{rcs} を経由し
11815: ないで自分自身でファイルを格納する現在のバージョンの @sc{cvs} に変更す
11816: ることもできます。
11817: 
11818: @item cvs checkout: could not check out @var{file}
11819: CVS 1.9 では、これは @code{co} プログラム (@sc{rcs} プログラムの一部で
11820: す) が失敗の値を返したということです。他のエラーメッセージがその前にあ
11821: るはずですが、別のエラーメッセージなしに発生することも確認されており、
11822: 原因はよくわかっていません。現在のバージョンの CVS は @code{co} を実行
11823: しないので、このメッセージが別のエラーメッセージとともに現れなければ、
11824: それは間違いなく CVS のバグです (@pxref{BUGS})。
11825: @c My current suspicion is that the RCS in the rcs (not
11826: @c cvs/winnt/rcs57nt.zip) directory on the _Practical_
11827: @c CD is bad (remains to be confirmed).
11828: @c There is also a report of something which looks
11829: @c very similar on SGI, Irix 5.2, so I dunno.
11830: 
11831: @item cvs [login aborted]: could not find out home directory
11832: これはホームデレクトリの位置を特定するために CVS が使用する環境変数を
11833: 設定する必要があるということです。@ref{Environment variables} の HOME,
11834: HOMEDRIVE, HOMEPATH の議論を参照してください。
11835: 
11836: @item cvs update: could not merge revision @var{rev} of @var{file}: No such file or directory
11837: CVS 1.9 以前は @code{rcsmerge} プログラムを見つけるときに問題が発生し
11838: たときにこのメッセージを印字します。それが @code{PATH} にあることを確
11839: 認するか、外部 @code{rcsmerge} プログラムを必要としない現在のバージョ
11840: ンの CVS に更新してください。
11841: 
11842: @item cvs [update aborted]: could not patch @var{file}: No such file or directory
11843: これは @code{patch} プログラムの探索に問題があったということです。それ
11844: が @code{PATH} 上にあるとを確認してください。メッセージの外観とは違っ
11845: て、@var{file} を見つけるかどうかについて言っているのでは@emph{ない}こ
11846: とに注意してください。クライアントとサーバが現在のバージョンの 
11847: @sc{cvs} を実行しているなら、外部 patch プログラムは必要ではなく、この
11848: メッセージを見ることはないでしょう。しかし、クライアントかサーバが 
11849: @sc{cvs} 1.9 を実行していれば、@code{patch} が必要です。
11850: 
11851: @item cvs update: could not patch @var{file}; will refetch
11852: これは、何らかの理由により、クライアントはサーバが送った patch を適用
11853: できなかったということです。メッセージは心配するようなものではありませ
11854: ん。これは、patch の適用ができなかったというのはちょっと作業を遅らせる
11855: だけで、@sc{cvs} が実行することには影響しないからです。
11856: @c xref to update output.  Or File status?
11857: @c Or some place else that
11858: @c explains this whole "patch"/P/Needs Patch thing?
11859: 
11860: @item dying gasps from @var{server} unexpected
11861: @sc{cvs} 1.9.18 以前のサーバにはこれを発生する既知のバグがあります。私
11862: は、@samp{-t} 広域オプションを使用しているときに再現可能です。もし興味
11863: があれば、それは Andy Piper の1997年11月4日の src/filesubr.c への変更
11864: で修正されました。このメッセージが出たときは、おそらく失敗した操作をた
11865: だもう一度試すことができます。また、この原因に関して情報を発見したなら、
11866: @ref{BUGS} に書かれているように我々に知らせてください。
11867: 
11868: @item end of file from server (consult above messages if any)
11869: このメッセージの一番多い原因は、外部 @code{rsh} プログラムを使用してい
11870: て、それがエラーを出して終了するというものです。この場合 @code{rsh}
11871: プログラムは、上のメッセージの前にメッセージを印字しているはずです。
11872: @sc{cvs} のクライアントとサーバの設定の情報は @ref{Remote
11873: repositories} を参照してください。
11874: 
11875: @cindex mkmodules
11876: @item cvs commit: Executing 'mkmodules'
11877: これはリポジトリが @sc{cvs} 1.8 より前のバージョンの @sc{cvs} で設定さ
11878: れているということです。@sc{cvs} 1.8 以降を使っていると、上記のメッセー
11879: ジの前に以下のものがでます。
11880: 
11881: @example
11882: cvs commit: Rebuilding administrative file database
11883: @end example
11884: 
11885: 両方のメッセージが表示されれば、データベースは2回再構築されていて、こ
11886: れは不必要ですが、無害です。重複を避けたくて、@sc{cvs} 1.7 以前を使っ
11887: ていないなら、@code{modules} ファイルにある全ての @code{-i mkmodules}
11888: を消してください。@code{modules} ファイルの情報は @ref{modules} を参照
11889: してください。
11890: 
11891: @c This messsage comes from "co", and I believe is
11892: @c possible only with older versions of CVS which call
11893: @c co.  The problem with being able to create the bogus
11894: @c RCS file still exists, though (and I think maybe
11895: @c there is a different symptom(s) now).
11896: @c FIXME: Would be nice to have a more exact wording
11897: @c for this message.
11898: @item missing author
11899: 普通これは使用者名が空の RCS ファイルを作成したときに発生します。CVS
11900: は、間違って author 部分に値のない不正な RCS ファイルを作成します。解
11901: 決策は、使用者名が空でないことを確認して、RCS フィルを再作成することで
11902: す。
11903: @c "make sure your username is set" is complicated in
11904: @c and of itself, as there are the environment
11905: @c variables the system login name, &c, and it depends
11906: @c on the version of CVS.
11907: 
11908: @item *PANIC* administration files missing
11909: これは普通は CVS という名前のディレクトリがあるけれど、CVS が CVS ディ
11910: レクトリに置く管理ファイルがないということです。もし問題が CVS 以外の
11911: 何らかの機構で CVS ディレクトリを作ったというものであれば、CVS 以外の
11912: 名前を使ってください。もしそうでなければ、それは CVS のバグを示してい
11913: ます (@pxref{BUGS})。
11914: 
11915: @item rcs error: Unknown option: -x,v/
11916: このメッセージの後には @sc{rcs} の使用法のメッセージが続きます。それは
11917: 古いバージョンの @sc{rcs} (おそらくオペレーティングシステムと共に提供
11918: されたものでしょう) があるということです。CVS は @sc{rcs} バージョン 5
11919: 以降でのみ動作します。
11920: @c For more information on installing @sc{cvs}, see
11921: @c (FIXME: where?  it depends on whether you are
11922: @c getting binaries or sources or what).
11923: @c The message can also say "ci error" or something
11924: @c instead of "rcs error", I suspect.
11925: 
11926: @item cvs [server aborted]: received broken pipe signal
11927: これは、@sc{cvs} かそれが実行されているシステムの追跡が困難なバグ (良
11928: く判っていません---我々はまだ追いかけていません!) により発生するようで
11929: す。@sc{cvs} コマンドが完了した後でのみ発生するようで、メッセージは無
11930: 視できます。しかしながら、その原因に関する情報を発見したなら、
11931: @ref{BUGS} で説明されているように我々に知らせてください。
11932: 
11933: @item Too many arguments!
11934: このメッセージは普通は @sc{cvs} のソース配布の @file{contrib} ディレク
11935: トリにある @file{log.pl} スクリプトにより印字されます。@sc{cvs} のバー
11936: ジョンには、@file{log.pl} が既定の @sc{cvs} インストールに含まれている
11937: ものもあります。@file{log.pl} スクリプトは @file{loginfo} 管理ファイル
11938: から呼ばれます。@file{loginfo} で渡されている引数があなたのバージョン
11939: の @file{log.pl} が期待するものとあっているか調べてください。特に、
11940: @sc{cvs} 1.3 以前の @file{log.pl} はログファイルを引数として期待します
11941: が、@sc{cvs} 1.5 以降の @file{log.pl} はログファイルは @samp{-f} オプ
11942: ションで指定されることを期待します。もちろん、@file{log.pl} が必要でな
11943: ければ、@file{loginfo} 中で註釈にして、使用しないようにすることができ
11944: ます。
11945: 
11946: @item cvs [login aborted]: unrecognized auth response from @var{server}
11947: このメッセージは普通はサーバが適切に設定されていないことを意味します。
11948: 例えば、@file{inetd.conf} が存在しない cvs 実行ファイルを指していると
11949: きです。これをデバッグするためには、inetd が書くログファイル
11950: (@file{/var/log/messages} やあなたのシステムの inetd が使うその他のも
11951: の) を見つけてください。詳細は @ref{Connection} と @ref{Password
11952: authentication server} 参照。
11953: 
11954: @item cvs commit: Up-to-date check failed for `@var{file}'
11955: これはあなたが最後に @code{cvs update} を実行した後に誰かが変更を格納
11956: したということです。ですから、@code{cvs commit} を継続する前に 
11957: @code{cvs update} をする必要があります。CVS はあなたのした変更と他の人
11958: がした変更をマージします。衝突が発見されなれば、@samp{M cacErrCodes.h} 
11959: のように報告され、@code{cvs commit} を実行する準備が整っています。もし
11960: 衝突が発見されれば、その由を印字し、@samp{C cacErrCodes.h} と報告され、
11961: 手で衝突を解消する必要があります。この過程の詳細は @ref{Conflicts
11962: example} を参照してください。
11963: 
11964: @item Usage:	diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
11965: @example
11966: Only one of [exEX3] allowed
11967: @end example
11968: これは @code{diff3} と @code{rcsmerge} のインストールに問題があること
11969: を示しています。特に @code{rcsmerge} は GNU diff3 を探すようにコンパイ
11970: ルされているけれど、代わりに unix の diff3 が使われています。一番簡単
11971: な解決法は外部の @code{rcsmerge} や @code{diff3} プログラムに頼らない
11972: 現在のバージョンの @sc{cvs} に更新することです。
11973: 
11974: @item warning: unrecognized response `@var{text}' from cvs server
11975: もし @var{text} が有効な応答 (@samp{ok} のようなもの) で、続きに余分な
11976: キャリッジリターンがあると (多くのシステムではこれはメッセージの2番目
11977: の部分が1番目の部分を上書きします)、おそらく、既定では透過的なデータス
11978: トリームを提供しない、多くの unix でない rsh のバージョンで 
11979: @samp{:ext:} 接続方法を使用としているのでしょう。その様な場合はたぶん 
11980: @samp{:ext:} の代わりに @samp{:server:} を試みるのが良いでしょう。
11981: @var{text} が何か他のものなら、CVS サーバに問題があることを表します。
11982: CVS サーバを設定するための指示を見てインストールを再度確認してください。
11983: 
11984: @item cvs commit: [@var{time}] waiting for @var{user}'s lock in @var{directory}
11985: これは普通のメッセージであり、エラーではありません。詳細は
11986: @ref{Concurrency} 参照。
11987: 
11988: @item cvs commit: warning: editor session failed
11989: @cindex exit status, of editor
11990: これは @sc{cvs} が使用しているエディタが非零の値で終了したということで
11991: す。vi のバージョンにはファイルの編集に問題がなかったときでさえそうす
11992: るものがあります。もしそうなら、環境変数 @sc{CVSEDITOR} を以下のような
11993: 小さなスクリプトを指すようにしてください:
11994: 
11995: @example
11996: #!/bin/sh
11997: vi $*
11998: exit 0
11999: @end example
12000: 
12001: @c "warning: foo was lost" and "no longer pertinent" (both normal).
12002: @c Would be nice to write these up--they are
12003: @c potentially confusing for the new user.
12004: @end table
12005: 
12006: @node Connection
12007: @appendixsec CVS サーバに接続をしようとするときの問題
12008: 
12009: この章は @sc{cvs} サーバに接続しようとしたときに問題が起こったときに何
12010: をすれば良いかということを書いています。 Windows で @sc{cvs} コマンド
12011: ライン・クライアントを実行しているなら、まず @sc{cvs} 1.9.12 以降に更
12012: 新してください。以前のバージョンのエラー報告は、問題がどうであったかに
12013: ついて、ほとんど情報を提供しません。クライアントが Windows でなければ、
12014: @sc{cvs} 1.9 は問題ありません。
12015: 
12016: 問題を追いかけるためにエラー・メッセージが十分でなければ、次の手段は使
12017: 用している接続方法によってかなり異なります。
12018: 
12019: @table @code
12020: @cindex :ext:, troubleshooting
12021: @item :ext:
12022: コマンド行からの rsh プログラムの実行を試してください。例えば: "rsh
12023: servername cvs -v" は @sc{cvs} のバージョン情報を印字します。もしこれ
12024: が動作しなければ、@sc{cvs} の問題を気にする前にそれを修正する必要があ
12025: ります。
12026: 
12027: @cindex :server:, troubleshooting
12028: @item :server:
12029: この接続方法を使用するためにコマンド行の rsh プログラムは必要ではあり
12030: ませんが、rsh プログラムがあれば、デバッグ道具として役に立つでしょう。:
12031: ext: のところの指示に従ってください。
12032: 
12033: @cindex :pserver:, troubleshooting
12034: @item :pserver:
12035: 良いデバッグ道具は "telnet servername 2401" です。接続後、任意のテキス
12036: ト (例えば、"foo" リターン)。@sc{cvs} が正しく動作していれば、以下のよ
12037: うに反応するはずです。
12038: 
12039: @example
12040: cvs [pserver aborted]: bad auth protocol start: foo
12041: @end example
12042: 
12043: これの動作に失敗すれば、inetd が正しく動作しているか確認してください。
12044: inetd.conf での起動を cvs の代わりに echo プログラムに変更してください。
12045: 例えば:
12046: 
12047: @example
12048: 2401  stream  tcp  nowait  root /bin/echo echo hello
12049: @end example
12050: 
12051: その変更をして、inetd に設定ファイルを再読み込みするように指示した後で
12052: は、"telnet servername 2401" はテキスト hello を表示して、サーバが接続
12053: を切るはずです。これが動作しなければ、@sc{cvs} の問題を気にする前にそ
12054: れを修正してください。
12055: 
12056: AIX システムでは、システムにポート 2401 を使おうとするプログラムがあり
12057: ます。これは、ポート 2401 は @sc{cvs} での使用に登録されているという点
12058: で AIX の問題です。この問題を解決するために AIX のパッチがあるというこ
12059: とを聞いたことがあります。
12060: @end table
12061: 
12062: @node Other problems
12063: @appendixsec 他のよくある問題
12064: 
12065: これは上の分類には合わない問題の一覧です。順番には特に意味はありません。
12066: 
12067: @itemize @bullet
12068: @item
12069: @sc{cvs} 1.9.18 以前を実行していて、@ref{Conflicts example} で説明され
12070: ているように、@code{cvs update} が衝突を発見し、マージを試みたけれど、
12071: 衝突があることを報告しなかったら、@sc{rcs} の古いバージョンが存在しま
12072: す。一番簡単な解決は、おそらく外部 @sc{rcs} プログラムを使用しない現在
12073: のバージョンの @sc{cvs} に変更することです。
12074: @end itemize
12075: 
12076: @c ---------------------------------------------------------------------
12077: @node Credits
12078: @appendix Credits
12079: 
12080: @cindex Contributors (manual)
12081: @cindex Credits (manual)
12082: 当時 Cygnus Support にいた Roland Pesch <@t{roland@@wrs.com}> 
12083: は @sc{cvs} 1.3 とともに頒布されたマニュアルを書きました。
12084: 記述の多くは、彼の文章から受け継いでいます。
12085: また彼にこのマニュアルの初期の草稿を読んでもらい、
12086: 多くのアイディアと訂正を頂きました。
12087: 
12088: メーリング・リスト @code{info-cvs} も時には有益でした。
12089: 私は以下の人物が行なった投稿による情報を含めました:
12090: David G. Grubbs <@t{dgg@@think.com}>.
12091: 
12092: @sc{rcs} の man からいくつか文章を引用しています。
12093: 
12094: David G. Grubbs 氏による @sc{cvs} @sc{faq} は、
12095: 有用な素地を与えてくれました。
12096: @sc{faq} はもうメンテナンスされていませんが、
12097: このマニュアルが (少くとも @sc{cvs} の使用方法の文書化に関して)、
12098: その後継に最も近いものでしょう。
12099: 
12100: また、次に挙げる人物が、私の誤りを訂正してくれました:
12101: 
12102: @display
12103: Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
12104: Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
12105: Karl Pingle <@t{pingle@@acuson.com}>,
12106: Thomas A Peterson <@t{tap@@src.honeywell.com}>,
12107: Inge Wallin <@t{ingwa@@signum.se}>,
12108: Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>,
12109: Michael Brown <@t{brown@@wi.extrel.com}>.
12110: @end display
12111: 
12112: ここの貢献者の一覧は包括的なものであはありません。このマニュアルへの貢
12113: 献者のより完全な一覧は @sc{cvs} のソース配布のファイル 
12114: @file{doc/ChangeLog} を見てください。
12115: 
12116: @c ---------------------------------------------------------------------
12117: @node BUGS
12118: @appendix CVS かこのマニュアルのバグに対処する
12119: 
12120: @cindex Bugs in this manual or CVS
12121: @sc{cvs} もこのマニュアルも完璧ではなく、また永遠にそうならないでしょ
12122: う。@sc{cvs} を使用していて問題にぶつかったり、バグを見つけたと思った
12123: りしたときは、いろいろな方法があります。また、マニュアルにはっきりしな
12124: いところがあれば、マニュアルのバグと考えられますので、これらの問題も 
12125: @sc{cvs} 自身の問題と同様に行動をするに値します。
12126: 
12127: @cindex Reporting bugs
12128: @cindex Bugs, reporting
12129: @cindex Errors, reporting
12130: @itemize @bullet
12131: @item
12132: 報告したバグを誰かに修正して欲しい場合は、代金と交換にしてくれる会社が
12133: あります。そのような会社は2つあります:
12134: 
12135: @cindex Signum Support
12136: @cindex Cyclic Software
12137: @cindex Support, getting CVS support
12138: @example
12139: Signum Support AB
12140: Box 2044
12141: S-580 02  Linkoping
12142: Sweden
12143: Email: info@@signum.se
12144: Phone: +46 (0)13 - 21 46 00
12145: Fax:   +46 (0)13 - 21 47 00
12146: http://www.signum.se/
12147: 
12148: Cyclic Software
12149: United States of America
12150: http://www.cyclic.com/
12151: info@@cyclic.com
12152: @end example
12153: 
12154: @item
12155: @sc{cvs} をオペレーティング・システムのベンダーやフリーウェアの 
12156: @sc{cd-rom} のベンダーのような配布者から取得していれば、配布者がサポー
12157: トを提供しているかどうかを知りたいでしょう。しばしば、サポートしなかっ
12158: たり、最小限のサポートしか提供しないかもしれませんが、それは配布者によっ
12159: て異なります。
12160: 
12161: @item
12162: もし十分な技能と時間があれば、バグを自分自身で修正しようと思うでしょう。
12163: その修正を将来の @sc{cvs} のリリース含めたいときは、@sc{cvs} のソース
12164: 配布にあるファイル @sc{hacking} を見てください。修正の提出方法に関する
12165: たくさんの情報があります。
12166: 
12167: @item
12168: ネット上に助けになるリソースがあるかもしれません。以下の2つは開始する
12169: 良い場所です:
12170: 
12171: @example
12172: http://www.cyclic.com
12173: http://www.loria.fr/~molli/cvs-index.html
12174: @end example
12175: 
12176: もし非常にやる気になれば、ネット上での情報を増やすと感謝される可能性が
12177: 高いでしょう。例えば、標準の @sc{cvs} 配布が Windows 95 について作業を
12178: する前に、@sc{cvs} を Windows 95 で実行するための説明とパッチのあるウェ
12179: ブページがあり、色々な人がその題がメーリングリストやニュースグループで
12180: 出る度にそのページを知らせることで手助けをしていました。
12181: 
12182: 訳註: 日本語のウェブページは以下のものが良いでしょう。
12183: 
12184: @example
12185: http://www.cyclic.com/cvs/lang-jp.html
12186: http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
12187: @end example
12188: 
12189: @item
12190: バグを @code{bug-cvs} に報告することもできます。誰かがあなたのバグ報告
12191: に対して何かをしようと思うかもしれないし、思わないかもしれない、という
12192: ことに注意してください---もし解決策が必要なら、上の方法のどれかを考慮
12193: してください。ですが、おそらく人々は特に大変な結果になるバグと、簡単に
12194: 修正できるバグの両方、もしくはどちらかに該当するもに関心があるでしょう。
12195: また、バグの本質と他の関係する情報を明確にすることで可能性を高めるこが
12196: できます。バグを報告するためには @code{bug-cvs@@gnu.org} に email を送
12197: ります。@code{bug-cvs} へ送ったものは @sc{gnu} Public License の条件の
12198: 下で配布されるかもしれないことに注意してください。もしこれを好まなけれ
12199: ば、送らないでください。普通は、メールを @code{bug-cvs} ではなく、
12200: @sc{cvs} の管理者に直接送ることの正当性はありません。そのようなバグ報
12201: 告に関心のある管理者は @code{bug-cvs} を読んできます。また、バグ報告を
12202: 他のメーリングリストやニュースグループに送ることは @code{bug-cvs} へ送
12203: る代わりには@emph{ならない}ということにも注意してださい。@sc{cvs} のバ
12204: グをどの場所でも好きなところで議論するのは良いことですが、
12205: @code{bug-cvs} 以外に送られたバグ報告を管理者の誰かが読んでいるとは限
12206: りません。
12207: @end itemize
12208: 
12209: @cindex Known bugs in this manual or CVS
12210: 結構頻繁に、既知のバグの一覧や特定のバグが知られたものかどうかの一覧が
12211: あるかどうかを尋ねられます。@sc{cvs} のソース配布の @sc{bugs} ファイル
12212: は既知のバグのリストの一つですが、必ずしも包括的なものであろうとはして
12213: いません。おそらく、既知のバグの包括的な、詳細な一覧は存在することはな
12214: いでしょう。
12215: 
12216: @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
12217: @node Translation
12218: @appendix 日本語訳について
12219: 
12220: この @sc{cvs} のマニュアルは、
12221: @sc{cvs} @value{CVSVN} に付属していた、
12222: @file{cvs.texinfo} を日本語訳したものです。
12223: 文書の構造やノード名等は(この節を除いて)そのまま使用しており、
12224: 文章は自分に可能な限り忠実に訳しています。
12225: 修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。
12226: 
12227: @flushright
12228: 廣保 誠 <@t{hiroyasu@@iedc.mke.mei.co.jp}>
12229: @end flushright
12230: 
12231: @unnumberedsubsec 訳者からの謝辞
12232: 
12233: 大阪大学の西田圭介さんが、引地夫妻に問い合わせてこの文書の
12234: 配布条件の推奨訳を入手したり、一部の下訳を送ってくれたりしました。
12235: また @sc{cvs} について日本語で情報交換するためのメーリング・
12236: リストを立ち上げました。現在このメーリング・リストは
12237: 京都工芸繊維大学の西本卓也さんが引き継いでいます。
12238: 詳細は @file{http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html} 
12239: を参照して下さい。@sc{cvs} 1.9 から @sc{cvs} @value{CVSVN} への更新は
12240: 林芳樹 <g740685@@komaba.ecc.u-tokyo.ac.jp> が行いました。
12241: 
12242: @unnumberedsubsec 日本語訳の配布条件
12243: 
12244: この文書を修正・再配布する場合には、
12245: 原英文の配布条件に従って下さい。
12246: 以下に許諾文の参考訳を付けます。
12247: 
12248: Copyright @copyright{} 1992, 1993 Signum Support AB
12249: Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc.
12250: 
12251: 上記の著作権表示と本許可告知が
12252: すべての写しに前もって載せられている場合にのみ、
12253: 本マニュアルをそのまま複写し配布することを許可します。
12254: 
12255: @ignore
12256: TeX による処理結果に本複写許可告知と同一のものが載せられている場合にのみ、
12257: 本マニュアルのファイルを TeX により出力することを許可します。
12258: (ただし、本段落は TeX の処理結果には表れませんので、
12259: 実際の出力物に本段落は削除されることを除きます。)
12260: 
12261: @end ignore
12262: 本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件の
12263: もとに配布される場合にのみ許可します。
12264: 
12265: 本マニュアルの外国語 (英語以外の言語) への翻訳版の複写と配布は、
12266: 上記の修正版の場合に準じますが、
12267: 本許可告知は Free Software Foundation の許可を得た
12268: 翻訳でなければなりません。
12269: 
12270: @c ---------------------------------------------------------------------
12271: @node Index
12272: @unnumbered Index
12273: @cindex Index
12274: 
12275: @printindex cp
12276: 
12277: @summarycontents
12278: 
12279: @contents
12280: 
12281: @bye
12282: 
12283: Local Variables:
12284: fill-column: 70
12285: End:

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