SubversionとMercurial（HG）の比較

バージョン管理システムを初めて知ったのは学校に戻ったときです。 それはSubversionでした。 その時、彼の強さと能力に非常に感銘を受けました。 しかし、時間が経ちました。 ファイルやディレクトリなどの名前を変更するのはあまり楽しい瞬間ではありませんでした（はい、長いライブsvn 1.5、1.6およびその永遠のフォルダ.svn）。 そして、ある日、バージョン管理システムの変更について考えていなかったら、すべてが同じ流れで続いていたでしょう。 すべてが予想外に素早く起こり、Mercurialが私の目の前に現れました。 その機能について読み、経験豊富なヒントを求めなければなりませんでしたが、今では同僚が新しいツールの動作と動作を理解するのを助けました。 Hgを知るようになればなるほど、それが好きになり、むしろ、バージョン管理への分散型アプローチが好きになりましたが、Subversionは必然的に背景に消えていきました。

しかし、新しい職場で再びSubversionを思い出さなければなりませんでしたが、率直に言って、私は幸せになれませんでした。 幸いなことに、これは会社の無条件のポリシーではなく、特に一部の従業員がGitを選択して正常に作業していることを考えると、代替手段を提供することは非常に可能です。 したがって、小さなことは、分散型バージョン管理システム（GitまたはMercurial）を使用する利点を明確に示すことですが、個人的な経験から、Hgについて話すことにしました。 実際、この記事は、バージョン管理システムの比較と変更を目的として、私が保持しているラウンドテーブルの要約です。





どのバージョン管理システムが優れているかについては多くの意見があります。 もちろん、それぞれの意見には賛否両論があります。 ただし、少なくとも最も単純なシナリオを考えてみましょう。2人以上がプロジェクトに取り組んでおり、プロジェクトがさらにサポートと開発を必要とする場合（たとえば、ライブラリとして）、svnに保存すると、Mercurialに保存するよりもはるかに面倒です

Mercurialを他の機能と区別する特定の機能に移りましょう。



1. svn commitとは異なり、hg pushコマンドを使用すると、プロジェクト内の何かを変更してサーバーにこれらの変更をコミットしたかどうかを常に確認できます。



svn commit-ローカルの変更をリモートサーバーに送信するコマンド。 それは原子的に起こります。 ただし、変更されたファイルの基になっているバージョンがリモートサーバー上の最後ではない場合にのみ失敗します。 つまり、ディレクトリにa.txtとb.txtという2つのファイルがあり、b.txtのみを変更し、Petyaのみをa.txtファイルに変更した場合、commitコマンドは正常に完了し、svn updateコマンドを実行しなければ（すべてのファイルを更新します）最新バージョンへのディレクトリ）、あなたはそれについて知りません。 Svnは、プロジェクトフォルダーからのコミット（およびチェックアウト）もサポートしています。 このため、あるフォルダーでコミットした場合、別のフォルダーでの変更についてはわかりません。



hg push-hg commitコマンドで以前に行われた一連の変更を送信するためのコマンド。 最後のコマンドは、リポジトリの現在の状態をキャプチャしますが、完全にローカルで実行します。 hg pushコマンドが実行された場合にのみ、変更がリモートサーバーに送信されます。 これは変更を転送するためのコマンドであるため、リポジトリ全体に完全に拡張されます。 したがって、このコマンドを使用すると、リポジトリの状態全体が完全に記録されます。 そして、誰かがあなたの前にプッシュすることができた場合、この状況はクローバーとして扱われ、デフォルトでは、hg pushは失敗し、あなたのアクションはリモートストレージに新しいヘッドを作ると言います。

完全を期すために、頭を定義しましょう。 これは、それ自体がこのブランチの他のリビジョンの親ではないリビジョンです。 ポリヘッド-1つのブランチに複数のヘッドがある状況。

誰かが先を行ったときの状況に戻りましょう。 エラーが返されたら、hg pullコマンドを実行する必要があります。これにより、不足しているすべてのリビジョンがローカルストレージにプルされます。 繰り返しますが、このアクションがファイルに影響を与えることはありません。 それらのどれも変更されません。 このコマンドは、まだ持っていない変更のリストを履歴に追加するだけです。 したがって、リポジトリ内の現在の状況を視覚化すると、多くのヘッドが形成されていることがわかります。 ローカルストレージの多面体は怖くない。 結局のところ、私たち自身がそれを作りました。 リモートストレージで同じ状況を作成し、誰かが彼を説得することができれば、はるかに危険です。 この人は、どのバージョンが最も関連性があり、どのように作業するかを理解できなくなります。 彼は走り始め、悲鳴を上げ、これがすべて複雑すぎて理解できないとcurります。 したがって、現在の状態でプッシュすることは絶対にしないでください（Mercurialでは、hg push --forceコマンドを使用してのみこれを行うことができます。 したがって、2つの目標のマージを実行し、Mercurialが安全にリモートサーバーにアップロードできる目標を取得する必要があります。



そして、なぜこれが重要なのか。 何らかの理由で別の開発者が一般的なコンポーネント（ロジック、インターフェイス、またはその他）を変更し、それについて知らなかった場合、svnの場合、リモートリポジトリに誤ったコードまたはコンパイルされていないコードさえ含まれている可能性があります。 同時に、最初のそのような横棒は非常に迅速に検出できます（それでも、時々svn updateを行い、コンパイルを開始しますよね？）、しかし、別の横棒の発見はテストにドラッグできます。 Mercurialのロジックにより、変更についてすぐに学習し、マージですべてのチェックを一度に実行できます。 もちろん、作業と並行して変更されたものに関心がなかった場合、svnと同じ状況になるリスクがありますが、1つの違いがあります-最初の場合はこれについても知らず、2番目に得点します。

人がsvn commitコマンドの前にsvn updateコマンドを作成せず、コードをチェックしない場合、彼は有罪であり、ここにプラスはないと主張することができますが、これは間違った意見です。 svnの一連の更新/コミットコマンドはアトミックではありません。hgpushはアトミック操作であり、これにより人生が大幅に簡素化されます。



2. pull、mergeコマンドを使用すると、svn updateとは異なり、リモートサーバーへの転送を管理していない状態を失うことはありません。



これについてはすでに言及しました-プルを使用すると、ファイルを変更せずに、履歴に対する以前は不明な一連の変更を取得できます。 また、Mercurialのマージはローカルおよびローカルリビジョンで行われるため、これらのリビジョンはどこにも失われません。 必要に応じて、いつでもマージ結果を削除して再度実行するか、すべてのプル/マージの前にあったリ​​ポジトリのバージョンに完全にロールバックできます。 SVNでは、これは非現実的です。 作業コピーからsvn updateを実行すると、変更されていない、新しい、自動的に連続するファイル、競合ファイル、および変更した通常のファイルの寄せ集めができます。 この場合、svn update以前の状態をリポジトリに戻すことはできません。 まさか。



3.別の小さなバン-Mercurialのリポジトリの任意のバージョンに数秒でロールバックします。 唯一の制限は、ローカルコピーがクリーンである必要があることです（コミットされていない変更はありません）。 これは、hg updateを使用して目的のリビジョンを指定して実行できます。 同時に、すべての履歴がローカルにあるため、リモートサーバーに接続する必要はありません。 svnでは、これはリモートサーバーでのみ、目的のリビジョンでリポジトリを再度ダウンロードすることによってのみ実行できます。



4.アプリケーションで何かを緊急に行う必要があることがよくあります。 たとえば、彼らはあなたに駆けつけて来て、緊急にビルドを取得したいと思っています（私はモバイル開発に携わっているので、ビルドサーバーがありますが、これは起こります）。 そして、あなたはある種の素晴らしい機能をカットしているので、あなたのプロジェクトは完全に台無しにされています。 SVNでは、最後のリビジョンからすべての種類をダウンロードするか、コードを多少動作する状態にロールバックするか、今はできないと言う必要があります。 すべてのオプションはまあまあで、通常はかなり時間がかかります。 分散型バージョン管理システムでは、ローカルコミットを行ってから、作業バージョンのコードにロールバックしてプロジェクトをビルドできます。 この場合、その後は、混乱する前のリポジトリの状態に正確に戻ります！



5.別の一般的な発生は、ライブラリプロジェクトの開発です。 そして、長い間書かれていて、外部svnによって接続されたライブラリを使用するプロジェクトをビルドするように予期せずに要求された場合、大きな問題が発生する可能性があります。 古いライブラリを使用しているため、単にアセンブルされていない可能性があります。古いライブラリを使用して、書き換えや再構築などを行うことができました。 唯一の解決策は、このプロジェクトが機能するリビジョンを探し、ライブラリをコピーアンドペーストすることです。 このような可能性の可能性は時間の増加とともに指数関数的に減少するため、新しいバージョンのライブラリをサポートするための小さなプロジェクト完了オプションは考慮していません。 Mercurialにはサブリポジトリの概念があります。これは、リポジトリ自体だけでなく、その特定のバージョンも指します。 したがって、プロジェクトが動作しているライブラリのバージョンを常に把握しており、その変更を恐れることはできません。



6. hgですでにブランチについて言及しました。 svnでブランチがどのように実装されているかを思い出してください。 これらは、リポジトリの完全なコピーを含む単なるフォルダーです。 バージョン1.5以降、このようなファイルの履歴が表示されますが、これらはまだフォルダーとファイルにすぎません。 それらを使用するには、命名とコンテンツに関する特別な規則を順守する必要があります。 Mercurialでは、ブランチはリポジトリの名前付き状態とその変更です。 また、ブランチで作業する場合、すべてが同じブランチで作業する場合とまったく同じです。 はるかに簡単です。



7.ポイント6と同様に、タグについて話すことができます。



8.最後に、コミットの履歴について述べたいと思います。 svnで純粋に単純であり、実際には10ではなくリビジョン2に基づいていて、3から10で何が起こっているのかわからなかったと言うことは不可能です。ただし、コミットは11でなければなりません。バージョン2リポジトリで作業し、リビジョン10でコミット3を行い、その後でのみ変更3を行ったことを確認します。このようなデータは、重要なイベントを追跡する場合に重要です。



記事をまとめると、私はMercurialを使っている間ずっと、その短所に名前を付けることができないことに注意したいと思います。 一部は速度に問題があり、一部はサーバーへの変更をコミットするcommit / pushコマンドの複雑さに起因します。 私にとっては、速度の特別な遅れに気づかなかったのでこれは問題ではありません（もちろん、リポジトリの巨大なサイズがありましたが、これらは人生の小さなものです）、そして2番目は習慣の問題です。



一般に、リストされているMercurialの利点の一部は、他の分散型バージョン管理システムに移行できます。 そしてこの記事では、私自身が経験した例として、Mercurialに基づいて、このようなシステムを使用する主な利点をすべて収集したいと思います。 あなたが選択の苦痛を経験しなければならないならば、私はこの記事が役に立つことを望みます。



ps最後に、Gitに切り替えることにしました=）