Amazon S3でGitとMercurialリポジトリを拡張する

確かに、あなたの多くは、バージョン管理システムはバイナリファイル、大きなファイル、特に大きなバイナリファイルとは仲が悪いことをあなた自身の経験から聞いたり知っています。 以下、MercurialやGITなどの人気のある分散バージョン管理システムについて説明します。



多くの場合、それは重要ではありません。 これが理由か結果かはわかりませんが、バージョン管理システムは主に比較的小さなテキストファイルの保存に使用されます。 時にはいくつかの写真やライブラリ。



プロジェクトで高解像度の多数の画像、サウンドファイル、ソースファイル、グラフィック、3D、ビデオ、またはその他のエディターを使用している場合、これは問題です。 通常、これらのファイルはすべてサイズが大きく、バイナリです。つまり、バージョン管理システムとホスティングリポジトリのすべての利点と便利さは、関連するすべてのサービスとともに利用できなくなります。



次に、バージョン管理システムとAmazon S3（クラウドファイルストレージ）の統合例を見て、両方のソリューションを活用し、欠点を補います。



ソリューションはC＃で記述されており、Amazon Web Services APIを使用し、Mercurialリポジトリのセットアップ例を示しています。 コードは開いており、リンクは記事の最後にあります。 すべてが多かれ少なかれモジュール方式で記述されているため、Amazon S3以外のサポートを追加することは難しくありません。 GITのセットアップも同様に簡単になると思います。



だから、それはすべてアイデアから始まりました-バージョン管理システムとリポジトリ自体との統合後、ユーザーからの追加のアクションを必要とせずに完全に気付かれずに動作するプログラムが必要です。 魔法みたい。



バージョン管理システムとの統合は、いわゆるフック（独自のハンドラーを割り当てることができるイベント）を使用して実装できます。 データの受信または別のリポジトリへの送信時に起動されるものに関心があります。 Mercurialには、着信および発信と呼ばれる必要なフックがあります。 したがって、イベントごとに1つのコマンドを実装する必要があります。 1つは更新されたデータを作業フォルダーからクラウドにダウンロードするためのもので、もう1つはリバースプロセスのためのものです。更新をクラウドから作業フォルダーにダウンロードするためのものです。



リポジトリとの統合は、メタデータファイルまたはインデックスファイル、または任意の方法を使用して実行されます。 このファイルには、すべての監視対象ファイルの説明、少なくともそれらへのパスが含まれている必要があります。 そして、この特定のファイルはバージョン管理下に置かれます。 監視対象のファイル自体は、無視されるファイルのリストである.hgignoreにあります。それ以外の場合、このベンチャーの要点はすべて消えます。

リポジトリ統合

メタデータファイルは次のようになります。

<?xml version="1.0" encoding="utf-8"?> <assets> <locations> <location>Content\Textures</location> <location>Content\Sounds</location> <location searchPattern="*.pdf">Docs</location> <location>Reference Libraries</location> </locations> <amazonS3> <accesskey>*****************</accesskey> <secretkey>****************************************</secretkey> <bucketname>mybucket</bucketname> </amazonS3> <files> <file path="Content\Textures\texture1.dds" checksum="BEF94D34F75D2190FF98746D3E73308B1A48ED241B857FFF8F9B642E7BB0322A"/> <file path="Content\Textures\texture1.psd" checksum="743391C2C73684AFE8CEB4A60B0317E634B6E54403E018385A85F048CC5925DE"/> <!--        --> </files> </assets>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルには、場所、amazonS3、およびファイルの3つのセクションがあります。 最初の2つはユーザーが最初に設定し、最後の2つはプログラム自体がファイル自体を追跡するために使用します。



場所は、追跡ファイルが検索されるパスです。 これらは、絶対パスまたはこのxml設定ファイルへの相対パスです。 バージョン管理システムの無視ファイルに同じパスを追加して、それ自体がそれらを追跡しようとしないようにする必要があります。



AmazonS3は、ご想像のとおり、クラウドファイルストレージ設定です。 最初の2つのキーはアクセスキーで、AWSユーザー用に生成できます。 Amazon APIリクエストに暗号で署名するために使用されます。 Bucketnameはバケットの名前です。バケットは、ファイルとフォルダーを含めることができ、監視対象ファイルのすべてのバージョンを保存するために使用されるAmazon S3内のエンティティです。



このセクションは、リポジトリでの作業中にプログラム自体によって編集されるため、ファイルを構成する必要はありません。 現在のバージョンのすべてのファイルのリストとパスとハッシュが含まれます。 したがって、pullと一緒にこのxmlファイルの新しいバージョンを取得し、Filesセクションの内容を監視対象フォルダー自体の内容と比較すると、どのファイルが追加され、どのファイルが変更され、どのファイルが単に移動または名前変更されたかを理解できます。 プッシュ中、比較は反対方向に実行されます。

バージョン管理システムとの統合

チーム自体についてです。 このプログラムは、プッシュ、プル、ステータスの3つのコマンドをサポートしています。 最初の2つは、対応するフックを設定するためのものです。 ステータスは、監視対象ファイルに関する情報を表示し、その出力はhg statusの出力に似ています-どのファイルが作業フォルダーに追加され、変更、移動され、どのファイルがそこにないかを理解するために使用できます。



pushコマンドは次のように機能します。 最初に、xmlファイル、パス、およびハッシュから監視対象ファイルのリストを取得します。 これは、リポジトリに記録される最後の状態になります。 次に、作業フォルダーの現在の状態に関する情報（すべての監視対象ファイルのパスとハッシュ）が収集されます。 これは、両方のリストの比較です。



4つの異なる状況があります。

1. 作業フォルダーには新しいファイルが含まれています。 これは、パスまたはハッシュによって一致するものがない場合に発生します。 その結果、xmlファイルが更新され、新しいファイルに関するレコードが追加され、ファイル自体がS3にアップロードされます。
2. 作業フォルダーには、変更されたファイルが含まれています。 これは、パスに沿って一致するが、ハッシュ一致がない場合に発生します。 その結果、xmlファイルが更新され、対応するレコードのハッシュが変更され、ファイルの更新されたバージョンがS3にロードされます。
3. 作業フォルダーには、移動または名前変更されたファイルが含まれます。 これは、ハッシュの一致がある場合に発生しますが、途中で一致するものはありません。 その結果、xmlファイルが更新され、対応するレコードのパスが変更され、S3に何もロードする必要がありません。 実際のところ、S3にファイルを保存するためのキーはハッシュであり、パス情報はxmlファイルにのみ記録されます。 この場合、ハッシュは変更されていないため、S3で同じファイルをリロードしても意味がありません。
4. 追跡されたファイルは、作業フォルダーから削除されます。 これは、xmlファイルのエントリのいずれかがローカルファイルのいずれとも一致しない場合に発生します。 その結果、このエントリはxmlファイルから削除されます。 S3の主な目的は、すべてのバージョンのファイルを保存して、任意のリビジョンにロールバックできるようにすることであるため、S3から何も削除されません。

考えられる5番目の状況があります-ファイルは変更されていません。 これは、パスとハッシュの両方に一致する場合に発生します。 この状況では、アクションは不要です。



pullコマンドは、xmlのファイルのリストをローカルファイルのリストと比較し、まったく同じように機能しますが、反対方向にのみ機能します。 たとえば、xmlに新しいファイルに関するエントリが含まれている場合、つまり、パスにもハッシュにも一致しない場合、このファイルはS3からダウンロードされ、指定されたパスにローカルに書き込まれます。



フックが構成されたhgrcの例：

 [hooks] postupdate = \path\to\assets.exe pull \path\to\assets.config \path\to\checksum.cache prepush = \path\to\assets.exe push \path\to\assets.config \path\to\checksum.cache
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ハッシング

S3へのアピールは最小限に抑えられます。 GetObjectとPutObjectの2つのコマンドのみが使用されます。 ファイルは、新しいファイルまたは変更されたファイルである場合にのみ、S3からダウンロードおよびダウンロードされます。 これは、ファイルハッシュをキーとして使用することで可能です。 つまり、物理的にすべてのファイルのすべてのバージョンが、階層もフォルダーもまったくないS3バケットにあります。 明らかなマイナス-衝突があります。 2つのファイルのハッシュが同じ場合、そのうちの1つに関する情報はS3に記録されません。



ハッシュをキーとして使用することの利便性は、潜在的な危険よりも重要なので、それらを放棄したくありません。 衝突の可能性をできるだけ考慮に入れ、それを可能な限り減らし、結果がそれほど致命的ではないようにすることだけが必要です。



確率を減らすには非常に簡単です-より長いキーを持つハッシュ関数を使用する必要があります。 私の実装では、SHA256を使用しましたが、これで十分です。 ただし、これはまだ衝突の可能性を排除しません。 変更を行う前に、それらを定義できる必要があります。



これも難しいことではありません。 すべてのローカルファイルは、プッシュコマンドとプルコマンドを実行する前に既にハッシュされています。 ハッシュ間に一致があるかどうかを確認するだけです。 リポジトリで衝突が修正されないように、プッシュ中にチェックを行うだけで十分です。 衝突が検出されると、ユーザーにこの問題が通知され、2つのファイルのいずれかを変更してもう一度プッシュするように求められます。 そのような状況の可能性が低いことを考えると、このソリューションは満足のいくものです。

最適化

このようなプログラムには、厳密なパフォーマンス要件はありません。 1〜5秒間機能しますが、それほど重要ではありません。 ただし、考慮することができるおよび考慮すべき明らかな場所があります。 そしておそらく最も明白なのはハッシュです。



選択したアプローチでは、実行時にすべてのコマンドが監視対象ファイルすべてのハッシュを計算する必要があると想定しています。 ファイルが数千の場合、またはファイルの合計サイズが1ギガバイトを超える場合、この操作には1分以上かかることがあります。 1分間のハッシュの計算は許されないほど長いです。



リポジトリの一般的な使用では、プッシュの直前にすべてのファイルを変更する必要がないことに気づいた場合、ソリューションは明らかになります-キャッシング。 私の実装では、パイプで区切られたファイルを使用することに決めました。このファイルはプログラムの隣にあり、以前に計算されたすべてのハッシュに関する情報を含みます。

   | |  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルは、コマンドが実行される前にロードされ、プロセスで使用され、コマンドの実行後に更新および保存されます。 したがって、logo.jpgファイルのハッシュが1日前に最後に計算され、ファイル自体が3日前に最後に変更された場合、そのハッシュを再計算する意味はありません。



最適化は、元のFileStreamの代わりにBufferedStreamを使用して、ハッシュを計算する読み取りを含むファイルを読み取るためのストレッチと呼ばれることもあります。 テストでは、合計サイズが1ギガバイトを超える1万個のファイルのハッシュを計算するために、バッファーサイズが1メガバイト（FileStram 8キロバイトの代わり）のBufferedStreamを使用すると、標準HDDのFileStreamに比べてプロセスが4倍速くなることが示されました。 ファイルがそれほど多くなく、ファイル自体が1メガバイトより大きい場合、その差はそれほど大きくなく、約5〜10パーセントになります。

Amazon s3

ここでは、2つのポイントを明確にする価値があります。 最も重要なことは、おそらく問題の価格です。 ご存知のように、新しいユーザーの場合、制限を超えなければ最初の1年間の使用は無料です。 制限は次のとおりです。5ギガバイト、1か月あたり20,000のGetObject要求、1か月あたり2,000のPutObject要求。 全額を支払うと、1か月で約1ドルの価値があります。 このために、地域内のいくつかのデータセンターの予約と高速を取得します。



また、読者が最初から次の質問に苦しめられていることを敢えて示唆します。Dropboxがある場合、なぜこのバイクなのでしょうか。 実際には、Dropboxを直接コラボレーションに使用するのは面倒です-競合にまったく対処しません。



しかし、直接使用しない場合はどうなりますか？ 実際、上記のソリューションでは、Amazon S3を同じDropbox、Skydrive、BitTorrent Syncまたは他のアナログに簡単に置き換えることができます。 この場合、それらはファイルのすべてのバージョンのリポジトリとして機能し、ハッシュはファイル名として使用されます。 私のソリューションでは、これはAmazonS3RemoteStorageの類似物であるFileSystemRemoteStorageを通じて実装されています。



約束のソースリンク： bitbucket.org/openminded/assetsmanager