Clever Geek Handbook

Hg Init：パート6.リポジトリアーキテクチャ

これは、 Hg Initシリーズの6番目の最終パートであるJoel Spolsky のMercurial Tutorialです。 前のパーツ：







Mercurialでは、非常に柔軟なリポジトリ設定が可能です。 さらに、合併はうまく機能し、それらに依存できるため、チームの開発プロセスの要件に応じて特別なサービスリポジトリを作成できます。



パート6.リポジトリアーキテクチャ





私たちのレシピは良くなっています：











変更セット番号を見てみましょう。







部屋の最初の部分である13は短くて快適です。 問題は...彼女に頼ることができないことです！



チームメンバーと合併者の独立した仕事により、これらの短い数字はチームメンバーごとに異なり始める可能性があります。







したがって、実際には、「13番目の変更セットからコンパイルされたバージョンをリリースしましょう」と言うことはできません。なぜなら、従業員は13番目のセットとは異なる考えを持っているかもしれないからです そのため、そのクレイジーな16進数もあります。







この16進数はすべてのリポジトリで一意であり、変更されることはありません。



つまり、私は人々に言うことができます：「ねえ、今日リリース！ 1b03ab783b17番目の変更セット！」。 同意して、このセットに名前を付けることができたらいいですね？



まあ、あなたはそのような機会を持っています。 この名前は、タグ（または英語タグのタグ）と呼ばれます。







今すぐログを見てみましょう：







変更セットにタグを追加すると、変更セットになることに注意してください。 この一連の変更は、リポジトリに自動的にコミットされます（コミット）。 したがって、リリースしたコードのバージョンを参照するたびに、 1b03ab783b17の代わりにVersion-1.0を使用できます。



副所長は31階から降りて、新しいバージョンのリリースについてのオフィスパーティーに参加し、かなり高価なスパークリングワインの箱を持ってきました。 スタンは少し酔った。 まあ、それほどではありません。 実際、前例のないものでした。 スタンはシャツを脱いで、みんなに彼の筋肉とハンサムな腹を見せて、マーケティング部門の女性を感動させようとしました。 彼は自慢しました：「私はランプに引っ張られます」（私たちのオフィスでは長い蛍光灯を使用しています）。 一般的に、彼は飛び上がってランプをつかみ、そしてもちろん、ランプと天井タイルとともにそれを引き裂きました。 約4.5 kgのランプが1 組のワイヤーにかかっているため、それは驚くことではありません。Stanの重量は130〜135 kgの非常に人気のある範囲内にあります。 割れたガラスと防音タイルが至る所にありました。 スタンは彼の尻尾に倒れ、安全でない労働条件で会社を訴えると文句を言い始めました。



残りはGuac 2.0で作業するために仕事に戻りました。







コミット：







言うまでもなく、このレシピはまだ疑わしいです。 たとえば、彼はテストされていません。 そして、クライアントが呼び出します。



「塩辛い！」クライアントは泣き叫ぶ。 いいえ、彼はバージョン2.0のリリースを待ってエラーを修正したくありません。



幸いなことに、そのタグがあります。 hg up



を使用して、リポジトリ内の任意のバージョンに移動できます。







今、私はこの愚かな塩の問題を修正することができます：







次に：







Mercurialは、自分の行動が新しい頭を作ったことを思い出させてくれます。 リポジトリには2つのヘッドがあります。最近作業したバージョン2.0と、コミットしたばかりのバージョンです。







現時点では、クライアントに最新の変更を加えたバージョンを提供し、1.1としてマークし、バージョン2.0を引き続き使用できます。







ただし、1つの問題があります。バージョン2.0には、saltに関する修正がありません。 どうすれば修正できますか？











よくここに。 タグのマージを行う必要があります。 これはMercurialの既知のバグです。 問題は、Mercurialのタグが.hgtagsと呼ばれるファイルであり、バージョン管理もあることです。 したがって、ときどき、.hgtagsファイルの異なるバージョンを手動でマージする必要があります。 このような状況では、アクションは簡単です...各行の両方のバージョンを常にファイルに保存する必要があります。







上記の簡単な方法で、マークされた古いバージョンに切り替える方法は、リリースされたコードで計画外の小さな変更を1つだけ行う必要がある場合に適しています。 しかし、真実は、ほとんどのソフトウェアプロジェクトでそのような状況が絶えず発生することであり、Mercurialはそれらに対処するより信頼性の高い方法を持っています。



そこで、1.0以降に行われたすべての変更を元に戻し、リポジトリをリリース1.0の時点の状態に戻します。次に、既存のクライアントのバグを修正し、新しいバージョンを並行して作業するためのファッショナブルで信頼性の高い方法を示します。







アイデアは、1つのリポジトリを操作する代わりに、2つのリポジトリを用意するというものです。 1つのリポジトリは安定版と呼ばれ、2番目はdevです。



安定したリポジトリには、クライアントに送信されるコードの最新のメジャーバージョンが含まれています。 バグを緊急に修正する必要があるたびに、 安定版でそれを行います。 この例では、バージョン1.0のすべてのパッチがstableに分類されます。



devリポジトリは、次のメジャーバージョン、つまりバージョン2.0が開発されている場所です。



バージョン1.0がリリースされるとすぐに、 devで stableをクローンします：







現在、2つの同一のリポジトリがあります。







両方のリポジトリの履歴は14番目の変更セットまで含まれているため、Mercurialはディスク上に2つのコピーを作成する代わりにハードリンクを使用します 。 したがって、 hg clone



操作は高速で安価です。つまり、多くのリポジトリクローンをためらうことなく作成できます。



それでは、 devリポジトリでguacの作業を始めましょう。







そして、 安定したリポジトリでその塩問題を修正します。







このバージョンにフラグを付けて、1.1としてリリースします。







さて、時々、変更をstableからdevにプルする必要があります：







ここに私たちがやったことがあります：







そして、 このクレイジーな絵に描かれていることを理解できれば、Mercurialを理解するのにもう問題はありません。 一番下の行は、バグ修正のみが安定したリポジトリに入れられ、新しいコードがdevリポジトリに保存され、バグ修正とのマージが実行されるということです。



複数のリポジトリには他の用途があります。







大規模で複雑な組織では、これらの手法を組み合わせて、相互に変更をプルするリポジトリチェーンを設定できます。 一部の機能はテストと統合の段階を経て、最終的にクライアントが受け取るコードを格納するメインリポジトリにあるまで、リポジトリチェーンに引き込まれます。







自分でテストする




このパートを読んだ後にできることは次のとおりです。

  1. 古いバージョンをマークして、それらに戻ります。
  2. 2つのリポジトリ（安定版と開発版）でチームの作業を整理します。




さて、マニュアルの最後にたどり着きました。 Mercurialのすべての機能を説明することはできませんでしたが、詳細な研究には十分な資料があります。 すべてを非常に詳細に説明する本があります。 ご質問がある場合は、 Kiln Knowledge Exchange Webサイトにご招待します（Kiln専用のStackOverflowのようなもので、このサイトではMercurialに関する質問を歓迎します）。



翻訳者からのコメント：

あなたが私のようにワカモレを見ることに興味があるなら、この料理の調理プロセスを示すビデオがあります。





More articles:


All Articles