Hg Init：パート1. Subversionユーザー向けの再トレーニング

Hg Init：Mercurialチュートリアル。

Mercurialは、最新のオープンソース分散バージョン管理システムです。 このシステムは、Subversionのような以前のシステムの魅力的な代替品です。 このシンプルな6部構成のチュートリアルでは、 Joel SpolskyがMercurialの重要な原則について語っています。



Subversionを使用した場合、Mercurialは理解できません。 このパートでは、Mercurialを使用する際の主な違いについて説明します。 Subversionを使用したことがない場合は、 この部分をスキップできます。

パート1. Subversionユーザー向けの再トレーニング

私の会社のプログラマーがSubversionをMercurialに変更することに決めたとき、私はどのような混乱を覚えましたか！



そもそも、何も変更する必要がないという愚かな理由をすべて説明し始めました。 「リポジトリを中央サーバーに保存する必要があります。より安全です」と私は言いました。 知ってる？ 私は間違っていました。 Mercurialを使用する場合、各開発者はハードドライブにリポジトリの完全なコピーを持っています。 実際にはより安全です。 いずれにせよ、Mercurialを使用するほぼすべてのチームには、中央リポジトリも存在します。 そして、このリポジトリを必要なすべての強迫観念でバックアップできます。 また、 サイロン 、 攻撃機、素敵なラブラドゥードルなど、IT部門が必要とする3段階の防御を配置できます。







「分散バージョン管理システムの問題は、分岐が非常に簡単になることです」と私は言いました。 「そして、枝は常に問題をもたらします。」 ここで私も間違っていたことがわかりました。 波は消えました。 Subversionはマージが適切に機能するための十分な情報を保存しないため、Subversionを使用する場合、ブランチに問題があります。 Mercurialでは、マージは痛みがなく簡単であるため、分岐は一般的で無害です。



それから私は言った：「まあ、私はこのシステムを使用するが、私がそれを理解できることを期待しない」。 そして、ジェイコブにチートシートを作ってほしいと頼みました。これは、Mercurialのアナログを使って、通常Subversionで行っていたすべてのことです。



このチートシートを紹介することはできますが、数か月間脳が再構築できなかったため、見せません。



Subversionを使用している場合、頭は少し...ええと、もっと柔らかく言うにはどうでしょうか。 あなたは頭に負傷しています！ いいえ、うまくいきませんでした。 再訓練が必要です。 私は6ヶ月間負傷して歩き回ったが、MercurialはSubversion よりも複雑だと思った。 しかし、これは、新しいシステムが実際にどのように機能するかを理解していなかったためです。 私はそれがどのように機能するかを理解するとすぐに、それが判明しました-おっと！ はい、それは十分に簡単です。



そこで、このマニュアルを書きましたが、頭にはすでに十分な傷があるので、Subversionの用語ですべてを説明しないように一生懸命努力しました。 それらは十分にあります。 代わりに、Subversionを使用してMercurialに切り替える人のために、チュートリアルの冒頭でこのパートを作成しました。



Subversionを使用したことがない場合は、次の記事（ 「Mercurial Basics」 ）にスキップして、お見逃しなく。



準備はいい？ さて、簡単な調査から始めましょう。

質問1：初めて完璧なコードを書くのはいつもですか？

最初の質問に「はい」と答えた場合、あなたは嘘つきであり、詐欺師です。 「バナナ」を手に入れて、もう一度やり直してください。



新しいコードにはバグがあります。 彼がきちんと働き始めるには時間がかかります。 それまでの間、このコードはチームの他の開発者を傷つける可能性があります。



Subversionの仕組みは次のとおりです。

• リポジトリに新しいコードを持ち込むと、誰もがそれを受け取ります。

あなたが書くすべての新しいコードにはバグが含まれているので、あなたには選択肢があります。

• バグのあるコードを作成して、人々を狂わせることができます。
• 完全にデバッグするまで、新しいコードを保持できます。

Subversionは常にこの恐ろしい選択に直面しています。 リポジトリには、書き込まれたばかりの新しいコードが含まれているため、バグのあるコードでいっぱいであるか、書き込まれたばかりの新しいコードがリポジトリに追加されません。



Subversionのユーザーとして、私たちはこのジレンマに非常に慣れているため、このジレンマが存在しないシステムを想像するのは困難です。



Subversionを使用するチームは、多くの場合、数日または数週間リポジトリに何も追加しません。 そのようなチームでは、新参者はビルドを壊したり、主任開発者のマイクを怒らせたり、同様の理由で何かをリポジトリにアップロードすることを恐れています。 マイクはかつてビルドを壊した変更のために非常に怒ったので、彼は訓練生に突進し、彼の机からすべてを払い、「これがあなたの最後の日です！」と叫んだ。 この日は最後ではありませんでしたが、貧しい研修生は実際にズボンを濡らしました。



これらの恐怖と懸念はすべて、バージョン管理システムを利用せずに毎週コードを書いてから、リポジトリにコードを持ち込む経験のある人を探すことを意味します。 そして、なぜリポジトリを使用できないのでしょうか？



Subversionのある生活の簡単な図を以下に示します。









Mercurialを使用する場合、各開発者は自分のコンピューター上に存在する独自のリポジトリを持ちます。









そのため、リポジトリを変更し、いつでもバージョン管理システムのすべての利点を享受できます。 毎回、コードを少し改善して、リポジトリに追加できます。



コードの信頼性が高く、他のユーザーにそのコードを使用させたい場合は、リポジトリから中央リポジトリに変更をプッシュします。 誰もが中央リポジトリから一般的な変更を引き出し、遅かれ早かれ誰もが新しいコードを受け取ります。 彼が準備ができたら。



Mercurialは、コードがリポジトリに入力された瞬間と、他のすべての人が受信した時間を分離します。



そして、それはあなたがコミット（ hg com



）できることを意味しますが、他の誰もあなたの変更を取得しません。 安定したクールな自分に合った変更を蓄積したら、それらをメインリポジトリにプッシュ（ hg push



）します。

別の大きな概念上の違い

どの通りにも名前があることを知っていますか？



まあ、日本ではこれは完全に真実ではないことがわかります。 日本人は通常、通りの間のブロックに番号を付けるだけで、非常に重要な通りだけに名前があります。



SubversionとMercurialには同様の違いがあります。



Subversionはリビジョンで考えます。 リビジョンとは、特定の時点でファイルシステム全体がどのように見えるかです。



Mercurialでは、 一連の変更を検討します。 変更セットは、2つの隣接するリビジョン間の変更の明確なリストです。



それの6つまたは半ダース-違いは何ですか？



それが違いです。 あなたと私が何らかのコードで共同作業していると想像してください。 そして、このコードのブランチを作成し、それぞれが自分の場所に行き、コードに多くの独立した変更を加えたため、ブランチは異なる方向にかなり分岐しました。



マージを行う必要があるとき、Subversionは両方のリビジョン（私の変更されたコードと変更されたコード）を見て、それらを1つの大きな恐ろしい混乱にまとめる方法を推測しようとします。 通常、Subversionは成功せず、競合の長いリスト（「競合のマージ」）を取得します。これは実際には競合ではなく、システムが変更を認識できない場所にすぎません。



比較のために、Mercurialで独立して作業した場合、システムは一連の変更を保存しました。 したがって、コードマージを実行する場合、Mercurialは実際により多くの情報を取得します。システムは各自が変更されたことを認識しており 、最終バージョンを確認してまとめ方を推測する代わりに、 これらの変更を再適用できます一緒に。



たとえば、関数を少し変更してどこかに移動した場合、Subversionは実際にこれを覚えていません。 そのため、マージに関しては、彼女はどこからともなくコードに新しい関数が登場したと判断するかもしれません。 同時に、Mercurialは次のことを記憶します。関数が変更され、関数が移動しました。 これは、この関数も変更した場合、Mercurialが変更を正常にマージする可能性がはるかに高くなることを意味します。



Mercurialは変更セットの観点から考えるので、これらの変更セットを使用して興味深いことができます。 中央リポジトリにこれらの変更を加えて、全員に強制的に使用させる代わりに、友人にこれらの変更を試行させることができます。



これがすべてあなたを少し混乱させるようであれば、心配しないでください。 このマニュアルを読むと、すべてが明確になります。 現時点では、最も重要なことを知っておく必要があります。Mercurialはリビジョンではなくチェンジセットで動作するため、MercurialでのコードのマージはSubversionよりもはるかに優れています。



マージは悪夢ではないため、ブランチを自由に作成できます 。



面白いものを見つけたいですか？ 私が話したメンバーとSubversionを使用するほとんどすべてのチームは、同じストーリーのバージョンを持っています。 ストーリーは非常に一般的であるため、「Subversionメインストーリー」と呼んでいます。 ストーリーは次のとおりです。ある時点で、彼らはコードの開発に分岐を試みました。 通常、顧客に提供されたバージョンを、開発者が忙しいバージョンから分離するために。 そして誰もが、これを行おうとしたとき、合併が必要になる瞬間まですべてがうまくいったと私に言った。 そして合併は悪夢でした。 5分間のプロセスを想定していたものが、1台のコンピューターで6人のプログラマーになり、2週間働いて、安定したブランチから開発者ブランチに各バグ修正を手動で入力しようとしました。



そして、ほぼすべてのチームが「二度と」と誓い、枝を放棄したと私に言った。 そして今、彼らはこれを行います：大きな#ifdef



ブロック内の各新機能。 そのため、リポジトリのトランクでいつでも動作でき、クライアントはデバッグされるまで新しいコードを受け取ることはありません。率直に言って、これはばかげています。



安定したコードと開発コードを分離することは、バージョン管理システムでできることです 。



Mercurialに切り替えると、これに気付かないこともありますが、分岐が再び可能になり、何も恐れる必要がなくなります。



これは、小さなチームのプログラマーが新しい機能に取り組んでいるチームリポジトリがあり、すべての準備ができたら、その変更をメインリポジトリにマージできることを意味します。 そしてそれは動作します！



これは、テスターのチームが新しいコードを試すテストサービスのリポジトリがある場合があることを意味します。 正常に機能する場合、テストサービスは中央リポジトリに変更を加えます。これは、中央リポジトリに常に信頼できるテスト済みコードがあることを意味します。 そしてそれは動作します！



これは、別々のリポジトリで実験を行うことができ、実験が成功した場合、メインリポジトリに変更をマージし、失敗した場合は単に破棄することを意味します。 そしてそれは動作します！

そして最後の大きな概念上の違い

SubversionとMercurialの最後の重要な概念上の違いはそれほど重要ではありませんが、知らない場合は不快な立場に置かれる可能性があります。 ここにあります：



Subversionは基本的にファイルの変更管理システムであり、Mercurialでは、変更管理はすべてのサブディレクトリを含むディレクトリ全体に適用されます。



これは主に次のように現れます。Subversionでは、サブディレクトリにいてリポジトリを変更すると、このサブディレクトリとそのすべてのサブディレクトリから変更のみが行われます。 これにより、別のサブディレクトリからの変更を忘れることがあります。 また、Mercurialでは、すべてのコマンドは常にディレクトリツリー全体に適用されます。 コードがc：\ codeにある場合、 hg commit



を実行すると、 c：\ codeまたは任意のサブディレクトリに配置できます -結果は同じになります。



これはそれほど重要ではありませんが、会社全体に1つの巨大なリポジトリを使用することに慣れている場合は、一部の人々はそれらに関係する特定のサブディレクトリのみで作業します。Mercurialを使用する場合、これは最善の方法ではないことを知ってください。 各プロジェクトには多くの小さなリポジトリを用意する方が良いでしょう。

そして最後に...

さて、あなたはただ私の言葉を受け入れなければならない部分です。



MercurialはSubversionよりも優れています。



チームでコードを作成する方が良いでしょう。 コードだけで作業する方が良いでしょう。



ちょうど良い 。



そして、Mercurialの仕組みとMercurialの仕組みを理解し、このシステムに苦労せず、Subversionで行ったようにMercurialですべてをやろうとせず、代わりに学ぶなら、私の言葉を覚えておいてください。 Mercurialがあなたに期待するように動作します。あなたは幸せで、成功し、栄養が豊富で、いつでもテレビからリモコンを見つけることができます。



そして最初は、Mercurialを終了してSubversionに戻るという考えに誘惑されます。 まるで外国に住んでいるかのように奇妙であり、故郷に引き戻され、Mercurialの作業コピーがスペースを取りすぎると宣言するなど、あらゆる種類の言い訳が出てくるからです。実際、それらはSubversionよりも少ないスペースを使用します。 これは本当です！



そして、Subversionと同じ方法でブランチを作成しようとして混乱したため、Subversionに戻ります。Mercurialのようにブランチを作成する必要があり、リポジトリのクローンを作成しました。 Subversionでどのように機能し、Mercurialで受け入れられた方法を学ぶことができます。



その後、Jacob、またはそこにいるJacobに相当する人に、MercurialにSubversionのチートシートを渡してもらい、 hg fetch



はsvn up



ようなもので、実際には理解できないと考えて3か月を費やしますそのhg fetch



が行われ、いつかすべてがうまくいかず、Mercurialのせいになりますが、Mercurialの仕組みを理解していないことを自分で責めるべきです。



あなたがそうすることを知っています、なぜならそれが私がしたことだからです。



同じ間違いをしないでください。 Mercurialを学び、それを信頼し、そのスタイルですべてを行う方法を見つければ、バージョン管理システムの分野で世代全体を前進させることができます。 競合他社は、ベンダーがライブラリを更新した後に生じた競合を解決するために1週間を費やしますhg merge



、 hg merge



と入力して、「ああ、かっこいい、うまくいった」と言います。そして、マイクはリラックスして、研修生と枠を共有し、春になると、近くの大学の若者がダウンジャケットを短い破れたTシャツに交換し、生活が良くなります。



ここに続きます：

Hg Init：パート2：Mercurialの基本