# HG changeset patch # User Yoshiki Yazawa # Date 1231492032 -32400 # Node ID 9f7812b79c70fc83d8838264744b02500a67c365 # Parent 24c6081cea2b457aa912bea71596013a68ba88b7 more daily.tex diff -r 24c6081cea2b -r 9f7812b79c70 ja/daily.tex --- a/ja/daily.tex Fri Jan 09 17:01:40 2009 +0900 +++ b/ja/daily.tex Fri Jan 09 18:07:12 2009 +0900 @@ -5,30 +5,51 @@ %\section{Telling Mercurial which files to track} \section{追跡すべきファイルのMercurialへの登録} -Mercurial does not work with files in your repository unless you tell -it to manage them. The \hgcmd{status} command will tell you which -files Mercurial doesn't know about; it uses a ``\texttt{?}'' to -display such files. +%Mercurial does not work with files in your repository unless you tell +%it to manage them. The \hgcmd{status} command will tell you which +%files Mercurial doesn't know about; it uses a ``\texttt{?}'' to +%display such files. + +Mercurialは，ユーザによるファイル管理の指示がない限り，リポジトリ内のファ +イルであっても管理を行わない．Mercurialが管理しないファイルは +\hgcmd{status}コマンドを実行すると``\texttt{?}''と表示される． -To tell Mercurial to track a file, use the \hgcmd{add} command. Once -you have added a file, the entry in the output of \hgcmd{status} for -that file changes from ``\texttt{?}'' to ``\texttt{A}''. +%To tell Mercurial to track a file, use the \hgcmd{add} command. Once +%you have added a file, the entry in the output of \hgcmd{status} for +%that file changes from ``\texttt{?}'' to ``\texttt{A}''. +%\interaction{daily.files.add} + +Mercurialにファイルの追跡をさせるには，\hgcmd{add}コマンドを用いる．一度 +ファイルを追加すると，\hgcmd{status}コマンドの出力は``\texttt{?}''から +``\texttt{A}''に変わる． \interaction{daily.files.add} -After you run a \hgcmd{commit}, the files that you added before the -commit will no longer be listed in the output of \hgcmd{status}. The -reason for this is that \hgcmd{status} only tells you about -``interesting'' files---those that you have modified or told Mercurial -to do something with---by default. If you have a repository that -contains thousands of files, you will rarely want to know about files -that Mercurial is tracking, but that have not changed. (You can still -get this information; we'll return to this later.) +%After you run a \hgcmd{commit}, the files that you added before the +%commit will no longer be listed in the output of \hgcmd{status}. The +%reason for this is that \hgcmd{status} only tells you about +%``interesting'' files---those that you have modified or told Mercurial +%to do something with---by default. If you have a repository that +%contains thousands of files, you will rarely want to know about files +%that Mercurial is tracking, but that have not changed. (You can still +%get this information; we'll return to this later.) -Once you add a file, Mercurial doesn't do anything with it -immediately. Instead, it will take a snapshot of the file's state the -next time you perform a commit. It will then continue to track the -changes you make to the file every time you commit, until you remove -the file. +\hgcmd{commit}コマンドを実行すると，commitの前に追加したファイルは +\hgcmd{status}の出力に現れなくなる．これは，\hgcmd{status}がデフォルトで +は変更を加えたり，Mercurialに何かをさせたといった``注目すべき''ファイルの +みを表示するためである．数千のファイルからなるリポジトリの場合，Mercurialが +追跡しているものの，変更の加えられていないファイルについて何かを知りたい +ということは稀である．（もちろん知りたい場合は情報を得ることもできる．こ +れについては後述する．） + +%Once you add a file, Mercurial doesn't do anything with it +%immediately. Instead, it will take a snapshot of the file's state the +%next time you perform a commit. It will then continue to track the +%changes you make to the file every time you commit, until you remove +%the file. + +追加したファイルに対してMercurialが直ちに行うことは何もないが，その代わり +に次回のコミット時にファイル状態のスナップショットを取る．そしてファイル +を削除するまでコミット毎にファイルの変化を追跡する． %\subsection{Explicit versus implicit file naming} \subsection{明示的なファイル命名対暗黙のファイル命名} @@ -321,60 +342,99 @@ %\subsection{Renaming files and merging changes} \subsection{ファイルのリネームと変更のマージ} -Since Mercurial's rename is implemented as copy-and-remove, the same -propagation of changes happens when you merge after a rename as after -a copy. +%Since Mercurial's rename is implemented as copy-and-remove, the same +%propagation of changes happens when you merge after a rename as after +%a copy. + +Mercurialのリネームはコピーと削除として実装されており，リネーム後にマー +ジを行うのと，コピー後にマージを行うのでは同じ変更の波及が起きる． + +%If I modify a file, and you rename it to a new name, and then we merge +%our respective changes, my modifications to the file under its +%original name will be propagated into the file under its new name. +%(This is something you might expect to ``simply work,'' but not all +%revision control systems actually do this.) -If I modify a file, and you rename it to a new name, and then we merge -our respective changes, my modifications to the file under its -original name will be propagated into the file under its new name. -(This is something you might expect to ``simply work,'' but not all -revision control systems actually do this.) +私がファイルを変更し，あなたがそのファイルをを新しい名前にリネームした場 +合，我々がお互いの変更をマージすると元のファイル名に対する私の変更は，新 +しいファイル名のファイルに波及する． （これができるのは当たり前と思うかも +しれないが，実のところ，全てのリビジョンコントロールシステムができるわけ +ではない．） -Whereas having changes follow a copy is a feature where you can -perhaps nod and say ``yes, that might be useful,'' it should be clear -that having them follow a rename is definitely important. Without -this facility, it would simply be too easy for changes to become -orphaned when files are renamed. +%Whereas having changes follow a copy is a feature where you can +%perhaps nod and say ``yes, that might be useful,'' it should be clear +%that having them follow a rename is definitely important. Without +%this facility, it would simply be too easy for changes to become +%orphaned when files are renamed. + +変更がコピーに従う機能が有用であることは，おそらく容易に同意が得られると +ころであると思われる．とりわけリネームに追従する機能はきわめて重要である +ことは明白である．もしこの機能がなければ，ファイルのリネームによって変更 +は容易く行き場を失ってしまうだろう． %\subsection{Divergent renames and merging} \subsection{名前とマージの発散} -The case of diverging names occurs when two developers start with a -file---let's call it \filename{foo}---in their respective -repositories. +%The case of diverging names occurs when two developers start with a +%file---let's call it \filename{foo}---in their respective +%repositories. + +2人の開発者のリポジトリ間で1つのファイル ---\filename{foo}と呼ぶことにす +る--- について名前の発散が起こった場合について考えてみよう． \interaction{rename.divergent.clone} -Anne renames the file to \filename{bar}. +%Anne renames the file to \filename{bar}. +アンはファイルを\filename{bar}と改名した． \interaction{rename.divergent.rename.anne} -Meanwhile, Bob renames it to \filename{quux}. +%Meanwhile, Bob renames it to \filename{quux}. +その間，ボブは同じファイルを\filename{quux}と改名した． \interaction{rename.divergent.rename.bob} -I like to think of this as a conflict because each developer has -expressed different intentions about what the file ought to be named. +%I like to think of this as a conflict because each developer has +%expressed different intentions about what the file ought to be named. + +各々の開発者はファイルがどのように呼ばれるべきかについて異なった意図を持っ +ており，これはコンフリクトと考えられる． -What do you think should happen when they merge their work? -Mercurial's actual behaviour is that it always preserves \emph{both} -names when it merges changesets that contain divergent renames. +%What do you think should happen when they merge their work? +%Mercurial's actual behaviour is that it always preserves \emph{both} +%names when it merges changesets that contain divergent renames. +%\interaction{rename.divergent.merge} + +彼らがマージを行った際にどうなればよいだろうか？ Mercurialの実際の挙動 +は，発散したリネームがあるチェンジセットをマージした場合は常に\emph{両方}の +名前を保存する． \interaction{rename.divergent.merge} -Notice that Mercurial does warn about the divergent renames, but it -leaves it up to you to do something about the divergence after the merge. +%Notice that Mercurial does warn about the divergent renames, but it +%leaves it up to you to do something about the divergence after the merge. + +Mercurialは名前の発散について警告するが，マージ後も名前の発散の解決はユー +ザに任せる点に注意． %\subsection{Convergent renames and merging} \subsection{リネームとマージによる収束} -Another kind of rename conflict occurs when two people choose to -rename different \emph{source} files to the same \emph{destination}. -In this case, Mercurial runs its normal merge machinery, and lets you -guide it to a suitable resolution. +%Another kind of rename conflict occurs when two people choose to +%rename different \emph{source} files to the same \emph{destination}. +%In this case, Mercurial runs its normal merge machinery, and lets you +%guide it to a suitable resolution. + +2人のユーザが異なる\emph{ソース}ファイル群を同一の\emph{目的}ファイルにリ +ネームすると衝突が起きる．この場合，Mercurialは通常のマージ機構を起動し， +ユーザに適切な解決を促す． %\subsection{Other name-related corner cases} \subsection{名前に関連したいくつかの問題} -Mercurial has a longstanding bug in which it fails to handle a merge -where one side has a file with a given name, while another has a -directory with the same name. This is documented as~\bug{29} . +%Mercurial has a longstanding bug in which it fails to handle a merge +%where one side has a file with a given name, while another has a +%directory with the same name. This is documented as~\bug{29} . +%\interaction{issue29.go} + +Mercurialには，一方を名前を与えたファイル，もう一方を同名のディレクトリと +してマージを行うと失敗するバグが以前からある．これは~\bug{29}としてドキュ +メント化されている． \interaction{issue29.go} %\section{Recovering from mistakes} @@ -398,7 +458,6 @@ される．また\hgcmd{revert}はファイルへの間違った変更を消去するのも使える． %It's useful to remember that the \hgcmd{revert} command is useful for - %changes that you have not yet committed. Once you've committed a %change, if you decide it was a mistake, you can still do something %about it, though your options may be more limited. diff -r 24c6081cea2b -r 9f7812b79c70 ja/todo.txt --- a/ja/todo.txt Fri Jan 09 17:01:40 2009 +0900 +++ b/ja/todo.txt Fri Jan 09 18:07:12 2009 +0900 @@ -3,11 +3,11 @@ branch.tex 100% collab.tex 100% concepts.tex -daily.tex 2% +daily.tex 5% filenames.tex 100% hg_id.tex noneed hgext.tex 100% -hook.tex 1% +hook.tex 10% intro.tex license.tex mq-collab.tex 100%