この記事は、元の場所http://blogs.collab.net/subversion/reducing_network_traffiic_in_subversion_1-8.からの許可を得てミラーリングされています。無効なリンクは削除または更新されています。

著者: C. Michael Pilato

概要: Subversion 1.7でリリースされたWC-NGを基盤として、リポジトリアクセスモジュールlibsvn_ra_serfは、ファイルの内容がローカルのpristineストアに既に存在する場合、svn switchおよびsvn updateのネットワークトラフィックを大幅に削減できます。

投稿日 2012-10-24

この記事では、執筆時点で開発コードベースで使用可能ですが、公式リリースではまだ公開されておらず、そのようなリリース前に変更される可能性のあるApache Subversionの機能について説明します。

私は、Subversionのスパースチェックアウト機能を非常に気に入っているという事実について、謝罪も隠蔽もしていません。この機能が利用可能になった瞬間、私はローカルのSubversionバージョン管理プロジェクトを、30個ほどのばらばらのトランクとブランチの作業コピーの散らかった状態から、プロジェクトのルートディレクトリをルートとする単一の作業コピーに再編成し、そこから疎に配置しました。

正直に言うと、（少なくとも私にとって）即時のメリットは、ほとんどがソフトなもの、つまり、Subversionが私にとって何をしているかではなく、Subversionの操作の合間に私が何をしているかという、目に見えない改善でした。私のワークスペースはより整理されました。どの作業コピーに何が含まれているかを覚えるのに費やす時間が短縮されました。単一の更新を実行するだけで、自分が関心のあるプロジェクトツリーの部分で何が起こっているかをよりよく把握できるようになりました。これらは、ベンチマークツールや回帰テストスイートで測定できるものではなく、散らかった脳の床の露出表面積の増加率によって測定されます。

Subversion開発者は、Subversion 1.5でスパースチェックアウトをデビューさせ、後続のリリースでそれをいくらか改善しました。たとえば、Subversion 1.6では、既存の作業コピーメンバーを除外、つまり「望遠鏡を解除」する機能が追加されました。これで、不要になったサブツリーを含む作業コピーを破棄して再構築する必要がなくなりました。また、Subversionのマージとマージ追跡機能（後者はSubversion 1.5でも導入されました）も改善され、疎に配置された作業コピーが関係する場合に期待どおりに動作するようになりました。

Subversion 1.7は、Subversion全般に別の有用な改善をもたらしました。作業コピー管理領域の再設計（ストレージメカニズムとプログラミングインターフェイスの両方）は、 partly 新しい機能開発を促進するために行われました。WC-NG（新しい作業コピーの概念と呼ばれています）は、作業コピーメタデータの編成とアクセス方法の大幅な書き換えであり、期待どおり、その特性のいくつかが私の注目を集めました。まず、WC-NGは、バージョン管理されたファイルのキャッシュされたすべてのpristineテキストベースコピーを単一の場所に移動し、SHA-1チェックサムでインデックス付けします。ディスク使用量を最適化するために、同じコンテンツの重複コピーがある場合は、単一のコピーのみが保持されます。私はSubversionのリポジトリとリポジトリアクセス機能の開発をクライアント側の動作よりも多く行ってきたので、私にとって明らかなある種の対称性がありました。Subversionリポジトリ *も* SHA-1チェックサムをキーとするインデックスを使用してファイルコンテンツを追跡し、*も*ファイルコンテンツの特定の「表現」の単一のコピーのみを保持しようとします。次に、WC-NGは、（現在の作業コピー状態に関連付けられていないため）厳密には不要になったpristineテキストベースを先制的にパージしません。むしろ、これらのpristineバージョンは時間の経過とともに蓄積され、ユーザーは `svn cleanup` を実行して、Subversionに保存されたpristineテキストベースと現在の作業コピー状態を調整させて、不要なものを破棄させることができます。

機会を感じて、Subversion 1.7リリースサイクルの終わり頃に、Subversionのmod_dav_svn Apacheサーバーモジュールに、更新（またはチェックアウト、切り替え、マージ、差分など）を求めるクライアントに、推奨または提供するファイルコンテンツのSHA-1チェックサムを通知するように指示しました。 クライアントに。（サーバーはSubversion 1.0以前からこのコンテンツのMD5チェックサムを送信していましたが、プロジェクトとしてSHA-1に変換しようとしています。）クライアントがその情報で何をするかはまだわかりませんでしたが、私や他のSubversion開発者にとっては価値があるように思えました。同じことを感じていました。

Subversion 1.7がリリースされた後、私はついにその空白を埋めることができました。Subversion 1.8は、単一のHTTPリポジトリアクセスモジュールlibsvn_ra_serfで出荷される予定です。HTTP通信に対するSerfのアプローチは、以前のNeonベースのアプローチとは異なり、少数の同期モノリシックリクエストではなく、多数の小さなパイプライン化されたリクエストを使用することを好みます。libsvn_ra_serfを使用して実行されたチェックアウトと更新は、サーバーに更新レポートを要求します。更新プロセスを完了するために、クライアントがサーバーからフェッチする必要があるもののリスト（必要に応じてショッピングリスト）が含まれています。Subversion 1.7では、サーバーにそのショッピングリストに各アイテムに必要なSHA-1チェックサム（類推を続ける場合はUPCコード）を含めるように指示しました。Subversionトランク（別名「1.8-dev」）コードベースでは、libsvn_ra_serfにそのUPCコードを取得し、WC-NGにそのコードを持つファイルが「pristineパントリー」にあるかどうかを尋ね、もしそうなら、ソースをファイルに直接指示しました。サーバーに別のファイルのコピーを要求するのではなく、ローカルのpristineストアからファイルを作成します。（最初の実装の後、libsvn_ra_serfにMD5チェックサムを同じように処理するように指示し、この最適化をサポートされている最も古いSubversionサーバーに対しても効果的に機能させました。）

これはどういう意味ですか？スピード。

HTTP経由で通信するためにSubversion 1.8クライアントを使用する場合、状況によっては、ネットワーク経由でダウンロードするファイルを少なくする（ゼロにすることさえある）ことができます。たとえば、作業コピーを一時的に古いリビジョンにバックデートしてから、以前のリビジョンに再び更新する場合、Subversionはファイルのコンテンツをネットワーク経由でまったくフェッチする必要はありません。バックデート以降に `svn cleanup` を実行していない限り、作業コピー管理領域には、その若いリビジョンのファイルのpristineバージョンがまだ保持されています。同様に、誰かが作業コピーにローカルに持っているファイルの名前変更をコミットした場合、Subversionはその移動されたファイルの内容をネットワーク経由で再度フェッチする必要はありません。これらの内容のコピーは、ローカルのpristineテキストベースストアに既に存在します。

さて、私はこの投稿をスパースチェックアウトについて叫び始めました。どうして？関係は何ですか？Subversionの動作に対するこの小さな変更が実際に輝く可能性があると私が考えるのは、スパースチェックアウトの下にあるからです。pristineデータストアは作業コピーごとであるため、それを使用するリポジトリツリーのセクションが多いほど、そうでなければネットワーク経由でフェッチする必要があるものが見つかる可能性が高くなります。疎に配置された作業コピーを使用すると、プロジェクトの新しいブランチなどを「サブスクライブ」する必要があるときはいつでも、Subversionの新しいファイルコンテンツを取得しない機能は、既存のpristineストア全体を自由に使用できます。Subversionは、作業コピー内の他のブランチまたはタグに他の正確なコピーがないファイルのみをそのブランチでフェッチする必要があります。これは、単一のブランチ専用の、新しくチェックアウトされた作業コピーとは大きく異なります。pristineストアはチェックアウト後まで完全に空であり、Subversionはチェックアウトセット内のすべてのファイルをネットワーク経由でダウンロードすることを強制します。さらに、ブランチまたはその他の特定のサブツリーを除外してから後で復元する必要がある場合、その復元プロセスは、除外される前のそのサブツリーのpristineコンテンツと、作業コピー内の他の場所にある他のすべてのアイテムのpristineコンテンツにアクセスできます。ワイヤ転送に頼る前に、データを取得します。

たとえば、比較的単純でありふれた状況を考えてみましょう。あなたはプロジェクトのトランクに取り組んでおり、ブランチを作成して開発の一部をもう少し分離して行う必要があると判断しましたが、それでもトランクも追跡したいと考えています。過去には、ほとんどの人は

1. `svn copy URL NEW-URL` を使用してブランチを作成します。
2. ブランチの新しい作業コピーをチェックアウトし、それらのすべてのファイルがネットワーク経由で転送されるときにあくびをします。（熟練したSubversionユーザーは、作業コピーディレクトリのローカルOSレベルのコピーを作成し、 `svn switch` を使用してそのコピーを新しいブランチを追跡させることで、これを省略します。）
3. ブランチでの作業を開始します。
4. トランクで発生した変更をブランチに時々同期させ、ファイルのデルタを再びネットワーク経由で転送します。

スパースチェックアウトとpristineストレージソーシングの改善を使用すると、状況は似ていますが、ネットワークトラフィックはそれほど多くありません。

1. `svn copy URL NEW-URL` を使用してブランチを作成します。
2. 疎に配置された作業コピーに新しいブランチを含めるように更新します。新しいブランチのコンテンツはトランクのコンテンツと完全に一致するため、ファイルコンテンツはネットワーク経由でまったく転送されません！
3. ブランチでの作業を開始します。
4. トランクで発生した変更をブランチに時々同期させますが、ブランチで変更されたファイルのファイルデルタのみがネットワーク経由で転送されます。

もちろん、Subversionはこれまでと同様に、アクセス権限にパスベースのアプローチを使用しています。 あるブランチでユーザーがファイルの内容を読めるようになったからといって、リポジトリ内の他の読めない場所に同じファイルが存在することを知ることができるようになったわけではありません。私が行ったのは、クライアントがローカルのpristineキャッシュに既に保持しているファイルの内容を再取得することを回避できるようにしただけです。

Apache Subversionコミュニティは、Subversion 1.8となる開発活動を縮小し始めようとしています。プロジェクトの公開資料（ロードマップページや1.8リリースノートなど。どちらも現在進行中です）をご覧いただき、興味のある機能や拡張機能がないかを確認することをお勧めします。これらの新しい機能のいくつかをテストし、正式リリースされた際に最高の状態になるようにご協力いただければ幸いです。