# HG changeset patch # User Yoshiki Yazawa # Date 1203348804 -32400 # Node ID 0a551d1b44a6790ace96e71769c64672c5ea70d2 # Parent 2052bee9f07491cc63f9fbf3c18c94830e634559 more branch.tex diff -r 2052bee9f074 -r 0a551d1b44a6 ja/branch.tex --- a/ja/branch.tex Mon Feb 18 06:48:59 2008 +0900 +++ b/ja/branch.tex Tue Feb 19 00:33:24 2008 +0900 @@ -229,13 +229,13 @@ %which you can then fix and commit. You should then run \hgcmd{tags} %again, just to be sure that your fix is correct. -この設計の不幸な結果は，変更をコミットした\emph{後}でないとマージした -\sfilename{.hgtags}ファイルを実際にはベリファイできないことである． -そのため，マージ中に\sfilename{.hgtags}のコンフリクト解決をしている場合 -は，コミット後に忘れず\hgcmd{tags}を実行する必要がある． -\sfilename{.hgtags}にエラーが見つかった場合，エラーのある場所を報告する． -それを見て修正し，コミットすることができる．そこで\hgcmd{tags}を再び走ら -せ，修正が正しいことを確認すべきである． +この設計の残念な結果は，変更をコミットした\emph{後}でないとマージした +\sfilename{.hgtags}ファイルを実際にはベリファイできないことである．そのた +め，マージ中に\sfilename{.hgtags}のコンフリクト解決をしている場合は，コミッ +ト後に忘れず\hgcmd{tags}を実行する必要がある．\sfilename{.hgtags}にエラー +が見つかった場合，エラーのある場所を報告する．それを見て修正し，コミット +することができる．そこで\hgcmd{tags}を再び走らせ，修正が正しいことを確認 +すべきである． %\subsection{Tags and cloning} @@ -252,85 +252,141 @@ をクローンすることができるが、クローンしたコピーは，指定したリビジョン後 の履歴を持たないため、不用心なユーザはしばしば驚くことになる。 -Recall that a tag is stored as a revision to the \sfilename{.hgtags} -file, so that when you create a tag, the changeset in which it's -recorded necessarily refers to an older changeset. When you run -\hgcmdargs{clone}{-r foo} to clone a repository as of tag -\texttt{foo}, the new clone \emph{will not contain the history that - created the tag} that you used to clone the repository. The result -is that you'll get exactly the right subset of the project's history -in the new repository, but \emph{not} the tag you might have expected. +%Recall that a tag is stored as a revision to the \sfilename{.hgtags} +%file, so that when you create a tag, the changeset in which it's +%recorded necessarily refers to an older changeset. +%When you run \hgcmdargs{clone}{-r foo} to clone a repository as of tag +%\texttt{foo}, the new clone \emph{will not contain the history that +%created the tag} that you used to clone the repository. +%The resultis that you'll get exactly the right subset of the project's +%history in the new repository, but \emph{not} the tag you might have +%expected. - - - +タグは\sfilename{.hgtags}ファイル内のリビジョンとして記録されていることを +思い出して欲しい．このため，タグ作成時に，タグが記録されているチェンジセッ +トから古いチェンジセットへの参照が生じる．タグ\texttt{foo}が付いているリ +ポジトリをクローンするために\hgcmdargs{clone}{-r foo}実行する時，新しいク +ローンはタグを生成した履歴を\emph{含まない}．結果として，新しいリポジトリ +に含まれる履歴は，プロジェクト履歴のサブセットになり，タグは含まれない． %\subsection{When permanent tags are too much} \subsection{永久タグが必要でない場合} -Since Mercurial's tags are revision controlled and carried around with -a project's history, everyone you work with will see the tags you -create. But giving names to revisions has uses beyond simply noting -that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If -you're trying to track down a subtle bug, you might want a tag to -remind you of something like ``Anne saw the symptoms with this -revision''. +%Since Mercurial's tags are revision controlled and carried around with +%a project's history, everyone you work with will see the tags you +%create. But giving names to revisions has uses beyond simply noting +%that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If +%you're trying to track down a subtle bug, you might want a tag to +%remind you of something like ``Anne saw the symptoms with this +%revision''. + +Mercurialのタグはリビジョンコントロールされ，プロジェクト履歴に付随してい +るため，同じプロジェクトで働く人は皆タグを知ることになる．リビジョンに名 +前を付けることは，単にリビジョン\texttt{4237e45506ee}がバージョン +\texttt{v2.0.2}であると記述する以上の意味を持つ．もしバグを追跡しているな +ら，``Anne saw the symptoms with this revision''（アンはこのリビジョンで +症状を見た）などのタグを付けたくなるだろう． -For cases like this, what you might want to use are \emph{local} tags. -You can create a local tag with the \hgopt{tag}{-l} option to the -\hgcmd{tag} command. This will store the tag in a file called -\sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, -\sfilename{.hg/localtags} is not revision controlled. Any tags you -create using \hgopt{tag}{-l} remain strictly local to the repository -you're currently working in. +%For cases like this, what you might want to use are \emph{local} tags. +%You can create a local tag with the \hgopt{tag}{-l} option to the +%\hgcmd{tag} command. This will store the tag in a file called +%\sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, +%\sfilename{.hg/localtags} is not revision controlled. Any tags you +%create using \hgopt{tag}{-l} remain strictly local to the repository +%you're currently working in. + +このような場合，\emph{ローカル}タグを使いたくなるはずだ．ローカルタグは +\hgcmd{tag}コマンドを\hgopt{tag}{-l}オプション付きで使うことで作成できる． +このオプションを使うと，タグは\sfilename{.hg/localtags}というファイルに保 +存される．\sfilename{.hgtags}と違って，\sfilename{.hg/localtags}はリビジョ +ンコントロールされない．\hgopt{tag}{-l}オプションで作成したあらゆるタグ +は厳密にローカルに管理され，今作業しているろポジ取りには一切反映されない． + %\section{The flow of changes---big picture vs. little} \section{更新の流れ---大局的 vs.局所的} -To return to the outline I sketched at the beginning of a chapter, -let's think about a project that has multiple concurrent pieces of -work under development at once. +%To return to the outline I sketched at the beginning of a chapter, +%let's think about a project that has multiple concurrent pieces of +%work under development at once. + +この章の最初で示したアウトラインに戻るために，プロジェクトが開発中，一度 +に複数の並行した部分を持つと考えよう． -There might be a push for a new ``main'' release; a new minor bugfix -release to the last main release; and an unexpected ``hot fix'' to an -old release that is now in maintenance mode. +%There might be a push for a new ``main'' release; a new minor bugfix +%release to the last main release; and an unexpected ``hot fix'' to an +%old release that is now in maintenance mode. + +新しい``main''をリリースする状況で，最新のメインリリースに対する新しい小 +規模なバグフィックスリリースと既にメンテナンスモードになっている古いリリー +ス向けの予期せぬ``hot fix'' をリリースする状況を考える． + -The usual way people refer to these different concurrent directions of -development is as ``branches''. However, we've already seen numerous -times that Mercurial treats \emph{all of history} as a series of -branches and merges. Really, what we have here is two ideas that are -peripherally related, but which happen to share a name. +%The usual way people refer to these different concurrent directions of +%development is as ``branches''. However, we've already seen numerous +%times that Mercurial treats \emph{all of history} as a series of +%branches and merges. Really, what we have here is two ideas that are +%peripherally related, but which happen to share a name. +%\begin{itemize} +%\item ``Big picture'' branches represent the sweep of a project's +% evolution; people give them names, and talk about them in +% conversation. +%\item ``Little picture'' branches are artefacts of the day-to-day +% activity of developing and merging changes. They expose the +% narrative of how the code was developed. +%\end{itemize} + +人々が，異なった並行的な開発の方向性について触れる時は，``ブランチ''とし +て言及する．しかし，既に幾度となくMercurialが\emph{全ての履歴}を一連のブ +ランチとマージとして取り扱っているのを見てきた．ここでは，わずかに関連し +ているが名前を共有している2つのアイディアを考える． \begin{itemize} -\item ``Big picture'' branches represent the sweep of a project's - evolution; people give them names, and talk about them in - conversation. -\item ``Little picture'' branches are artefacts of the day-to-day - activity of developing and merging changes. They expose the - narrative of how the code was developed. +\item ``Big picture''ブランチはプロジェクトの進化を表す．開発者はこれら + に名前を与え，会話で用いる． +\item ``Little picture''ブランチは日々の開発とマージの所産で，コードがど + のように開発されたかを示すものである． \end{itemize} %\section{Managing big-picture branches in repositories} \section{リポジトリ間での大局的ブランチの管理} -The easiest way to isolate a ``big picture'' branch in Mercurial is in -a dedicated repository. If you have an existing shared -repository---let's call it \texttt{myproject}---that reaches a ``1.0'' -milestone, you can start to prepare for future maintenance releases on -top of version~1.0 by tagging the revision from which you prepared -the~1.0 release. +%The easiest way to isolate a ``big picture'' branch in Mercurial is in +%a dedicated repository. If you have an existing shared +%repository---let's call it \texttt{myproject}---that reaches a ``1.0'' +%milestone, you can start to prepare for future maintenance releases on +%top of version~1.0 by tagging the revision from which you prepared +%the~1.0 release. +%\interaction{branch-repo.tag} +%You can then clone a new shared \texttt{myproject-1.0.1} repository as +%of that tag. +%\interaction{branch-repo.clone} + +Mercurialで``bit picture''を隔離する最も簡単な方法は，専用のリポジトリを +用意することである．もし一つの共有リポジトリを持っている場合，これを +\texttt{myproject}と呼ぶことにしる．これが``1.0''マイルストーンに到達した +ら，1.0に1.0リリースとタグを付け，将来のメンテナンスリリースに備えること +ができる． \interaction{branch-repo.tag} -You can then clone a new shared \texttt{myproject-1.0.1} repository as -of that tag. +そして新たに\texttt{myproject-1.0.1}とタグを付けてリポジトリをクローンす +る． \interaction{branch-repo.clone} -Afterwards, if someone needs to work on a bug fix that ought to go -into an upcoming~1.0.1 minor release, they clone the -\texttt{myproject-1.0.1} repository, make their changes, and push them -back. +%Afterwards, if someone needs to work on a bug fix that ought to go +%into an upcoming~1.0.1 minor release, they clone the +%\texttt{myproject-1.0.1} repository, make their changes, and push them +%back. +%\interaction{branch-repo.bugfix} +%Meanwhile, development for the next major release can continue, +%isolated and unabated, in the \texttt{myproject} repository. +%\interaction{branch-repo.new} + +以後，バグフィックスをしたい人は1.0.1マイナーリリースへいくべきである． +彼らは\texttt{myproject-1.0.1}リポジトリをクローンし，変更を加え，プッシュ +する． \interaction{branch-repo.bugfix} -Meanwhile, development for the next major release can continue, -isolated and unabated, in the \texttt{myproject} repository. +一方で次のメジャーリリースに向けての開発は，\texttt{myproject}リポジトリ +の中で隔離され，滞る事なく継続することが可能である． \interaction{branch-repo.new} %\section{Don't repeat yourself: merging across branches}