# HG changeset patch # User Yoshiki Yazawa # Date 1247307935 -32400 # Node ID 8a3041e6f3cb38f6426cd8d3af369ea451a21b60 # Parent 896ab6eaf1c6b6d6028ffdec642767f154bf28b1 reflect comments by Hiroshi Someya. diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/branch.tex --- a/ja/branch.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/branch.tex Sat Jul 11 19:25:35 2009 +0900 @@ -17,7 +17,7 @@ %they're based, but with a few bugs fixed. 多くのソフトウェアプロジェクトでは，新機能を持つメジャーリリースを定期的 -にリリースする．並行して多数のマイナーリリースも行なわれる．これらはメ +にリリースする．並行して多数のマイナーリリースも行われる．これらはメ ジャーリリースのバグを修正したものである． %In this chapter, we'll start by talking about how to keep records of @@ -67,11 +67,11 @@ %\item Newline (ASCII 10, ``\Verb+\n+'') %\end{itemize} -タグは実のところリビジョンに付けられたシンボリックネームに他ならない．タ -グは単にユーザの便宜のために付けられる．タグは特定のリビジョンを参照する -ための手軽で永続的な方法で，Mercurialはタグを翻訳しない．タグの名前には， -明確にパースするためのいくつかのもの以外の制限はない．タグネームは以下の -文字を含むことはできない． +タグは実のところリビジョンに付けられたシンボル名に他ならない．タグは単に +ユーザの便宜のために付けられる．タグは特定のリビジョンを参照するための手 +軽で永続的な方法で，Mercurialはタグを翻訳しない．タグの名前には，明確にパー +スするために必要ないくつかのもの以外に制限はない．タグネームは以下の文字 +を含むことはできない． \begin{itemize} \item コロン (ASCII 58, ``\texttt{:}'') \item 復帰文字 (ASCII 13, ``\Verb+\r+'') @@ -82,7 +82,7 @@ %You can use the \hgcmd{tags} command to display the tags present in %your repository. In the output, each tagged revision is identified %first by its name, then by revision number, and finally by the unique -%hash of the revision. +%hash of the revision. %\interaction{tag.tags} %Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The %\texttt{tip} tag is a special ``floating'' tag, which always @@ -133,9 +133,9 @@ リポジトリの中で使えるタグ数，一つのリビジョンに付けられるタグ数に上限は ない．事情はプロジェクトによって異なるだろうが，実用的にはタグを多く付け -すぎることはあまり良い考えとは言えない．タグとはリビジョンを見つけ易くす -るために使うものだからだ．タグを多く付けすぎると，タグによってリビジョン -の区別をすることがとたんに難しくなる． +すぎることはあまり良い考えとは言えない．タグとはリビジョンを見つけやすく +するために使うものだからだ．タグを多く付けすぎると，タグによってリビジョ +ンの区別をすることがとたんに難しくなる． %For example, if your project has milestones as frequent as every few %days, it's perfectly reasonable to tag each one of those. But if you @@ -281,9 +281,9 @@ %remind you of something like ``Anne saw the symptoms with this %revision''. -Mercurialのタグはリビジョンコントロールされ，プロジェクト履歴に付随してい -るため，同じプロジェクトで働く人は皆タグを知ることになる．リビジョンに名 -前を付けることは，単にリビジョン\texttt{4237e45506ee}がバージョン +Mercurialのタグはリビジョンコントロールされ，プロジェクトの履歴に付随して +いるため，同じプロジェクトで働く人は皆タグを知ることになる．リビジョンに +名前を付けることは，単にリビジョン\texttt{4237e45506ee}がバージョン \texttt{v2.0.2}であると記述する以上の意味を持つ．もしバグを追跡しているな ら，``Anne saw the symptoms with this revision''（アンはこのリビジョンで 症状を見た）などのタグを付けたくなるだろう． @@ -318,9 +318,10 @@ %release to the last main release; and an unexpected ``hot fix'' to an %old release that is now in maintenance mode. -新しい``main''をリリースする状況で，最新のメインリリースに対する新しい小 -規模なバグフィックスリリースと既にメンテナンスモードになっている古いリリー -ス向けの予期せぬ``hot fix'' をリリースする状況を考える． +新しい``main''をリリースする準備にかかっている状態で，最新のメインリリー +スに対する新しい小規模なバグフィックスリリースと，既にメンテナンスモード +になっている古いリリース向けの計画外の``hot fix''をリリースする状況を考え +る． %The usual way people refer to these different concurrent directions of @@ -362,7 +363,7 @@ %of that tag. %\interaction{branch-repo.clone} -Mercurialで``bit picture''を隔離する最も簡単な方法は，専用のリポジトリを +Mercurialで``big picture''を隔離する最も簡単な方法は，専用のリポジトリを 用意することである．もし一つの共有リポジトリを持っている場合，これを \texttt{myproject}と呼ぶことにしる．これが``1.0''マイルストーンに到達した ら，1.0に1.0リリースとタグを付け，将来のメンテナンスリリースに備えること @@ -431,7 +432,7 @@ 多くの場合，ブランチ毎に複数のリポジトリを用意し隔離するのは正しいアプロー チである．これは単純なため把握が容易であり，失敗を犯す可能性が低い．作業 しているブランチとディレクトリの間には1対1の関係がある．Mercurialを考慮し -ない通常のツールをブランチ／リポジトリ内のファイルに大して使うことも可能 +ない通常のツールをブランチ／リポジトリ内のファイルに対して使うことも可能 である． %If you're more in the ``power user'' category (\emph{and} your @@ -514,10 +515,10 @@ か分からないかもしれない．\hgcmd{status}コマンドと\hgcmd{tip}コマンドは それぞれ何を表示するだろうか？ \interaction{branch-named.status} -ワーキングディレクトリ内では何も変化は起きず，何のヒストリも生成されてい -ない．これから分かるように，\hgcmd{branch}コマンドを実行しても，永続的な -効果は何も起きない．このコマンドは\emph{次の}チェンジセットのコミットが -どのブランチに対して行われるかをMercurialコマンドに示すのに使われる． +ワーキングディレクトリ内では何も変化は起きず，何の履歴も生成されていな +い．これから分かるように，\hgcmd{branch}コマンドを実行しても，永続的な効 +果は何も起きない．このコマンドは\emph{次の}チェンジセットのコミットがどの +ブランチに対して行われるかをMercurialコマンドに示すのに使われる． %When you commit a change, Mercurial records the name of the branch on %which you committed. Once you've switched from the \texttt{default} @@ -540,7 +541,7 @@ %Once you've named a branch and committed a change with that name, %every subsequent commit that descends from that change will inherit %the same branch name. You can change the name of a branch at any -%time, using the \hgcmd{branch} command. +%time, using the \hgcmd{branch} command. %\interaction{branch-named.rebranch} %In practice, this is something you won't do very often, as branch %names tend to have fairly long lifetimes. (This isn't a rule, just an @@ -548,7 +549,7 @@ ブランチに名前を付け，その名前を使って変更のコミットを行うと，以後に続く 全てのコミットは同じ名前を持つ．名前の変更は\hgcmd{branch}コマンドを使うこ -とではいつでも可能だ． +とでいつでも可能だ． \interaction{branch-named.rebranch} 実用においては，ブランチ名はかなり長い期間使われる傾向があり，変更は頻繁 には行われない．（これは法則と言えるようなものではなく，単なる観測結果で @@ -580,9 +581,9 @@ %We're on the \texttt{bar} branch, but there also exists an older %\texttt{foo} branch. -このふるまいはやや奇異かもしれない．実際の動作を見てみることにする．まず -我々がどのブランチにいるかを調べ，リポジトリにどんなブランチがあるか見て -みよう． +この振舞いはやや奇異かもしれない．実際の動作を見てみることにする．まず我々 +がどのブランチにいるかを調べ，リポジトリにどんなブランチがあるか見てみよ +う． \interaction{branch-named.parents} 今いるのは\texttt{bar}ブランチで，\texttt{foo}ブランチも存在する． @@ -639,7 +640,7 @@ これはマージの際にMercurialがブランチ名をどのように選ぶかに影響を与える． マージ後、マージの結果をコミットする際にMercurialは1番目の親のブランチ名 を用いる．1番目の親のブランチ名が\texttt{foo}で，\texttt{bar}とマージを -行なったとすると，マージ後のブランチ名は\texttt{foo}となる． +行ったとすると，マージ後のブランチ名は\texttt{foo}となる． %It's not unusual for a repository to contain multiple heads, each with %the same branch name. Let's say I'm working on the \texttt{foo} @@ -650,7 +651,7 @@ 1つのリポジトリが同じブランチ名を持ついくつものheadを持っていることは珍し いことではない．今，私とあなたが同じ\texttt{foo}ブランチで作業をしており， -それぞれ異なった変更をコミットするとしよう．あなたの行なった変更を私が +それぞれ異なった変更をコミットするとしよう．あなたの行った変更を私が pullすると，私は\texttt{foo}ブランチに2つのheadを持つことになる．マージ の結果は，あなたが期待するように\texttt{foo}ブランチ上で1つのheadになる． @@ -660,7 +661,7 @@ %\interaction{branch-named.merge} しかし，私が\texttt{bar}ブランチで作業をしていて，\texttt{foo}ブランチか -らマージを行なうと，成果物は\texttt{bar}ブランチに残ることになる． +らマージを行うと，成果物は\texttt{bar}ブランチに残ることになる． \interaction{branch-named.merge} %To give a more concrete example, if I'm working on the @@ -671,7 +672,7 @@ もっと具体的な例を挙げると，もし私が\texttt{bleeding-edge}ブランチで作業 をしていて，\texttt{stable}ブランチの新しい修正を取り込むために -\texttt{stable}からpullとmergeを行なうと，Mercurialは``正しい''ブランチ名 +\texttt{stable}からpullとmergeを行うと，Mercurialは``正しい''ブランチ名 (\texttt{bleeding-edge})を選ぶ． %\section{Branch naming is generally useful} @@ -710,8 +711,8 @@ 共有リポジトリを使って作業している場合，\hook{pretxnchangegroup}フックを 設定することで間違ったブランチ名を持つ更新をブロックすることができる．こ れは例えば``最先端''ブランチから``安定''ブランチへ変更をpushするような間 -違いを防ぐのにシンプルかつ効果的な方法である．フックは，例えば共有リポジ -トリの \hgrc に +違いを防ぐのにシンプルかつ効果的な方法である．フックは，共有リポジトリの +\hgrc に \begin{codesample2} [hooks] pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch @@ -719,7 +720,7 @@ のように記述される． -%%% Local Variables: +%%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" -%%% End: +%%% End: diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/cmdref.tex --- a/ja/cmdref.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/cmdref.tex Sat Jul 11 19:25:35 2009 +0900 @@ -61,7 +61,7 @@ %all of them. このオプションが指定されなければ\hgcmd{diff}はバイナリと判定されたファイ -ルに対するdiffの生成を行なわない．\hgopt{diff}{-a}を指定すると +ルに対するdiffの生成を行わない．\hgopt{diff}{-a}を指定すると \hgcmd{diff}は全てのファイルをテキストとして扱い，全てのファイルに対して diffを生成する． @@ -69,9 +69,9 @@ %few embedded NUL characters. If you use it on files that contain a %lot of binary data, its output will be incomprehensible. -このオプションは，ほぼ全てがテキストだが一部にNUL文字を含んでいるようなファ -イルに対して有用である．このオプションをバイナリデータが多く含まれるファ -イルに適用すると無意味な出力になるだろう． +このオプションは，ほぼ全てがテキストだが一部にヌル文字を含んでいるような +ファイルに対して有用である．このオプションをバイナリデータが多く含まれる +ファイルに適用すると無意味な出力になるだろう． \optref{diff}{b}{ignore-space-change} @@ -97,7 +97,7 @@ %\interaction{cmdref.diff-p} ハンクヘッダの中に含まれている関数の名前を表示する．検索は単純な発見的方 -法で行なう．この機能はデフォルトで有効にされており，\hgopt{diff}{-p}オプ +法で行う．この機能はデフォルトで有効にされており，\hgopt{diff}{-p}オプ ションは下の例のように\rcitem{diff}{showfunc}設定を変更されるまで意味をな さない． \interaction{cmdref.diff-p} diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/collab.tex --- a/ja/collab.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/collab.tex Sat Jul 11 19:25:35 2009 +0900 @@ -133,8 +133,8 @@ ムにとっては大きな驚きと葛藤を与えてしまったことがある．複雑なブランチの 集合がなぜ必要なのか変更がブランチ間でどのように伝播するのかを説明したに もかかわらず，幾人かのチームメンバーは反発した．彼らは聡明であったが，私 -が拘ったルールが作業に与える制限や，モデルの細部に与える影響に注意を払う -ことは望まなかった． +の拘ったルールが作業に与える制限や，モデルの細部に与える影響に注意を払う +ことを望まなかった． %Don't sweep foreseeable social or technical problems under the rug. %Whatever scheme you put into effect, you should plan for mistakes and @@ -506,12 +506,12 @@ Linusは多くの``信頼できる代行者''を持っている．原則的には彼は彼らが公開し たものは何でもpullする．多くの場合，彼らの変更をレビューすることもしな -い．代行者の何人かはメンテナーとなることを同意しており，カーネル内の特定 -のサブシステムに対して責任を持つ．カーネルハッカーの誰かがLinusのツリーの -サブシステムに変更を加えたいと思ったら，サブシステムのメンテナーを見つけ -出した上で，メンテナーに変更を取り込んで貰うように依頼する必要がある．メ -ンテナーが変更をレビューし，取り込むことに同意すれば，正式なコースで変更 -をLinusに手渡す． +い．代行者の何人かはメンテナとなることを同意しており，カーネル内の特定の +サブシステムに対して責任を持つ．カーネルハッカーの誰かがLinusのツリーのサ +ブシステムに変更を加えたいと思ったら，サブシステムのメンテナを見つけ出し +た上で，メンテナに変更を取り込んで貰うように依頼する必要がある．メンテナ +が変更をレビューし，取り込むことに同意すれば，正式なコースで変更をLinusに +手渡す． %Individual lieutenants have their own approaches to reviewing, %accepting, and publishing changes; and for deciding when to feed them @@ -553,13 +553,13 @@ %hasn't yet accepted, people with similar interests may pull your %changes regularly to keep up with your work. -第二に，これは評判と称賛とによるシステムであるということだ．無名の開発者 -の変更に対してはLinusはおそらく反応することなく無視する．しかしサブシステ -ムメンテナは変更をレビューし，適切であると判断すれば採り入れる．開発者が -良い変更を行えば行うほど，メンテナは開発者の判断を信用し，変更を採り入れ -るようになるだろう．開発者が著名で，Linusがいまだに受け入れていない，長期 -間にわたるブランチのメンテナであるならば，同じ興味を持つ人々が彼の作業を -取り込むために変更を定期的にpullすることだろう． +第二に，これは評判と称賛によるシステムであるということだ．無名の開発者の +変更に対してはLinusはおそらく反応することなく無視する．しかしサブシステム +メンテナは変更をレビューし，適切であると判断すれば採り入れる．開発者が良 +い変更を行えば行うほど，メンテナは開発者の判断を信用し，変更を採り入れる +ようになるだろう．開発者が著名で，Linusがいまだに受け入れていない，長期間 +にわたるブランチのメンテナであるならば，同じ興味を持つ人々が彼の作業を取 +り込むために変更を定期的にpullすることだろう． %Reputation and acclaim don't necessarily cross subsystem or ``people'' %boundaries. If you're a respected but specialised storage hacker, and @@ -702,10 +702,10 @@ %This can help you to quickly get acquainted with using commands on %network-hosted repositories. -Mercurialの\hgcmd{serve}コマンドを使って，手元のコンピュータでリポジトリ -サービスを行うのは簡単である．遠方にあるサーバとやりとりするのと同様に -\hgcmd{clone}，\hgcmd{incoming}等のコマンドを使うことができる．これはリポ -ジトリをネットワークで提供することに慣れるのに役立つだろう． +Mercurialの\hgcmd{serve}コマンドを使って，簡単に手元のコンピュータでリポ +ジトリサービスを行うことができる．遠方にあるサーバとやりとりするのと同様 +に\hgcmd{clone}，\hgcmd{incoming}等のコマンドを使うことができる．これはネッ +トワークでリポジトリを提供する練習になるだろう． %\subsection{A few things to keep in mind} \subsection{覚えておくべき2, 3の点} @@ -973,7 +973,7 @@ パスフレーズをエージェントに記憶させる弊害は，パワーサイクルを行っても場 合によっては周到な手段を用いる攻撃者にパスフレーズのプレーンテキスト情報 -を取得される可能性があることである．このリスクが許容で着る物稼働かは自分 +を取得される可能性があることである．このリスクが許容できるかどうかは自分 自身で判断して欲しい．この方法を用いることで，タイプ回数を減らせることは 確かである． @@ -1287,8 +1287,8 @@ %Depending on how ambitious you are, configuring Mercurial's CGI %interface can take anything from a few moments to several hours. -どの程度のことを狙うかによって，MercurialのCGIインタフェースの設定には数 -分から数時間程度の時間がかかる． +MercurialのCGIインタフェースの設定にかかる時間は，目的とするところに応じ +て数分から数時間程度の幅がある． %We'll begin with the simplest of examples, and work our way towards a %more complex configuration. Even for the most basic case, you're @@ -1442,7 +1442,7 @@ 由が考えられ，実際，そのすべてに引っ掛かっている可能性が高いので，以下の 記述を注意深く読んで欲しい．ここに挙げたのは，Fedora~7で，新規にインストー ルされたApacheと，この例題のために新規に作成したユーザアカウントで筆者が -実際にで遭遇した問題である． +実際に遭遇した問題である． %Your web server may have per-user directories disabled. If you're %using Apache, search your config file for a \texttt{UserDir} @@ -1518,8 +1518,8 @@ %of executing it, you may need to either uncomment (if already present) %or add a directive like this. ApacheがCGIスクリプトを実行するのではなく，スクリプト自体のテキストを送っ -てくる場合は，以下のディレクティブを追加するか，すでに存在してコメントア -ウトされていれば，アンコメントする． +てくる場合は，以下のディレクティブを追加する．ディレクティブがすでにあり， +コメントアウトされているのなら，有効化する． \begin{codesample2} AddHandler cgi-script .cgi \end{codesample2} @@ -1853,7 +1853,7 @@ \item[\rcitem{web}{allowpull}] ブール値．リモートユーザにウェブインタフェー スを用いた~HTTPによる\hgcmd{pull}及び\hgcmd{clone}を許可す るかどうかを決める．\texttt{no}または\texttt{false}の場合， - ウェブインタフェースは人間の閲覧のみが可能になる． + ウェブインタフェースはブラウザによる閲覧のみが可能になる． %\item[\rcitem{web}{contact}] String. A free-form (but preferably % brief) string identifying the person or group in charge of the @@ -2066,7 +2066,7 @@ %stating that it does not trust their \filename{.hg/hgrc}. システム全体の\filename{hgrc}ファイルが有用な場合の一例に，他のユーザが所 -有数rリポジトリからpullする場合がある．デフォルトではMercurialは別のユー +有するリポジトリからpullする場合がある．デフォルトではMercurialは別のユー ザの所有するリポジトリ内にある\filename{.hg/hgrc}ファイルのほとんどの項目 を信頼しない．そのようなリポジトリからクローンや変更のpullを行う と，Mercurialは\filename{.hg/hgrc}を信頼しないという警告を表示する． diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/concepts.tex --- a/ja/concepts.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/concepts.tex Sat Jul 11 19:25:35 2009 +0900 @@ -469,7 +469,7 @@ %purposes. Mercurial uses the parents of the dirstate as \emph{the % parents of a new changeset} when you perform a commit. -dirstateは管理目的意外の情報も保存している． Mercurialは，コミットの際に +dirstateは管理目的以外の情報も保存している． Mercurialは，コミットの際に dirstateの両親を\emph{新たなチェンジセットの両親}として用いる． \begin{figure}[ht] @@ -606,9 +606,9 @@ ``エラー''という言葉を引用符で括ったのは，この状態は\hgcmd{merge}と \hgcmd{commit}だけで解消できるからだ．言い替えると，この状態はほとんどの -場合害をなすものではななく，単に初心者を驚かす程度のものである．この振舞 -を避ける別の方法や，なぜMercurialがこのように驚かせるような方法で動作する -のかについては後ほど議論する． +場合害をなすものではなく，単に初心者を驚かす程度のものである．この振舞を +避ける別の方法や，なぜMercurialがこのように驚かせるような方法で動作するの +かについては後ほど議論する． \end{note} %\subsection{Merging changes @@ -684,8 +684,8 @@ 詳しく述べればマージにはいろいろな特殊例がある．しかしここでは最も普通の 選択について説明する．これまで見てきたように，大半のケースは完全に自動で -あり，実際に大半のマージは衝突を解決するために入力を求めることなく自動的 -に完了する． +あり，実際に大半のマージはコンフリクトを解決するために入力を求めることな +く自動的に完了する． %When you're thinking about what happens when you commit after a merge, %once again the working directory is ``the changeset I'm about to @@ -816,7 +816,7 @@ ルゴリズム（広く用いられている圧縮パッケージである\texttt{bzip2}で使われ ているBurrows-Wheelerアルゴリズム）で再圧縮する．このアルゴリズムと，（リ ビジョン毎でなく）ストリーム全体を圧縮することにより，送信されるバイト数 -は大きく低減され，あらゆるネットワークでよい性能をえることができる． +は大きく低減され，あらゆるネットワークでよい性能を得ることができる． %(If the connection is over \command{ssh}, Mercurial \emph{doesn't} %recompress the stream, because \command{ssh} can already do this @@ -914,7 +914,7 @@ らく待つ．しかしリポジトリが長時間にわたってロックされ続ける場合は，書き 込みしようとするプロセスはタイムアウトする．これは，例えば，日常用いる自 動スクリプトは永遠にスタックするわけではないことを意味する．（もちろんタ -イムアウトまでの時間はゼロから無限の間で設定かのうである） +イムアウトまでの時間はゼロから無限の間で設定可能である） %\subsubsection{Safe dirstate access} \subsubsection{安全なdirstateアクセス} @@ -930,9 +930,9 @@ リビジョンデータの時と同様に，Mercurialはdirstateファイルを読み出す際には ロックを行わない．ロックを行うのは書き込みの時のみである．一部のみが書き 込まれたdirstateファイルを読み込まないようにするため， Mercurialは同じディ -レクトリ内にユニークな名前でdirstateファイルを書き，この一時ファイルをア -トミックに\filename{dirstate}にリネームする．これによ -り，\filename{dirstate}ファイルは常に完全であることが保証される． +レクトリ内に固有な名前でdirstateファイルを書き，この一時ファイルをアトミッ +クに\filename{dirstate}にリネームする．これにより，\filename{dirstate}ファ +イルは常に完全であることが保証される． %\subsection{Avoiding seeks} \subsection{シークの回避} @@ -941,8 +941,8 @@ %disk head, since any seek is far more expensive than even a %comparatively large read operation. -Mercurialの性能には，ディスクヘッドのシークを避けることが不可欠である． -シークは大規模な読み出し操作と比較しても非常に高くつく． +ディスクヘッドのシークを避けることはMercurialの性能にとって極めて重要であ +る．シークは大規模な読み出し操作と比較しても非常に高価である． %This is why, for example, the dirstate is stored in a single file. If %there were a dirstate file per directory that Mercurial tracked, the diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/daily.tex --- a/ja/daily.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/daily.tex Sat Jul 11 19:25:35 2009 +0900 @@ -430,7 +430,7 @@ %this behavior is not appropriate to your specific case. 何らかの理由でこのように変更が自動的に波及するやり方が好ましくないと思わ -れる場合は，システム標準のあファイルコピーコマンド（UNIX系システムでは +れる場合は，システム標準のファイルコピーコマンド（UNIX系システムでは \command{cp}）を使ってファイルのコピーを行い，\hgcmd{add}で新しいコピーを 手動で追加することができる．これを実際に行う前 に，~\ref{sec:daily:why-copy}節を再読し，このやり方の詳細を踏まえた上で， @@ -587,7 +587,7 @@ 変更がコピーに従う機能が有用であることは，おそらく容易に同意が得られると ころであると思われる．とりわけリネームに追従する機能はきわめて重要である ことは明白である．もしこの機能がなければ，ファイルのリネームによって変更 -は容易く行き場を失ってしまうだろう． +はたやすく行き場を失ってしまうだろう． %\subsection{Divergent renames and merging} \subsection{名前とマージの発散} @@ -638,8 +638,8 @@ %guide it to a suitable resolution. 2人のユーザが異なる\emph{ソース}ファイル群を同一の\emph{目的}ファイルにリ -ネームすると衝突が起きる．この場合，Mercurialは通常のマージ機構を起動し， -ユーザに適切な解決を促す． +ネームするとコンフリクトが起きる．この場合，Mercurialは通常のマージ機構を +起動し，ユーザに適切な解決を促す． %\subsection{Other name-related corner cases} \subsection{名前に関連したいくつかの問題} diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/filenames.tex --- a/ja/filenames.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/filenames.tex Sat Jul 11 19:25:35 2009 +0900 @@ -22,8 +22,8 @@ %If you explicitly name real files on the command line, Mercurial works %with exactly those files, as you would expect. -コマンドラインに実際のファイル名を明示的に与えた時は，Mercurialはそれら -のファイルそのものを扱う． +コマンドラインに実際のファイル名を明示的に与えた時は，Mercurialは与えら +れたファイルだけを扱う． \interaction{filenames.files} %When you provide a directory name, Mercurial will interpret this as @@ -66,10 +66,10 @@ % or pattern (see below). This protects you from accidentally % deleting files by running \hgcmd{remove} with no arguments, for % example. - \item 復元が難しかったり不可能であるような効果を持つコマンドの場合，最低 - 1つの名前やパターンを陽に要求する．（下記を参照．）これにより，例 - えば\hgcmd{remove}に引数を与えなかったことによって誤ってファイルを - すべて消したりすることがなくなる． + \item 復元が困難であったり不可能であるような効果を持つコマンドの場合，最 + 低1つの名前やパターンを明示することを求める（下記を参照．）．こう + することで，例えば\hgcmd{remove}に引数を与えなかったためにファイル + すべてを誤って消すことがなくなる． \end{itemize} %It's easy to work around these default behaviours if they don't suit @@ -87,27 +87,20 @@ %Along the same lines, some commands normally print file names relative %to the root of the repository, even if you're invoking them from a %subdirectory. Such a command will print file names relative to your - %subdirectory if you give it explicit names. Here, we're going to run - %\hgcmd{status} from a subdirectory, and get it to operate on the %entire working directory while printing file names relative to our - %subdirectory, by passing it the output of the \hgcmd{root} command. %\interaction{filenames.wdir-relname} -サブディレクトリから起動してもリポジトリのルートへの相対パスでファイル名 -を表示するコマンドもある．そのようなコマンドでは，サブディレクトリの名前 -を明示的に与えると，サブディレクトリからの相対パスを表示するようになる． - -ここではサブディレクトリから\hgcmd{status}を実行する際に， - - -して， -コマンドがワーキングディレクトリ全体のファイル名をサブディレクトリに対して相対的に -表示する様を見てみよう． - - +サブディレクトリから起動してもファイル名をリポジトリのルートからの相対パ +スで表示するコマンドがある．そのようなコマンドに明示的にサブディレクトリ +名を与えると，現在のサブディレクトリからの相対パスが表示される．ここで， +サブディレクトリ内から\hgcmd{status}コマンドに\hgcmd{root}コマンドの出力 +を引数として与えて起動し， \hgcmd{status}コマンドがワーキングディレクトリ +内のファイルを現在のサブディレクトリに対する相対パスで表示する様子を見て +みよう． +\interaction{filenames.wdir-relname} %\section{Telling you what's going on} @@ -593,7 +586,8 @@ ちは問題とならない．しかしワーキングディレクトリをそのチェンジセットに \hgcmd{update}しようとしたり，そのチェンジセットと\hgcmd{merge}しようとす ると，Mercurialは， 2つのファイル名をファイルシステムが同じ名前として扱う -ために生じるコンフリクトを検出し， updateやmergeを許さない． +ために生じるコンフリクトを検出し， \hgcmd{update}や\hgcmd{merge}を許さな +い． %\subsection{Fixing a case conflict} \subsection{大文字小文字の衝突を解決する} @@ -627,7 +621,7 @@ %you can continue development unimpeded. 大小文字のファイル名コンフリクトがあるチェンジセットはプロジェクトの履歴 -に残っており， WindowsやMacOSしすてむではそのチェンジセットへ +に残っており， WindowsやMacOSシステムではそのチェンジセットへ \hgcmd{update}することはできないものの，問題なく開発を続けることができる． diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/hgext.tex --- a/ja/hgext.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/hgext.tex Sat Jul 11 19:25:35 2009 +0900 @@ -191,8 +191,8 @@ %extensions. But the performance improvement is worth it! 2007年5月までは\hgext{inotify}拡張はMercurialに同梱されていなかった．その -ため，セットアップは他の拡張に比べてやや複雑だが，得られる性能向上はには -それだけの価値がある． +ため，セットアップは他の拡張に比べてやや複雑だが，得られる性能向上にはそ +れだけの価値がある． %The extension currently comes in two parts: a set of patches to the %Mercurial source code, and a library of Python bindings to the diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/hook.tex --- a/ja/hook.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/hook.tex Sat Jul 11 19:25:35 2009 +0900 @@ -318,8 +318,8 @@ Mercurialはデータの読み書きの順序を注意深く行うため，リポジトリからのデー タ読み出しの際にロックを取得する必要がない． Mercurialのリポジトリから読 -み出しを行う部分は，ロックを全く気にする必要がない．この無ロック読み出し -によって，同時実行性と性能を大幅に高めている． +み出しを行う部分は，ロックを全く気にする必要がない．このロックなし読み出 +しによって，同時実行性と性能を大幅に高めている． %With great performance comes a trade-off, though, one which has the %potential to cause you trouble unless you're aware of it. To describe @@ -1100,7 +1100,7 @@ \hgext{acl}フックをテストしたい場合は，Mercurialのデバッグ出力を有効にし て実行すると良い．サーバ上で実行するのであれば、\hggopt{--debug}オプショ ンを渡すのは不便であったり、不可能であったりすることがある。このため、デ -バッグ出力は \hgrc でえも有効にできることを記憶しておくべきである． +バッグ出力は \hgrc でも有効にできることを記憶しておくべきである． \begin{codesample2} [ui] debug = true @@ -1316,9 +1316,9 @@ %section. デフォルトでは\hgext{bugzilla}フックはバグを更新するBugzillaユーザ名とし -てチェンジセットのコミッタのemailアドレスを使おうとする． -この挙動が望ましくない場合は，\rcsection{usermap}セクションをせっていする -ことでコミッタのemailアドレスをBugzillaのユーザ名にマップすることができる． +てチェンジセットのコミッタのemailアドレスを使おうとする．この挙動が望まし +くない場合は，\rcsection{usermap}セクションを設定することでコミッタの +emailアドレスをBugzillaのユーザ名にマップすることができる． %Each item in the \rcsection{usermap} section contains an email address %on the left, and a Bugzilla user name on the right. @@ -1820,7 +1820,7 @@ %parameter is ``\texttt{node}'', the name of the environment variable %representing that parameter will be ``\texttt{HG\_NODE}''. -フックパラメータはフックに環境篇ストして渡される．各々の環境変数名は大文 +フックパラメータはフックに環境変数として渡される．各々の環境変数名は大文 字に変換され，接頭辞``\texttt{HG\_}''が付けられる．例えば ``\texttt{node}''というパラメータが使われたとすると，このパラメータを表 す環境変数名は``\texttt{HG\_NODE}''となる． @@ -2178,7 +2178,7 @@ %push to it, while still allowing a local administrator to modify the %repository. -このフックを使って，外部の変更がリポジトリについかされないようにすること +このフックを使って，外部の変更がリポジトリに追加されないようにすること もできる．例えば，このフックをサーバで提供されるブランチを一時的または永 続的に``凍結''し，ローカルな管理者はリポジトリを変更できるが，リモート ユーザはそのリポジトリにpushできないようにできる． @@ -2312,9 +2312,10 @@ %\end{itemize} \begin{itemize} -\item[\texttt{local}] ブール値．新しいタグがリポジトリローカルなもの - (\sfilename{.hg/localtags}に保存される)かMercurialに管理 - されるもの(\sfilename{.hgtags}に保存される)かを示す． +\item[\texttt{local}] ブール値．新しいタグが現在のリポジトリにローカルな + もの(\sfilename{.hg/localtags}に保存される)かMercurialでグロー + バルに管理されるもの(\sfilename{.hgtags}に保存される)かを示 + す． \item[\texttt{node}] チェンジセットID．タグ付けされるチェンジセットのID. \item[\texttt{tag}] 文字列．生成されたタグの名前． \end{itemize} @@ -2524,9 +2525,10 @@ このフックへのパラメータ： \begin{itemize} -\item[\texttt{local}] ブール値．新しいタグがリポジトリローカルなもの - (\sfilename{.hg/localtags}に保存される)かMercurialに管理 - されるもの(\sfilename{.hgtags}に保存される)かを示す． +\item[\texttt{local}] ブール値．新しいタグが現在のリポジトリにローカルな + もの(\sfilename{.hg/localtags}に保存される)かMercurialにグロー + バルに管理されるもの(\sfilename{.hgtags}に保存される)かを示 + す． \item[\texttt{node}] チェンジセットID．タグ付けされるチェンジセットのID. \item[\texttt{tag}] 文字列．生成されたタグの名前． \end{itemize} diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/intro.tex --- a/ja/intro.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/intro.tex Sat Jul 11 19:25:35 2009 +0900 @@ -11,10 +11,9 @@ %new name that contains a number, each one higher than the number of %the preceding version. -リビジョンコントロールとは，複数のバージョンの情報をを管理するプロセスで -ある．最も単純な方法は，ファイルを変更したら，それまでのバージョンよりも -大きな数字を含む新たな名前でセーブを行うなどの方法で全て手で行うことであ -る． +リビジョンコントロールとは，複数のバージョンの情報を管理するプロセスであ +る．最も単純な方法は，ファイルを変更したら，それまでのバージョンよりも大 +きな数字を含む新たな名前でセーブを行うなどの方法で全て手で行うことである． %Manually managing multiple versions of even a single file is an %error-prone task, though, so software tools to help automate this @@ -54,9 +53,9 @@ % makes it easier for you to collaborate. For example, when people % more or less simultaneously make potentially incompatible changes, % the software will help you to identify and resolve those conflicts. - \item 他の人と作業している時，リビジョンコントロールソフトウェアは共同 - 作業を助ける．例えば，人々が同時に互換性のない変更を行った場合， - ソフトウェアはコンフリクトを特定し，可決することを助ける． + \item リビジョンコントロールソフトウェアは他の人との共同作業を助ける．例 + えば，複数のユーザが同時に互換性のない変更を行った場合，ソフトウェ + アの支援でコンフリクトを特定し解決することができる． %\item It can help you to recover from mistakes. If you make a change % that later turns out to be in error, you can revert to an earlier % version of one or more files. In fact, a \emph{really} good @@ -84,10 +83,10 @@ %\emph{benefits} compare to its \emph{costs}. A revision control tool %that's difficult to understand or use is going to impose a high cost. -リビジョンコントロールの実用性に関する鍵になる質問は，これらの2つの異なっ -たスケール（``一人のハッカー''レベルから``大規模チーム''レベルまで）にお -いて，コストに対してどれだけ利益があるのかということである．理解や使用が -困難なリビジョンコントロールツールは高いコストを押しつける． +リビジョンコントロールが実用的であるかどうか判断する鍵は，さまざまな開発 +スケール（``1人のハッカー''レベルから``大規模チーム''レベルまで）におい +て，支払うコストに対してどれだけ効能が得られるかということである．理解や +使用が困難なリビジョンコントロールツールは高いコストを課すことになる． %A five-hundred-person project is likely to collapse under its own %weight almost immediately without a revision control tool and process. @@ -96,9 +95,8 @@ %guaranteed. 500人からなるプロジェクトでは，リビジョンコントロールツールなしでは殆んど -立ち行かない．この場合，リビジョンコントロールなしでは失敗することが殆ん -ど明白なため，リビジョンコントロールを行うコストを払うことは特に問題とは -ならない．%xxx +立ち行かない．この場合，リビジョンコントロールなしでは明らかに失敗するた +め，リビジョンコントロールを行うコストは特に問題とはならない．%xxx %On the other hand, a one-person ``quick hack'' might seem like a poor %place to use a revision control tool, because surely the cost of using @@ -243,12 +241,13 @@ %``pain level'' of fixing these architectural problems prohibitive. 1990年代中頃になると，CVSの問題が広く知られるようになってきた． CVSは一度 -に複数のファイルに対して行われる変更を論理的にアトミックな操作としてグルー -プ化するのではなく，ファイル毎に個別に記録していた．CVSのファイルヒエラル -キーの管理は不十分で，ファイルやディレクトリをリネームすると簡単にリポジ -トリが混乱した．さらに悪いことに，CVSのソースコードは読みにくく，メンテナ -ンスも難しかったため，アーキテクチャの問題を解決するのは不可能なレベルと -言えた． +に複数のファイルに対して行われる変更を論理的にアトミックな操作 +\footnote{訳注：あたかも原子のように，複数の要素に分解できない操作を言う}と +してグループ化するのではなく，ファイル毎に個別に記録していた．CVSのファイ +ルヒエラルキーの管理は不十分で，ファイルやディレクトリをリネームすると簡 +単にリポジトリが混乱した．さらに悪いことに，CVSのソースコードは読みにく +く，メンテナンスも難しかったため，アーキテクチャの問題を解決するのは不可 +能なレベルと言えた． %In 2001, Jim Blandy and Karl Fogel, two developers who had worked on %CVS, started a project to replace it with a tool that would have a @@ -322,12 +321,12 @@ 第二世代のツールは，ネットワーク中心のアーキテクチャに移行することで，そ れまでの制限を緩和し，プロジェクト全体を同時に管理した．プロジェクトが大 -きく成長すると，新たな問題に直面した．クライアントがサーバに頻繁に通信す +きく成長すると，新たな問題に直面した．クライアントとサーバが頻繁に通信す るため，大規模プロジェクトではサーバの規模が問題になった．信頼性のないネッ トワーク接続はリモートユーザがサーバと通信するのを妨げた．オープンソース プロジェクトがコミット権のないユーザにも匿名の読み出し専用アクセスを提供 -するようになると，ツールは彼らの行った変更を記録できないため，プロジェク -トとやりとりを行う自然な手段とは言えないことがわかった． +するようになると，ユーザらはこれらのツールが行った変更を記録できず，プロ +ジェクトとのやりとりが不便であることに不満を募らせていった． %The current generation of revision control tools is peer-to-peer in %nature. All of these systems have dropped the dependency on a single @@ -403,12 +402,12 @@ %you have a far-flung team of collaborators, this may be significant. 分散ツールでは，ネットワークの信頼性の与える影響は集中ツールに比べて遥か -に小さい．集中ツールは，いくつかの大きな制限のあるコマンドを除いてネット -ワーク接続なしに使用できない．分散ツールでは作業中にネットワーク接続が断 -たれたとしてもそれに気づくことすらないだろう．他のコンピュータのリポジト -リとの通信を行う動作のみが影響を受ける．このような動作はローカルでの動作 -より相対的に少ないはずだ．これが重大な問題となるのは，広範囲にわたるチー -ムで作業をしている場合であろう． +に小さい．集中ツールは，ネットワークに接続しなければ，大きな制限のあるい +くつかのコマンド以外は使用できない．分散ツールでは作業中にネットワーク接 +続が断たれたとしてもそれに気づくことすらないだろう．他のコンピュータのリ +ポジトリとの通信を行う動作のみが影響を受ける．このような動作はローカルで +の動作より相対的に少ないはずだ．これが重大な問題となるのは，広範囲にわた +るチームで作業をしている場合であろう． %\subsection{Advantages for open source projects} \subsection{オープンソースプロジェクトでの利点} @@ -464,7 +463,7 @@ 中リビジョンコントロールシステムでは，差異を\emph{技術的に}解決する過程に 困難を伴い，多くの場合，手動で解消する必要がある．どのリビジョン履歴を残 すのか決め，ほかのチームによる変更をツリーへなんらかの方法で継ぎ木する必 -要がある．この操作では，通常，一方のリビジョン履歴の一部または全体を失う +要がある．この操作では，通常，一方のリビジョン履歴の一部または全てを失う ことになる． %What distributed tools do with respect to forking is they make forking @@ -491,7 +490,7 @@ %to as a ``fork'' becomes \emph{purely} a social issue. If anything, %distributed tools \emph{lower} the likelihood of a fork: -各人が常に行う作業の断片がフォークとマージに位置付けられるならば，オープ +各人が行う全ての部分作業がフォークとマージに位置付けられるならば，オープ ンソース界は``フォーク''を\emph{純粋に}社会的な事象として扱うだろう．いず れにせよ分散ツールはフォークの蓋然性を\emph{下げる}： @@ -506,8 +505,9 @@ \begin{itemize} \item 中央集中的なツールが課す，コミット権を持った内部の人間と持たない外 部の人間の社会的な区別を取り去る - \item リビジョンコントロールソフトウェアの観点からすると，同じマージであ - るため，社会的なフォークの後に差異を解消するのを容易にする． + \item リビジョンコントロールソフトウェアの観点からは同じマージであるた + め，開発コミュニティのフォーク後に生じた差異を解消するのが容易にな + る． \end{itemize} @@ -926,8 +926,8 @@ Perforceの性能は，小規模なチームでの作業においてはかなり良い．しかしユー ザ数が数ダース以上に増加するに従って，急激に悪くなっていく．かなり大規模 -なPerforce環境では，ユーザの操作による負荷を軽減するためのプロキシーが必 -要になる． +なPerforce環境では，ユーザの操作による負荷を軽減するためのプロキシが必要 +になる． %\subsection{Choosing a revision control tool} \subsection{リビジョンコントロールツールを選ぶ} diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/mq-collab.tex --- a/ja/mq-collab.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/mq-collab.tex Sat Jul 11 19:25:35 2009 +0900 @@ -19,7 +19,7 @@ この章では，Linuxカーネル用Infinibandデバイスドライバの開発を管理するのに 用いたテクニックを例として用いる．このドライバは（ドライバとしては）大規 模で，35のソースファイルにわたる25000行からなる．このソースは小規模な開発 -者のチームによってい時管理されている． +者のチームによって維持管理されている． %While much of the material in this chapter is specific to Linux, the %same principles apply to any code base for which you're not the @@ -163,13 +163,12 @@ %This gives us a tiny repository that contains two patches that don't %have any dependencies on each other, because they touch different files. -多くのターゲットを対象としながら正常に保つ一番良い方方は，状況に応じて特 +多くのターゲットを対象としながら正常に保つ一番良い方法は，状況に応じて特 定のパッチを選べるようにすることである．MQはこの目的のためにquiltの \texttt{guards}コマンドに類似した``guards''と呼ばれる機能を提供している． 開始に当たって，実験のために単純なリポジトリを作成する． -\interaction{mq.guards.init} -小さなリポジトリを作り，別々のファイルを操作する互いに依存性のない2つのパッ -チを置く． +\interaction{mq.guards.init}小さなリポジトリを作り，別々のファイルを操作 +する互いに依存性のない2つのパッチを置く． %The idea behind conditional application is that you can ``tag'' a %patch with a \emph{guard}, which is simply a text string of your @@ -177,11 +176,10 @@ %patches. MQ will then either apply, or skip over, a guarded patch, %depending on the guards that you have selected. -条件付きでパッチパッチの適用をコントロールする方法の背後にあるの -は，\emph{guard}によってパッチに付けられた``タグ''である．タグは自由に選 -んだ単純なテキストで，MQがパッチを適用するときに用いる特定のガードを指定 -する．MQはガードパッチの適用またはスキップを，指定されたガードによって決 -定する． +条件付きでパッチの適用を制御する方法では，\emph{guard}によってパッチに付 +けられた``タグ''を活用する．タグは自由に選んだ単純なテキストで，MQがパッ +チを適用するときに用いる特定のガードを指定する．MQはガードパッチの適用ま +たはスキップを，指定されたガードによって決定する． %A patch can have an arbitrary number of guards; %each one is \emph{positive} (``apply this patch if this guard is diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/mq-ref.tex --- a/ja/mq-ref.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/mq-ref.tex Sat Jul 11 19:25:35 2009 +0900 @@ -224,7 +224,7 @@ % added to the newly created patch, so after this command completes, % the working directory will no longer be modified. \item[\hgxopt{mq}{qnew}{-f}] カレントディレクトリの内容が更新されている - 場合，新しいパッチを作成する．孤立した変王 + 場合，新しいパッチを作成する．孤立した変更 は新規に作成したパッチに追加され，このコマ ンドが終了するとワーキングディレクトリは変 更なしの状態になる． diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/mq.tex --- a/ja/mq.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/mq.tex Sat Jul 11 19:25:35 2009 +0900 @@ -179,8 +179,8 @@ %Quilt knows nothing about revision control tools, so it works equally %well on top of an unpacked tarball or a Subversion working copy. -quiltはリビジョン管理ツールについては全く関知しないため，展開されたtarボー -ル上でも，Subversionのワーキングコピー上でも同様に動作する． +quiltはリビジョン管理ツールについては全く関知しないため，展開されたtarアー +カイブ上でも，Subversionのワーキングコピー上でも同様に動作する． %\subsection{From patchwork quilt to Mercurial Queues} \subsection{patchwork quiltからMercurial Queuesへ} @@ -236,7 +236,7 @@ %leaving unneeded---or worse, misleading or destabilising---traces of %your missteps and errors in the permanent revision record. -伝統的なリビジョンコントロールツールは，行なった操作の永久的で不可逆的な +伝統的なリビジョンコントロールツールは，行った操作の永久的で不可逆的な 記録を残す．これには大きな価値がある一方で，窮屈に感じることもある．もし 過激な実験をするのであれば，どのように進めるか慎重にする必要がある．さも なければ，不要な，あるいは誤解を招いたり，安定性を損なうトレースとエラー @@ -271,7 +271,7 @@ 用されたパッチは，関連づけられたチェンジセットを持つため， \hgcmdargs{log}{\emph{filename}}によってどのチェンジセットとパッチがファ イルに影響を与えているか調べることができる．\hgext{bisect}コマンドで全て -のチェンジセットと適用されたパッチに対してバイナリサーチを行ない，どこで +のチェンジセットと適用されたパッチに対してバイナリサーチを行い，どこで バグが混入したか，あるいは修正されたかを調べることができる． \hgcmd{annotate}コマンドでどのチェンジセットかパッチがソースファイルの特 定の行を変更したか見ることができる． @@ -466,8 +466,8 @@ \sdirname{.hg/patches}ディレクトリの中には，\sfilename{series}と \sfilename{status}という2つのファイルも新しく作られる． -\sfilename{series}ふぁいるはMQが関知する，このリポジトリ内の全てのパッチ -のリストがあり，一行に一つのパッチが記述されている．Mercurialは +\sfilename{series}ファイルはMQが関知する，このリポジトリ内の全てのパッチ +のリストがあり，1行に1つのパッチが記述されている．Mercurialは \sfilename{status}ファイルを内部の管理に用いる．このファイルはリポジトリ 内でMQが適用した全てのパッチが記録されている． @@ -708,7 +708,7 @@ %files affected by the patch that it is popping. Be sure to read the %documentation for a command's \option{-f} option before you use it! -ワーキングディレクトリのチェックを行なうコマンドは全て，上級者向けの強制 +ワーキングディレクトリのチェックを行うコマンドは全て，上級者向けの強制 オプション\option{-f}を持っている．\option{-f}の厳密な意味は，コマンドに よって異なる．例えば\hgcmdargs{qnew}{\hgxopt{mq}{qnew}{-f}}は孤立した変 更を新しいパッチに取り込むという意味だが， @@ -725,7 +725,7 @@ %work on \emph{that} patch for a while. \hgxcmd{mq}{qrefresh}コマンドは\emph{最も上}に適用されたパッチに対してリ -フレッシュを行なう．これはリフレッシュによって1つのパッチに現在の作業をサ +フレッシュを行う．これはリフレッシュによって1つのパッチに現在の作業をサ スペンドしたり，別のトップパッチや一時的に作業するためパッチを作るために ポップやプッシュができるということを意味する． @@ -744,9 +744,9 @@ とする．最初のものはあなたのソフトウェアのコアを変更し，2番目のものは1番 目のものの上に展開する，今追加したコアのコードを使ったユーザインタフェー スだとする．UIパッチで作業中にコアのバグに気付いたとすると，簡単にコアの -修正は行なえる．単純に\hgxcmd{mq}{qrefresh}によって進行中のUIパッチをセー +修正は行える．単純に\hgxcmd{mq}{qrefresh}によって進行中のUIパッチをセー ブし，\hgxcmd{mq}{qpop}によってコアパッチへ遡る．コアのバグを修正した後 -に\hgxcmd{mq}{qrefresh}をコアパッチについて行ない，\hgxcmd{mq}{qpush}で +に\hgxcmd{mq}{qrefresh}をコアパッチについて行い，\hgxcmd{mq}{qpush}で UIパッチに戻って作業を続ける． %\section{More about patches} @@ -768,7 +768,7 @@ %pathnames usually have an extra component on the front that isn't %present in the actual path name. This is a holdover from the way that %people used to generate patches (people still do this, but it's -%somewhat rare with modern revision control tools). +%somewhat rare with modern revision control tools). パッチのファイルヘッダを見ると，パスネームの最初に追加の部分がついている のに気づくはずだ．これは実際のパスネームには存在しないもので，パッチを生 @@ -780,19 +780,20 @@ %unpack the tarball again (hence the need for the rename), and use the %\cmdopt{diff}{-r} and \cmdopt{diff}{-N} options to \command{diff} to %recursively generate a patch between the unmodified directory and the -%modified one. +%modified one. %The result would be that the name of the unmodified %directory would be at the front of the left-hand path in every file %header, and the name of the modified directory would be at the front %of the right-hand path. -アリスがtarボールを解凍し，ファイルを編集し，パッチを作りたいと思っている -とする．彼女はワーキングディレクトリをリネームしてtarボールをもう一度解凍 -し（このためにリネームが必要だった），\command{diff}に\cmdopt{diff}{-r}と -\cmdopt{diff}{-N}オプションをつけて，元のままのディレクトリと変更したディ -レクトリの間で再帰的にパッチを生成するだろう．生成されたパッチでは，全て -のファイルヘッダで元のままのディレクトリの名前が左側のパスの先頭に，変更 -されたディレクトリの名前が右側のパスの先頭に現れる． +アリスがtarアーカイブを展開し，ファイルを編集し，パッチを作りたいと思って +いるとする．彼女は差分を取るためにまず作業しているディレクトリをリネーム +し， tarアーカイブをもう一度展開する．そしてオリジナルのままのディレクト +リと，変更を行なったディレクトリの間で，そして\command{diff}に +\cmdopt{diff}{-r}と\cmdopt{diff}{-N}オプションを付けて，再帰的な差分を取 +り，パッチを生成するだろう．生成されたパッチファイルを見ると，各ファイル +のヘッダ部分で左辺値の先頭にオリジナルの方のディレクトリ名が現れ，右辺値 +の先頭に変更した方のディレクトリ名が現れているはずである． %Since someone receiving a patch from the Alices of the net would be %unlikely to have unmodified and modified directories with exactly the @@ -801,11 +802,11 @@ %strip when trying to apply a patch. This number is called the %\emph{strip count}. -ネット上のアリスたちからパッチを受け取った人は，変更なしのディレクトリと -変更されたディレクトリの両方をアリスと同じ名前で持っている可能性はまずな -い．\command{patch}コマンドには\cmdopt{patch}{-p}オプションがあり，パッ -チを適用する時にパスの要素を先頭からいくつ削るかを指定できる．この数は -\emph{ストリップカウント}と呼ばれる． +ネット上の多数のアリスたちからパッチを受け取った人は，変更なしのディレク +トリと変更されたディレクトリの両方をアリスと同じ名前で持っている可能性は +まずない．\command{patch}コマンドには\cmdopt{patch}{-p}オプションがあり， +パッチを適用する時にパスの要素を先頭からいくつ削るかを指定できる．この数 +は\emph{ストリップカウント}と呼ばれる． %An option of ``\texttt{-p1}'' means ``use a strip count of one''. If %\command{patch} sees a file name \filename{foo/bar/baz} in a file @@ -949,7 +950,7 @@ \item 実行ビットを考慮しないだけでなく，新しいファイルを読み取り可能属 性で作成し，実行可能属性は付けない． \item \command{patch}コマンドはファイルの削除を削除されるファイルと中身 - がからのファイルとの差分として扱う．従って，ファイルを削除するとい + が空のファイルとの差分として扱う．従って，ファイルを削除するとい うことは，パッチファイルの中ではファイルの中の全ての行を削除するこ とと等価である． \item \command{patch}コマンドはファイルの追加を空のファイルと追加される @@ -995,11 +996,11 @@ オフセットやfuzz factorの出たパッチをリフレッシュするのは多くの場合良い考 えである．パッチをリフレッシュすると，新しいコンテキスト情報が生成され， -パッチがクリーンに適用できるようになる．「常に」ではななく「多くの場合」 -と断ったのは，パッチをリフレッシュすることで，元のファイルの異なったリビ -ジョンでパッチが適用できなくなることがあるからだ．複数のバージョンのソー -スツリーの上で適用可能なパッチを管理しなければならないような場合などは， -パッチの結果を検証してあるのであればfuzzの出るパッチも許容され得る． +パッチがクリーンに適用できるようになる．「常に」ではなく「多くの場合」と +断ったのは，パッチをリフレッシュすることで，元のファイルの異なったリビジョ +ンでパッチが適用できなくなることがあるからだ．複数のバージョンのソースツ +リーの上で適用可能なパッチを管理しなければならないような場合などは，パッ +チの結果を検証してあるのであればfuzzの出るパッチも許容され得る． %\subsection{Handling rejection} \subsection{リジェクトの取り扱い} @@ -1439,7 +1440,7 @@ MQの\sdirname{.hg/patches}ディレクトリはMercurialリポジトリのワーキング ディレクトリの外にあるので，``下位の''Mercurialリポジトリはパッチの管理 -や，その損愛児対について何も知らない． +や，その存在自体について何も知らない． %This presents the interesting possibility of managing the contents of %the patch directory as a Mercurial repository in its own right. This @@ -1478,8 +1479,8 @@ %may not control. リポジトリ内でパッチを管理すると，複数の開発者が同じパッチシリーズの上で -衝突することなく作業できるようになる．これは彼らが下位のソースベースをコ -ントロールできるか否かに関わりがない． +コンフリクトすることなく作業できるようになる．これは彼らが下位のソースベー +スをコントロールできるか否かに関わりがない． %\subsection{MQ support for patch repositories} \subsection{MQによるパッチリポジトリサポート} @@ -1637,9 +1638,9 @@ %simple techniques to keep your work well organized. フリーソフトやオープンソースプロジェクトに提出するためのパッチシリーズに -対して作業しているときや，作業が終ったときに通常のチェンジセットとして取 -り込まれる予定のパッチシリーズに対してだ行しているときは，作業をうまく系 -統づけるための単純なテクニックがある． +対して作業しているときや，パッチとしての作業が終った際に通常のチェンジセッ +トとして取り込む予定のパッチシリーズに対して作業しているときは，作業をう +まく行なうためのシンプルなテクニックがある． %Give your patches descriptive names. A good name for a patch might be %\filename{rework-device-alloc.patch}, because it will immediately give diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/preface.tex --- a/ja/preface.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/preface.tex Sat Jul 11 19:25:35 2009 +0900 @@ -1,5 +1,5 @@ %\chapter*{Preface} -\chapter*{まえがき} +\chapter*{はじめに} \addcontentsline{toc}{chapter}{Preface} \label{chap:preface} @@ -7,8 +7,8 @@ %thus far grown due to people's willingness to strike out into %ill-charted territory. -分散リビジョンコントロールは比較的新しい領域であり，これまでの間違った領 -域から抜け出そうという人々の意志で急速に発展している． +分散リビジョンコントロールは比較的新しい領域であり，これまでの間違ったや +りかたから抜け出そうという人々の思いで急速に発展している． %I am writing a book about distributed revision control because I %believe that it is an important subject that deserves a field guide. @@ -16,15 +16,13 @@ %learn the terrain with, and yet it scales to the demands of real, %challenging environments where many other revision control tools fail. -筆者が分散リビジョンコントロールについての本を書いているのは，これがフィー -ルドガイドを必要とする重要な課題だと思ったからだ．Mercurialについて書こう -と選んだのは，これが全体を学ぶのが最も簡単なツールで，しかも他のリビジョ -ンコントロールツールが往々にして失敗している，実際の挑戦的な環境の求めに -合わせてスケールするツールだからだ． - +筆者が分散リビジョンコントロールの本を書いた理由は，これがフィールドガイ +ドを書くのに相応しい重要なテーマだと考えたからである．対象として +Mercurialを選んだ理由は，全体の学習が最も容易なツールであり，他のリビジョ +ンコントロールツールでは得がたいスケーラビリティを有しているからだ． %\section{This book is a work in progress} -\section{この本は執筆中である} +\section{この本は現在執筆中である} %I am releasing this book while I am still writing it, in the hope that %it will prove useful to others. I also hope that readers will @@ -67,11 +65,11 @@ %seconds, with any resulting timestamps correspondingly spread out, my %automated example scripts run many commands in one second. -このアプローチの小さな欠点は，例の中で見られる日付と時刻が人間がタイプし -ていれば有り得ないほど``集まって''しまっていることだ．人間であれば，1つの -コマンドを実行するのに数秒はかかり，タイムスタンプは広い範囲に拡がるはず -のところが，この本で例を作成するスクリプトでは，1秒に多くのコマンドを実行 -してしまう． +このアプローチの小さな欠点は，例の中に現れる日付と時刻が，人間のタイプで +は有り得ないほど``固まって''しまっていることだ．人間であれば，1つのコマン +ドを実行するのに数秒はかかり，タイムスタンプは広い範囲に拡がるはずのとこ +ろが，この本で例を作成するスクリプトでは，1秒の間に多くのコマンドを実行し +てしまう． %As an instance of this, several consecutive commits in an example can %show up as having occurred during the same second. You can see this @@ -110,7 +108,7 @@ この本の完全なソースは，\url{http://hg.serpentine.com/mercurial/book}に てMercurialリポジトリとして公開されている． -%%% Local Variables: +%%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" -%%% End: +%%% End: diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/srcinstall.tex --- a/ja/srcinstall.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/srcinstall.tex Sat Jul 11 19:25:35 2009 +0900 @@ -44,7 +44,7 @@ python setup.py install --force --home=\$HOME \end{codesample4} \end{enumerate} -インストールを行なうと，Mercurialはユーザホームディレクトリ内の +インストールを行うと，Mercurialはユーザホームディレクトリ内の \texttt{bin}サブディレクトリに収められる．このディレクトリがシェルのコマ ンドサーチパスにあるのを確認すること． @@ -87,10 +87,10 @@ もしMercurialをWindows上でソースからビルドしたいのであれば，Mercurial wiki \url{http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall} の -``hard way''の説明に従って行なう．この方法では多くの面倒な作業が待ち構え +``hard way''の説明に従って行う．この方法では多くの面倒な作業が待ち構え ていることを覚悟する必要がある． -%%% Local Variables: +%%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" -%%% End: +%%% End: diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/template.tex --- a/ja/template.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/template.tex Sat Jul 11 19:25:35 2009 +0900 @@ -102,8 +102,8 @@ このマニュアルで書いているように，これまでのところ，これらのコマンドだけ がスタイルとテンプレートをサポートしている．これらがカスタマイズ可能な出 力が必要な最も重要なコマンドであるため， Mercurialのユーザコミュニティか -ら他のコマンドにスタイルとテンプレートサポートを適用かのうにせよというプ -レッシャーはほとんどない． +ら他のコマンドにスタイルとテンプレートサポートを適用可能にせよというプレッ +シャーはほとんどない． %\section{The basics of templating} \section{テンプレートの基本} @@ -112,9 +112,9 @@ %text never changes, while other parts are \emph{expanded}, or replaced %with new text, when necessary. -最も単純なMercurialテンプレートはテキスト片である．テキストのある部分は不 -変で，他の部分は必要に応じて\emph{展開}されるたり新しいテキストに置換され -る． +最も単純なMercurialテンプレートはテキストの断片である．テキストの一部は必 +要に応じて\emph{展開}されたり新しいテキストに置換され，別の部分は不変で +ある． %Before we continue, let's look again at a simple example of %Mercurial's normal output. @@ -320,9 +320,9 @@ %common filter, \tplkwfilt{date}{isodate}, in action above, to make a %date readable. -テンプレート展開の結果のうち，いくつかはたやすく利用できるものではない． -Mercurialは展開されるキーワードを変更するための一連の\emph{filters}オプショ -ンを提供している．日時を可読にするためによく用いられる +テンプレート展開の結果には，そのままでは利用しづらいものもある． +Mercurialが提供する\emph{filters}オプションを用いて，展開されたキーワード +を読みやすく加工することができる．日時を可読にするためによく用いられる \tplkwfilt{date}{isodate}フィルタの動作例については既に見てきた． %Below is a list of the most commonly used filters that Mercurial @@ -543,9 +543,10 @@ %further 8~characters (at least on Unix-like systems, where a tab is %conventionally 8~characters wide). -望みの出力をえるために複数のフィルタを組み合わせるのはたやすい．以下の一 -連のフィルタは説明文を整理し，きれいに68桁に収まるように整形し，8文字の -インデントを行う．（UNIXシステムではタブは習慣的に8桁分の幅を持つ．） +複数のフィルタを組み合わせ，望みの出力を簡単に作ることができる．ここでは +例として，説明文を整理し，きれいに68桁に収まるように整形し，8文字のインデ +ントを行うフィルタチェーンを示す．（UNIXシステムの習慣では，タブ幅は8桁で +ある．） \interaction{template.simple.combine} diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/tour-basic.tex --- a/ja/tour-basic.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/tour-basic.tex Sat Jul 11 19:25:35 2009 +0900 @@ -762,9 +762,7 @@ \sfilename{.hgrc}というファイルを作成する． Mercurialはこのファイルから個 人設定を取得し，使用する．\sfilename{.hgrc}ファイルの最初の内容は以下のよ うな書式にする． -\begin{footnote} -Windowsでの適切なディレクトリを示すこと． -\end{footnote} +\footnote{Windowsでの適切なディレクトリを示すこと．} \begin{codesample2} # This is a Mercurial configuration file. [ui] diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/tour-merge.tex --- a/ja/tour-merge.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/tour-merge.tex Sat Jul 11 19:25:35 2009 +0900 @@ -84,9 +84,9 @@ %also known. The tip revision is thus a head, because the newest %revision in a repository doesn't have any children, but a repository %can contain more than one head. -headは子孫や子を持たない変更である．リポジトリの最新のリビジョンは子を持 -たないため，tipリビジョンはすなわちheadである．一方でリポジトリは複数の -headを持ち得る． +headは子やその子孫を持たない変更である．リポジトリの最新のリビジョンは子 +を持たないため，tipリビジョンはすなわちheadである．一方でリポジトリは複数 +のheadを持ち得る． \begin{figure}[ht] \centering @@ -157,8 +157,8 @@ %until we \hgcmd{commit} the results of the merge. %\interaction{tour.merge.commit} -マージを行うと，マージの結果を\hgcmd{commit}するまで，\hgcmd{parents}は2 -つのペアレントを表示する． +マージを行うと，マージの結果を\hgcmd{commit}するまで，\hgcmd{parents}は +親2つを表示する． \interaction{tour.merge.commit} %We now have a new tip revision; notice that it has \emph{both} of @@ -283,7 +283,7 @@ % most recent version from which the two versions we're trying to % merge are descended. \item 左にあるのはファイルの\emph{ベース}バージョンである．これはこれか - らマージしようとする2つのバージョンの親となる最も最近のバージョン + らマージしようとする2つのバージョンの親となる最も新しいバージョン である． %\item In the middle is ``our'' version of the file, with the contents @@ -436,7 +436,7 @@ %use from the command line, while others work ``behind the scenes,'' %for example adding capabilities to the server. -Mercurialはコアを小さく，扱いやすく保ったまま機能を拡張できる柔軟なエス九 +Mercurialはコアを小さく，扱いやすく保ったまま機能を拡張できる柔軟なエクス テンションメカニズムを提供している．コマンドラインから利用できる新しいコ マンドを追加するようなエクステンションもあれば，目に見えないところで例え ばサーバに機能を追加するようなものもある． diff -r 896ab6eaf1c6 -r 8a3041e6f3cb ja/undo.tex --- a/ja/undo.tex Fri Jul 10 02:32:17 2009 +0900 +++ b/ja/undo.tex Sat Jul 11 19:25:35 2009 +0900 @@ -76,8 +76,8 @@ \interaction{rollback.status} コミットは\filename{a}への変更を含んでいるが，\filename{b}への変更は含ん でいない．ここで私が同僚と共有しているリポジトリへチェンジセットのプッシュ -を行なったとしたら，彼らが変更をプルした時，\filename{a}の中の何かが彼ら -のリポジトリに含まれない\filename{b}への参照を行なう可能性は高い．そうなっ +を行ったとしたら，彼らが変更をプルした時，\filename{a}の中の何かが彼ら +のリポジトリに含まれない\filename{b}への参照を行う可能性は高い．そうなっ たら筆者は同僚の怒りを買うことになるだろう． %However, luck is with me---I've caught my error before I pushed the @@ -96,7 +96,7 @@ \hgcmd{rollback}コマンドを使用することでMercurialから最後の更新を取り除 くことができる． \interaction{rollback.rollback} -チェンジセットはりぽじとりの履歴にもはや存在せず，ワーキングディレクトリ +チェンジセットはリポジトリの履歴にもはや存在せず，ワーキングディレクトリ の\filename{a}は変更されたと認識される．コミットしてロールバックすると， ワーキングディレクトリは完全にコミット前の状態になり，チェンジセットは完 全に消去される．この状態で安全に\hgcmd{add} \filename{b}し，もう一度 @@ -128,10 +128,11 @@ %changes into the repository. ここであなたは誤ってローカルの0.9リポジトリに共有1.0リポジトリからプルし -たとする．最悪の場合，十分注意せず，これを共有の0.9リポジトリに書き戻して +たとする．最悪の場合，注意を怠って，これを共有の0.9リポジトリに書き戻して しまい，開発チーム全体を混乱させてしまうことが有り得る．（この場合どうす -ればいいのかについては後述する．）しかしMercurialはプル元のURLと疑いを持 -つに十分な巨大な変更を表示するため，即座に気づく可能性が高い． +ればいいのかについては後述する．）実際には，Mercurialはpull元のURLを表示 +するし，間違ったリポジトリからpullすれば大量のチェンジセットが表示される +ため，即座に何かがおかしいと気づくことだろう． %The \hgcmd{rollback} command will work nicely to expunge all of the %changesets that you just pulled. Mercurial groups all changes from @@ -207,7 +208,7 @@ ザクション一回分のみを記録している．ロールバック一回毎に一つ前のリビジョ ンに戻るわけではない． \interaction{rollback.twice} -リポジトリないで一度ロールバックしたら，別のコミットをするかプルをするま +リポジトリ内で一度ロールバックしたら，別のコミットをするかプルをするま でロールバックはできない． @@ -263,12 +264,11 @@ %\end{itemize} \hgcmd{revert}コマンドが扱えるケースについてまとめる．より詳しい説明は， -後の節で行なう． +後の節で行う． \begin{itemize} \item ファイルを変更した場合，\hgcmd{revert}はファイルを変更される前の状 態に戻す． - \item \hgcmd{add}を実行した場合，\hgcmd{revert}はaddを取り消すが，ファイ ル自体はそのまま手を触れずに残す． \item Mercurialを操作せずにファイルを消去していた場合，\hgcmd{revert}は @@ -343,7 +343,7 @@ %still removed! This is counter-intuitive (at least to me), but at %least it's easy to deal with. %So remember, to revert a \hgcmd{rename}, you must provide \emph{both} -%the source and destination names. +%the source and destination names. \hgcmd{rename}した後では，少し留意しておくべき点がある．リネーム後に \hgcmd{revert}した場合，ここで説明するように，リネームしたファイルの名前 @@ -364,7 +364,7 @@ %renamed-from file, don't forget to copy them over.) （一方，リネームした後にリネーム先のファイルを編集し，リネームの前後のファ -イル名を指定して取り消しを行ない，Mercurialがリネームの際に消去されたファ +イル名を指定して取り消しを行い，Mercurialがリネームの際に消去されたファ イルを修復すると，このファイルは編集前の状態になっている．リネーム後のファ イルへの変更がリネーム前のファイルに残るようにするには，コピーを作ってお く必要がある．） @@ -385,8 +385,8 @@ %automatically, and building blocks that let you reverse part of a %changeset by hand. -$a$をコミットした後で別の$b$をコミットし，ここで$a$は誤りであることに気づ -くいた場合を考える．Mercurialはチェンジセット全体とチェンジセットの一部分 +$a$をコミットした後で別の$b$をコミットし，ここで$a$は誤りであることに気が +ついた場合を考える．Mercurialはチェンジセット全体とチェンジセットの一部分 を手でバックアウトするように促す． %Before you read this section, here's something to keep in mind: the @@ -397,7 +397,7 @@ %section~\ref{sec:undo:aaaiiieee}. この節を読む前に，\hgcmd{backout}コマンドは履歴に\emph{追加}することで取 -り消し操作を行なうことを覚えておいて欲しい．変更や消去ではない．バグの修 +り消し操作を行うことを覚えておいて欲しい．変更や消去ではない．バグの修 正のために役立つツールだが，変更の取り消しのために用いると破滅的な結果を もたらす．後者の目的のためには\ref{sec:undo:aaaiiieee}を参照のこと． @@ -413,7 +413,7 @@ \hgcmd{backout}コマンドはチェンジセット全体の作用を打ち消す．Mercurialの 履歴は不変なので，このコマンドは取り消したいチェンジセットを取り除くもの では\emph{ない}．その代わり，取り除きたいチェンジセットの\emph{逆}の働き -の新たなチェンジセットをを生成する． +の新たなチェンジセットを生成する． %The operation of the \hgcmd{backout} command is a little intricate, so %let's illustrate it with some examples. First, we'll create a @@ -482,7 +482,7 @@ 最後のコミット以外の変更をバックアウトしたい時は， \hgcmd{backout}に\hgopt{backout}{--merge}オプションを付ける． \interaction{backout.non-tip.clone} -このオプションはどんなチェンジセットでも一回の動作で行なうことができ，手 +このオプションはどんなチェンジセットでも一回の動作で行うことができ，手 早く簡単である． \interaction{backout.non-tip.backout} @@ -505,11 +505,11 @@ %working directory, and commits the result of the merge. 図\ref{fig:undo:backout-non-tip}で示された履歴で，Mercurialは2つのコミッ -トを行なっている．（図中で箱で示された節点はMercurialが自動的にコミットし +トを行っている．（図中で箱で示された節点はMercurialが自動的にコミットし た変更である．）バックアウトプロセスの前にMercurialは，現在のワーキングディ レクトリの親が何であるかを記憶する．そしてターゲットのチェンジセットを取 り除き，これをチェンジセットとしてコミットする．最後にワーキングディレク -トリの前の親へマージを行ない，マージの結果をコミットする． +トリの前の親へマージを行い，マージの結果をコミットする． \begin{figure}[htb] \centering @@ -679,12 +679,12 @@ \begin{enumerate} \item ワーキングディレクトリがクリーンであることを確認する．i.e.\hgcmd{status} が空であることを確認する - \item 現在のワーキングディレクトリの親を記憶するこのチェンジセットを + \item 現在のワーキングディレクトリの親を記憶する．このチェンジセットを \texttt{orig}と呼ぶことにする． \item ワーキングディレクトリを，バックアウトしたチェンジセットの内容に - するために\hgcmd{update}と等価な動作を行なう．このチェンジセット + するために\hgcmd{update}と等価な動作を行う．このチェンジセット を\texttt{backout}と呼ぶ． - \item そのチェンジセットの親を見つけ出すこのチェンジセットを + \item そのチェンジセットの親を見つけ出す．このチェンジセットを \texttt{parent}と呼ぶことにする． \item \texttt{backout}チェンジセットが影響する各々のファイルに対して， \hgcmdargs{revert}{-r parent}と等価な操作を行い，チェンジセットが @@ -692,7 +692,7 @@ \item 新しいチェンジセットの結果をコミットする．このチェンジセットは \texttt{backout}を親に持つ． \item \hgopt{backout}{--merge}をコマンドラインから入力した場合， - \texttt{orig}とのマージを行ない，結果をコミットする． + \texttt{orig}とのマージを行い，結果をコミットする． \end{enumerate} %An alternative way to implement the \hgcmd{backout} command would be @@ -703,7 +703,7 @@ %well. \hgcmd{backout}コマンドを実装する別の方法として，\hgcmd{export}でバックア -ウトされるべきチェンジセットをdiffとして出力し， +ウトされるべきチェンジセットを差分として出力し， \command{patch}を\cmdopt{patch}{--reverse}オプション付きで呼び，ワーキン グディレクトリの操作を省略してリバースパッチする方法が考えられる． この方法はずっと単純だが，ほとんどうまく動かない． @@ -713,7 +713,7 @@ %good job when dealing with all the changes \emph{between} the change %you're backing out and the current tip. -\hgcmd{backout}がアップデート，コミット，マージ，コミットを行なう理由は， +\hgcmd{backout}がアップデート，コミット，マージ，コミットを行う理由は， バックアウトすべき変更と現在のチップの間で，マージ機構が最も良い結果を得 られるようにするためである． @@ -784,7 +784,7 @@ Mercurialは履歴を累積的なものとして扱う．全ての変更はそれに先立つ全ての変 更の上になりたっている．一般的に言って破壊的な変更を回避することはできな -い．たった一つの例外はコミットを行なった直後で，他のリポジトリにプッシュ +い．たった一つの例外はコミットを行った直後で，他のリポジトリにプッシュ もプルもされていない場合である．その場合，\ref{sec:undo:rollback}のセクショ ンで詳しく触れたように，安全に\hgcmd{rollback}を実行することができる． @@ -794,11 +794,10 @@ %still be present in the remote repository, so it will reappear in your %local repository the next time you pull. -間違った変更を他のリポジトリにプッシュした後でもローカ -ルコピーの変更を取り消すために依然として\hgcmd{rollback}を使うことが -\emph{できる}が，これは意図したような結果にはならない．変更は依然として -リモートのリポジトリにはそんざいしており，次にプルした時にはローカルリポ -ジトリにも現れる． +間違った変更を他のリポジトリにプッシュした後でもローカルコピーの変更を取 +り消すために依然として\hgcmd{rollback}を使うことが\emph{できる}が，これは +意図したような結果にはならない．変更は依然としてリモートのリポジトリには +存在しており，次にプルした時にはローカルリポジトリにも現れる． %If a situation like this arises, and you know which repositories your %bad change has propagated into, you can \emph{try} to get rid of the @@ -810,7 +809,7 @@ このような状況になった時，もしどのリポジトリにこの間違った変更が波及して いるのかが明らかであれば，それらのリポジトリの一つ一つから，変更を取り除 くことを試みることができる．これはもちろん満足のいく解決法ではない．もし -一つでも消去を忘れれば，変更は野放しになっており，さらに拡がり得る． +一つでも消去を忘れれば，変更は野放しになっており，さらに広がりうる． %If you've committed one or more changes \emph{after} the change that %you'd like to see disappear, your options are further reduced. @@ -841,7 +840,7 @@ ローカルリポジトリにいくつかの変更をコミットし，それらが別の所にプッシュ またはプルされていて，必ずしも大災害とは言えない．あなたはいくつかのクラ -スの間違った変更から自分自身でみを守ることができる．これはあなたのチーム +スの間違った変更から自分自身で身を守ることができる．これはあなたのチーム が中央のリポジトリから変更をプルしている場合は特に簡単である． %By configuring some hooks on that repository to validate incoming @@ -854,10 +853,9 @@ 中央リポジトリの上で，変更到着にフックを設定する（\ref{chap:hook}を参照） ことで，ある種の誤ったチェンジセットが中央リポジトリにコミットされるのを -自動的に防ぐことができる． -そのような設定を行うことで，ある種の誤ったチェンジセットはセントラルリポ -ジトリに波及することができず，死滅していく傾向がある．さらに良いこととし -ては，これは明示的に介入せずに発生させることができることがある． +自動的に防ぐことができる．そのような設定を行うことで，ある種の誤ったチェ +ンジセットは中央リポジトリに波及することができず，死滅していく傾向があ +る．好都合なことに，死滅は陽に介入する必要なく起きる。 %For instance, an incoming change hook that verifies that a changeset %will actually compile can prevent people from inadvertantly ``breaking @@ -919,7 +917,7 @@ 以下はこのコマンドをどのように適用できるのか理解を助けるシナリオである． \begin{itemize} \item バグが起きていなかった最も新しいバージョンを覚えているが，どのバー - ジョンでバグが混入したか分からない．ここでバイナリテストを行ない， + ジョンでバグが混入したか分からない．ここでバイナリテストを行い， バグの存在を調べる． \item バグを大急ぎで修正し，あなたのチームのバグデータベースをクローズ する．バグデータベースはどこでバグが修正されたかのチェンジセット @@ -939,15 +937,15 @@ %that you can't find from a simple text search of the files in the %tree) for which you can write a binary test. -この例から，\hgcmd{bisect}コマンドはバグのありかを探すのに役立つのではな -いことが分かるだろう．このコマンドはバイナリテストを行ない得るリポジトリ -で起きた（単純にツリーをテキストサーチしたのでは発見できない）変化全てを -知るのに使うことができる． +この例から，\hgcmd{bisect}コマンドは単にバグの所在を探すのに役立つだけで +はなく、バイナリテストを用意できるのであれば、リポジトリで起きたあらゆる +変化（単にツリーをテキストサーチしたのでは発見できない変化）を知るのに使 +えることがわかる。 %We'll introduce a little bit of terminology here, just to make it %clear which parts of the search process are your responsibility, and %which are Mercurial's. A \emph{test} is something that \emph{you} run -%when \hgcmd{bisect} chooses a changeset.A \emph{probe} is what +%when \hgcmd{bisect} chooses a changeset. A \emph{probe} is what %\hgcmd{bisect} runs to tell whether a revision is good. Finally, %we'll use the word ``bisect'', as both a noun and a verb, to stand in %for the phrase ``search using the \hgcmd{bisect} command''. @@ -968,13 +966,13 @@ %and limited your search to those, you'd still be looking at over 40 %hours to find the changeset that introduced your bug. -サーチプロセスを自動化するたんん淳和方法は，全てのチェンジセットをprobe -することである．しかしこれは殆んどスケールしない．一つのチェンジセットの -チェックに10分かかり，リポジトリにチェンジセットが10000あったとしたら，虱 -潰しのアプローチはバグを発生させたチェンジセットの特定に平均で35日かかる． -バグが最後の500チェンジセットで発生したことが分かっていて，サーチをそれら -のチェンジセットに限定したとしても，バグを引き起こしたチェンジセットの特 -定に40時間以上かかる． +サーチプロセスを自動化する単純な方法は，全てのチェンジセットをprobeするこ +とである．しかしこれは殆んどスケールしない．一つのチェンジセットのチェッ +クに10分かかり，リポジトリにチェンジセットが10000あったとしたら，虱潰しの +アプローチはバグを発生させたチェンジセットの特定に平均で35日かかる．バグ +が最後の500チェンジセットで発生したことが分かっていて，サーチをそれらのチェ +ンジセットに限定したとしても，バグを引き起こしたチェンジセットの特定に40 +時間以上かかる． %What the \hgcmd{bisect} command does is use its knowledge of the %``shape'' of your project's revision history to perform a search in @@ -989,9 +987,9 @@ \hgcmd{bisect}はあなたのプロジェクトのリビジョン履歴の``シェイプ''の知識 を，サーチすべきチェンジセット数の\emph{対数}に比例した時間でサーチするた -めに使う．（二分検索を行なう．）このアプローチによって10000チェンジセット +めに使う．（二分探索を行う．）このアプローチによって10000チェンジセット のサーチは，各々のサーチが10分かかったとしても，テスト数は14で3時間以下で -終了する．最後の100のチェンジセットに限って行なったとすると，およそ7回の +終了する．最後の100のチェンジセットに限って行ったとすると，およそ7回の テストで1時間程度で終了する． %The \hgcmd{bisect} command is aware of the ``branchy'' nature of a @@ -1181,7 +1179,7 @@ 40個のチェンジセットがあるにもかかわらず，\hgcmd{bisect}コマンドはバグを もたらしたチェンジセットを5回のテストで発見することができた． \hgcmd{bisect}のテスト回数は探索すべきチェンジセット数が増えるに従って， -対数敵に増えるが，虱潰し探索に対する優位性は，チェンジセットが増加するに +対数的に増えるが，虱潰し探索に対する優位性は，チェンジセットが増加するに 従って増加する． @@ -1208,7 +1206,7 @@ \section{効率的なバグの発見法} %\subsection{Give consistent input} -\subsection{一貫した入力を行う} +\subsection{正しい入力を行う} %The \hgcmd{bisect} command requires that you correctly report the %result of every test you perform. If you tell it that a test failed @@ -1219,10 +1217,10 @@ %the wrong changeset as the source of the bug. \hgcmd{bisect}コマンドは各テストで正しく結果を入力することが必要である． -もしテストに成功したのに失敗と入力するば，不定な状態を検知するかもしれな -い．入力の中で不定を特定できれば，コマンドは特定のチェンジセットがgoodか -つbadであると表示する．しかし完璧にこれを行うことは不可能で，間違ったチェ -ンジセットをバグの原因だと報告する可能性が高い． +もしテストに成功したのに失敗と入力すれば，矛盾が生じうる．入力の中に矛盾 +があることが分かれば，コマンドは特定のチェンジセットをgoodかつbadと表示す +る．しかし矛盾を完璧に見つけ出すことは困難で，誤ったチェンジセットをバグ +の起源と報告する可能性が高い． %\subsection{Automate as much as possible} \subsection{できる限り自動化する} @@ -1350,10 +1348,9 @@ %hence untestable state at that revision, perhaps because someone %checked in a change that prevented the project from building. -\hgcmdargs{bisect}{--skip}の使用が有用なもう一つ別の状況は，誰かがビルド -できなくなるような変更をチェックインしたために，試そうとしているリビジョ -ンがビルドできず，そのリビジョンをテストできないような場合である． - +\hgcmdargs{bisect}{--skip}が有効な別の例として，ビルド不能になる変更が +チェックインされたリビジョンがあり，これを飛ばさなければテストができない +ような状況がある． %\subsection{Bracket your search lazily} \subsection{探索を怠惰にブラケットする}