# HG changeset patch # User Yoshiki Yazawa # Date 1242118151 -32400 # Node ID 93d19b27859c55f5bab59f84d9ba8b9b95ed4634 # Parent 2a93b1d35990faf4586fbe33f2eb4f59b9531ad4 started concepts.tex diff -r 2a93b1d35990 -r 93d19b27859c ja/concepts.tex --- a/ja/concepts.tex Sun May 03 17:10:09 2009 +0900 +++ b/ja/concepts.tex Tue May 12 17:49:11 2009 +0900 @@ -1,232 +1,364 @@ -\chapter{Behind the scenes} +%\chapter{Behind the scenes} +\chapter{舞台裏} \label{chap:concepts} -Unlike many revision control systems, the concepts upon which -Mercurial is built are simple enough that it's easy to understand how -the software really works. Knowing this certainly isn't necessary, -but I find it useful to have a ``mental model'' of what's going on. +%Unlike many revision control systems, the concepts upon which +%Mercurial is built are simple enough that it's easy to understand how +%the software really works. Knowing this certainly isn't necessary, +%but I find it useful to have a ``mental model'' of what's going on. + +多くのリビジョンコントロールシステムと違って， Mercurialの動作の基本となっ +ているコンセプトを理解することは容易い． +これを理解することは必ずしも必要ではないが，筆者は，何が起きているのかに +ついてモデルを意識していることは有用であると考えている． + +%This understanding gives me confidence that Mercurial has been +%carefully designed to be both \emph{safe} and \emph{efficient}. And +%just as importantly, if it's easy for me to retain a good idea of what +%the software is doing when I perform a revision control task, I'm less +%likely to be surprised by its behaviour. -This understanding gives me confidence that Mercurial has been -carefully designed to be both \emph{safe} and \emph{efficient}. And -just as importantly, if it's easy for me to retain a good idea of what -the software is doing when I perform a revision control task, I'm less -likely to be surprised by its behaviour. +このことを理解した後で，筆者はMercurialが\emph{安全}と\emph{効率}を実現す +るように注意深く設計されていると確信するに至った． +また，重要な点として，リビジョンコントロールの操作を行う際にソフトウェア +が何をするのかを記憶に留めておくことによって，不意の挙動で驚くことが少な +くなった． -In this chapter, we'll initially cover the core concepts behind -Mercurial's design, then continue to discuss some of the interesting -details of its implementation. +%In this chapter, we'll initially cover the core concepts behind +%Mercurial's design, then continue to discuss some of the interesting +%details of its implementation. -\section{Mercurial's historical record} +この章ではまずMercurialの設計のコアコンセプトをカバーする．そして実装上の +いくつかの興味深い点の詳細について議論する． + +%\section{Mercurial's historical record} +\section{Mercurialの履歴記録} -\subsection{Tracking the history of a single file} +%\subsection{Tracking the history of a single file} +\subsection{ファイル履歴の追跡} + +%When Mercurial tracks modifications to a file, it stores the history +%of that file in a metadata object called a \emph{filelog}. Each entry +%in the filelog contains enough information to reconstruct one revision +%of the file that is being tracked. Filelogs are stored as files in +%the \sdirname{.hg/store/data} directory. A filelog contains two kinds +%of information: revision data, and an index to help Mercurial to find +%a revision efficiently. -When Mercurial tracks modifications to a file, it stores the history -of that file in a metadata object called a \emph{filelog}. Each entry -in the filelog contains enough information to reconstruct one revision -of the file that is being tracked. Filelogs are stored as files in -the \sdirname{.hg/store/data} directory. A filelog contains two kinds -of information: revision data, and an index to help Mercurial to find -a revision efficiently. +Mercurialはファイルへの変更を追跡する時，ファイルの履歴を\emph{filelog}と +呼ばれるメタデータオブジェクトに格納する．ファイルログ内の各々のエントリ +は，追跡対象のファイルのリビジョンを再建するのに十分な情報を持つ．ファイ +ルログは\sdirname{.hg/store/data}ディレクトリにファイルとして保存される． +ファイルログはリビジョンデータとMercurialがリビジョンを効率的に見つけられ +るようにするためのインデックスの2種類の情報を持つ． -A file that is large, or has a lot of history, has its filelog stored -in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}'' -suffix) files. For small files without much history, the revision -data and index are combined in a single ``\texttt{.i}'' file. The -correspondence between a file in the working directory and the filelog -that tracks its history in the repository is illustrated in -figure~\ref{fig:concepts:filelog}. +%A file that is large, or has a lot of history, has its filelog stored +%in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}'' +%suffix) files. For small files without much history, the revision +%data and index are combined in a single ``\texttt{.i}'' file. The +%correspondence between a file in the working directory and the filelog +%that tracks its history in the repository is illustrated in +%figure~\ref{fig:concepts:filelog}. + +サイズの大きなファイルや，膨大な履歴を持つファイルは，データが +(``\texttt{.d}'' suffix) およびインデックス (``\texttt{.i}'' suffix)のファ +イルに分割されたfilelogを持つ．サイズが小さく，履歴の大きくないファイルは +リビジョンデータとインデックスが1つの``\texttt{.i}''ファイルに結合されて +いる．ワーキングディレクトリ内のファイルとリポジトリ内の履歴を追跡する +filelogとの対応を図~\ref{fig:concepts:filelog}に示す． \begin{figure}[ht] \centering % \grafix{filelog} \includegraphics{filelog} - \caption{Relationships between files in working directory and - filelogs in repository} +% \caption{Relationships between files in working directory and +% filelogs in repository} + \caption{ワーキングディレクトリ内のファイルとリポジトリのファイルログ + の関係} \label{fig:concepts:filelog} \end{figure} -\subsection{Managing tracked files} +%\subsection{Managing tracked files} +\subsection{追跡されているファイルの管理} + +%Mercurial uses a structure called a \emph{manifest} to collect +%together information about the files that it tracks. Each entry in +%the manifest contains information about the files present in a single +%changeset. An entry records which files are present in the changeset, +%the revision of each file, and a few other pieces of file metadata. -Mercurial uses a structure called a \emph{manifest} to collect -together information about the files that it tracks. Each entry in -the manifest contains information about the files present in a single -changeset. An entry records which files are present in the changeset, -the revision of each file, and a few other pieces of file metadata. +Mercurialは\emph{マニフェスト}と呼ばれる構造を用いて，追跡すべきファイル +の情報を集めている．マニフェスト内の各々のエントリは，単一のチェンジセッ +ト内に存在するファイルの情報を持っている．エントリはどのファイルがチェン +ジセットに存在しているか，それらのリビジョンが何であるのかという情報と， +いくつかの他のファイルメタデータを記録している． + +%\subsection{Recording changeset information} +\subsection{チェンジセット情報の記録} -\subsection{Recording changeset information} +%The \emph{changelog} contains information about each changeset. Each +%revision records who committed a change, the changeset comment, other +%pieces of changeset-related information, and the revision of the +%manifest to use. -The \emph{changelog} contains information about each changeset. Each -revision records who committed a change, the changeset comment, other -pieces of changeset-related information, and the revision of the -manifest to use. +\emph{changelog}は各々のチェンジセットの情報を持つ．各々のリビジョン記録 +は，誰が変更をコミットしたのか，チェンジセットのコメント，変更に関連した +他の情報，使用されるマニフェストのリビジョンを持つ． -\subsection{Relationships between revisions} +%\subsection{Relationships between revisions} +\subsection{リビジョン間の関係} + +%Within a changelog, a manifest, or a filelog, each revision stores a +%pointer to its immediate parent (or to its two parents, if it's a +%merge revision). As I mentioned above, there are also relationships +%between revisions \emph{across} these structures, and they are +%hierarchical in nature. -Within a changelog, a manifest, or a filelog, each revision stores a -pointer to its immediate parent (or to its two parents, if it's a -merge revision). As I mentioned above, there are also relationships -between revisions \emph{across} these structures, and they are -hierarchical in nature. +チェンジログ，マニフェスト，ファイルログ内で，各々のリビジョンは直接の親 +（あるいはマージの場合はその両親）へのポインタを持つ． +すでに述べたように，この構造に現れるリビジョンの間には関係があり，本質 +的に階層的である． -For every changeset in a repository, there is exactly one revision -stored in the changelog. Each revision of the changelog contains a -pointer to a single revision of the manifest. A revision of the -manifest stores a pointer to a single revision of each filelog tracked -when that changeset was created. These relationships are illustrated -in figure~\ref{fig:concepts:metadata}. +%For every changeset in a repository, there is exactly one revision +%stored in the changelog. Each revision of the changelog contains a +%pointer to a single revision of the manifest. A revision of the +%manifest stores a pointer to a single revision of each filelog tracked +%when that changeset was created. These relationships are illustrated +%in figure~\ref{fig:concepts:metadata}. + +リポジトリにあるすべてのチェンジセットは，チェンジログ内で正確に1つのリビ +ジョンを持つ．チェンジログの各々のリビジョンは，マニフェストの単一のバー +ジョンへのポインタを持つ．マニフェストの各々のリビジョンは，チェンジセッ +トが生成された時のファイルログの各々の単一リビジョンへのポインタを持つ． +この関係を図~\ref{fig:concepts:metadata}に示す． \begin{figure}[ht] \centering \includegraphics{metadata} - \caption{Metadata relationships} +% \caption{Metadata relationships} + \caption{メタデータの関係} \label{fig:concepts:metadata} \end{figure} -As the illustration shows, there is \emph{not} a ``one to one'' -relationship between revisions in the changelog, manifest, or filelog. -If the manifest hasn't changed between two changesets, the changelog -entries for those changesets will point to the same revision of the -manifest. If a file that Mercurial tracks hasn't changed between two -changesets, the entry for that file in the two revisions of the -manifest will point to the same revision of its filelog. +%As the illustration shows, there is \emph{not} a ``one to one'' +%relationship between revisions in the changelog, manifest, or filelog. +%If the manifest hasn't changed between two changesets, the changelog +%entries for those changesets will point to the same revision of the +%manifest. If a file that Mercurial tracks hasn't changed between two +%changesets, the entry for that file in the two revisions of the +%manifest will point to the same revision of its filelog. -\section{Safe, efficient storage} +イラストで示されているように，リビジョンとチェンジログ，マニフェストまた +はファイルログの間には1対１の関係はない．マニフェストが2つのチェンジセッ +トの間で変化しなかった場合は，チェンジログ内でこれらのチェンジセットを表 +すエントリは同じバージョンのマニフェストを示す．Mercurialが追跡するファイ +ルが，2つのチェンジセット間で変化しなかった場合は， 2つのマニフェストのリ +ビジョンで，そのファイルを示すエントリはファイルログの同じリビジョンを示 +す． -The underpinnings of changelogs, manifests, and filelogs are provided -by a single structure called the \emph{revlog}. +%\section{Safe, efficient storage} +\section{安全かつ効率的なストレージ} + +%The underpinnings of changelogs, manifests, and filelogs are provided +%by a single structure called the \emph{revlog}. -\subsection{Efficient storage} +チェンジログ，マニフェスト，ファイルログの土台に使われているは共通の +\emph{revlog}という構造体である． + +%\subsection{Efficient storage} +\subsection{効率的なストレージ} -The revlog provides efficient storage of revisions using a -\emph{delta} mechanism. Instead of storing a complete copy of a file -for each revision, it stores the changes needed to transform an older -revision into the new revision. For many kinds of file data, these -deltas are typically a fraction of a percent of the size of a full -copy of a file. +%The revlog provides efficient storage of revisions using a +%\emph{delta} mechanism. Instead of storing a complete copy of a file +%for each revision, it stores the changes needed to transform an older +%revision into the new revision. For many kinds of file data, these +%deltas are typically a fraction of a percent of the size of a full +%copy of a file. + +revlogは\emph{delta}機構を使ってリビジョンの効率的な記憶を提供する．ファ +イルの各々のバージョンの完全なコピーを保存するのではなく，古いリビジョン +を新しいバージョンへ変換するのに必要な変更を保存する．多くのファイルデー +タに対して， deltaは典型的にはファイルのフルコピーの1パーセント未満でああ +る． -Some obsolete revision control systems can only work with deltas of -text files. They must either store binary files as complete snapshots -or encoded into a text representation, both of which are wasteful -approaches. Mercurial can efficiently handle deltas of files with -arbitrary binary contents; it doesn't need to treat text as special. +%Some obsolete revision control systems can only work with deltas of +%text files. They must either store binary files as complete snapshots +%or encoded into a text representation, both of which are wasteful +%approaches. Mercurial can efficiently handle deltas of files with +%arbitrary binary contents; it doesn't need to treat text as special. -\subsection{Safe operation} +古いリビジョンコントロールシステムのいくつかはテキストファイルのdeltaに対 +してしか機能しない．それらのシステムではバイナリファイルは完全なスナップ +ショットか，テキスト表現にエンコードされた形式である必要がある．これらは +共に無駄の多いアプローチである． Mercurialは任意のバイナリファイルについ +て，deltaを効率的に扱うことができ，テキストを特別扱いする必要がない． + +%\subsection{Safe operation} +\subsection{安全な動作} \label{sec:concepts:txn} -Mercurial only ever \emph{appends} data to the end of a revlog file. -It never modifies a section of a file after it has written it. This -is both more robust and efficient than schemes that need to modify or -rewrite data. +%Mercurial only ever \emph{appends} data to the end of a revlog file. +%It never modifies a section of a file after it has written it. This +%is both more robust and efficient than schemes that need to modify or +%rewrite data. + +Mercurialはrevlogファイルの末尾にデータの\emph{追加}のみを行う．一度書き +込まれた部分は後になって変更されることはない．これはデータの変更や再書き +込みを行う方法よりも頑強かつ効率的である． -In addition, Mercurial treats every write as part of a -\emph{transaction} that can span a number of files. A transaction is -\emph{atomic}: either the entire transaction succeeds and its effects -are all visible to readers in one go, or the whole thing is undone. -This guarantee of atomicity means that if you're running two copies of -Mercurial, where one is reading data and one is writing it, the reader -will never see a partially written result that might confuse it. +%In addition, Mercurial treats every write as part of a +%\emph{transaction} that can span a number of files. A transaction is +%\emph{atomic}: either the entire transaction succeeds and its effects +%are all visible to readers in one go, or the whole thing is undone. +%This guarantee of atomicity means that if you're running two copies of +%Mercurial, where one is reading data and one is writing it, the reader +%will never see a partially written result that might confuse it. + +加えて，Mercurialはあらゆる書き込みを複数のファイルへの\emph{トランザクショ +ン}の一部と見なす．トランザクション全体が成功し，読み出し側に一度に結果が +見える場合も，そうでない場合もトランザクションは\emph{アトミック}である． +このアトミック性の保証は， 2つのMercurialを，片方はデータの読み出し，もう +一方は書き込みで実行している場合，読み出し側には混乱の原因となる部分的な +書き込み結果は見えないことを意味する． -The fact that Mercurial only appends to files makes it easier to -provide this transactional guarantee. The easier it is to do stuff -like this, the more confident you should be that it's done correctly. +%The fact that Mercurial only appends to files makes it easier to +%provide this transactional guarantee. The easier it is to do stuff +%like this, the more confident you should be that it's done correctly. -\subsection{Fast retrieval} +Mercurialはファイルに追記のみをすることで，トランザクションの保証を容易に +している．物事を単純化することによって，処理の正しさを確実にするようにし +ている． + +%\subsection{Fast retrieval} +\subsection{高速な取得} -Mercurial cleverly avoids a pitfall common to all earlier -revision control systems: the problem of \emph{inefficient retrieval}. -Most revision control systems store the contents of a revision as an -incremental series of modifications against a ``snapshot''. To -reconstruct a specific revision, you must first read the snapshot, and -then every one of the revisions between the snapshot and your target -revision. The more history that a file accumulates, the more -revisions you must read, hence the longer it takes to reconstruct a -particular revision. +%Mercurial cleverly avoids a pitfall common to all earlier +%revision control systems: the problem of \emph{inefficient retrieval}. +%Most revision control systems store the contents of a revision as an +%incremental series of modifications against a ``snapshot''. To +%reconstruct a specific revision, you must first read the snapshot, and +%then every one of the revisions between the snapshot and your target +%revision. The more history that a file accumulates, the more +%revisions you must read, hence the longer it takes to reconstruct a +%particular revision. + +Mercurialはこれまでのリビジョンコントロールシステムに共通した落とし穴を +賢明に避けている．問題だったのは\emph{非効率的な取得}であった． +大抵のリビジョンコントロールシステムはリビジョンの内容をスナップショット +への一連の変更の増分として保存している．特定のリビジョンを再現するために +はまずスナップショットを読み込み，しかる後に目的のリビジョンを読む必要が +あった．ファイルへの履歴が増えれば増えるほど読み込まなければならないリビ +ジョンが多くなり，特定のリビジョンを再現するのに時間がかかるようになる． \begin{figure}[ht] \centering \includegraphics{snapshot} - \caption{Snapshot of a revlog, with incremental deltas} +% \caption{Snapshot of a revlog, with incremental deltas} + \caption{差分を用いたrevlogのスナップショット} \label{fig:concepts:snapshot} \end{figure} -The innovation that Mercurial applies to this problem is simple but -effective. Once the cumulative amount of delta information stored -since the last snapshot exceeds a fixed threshold, it stores a new -snapshot (compressed, of course), instead of another delta. This -makes it possible to reconstruct \emph{any} revision of a file -quickly. This approach works so well that it has since been copied by -several other revision control systems. +%The innovation that Mercurial applies to this problem is simple but +%effective. Once the cumulative amount of delta information stored +%since the last snapshot exceeds a fixed threshold, it stores a new +%snapshot (compressed, of course), instead of another delta. This +%makes it possible to reconstruct \emph{any} revision of a file +%quickly. This approach works so well that it has since been copied by +%several other revision control systems. -Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry -in a revlog's index file, Mercurial stores the range of entries from -the data file that it must read to reconstruct a particular revision. +Mercurialではこの問題を単純だが効果的な方法で解決している．前回にスナップ +ショットを作成した時点からの累積的な増分が一定の閾値を越えると，新たな増 +分ではなく，新たなスナップショットが保存される（このスナップショットは勿 +論圧縮されている）．これによって\emph{いかなる}リビジョンも迅速に再現され +る．このアプローチは以後他のリビジョンコントロールシステムにコピーされる +ほどうまく機能している． -\subsubsection{Aside: the influence of video compression} +%Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry +%in a revlog's index file, Mercurial stores the range of entries from +%the data file that it must read to reconstruct a particular revision. -If you're familiar with video compression or have ever watched a TV -feed through a digital cable or satellite service, you may know that -most video compression schemes store each frame of video as a delta -against its predecessor frame. In addition, these schemes use -``lossy'' compression techniques to increase the compression ratio, so -visual errors accumulate over the course of a number of inter-frame -deltas. +図~\ref{fig:concepts:snapshot}に概念を示す．Mercurialはrevlogのインデック +スファイルのエントリに特定のリビジョンを再現するのに必要なデータファイル +内のある範囲のエントリを保存する． + + + + + + + + -Because it's possible for a video stream to ``drop out'' occasionally -due to signal glitches, and to limit the accumulation of artefacts -introduced by the lossy compression process, video encoders -periodically insert a complete frame (called a ``key frame'') into the -video stream; the next delta is generated against that frame. This -means that if the video signal gets interrupted, it will resume once -the next key frame is received. Also, the accumulation of encoding -errors restarts anew with each key frame. + + +%\subsubsection{Aside: the influence of video compression} +\subsubsection{その他: ビデオ圧縮の影響} -\subsection{Identification and strong integrity} - -Along with delta or snapshot information, a revlog entry contains a -cryptographic hash of the data that it represents. This makes it -difficult to forge the contents of a revision, and easy to detect -accidental corruption. +%If you're familiar with video compression or have ever watched a TV +%feed through a digital cable or satellite service, you may know that +%most video compression schemes store each frame of video as a delta +%against its predecessor frame. In addition, these schemes use +%``lossy'' compression techniques to increase the compression ratio, so +%visual errors accumulate over the course of a number of inter-frame +%deltas. -Hashes provide more than a mere check against corruption; they are -used as the identifiers for revisions. The changeset identification -hashes that you see as an end user are from revisions of the -changelog. Although filelogs and the manifest also use hashes, -Mercurial only uses these behind the scenes. +%Because it's possible for a video stream to ``drop out'' occasionally +%due to signal glitches, and to limit the accumulation of artefacts +%introduced by the lossy compression process, video encoders +%periodically insert a complete frame (called a ``key frame'') into the +%video stream; the next delta is generated against that frame. This +%means that if the video signal gets interrupted, it will resume once +%the next key frame is received. Also, the accumulation of encoding +%errors restarts anew with each key frame. + +%\subsection{Identification and strong integrity} +\subsection{識別と強い一貫性} -Mercurial verifies that hashes are correct when it retrieves file -revisions and when it pulls changes from another repository. If it -encounters an integrity problem, it will complain and stop whatever -it's doing. +%Along with delta or snapshot information, a revlog entry contains a +%cryptographic hash of the data that it represents. This makes it +%difficult to forge the contents of a revision, and easy to detect +%accidental corruption. -In addition to the effect it has on retrieval efficiency, Mercurial's -use of periodic snapshots makes it more robust against partial data -corruption. If a revlog becomes partly corrupted due to a hardware -error or system bug, it's often possible to reconstruct some or most -revisions from the uncorrupted sections of the revlog, both before and -after the corrupted section. This would not be possible with a -delta-only storage model. +%Hashes provide more than a mere check against corruption; they are +%used as the identifiers for revisions. The changeset identification +%hashes that you see as an end user are from revisions of the +%changelog. Although filelogs and the manifest also use hashes, +%Mercurial only uses these behind the scenes. + +%Mercurial verifies that hashes are correct when it retrieves file +%revisions and when it pulls changes from another repository. If it +%encounters an integrity problem, it will complain and stop whatever +%it's doing. -\section{Revision history, branching, - and merging} +%In addition to the effect it has on retrieval efficiency, Mercurial's +%use of periodic snapshots makes it more robust against partial data +%corruption. If a revlog becomes partly corrupted due to a hardware +%error or system bug, it's often possible to reconstruct some or most +%revisions from the uncorrupted sections of the revlog, both before and +%after the corrupted section. This would not be possible with a +%delta-only storage model. -Every entry in a Mercurial revlog knows the identity of its immediate -ancestor revision, usually referred to as its \emph{parent}. In fact, -a revision contains room for not one parent, but two. Mercurial uses -a special hash, called the ``null ID'', to represent the idea ``there -is no parent here''. This hash is simply a string of zeroes. +%\section{Revision history, branching, and merging} +\section{リビジョン履歴，ブランチ，マージ} -In figure~\ref{fig:concepts:revlog}, you can see an example of the -conceptual structure of a revlog. Filelogs, manifests, and changelogs -all have this same structure; they differ only in the kind of data -stored in each delta or snapshot. +%Every entry in a Mercurial revlog knows the identity of its immediate +%ancestor revision, usually referred to as its \emph{parent}. In fact, +%a revision contains room for not one parent, but two. Mercurial uses +%a special hash, called the ``null ID'', to represent the idea ``there +%is no parent here''. This hash is simply a string of zeroes. -The first revision in a revlog (at the bottom of the image) has the -null ID in both of its parent slots. For a ``normal'' revision, its -first parent slot contains the ID of its parent revision, and its -second contains the null ID, indicating that the revision has only one -real parent. Any two revisions that have the same parent ID are -branches. A revision that represents a merge between branches has two -normal revision IDs in its parent slots. +%In figure~\ref{fig:concepts:revlog}, you can see an example of the +%conceptual structure of a revlog. Filelogs, manifests, and changelogs +%all have this same structure; they differ only in the kind of data +%stored in each delta or snapshot. + +%The first revision in a revlog (at the bottom of the image) has the +%null ID in both of its parent slots. For a ``normal'' revision, its +%first parent slot contains the ID of its parent revision, and its +%second contains the null ID, indicating that the revision has only one +%real parent. Any two revisions that have the same parent ID are +%branches. A revision that represents a merge between branches has two +%normal revision IDs in its parent slots. \begin{figure}[ht] \centering @@ -235,137 +367,146 @@ \label{fig:concepts:revlog} \end{figure} -\section{The working directory} +%\section{The working directory} +\section{ワーキングディレクトリ} -In the working directory, Mercurial stores a snapshot of the files -from the repository as of a particular changeset. +%In the working directory, Mercurial stores a snapshot of the files +%from the repository as of a particular changeset. -The working directory ``knows'' which changeset it contains. When you -update the working directory to contain a particular changeset, -Mercurial looks up the appropriate revision of the manifest to find -out which files it was tracking at the time that changeset was -committed, and which revision of each file was then current. It then -recreates a copy of each of those files, with the same contents it had -when the changeset was committed. +%The working directory ``knows'' which changeset it contains. When you +%update the working directory to contain a particular changeset, +%Mercurial looks up the appropriate revision of the manifest to find +%out which files it was tracking at the time that changeset was +%committed, and which revision of each file was then current. It then +%recreates a copy of each of those files, with the same contents it had +%when the changeset was committed. -The \emph{dirstate} contains Mercurial's knowledge of the working -directory. This details which changeset the working directory is -updated to, and all of the files that Mercurial is tracking in the -working directory. +%The \emph{dirstate} contains Mercurial's knowledge of the working +%directory. This details which changeset the working directory is +%updated to, and all of the files that Mercurial is tracking in the +%working directory. -Just as a revision of a revlog has room for two parents, so that it -can represent either a normal revision (with one parent) or a merge of -two earlier revisions, the dirstate has slots for two parents. When -you use the \hgcmd{update} command, the changeset that you update to -is stored in the ``first parent'' slot, and the null ID in the second. -When you \hgcmd{merge} with another changeset, the first parent -remains unchanged, and the second parent is filled in with the -changeset you're merging with. The \hgcmd{parents} command tells you -what the parents of the dirstate are. +%Just as a revision of a revlog has room for two parents, so that it +%can represent either a normal revision (with one parent) or a merge of +%two earlier revisions, the dirstate has slots for two parents. When +%you use the \hgcmd{update} command, the changeset that you update to +%is stored in the ``first parent'' slot, and the null ID in the second. +%When you \hgcmd{merge} with another changeset, the first parent +%remains unchanged, and the second parent is filled in with the +%changeset you're merging with. The \hgcmd{parents} command tells you +%what the parents of the dirstate are. -\subsection{What happens when you commit} +%\subsection{What happens when you commit} +\subsection{コミット時に何が起きるのか} -The dirstate stores parent information for more than just book-keeping -purposes. Mercurial uses the parents of the dirstate as \emph{the - parents of a new changeset} when you perform a commit. +%The dirstate stores parent information for more than just book-keeping +%purposes. Mercurial uses the parents of the dirstate as \emph{the +% parents of a new changeset} when you perform a commit. \begin{figure}[ht] \centering \includegraphics{wdir} - \caption{The working directory can have two parents} +% \caption{The working directory can have two parents} + \caption{ワーキングディレクトリは2つの親を持ち得る} \label{fig:concepts:wdir} \end{figure} -Figure~\ref{fig:concepts:wdir} shows the normal state of the working -directory, where it has a single changeset as parent. That changeset -is the \emph{tip}, the newest changeset in the repository that has no -children. +%Figure~\ref{fig:concepts:wdir} shows the normal state of the working +%directory, where it has a single changeset as parent. That changeset +%is the \emph{tip}, the newest changeset in the repository that has no +%children. \begin{figure}[ht] \centering \includegraphics{wdir-after-commit} - \caption{The working directory gains new parents after a commit} +% \caption{The working directory gains new parents after a commit} + \caption{コミット後，ワーキングディレクトリは新たな両親を持つ} \label{fig:concepts:wdir-after-commit} \end{figure} -It's useful to think of the working directory as ``the changeset I'm -about to commit''. Any files that you tell Mercurial that you've -added, removed, renamed, or copied will be reflected in that -changeset, as will modifications to any files that Mercurial is -already tracking; the new changeset will have the parents of the -working directory as its parents. +%It's useful to think of the working directory as ``the changeset I'm +%about to commit''. Any files that you tell Mercurial that you've +%added, removed, renamed, or copied will be reflected in that +%changeset, as will modifications to any files that Mercurial is +%already tracking; the new changeset will have the parents of the +%working directory as its parents. -After a commit, Mercurial will update the parents of the working -directory, so that the first parent is the ID of the new changeset, -and the second is the null ID. This is shown in -figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch -any of the files in the working directory when you commit; it just -modifies the dirstate to note its new parents. +%After a commit, Mercurial will update the parents of the working +%directory, so that the first parent is the ID of the new changeset, +%and the second is the null ID. This is shown in +%figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch +%any of the files in the working directory when you commit; it just +%modifies the dirstate to note its new parents. -\subsection{Creating a new head} +%\subsection{Creating a new head} +\subsection{新たなヘッドを作る} -It's perfectly normal to update the working directory to a changeset -other than the current tip. For example, you might want to know what -your project looked like last Tuesday, or you could be looking through -changesets to see which one introduced a bug. In cases like this, the -natural thing to do is update the working directory to the changeset -you're interested in, and then examine the files in the working -directory directly to see their contents as they werea when you -committed that changeset. The effect of this is shown in -figure~\ref{fig:concepts:wdir-pre-branch}. +%It's perfectly normal to update the working directory to a changeset +%other than the current tip. For example, you might want to know what +%your project looked like last Tuesday, or you could be looking through +%changesets to see which one introduced a bug. In cases like this, the +%natural thing to do is update the working directory to the changeset +%you're interested in, and then examine the files in the working +%directory directly to see their contents as they werea when you +%committed that changeset. The effect of this is shown in +%figure~\ref{fig:concepts:wdir-pre-branch}. \begin{figure}[ht] \centering \includegraphics{wdir-pre-branch} - \caption{The working directory, updated to an older changeset} +% \caption{The working directory, updated to an older changeset} + \caption{古いチェンジセットへと更新されたワーキングディレクトリ} \label{fig:concepts:wdir-pre-branch} \end{figure} -Having updated the working directory to an older changeset, what -happens if you make some changes, and then commit? Mercurial behaves -in the same way as I outlined above. The parents of the working -directory become the parents of the new changeset. This new changeset -has no children, so it becomes the new tip. And the repository now -contains two changesets that have no children; we call these -\emph{heads}. You can see the structure that this creates in -figure~\ref{fig:concepts:wdir-branch}. +%Having updated the working directory to an older changeset, what +%happens if you make some changes, and then commit? Mercurial behaves +%in the same way as I outlined above. The parents of the working +%directory become the parents of the new changeset. This new changeset +%has no children, so it becomes the new tip. And the repository now +%contains two changesets that have no children; we call these +%\emph{heads}. You can see the structure that this creates in +%figure~\ref{fig:concepts:wdir-branch}. \begin{figure}[ht] \centering \includegraphics{wdir-branch} - \caption{After a commit made while synced to an older changeset} +% \caption{After a commit made while synced to an older changeset} + \caption{古いチェンジセットに同期中にコミットが行われた場合} \label{fig:concepts:wdir-branch} \end{figure} -\begin{note} - If you're new to Mercurial, you should keep in mind a common - ``error'', which is to use the \hgcmd{pull} command without any - options. By default, the \hgcmd{pull} command \emph{does not} - update the working directory, so you'll bring new changesets into - your repository, but the working directory will stay synced at the - same changeset as before the pull. If you make some changes and - commit afterwards, you'll thus create a new head, because your - working directory isn't synced to whatever the current tip is. +%\begin{note} +% If you're new to Mercurial, you should keep in mind a common +% ``error'', which is to use the \hgcmd{pull} command without any +% options. By default, the \hgcmd{pull} command \emph{does not} +% update the working directory, so you'll bring new changesets into +% your repository, but the working directory will stay synced at the +% same changeset as before the pull. If you make some changes and +% commit afterwards, you'll thus create a new head, because your +% working directory isn't synced to whatever the current tip is. +% +% I put the word ``error'' in quotes because all that you need to do +% to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In +% other words, this almost never has negative consequences; it just +% surprises people. I'll discuss other ways to avoid this behaviour, +% and why Mercurial behaves in this initially surprising way, later +% on. +%\end{note} - I put the word ``error'' in quotes because all that you need to do - to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In - other words, this almost never has negative consequences; it just - surprises people. I'll discuss other ways to avoid this behaviour, - and why Mercurial behaves in this initially surprising way, later - on. -\end{note} +%\subsection{Merging heads} +\subsection{ヘッド間のマージ} -\subsection{Merging heads} - -When you run the \hgcmd{merge} command, Mercurial leaves the first -parent of the working directory unchanged, and sets the second parent -to the changeset you're merging with, as shown in -figure~\ref{fig:concepts:wdir-merge}. +%When you run the \hgcmd{merge} command, Mercurial leaves the first +%parent of the working directory unchanged, and sets the second parent +%to the changeset you're merging with, as shown in +%figure~\ref{fig:concepts:wdir-merge}. \begin{figure}[ht] \centering \includegraphics{wdir-merge} - \caption{Merging two heads} +% \caption{Merging two heads} + \caption{2つのヘッドのマージ} \label{fig:concepts:wdir-merge} \end{figure} @@ -409,7 +550,8 @@ changesets at once, the prospect of user confusion and making a terrible mess of a merge immediately becomes overwhelming. -\section{Other interesting design features} +%\section{Other interesting design features} +\section{設計の他の興味深い点} In the sections above, I've tried to highlight some of the most important aspects of Mercurial's design, to illustrate that it pays @@ -421,7 +563,8 @@ better idea of the amount of thinking that goes into a well-designed system. -\subsection{Clever compression} +%\subsection{Clever compression} +\subsection{賢い圧縮} When appropriate, Mercurial will store both snapshots and deltas in compressed form. It does this by always \emph{trying to} compress a @@ -441,138 +584,157 @@ the snapshot, again saving space compared to a naive delta-only approach. -\subsubsection{Network recompression} +%\subsubsection{Network recompression} +\subsubsection{ネットワーク再圧縮} -When storing revisions on disk, Mercurial uses the ``deflate'' -compression algorithm (the same one used by the popular \texttt{zip} -archive format), which balances good speed with a respectable -compression ratio. However, when transmitting revision data over a -network connection, Mercurial uncompresses the compressed revision -data. +%When storing revisions on disk, Mercurial uses the ``deflate'' +%compression algorithm (the same one used by the popular \texttt{zip} +%archive format), which balances good speed with a respectable +%compression ratio. However, when transmitting revision data over a +%network connection, Mercurial uncompresses the compressed revision +%data. + +%If the connection is over HTTP, Mercurial recompresses the entire +%stream of data using a compression algorithm that gives a better +%compression ratio (the Burrows-Wheeler algorithm from the widely used +%\texttt{bzip2} compression package). This combination of algorithm +%and compression of the entire stream (instead of a revision at a time) +%substantially reduces the number of bytes to be transferred, yielding +%better network performance over almost all kinds of network. -If the connection is over HTTP, Mercurial recompresses the entire -stream of data using a compression algorithm that gives a better -compression ratio (the Burrows-Wheeler algorithm from the widely used -\texttt{bzip2} compression package). This combination of algorithm -and compression of the entire stream (instead of a revision at a time) -substantially reduces the number of bytes to be transferred, yielding -better network performance over almost all kinds of network. +%(If the connection is over \command{ssh}, Mercurial \emph{doesn't} +%recompress the stream, because \command{ssh} can already do this +%itself.) + +%\subsection{Read/write ordering and atomicity} +\subsection{読み書きの順序とアトミック性} -(If the connection is over \command{ssh}, Mercurial \emph{doesn't} -recompress the stream, because \command{ssh} can already do this -itself.) - -\subsection{Read/write ordering and atomicity} +%Appending to files isn't the whole story when it comes to guaranteeing +%that a reader won't see a partial write. If you recall +%figure~\ref{fig:concepts:metadata}, revisions in the changelog point to +%revisions in the manifest, and revisions in the manifest point to +%revisions in filelogs. This hierarchy is deliberate. -Appending to files isn't the whole story when it comes to guaranteeing -that a reader won't see a partial write. If you recall -figure~\ref{fig:concepts:metadata}, revisions in the changelog point to -revisions in the manifest, and revisions in the manifest point to -revisions in filelogs. This hierarchy is deliberate. +%A writer starts a transaction by writing filelog and manifest data, +%and doesn't write any changelog data until those are finished. A +%reader starts by reading changelog data, then manifest data, followed +%by filelog data. -A writer starts a transaction by writing filelog and manifest data, -and doesn't write any changelog data until those are finished. A -reader starts by reading changelog data, then manifest data, followed -by filelog data. +%Since the writer has always finished writing filelog and manifest data +%before it writes to the changelog, a reader will never read a pointer +%to a partially written manifest revision from the changelog, and it will +%never read a pointer to a partially written filelog revision from the +%manifest. -Since the writer has always finished writing filelog and manifest data -before it writes to the changelog, a reader will never read a pointer -to a partially written manifest revision from the changelog, and it will -never read a pointer to a partially written filelog revision from the -manifest. +%\subsection{Concurrent access} +\subsection{同時アクセス} -\subsection{Concurrent access} +%The read/write ordering and atomicity guarantees mean that Mercurial +%never needs to \emph{lock} a repository when it's reading data, even +%if the repository is being written to while the read is occurring. +%This has a big effect on scalability; you can have an arbitrary number +%of Mercurial processes safely reading data from a repository safely +%all at once, no matter whether it's being written to or not. -The read/write ordering and atomicity guarantees mean that Mercurial -never needs to \emph{lock} a repository when it's reading data, even -if the repository is being written to while the read is occurring. -This has a big effect on scalability; you can have an arbitrary number -of Mercurial processes safely reading data from a repository safely -all at once, no matter whether it's being written to or not. +%The lockless nature of reading means that if you're sharing a +%repository on a multi-user system, you don't need to grant other local +%users permission to \emph{write} to your repository in order for them +%to be able to clone it or pull changes from it; they only need +%\emph{read} permission. (This is \emph{not} a common feature among +%revision control systems, so don't take it for granted! Most require +%readers to be able to lock a repository to access it safely, and this +%requires write permission on at least one directory, which of course +%makes for all kinds of nasty and annoying security and administrative +%problems.) -The lockless nature of reading means that if you're sharing a -repository on a multi-user system, you don't need to grant other local -users permission to \emph{write} to your repository in order for them -to be able to clone it or pull changes from it; they only need -\emph{read} permission. (This is \emph{not} a common feature among -revision control systems, so don't take it for granted! Most require -readers to be able to lock a repository to access it safely, and this -requires write permission on at least one directory, which of course -makes for all kinds of nasty and annoying security and administrative -problems.) +%Mercurial uses locks to ensure that only one process can write to a +%repository at a time (the locking mechanism is safe even over +%filesystems that are notoriously hostile to locking, such as NFS). If +%a repository is locked, a writer will wait for a while to retry if the +%repository becomes unlocked, but if the repository remains locked for +%too long, the process attempting to write will time out after a while. +%This means that your daily automated scripts won't get stuck forever +%and pile up if a system crashes unnoticed, for example. (Yes, the +%timeout is configurable, from zero to infinity.) + +%\subsubsection{Safe dirstate access} +\subsubsection{安全なdirstateアクセス} -Mercurial uses locks to ensure that only one process can write to a -repository at a time (the locking mechanism is safe even over -filesystems that are notoriously hostile to locking, such as NFS). If -a repository is locked, a writer will wait for a while to retry if the -repository becomes unlocked, but if the repository remains locked for -too long, the process attempting to write will time out after a while. -This means that your daily automated scripts won't get stuck forever -and pile up if a system crashes unnoticed, for example. (Yes, the -timeout is configurable, from zero to infinity.) +%As with revision data, Mercurial doesn't take a lock to read the +%dirstate file; it does acquire a lock to write it. To avoid the +%possibility of reading a partially written copy of the dirstate file, +%Mercurial writes to a file with a unique name in the same directory as +%the dirstate file, then renames the temporary file atomically to +%\filename{dirstate}. The file named \filename{dirstate} is thus +%guaranteed to be complete, not partially written. -\subsubsection{Safe dirstate access} +%\subsection{Avoiding seeks} +\subsection{シークの回避} + +%Critical to Mercurial's performance is the avoidance of seeks of the +%disk head, since any seek is far more expensive than even a +%comparatively large read operation. -As with revision data, Mercurial doesn't take a lock to read the -dirstate file; it does acquire a lock to write it. To avoid the -possibility of reading a partially written copy of the dirstate file, -Mercurial writes to a file with a unique name in the same directory as -the dirstate file, then renames the temporary file atomically to -\filename{dirstate}. The file named \filename{dirstate} is thus -guaranteed to be complete, not partially written. +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 +%disk would seek once per directory. Instead, Mercurial reads the +%entire single dirstate file in one step. -\subsection{Avoiding seeks} +その理由は，例えば，dirstateは1つのファイルに保存されているためで， +Mercurialが追跡しているdirstateファイルがディレクトリ毎にある +と，Mercurialはディレクトリ毎にシークを行うことになる．実際にはMercurial +は全体で一つのdirstateファイルをワンステップで読む． -Critical to Mercurial's performance is the avoidance of seeks of the -disk head, since any seek is far more expensive than even a -comparatively large read operation. - -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 -disk would seek once per directory. Instead, Mercurial reads the -entire single dirstate file in one step. +%Mercurial also uses a ``copy on write'' scheme when cloning a +%repository on local storage. Instead of copying every revlog file -Mercurial also uses a ``copy on write'' scheme when cloning a -repository on local storage. Instead of copying every revlog file -from the old repository into the new repository, it makes a ``hard -link'', which is a shorthand way to say ``these two names point to the -same file''. When Mercurial is about to write to one of a revlog's -files, it checks to see if the number of names pointing at the file is -greater than one. If it is, more than one repository is using the -file, so Mercurial makes a new copy of the file that is private to -this repository. +%from the old repository into the new repository, it makes a ``hard +%link'', which is a shorthand way to say ``these two names point to the +%same file''. When Mercurial is about to write to one of a revlog's +%files, it checks to see if the number of names pointing at the file is +%greater than one. If it is, more than one repository is using the +%file, so Mercurial makes a new copy of the file that is private to +%this repository. -A few revision control developers have pointed out that this idea of -making a complete private copy of a file is not very efficient in its -use of storage. While this is true, storage is cheap, and this method -gives the highest performance while deferring most book-keeping to the -operating system. An alternative scheme would most likely reduce -performance and increase the complexity of the software, each of which -is much more important to the ``feel'' of day-to-day use. +Mercurialはリポジトリをローカルストレージにクローンする際に``コピーオンラ +イト''手法を使っている． + -\subsection{Other contents of the dirstate} +%A few revision control developers have pointed out that this idea of +%making a complete private copy of a file is not very efficient in its +%use of storage. While this is true, storage is cheap, and this method +%gives the highest performance while deferring most book-keeping to the +%operating system. An alternative scheme would most likely reduce +%performance and increase the complexity of the software, each of which +%is much more important to the ``feel'' of day-to-day use. -Because Mercurial doesn't force you to tell it when you're modifying a -file, it uses the dirstate to store some extra information so it can -determine efficiently whether you have modified a file. For each file -in the working directory, it stores the time that it last modified the -file itself, and the size of the file at that time. +%\subsection{Other contents of the dirstate} +\subsection{dirstateの他の内容} -When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or -\hgcmd{copy} files, Mercurial updates the dirstate so that it knows -what to do with those files when you commit. +%Because Mercurial doesn't force you to tell it when you're modifying a +%file, it uses the dirstate to store some extra information so it can +%determine efficiently whether you have modified a file. For each file +%in the working directory, it stores the time that it last modified the +%file itself, and the size of the file at that time. -When Mercurial is checking the states of files in the working -directory, it first checks a file's modification time. If that has -not changed, the file must not have been modified. If the file's size -has changed, the file must have been modified. If the modification -time has changed, but the size has not, only then does Mercurial need -to read the actual contents of the file to see if they've changed. -Storing these few extra pieces of information dramatically reduces the -amount of data that Mercurial needs to read, which yields large -performance improvements compared to other revision control systems. +%When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or +%\hgcmd{copy} files, Mercurial updates the dirstate so that it knows +%what to do with those files when you commit. -%%% Local Variables: +%When Mercurial is checking the states of files in the working +%directory, it first checks a file's modification time. If that has +%not changed, the file must not have been modified. If the file's size +%has changed, the file must have been modified. If the modification +%time has changed, but the size has not, only then does Mercurial need +%to read the actual contents of the file to see if they've changed. +%Storing these few extra pieces of information dramatically reduces the +%amount of data that Mercurial needs to read, which yields large +%performance improvements compared to other revision control systems. + +%%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" %%% End: diff -r 2a93b1d35990 -r 93d19b27859c ja/todo.txt --- a/ja/todo.txt Sun May 03 17:10:09 2009 +0900 +++ b/ja/todo.txt Tue May 12 17:49:11 2009 +0900 @@ -2,12 +2,12 @@ 00book.tex 100% branch.tex 100% collab.tex 100% -concepts.tex +concepts.tex 20% daily.tex 100% filenames.tex 100% hg_id.tex noneed hgext.tex 100% -hook.tex 80% +hook.tex 100% intro.tex 100% license.tex - mq-collab.tex 100%