写真のGit。 Gitの大規模リポジトリ

gitを使用してすべての写真を保存するという考え方です。

何を達成したいですか？

1. 写真を1つのヒープ（DCIM）にダンプし、写真をフォルダーに分類する時間があります。
2. 1台のコンピューターから写真を捨てて、別のコンピューターで操作します。
3. すべてのコンピューターで魔法のように同期された写真とフォルダーの名前を変更します。
4. 写真を編集できるように、元の写真を復元できるようにします。
5. 編集の履歴を保持します。

判明したように、GITはこのタスクに対処するのが非常に困難です。

結果の構成、簡単に

ディレクティブのみが必要な場合は、最後の段落を参照してください。



クライアントでは、追加コマンドとコミットコマンドを高速化するために、アーカイブをオフにする必要があることがわかりました。 サーバーでは、アーカイブを無効にすることに加えて、メモリの使用を制限し、オブジェクトのパック/アンパックのポリシーを調整する必要があります。

sshを介したクローン作成はかなり遅く、サーバー上に多くのリソースを必要とします。 したがって、そのようなリポジトリーの場合は、「ダム」httpプロトコルを使用することをお勧めします。 さらに、次のようにgitを最新バージョンに更新する必要があります。 1.7.1にはメモリの問題があります。

*.* -delta



を.gitattributes



に記述することはまだ可能.gitattributes



、これはデルタパッケージングを無効にします。 つまり exifデータのみが変更された場合でも、ファイルはリポジトリ全体にコピーされます。 ここではこのアプローチを検討していません。

詳細

サーバーで作業するために、gitoliteを選択しました。 これは、リポジトリを管理するためのgitのラッパーです。 概して、野生のレポジトリのためにのみ-リポジトリはオンデマンドで作成されます。 しかし、リポジトリ内の設定を規定する彼の能力も有用でした。

Gitoliteのインストール

サーバー上

 useradd git su - git git clone git://github.com/sitaramc/gitolite gitolite/install -to $HOME/bin gitolite setup -pk sam.pub
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4.8章のすべての本で説明されています。



gitoliteの構成はクライアントで行われます。 gitolite-adminのクローンを作成し、変更を加え、コミットし、プッシュします。 野生のリポジトリを設定する-このようなブロックをgitolite-admin/conf/gitolite.conf

 # Repos to store photos, with name like 'Fotos-2013-03-13' repo Fotos-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] C = sam RW+ = CREATOR RW = WRITERS R = READERS
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の実験（3.7ギガバイトの写真をGitに追加）

空のリポジトリのクローンを作成した後、最初の.gitignore



1行のThumbs.db



を含む.gitignore



ファイルが追加されました。

2番目のコミットでは、3.7ギガバイトのボリュームを持つ367ファイルのフォルダーが追加されました。

jpg-439メガバイトの293枚の写真

aviで37本のビデオ-3.26ギガバイト

37 THMファイル-0.3メガバイト

 git clone git@my-server:Fotos-2013-03-01 cd 2013-03-01 echo Thumbs.db > .gitignore git add .gitignore git commit -m 'Initial commit' git add <> #  4  46  git commit #  47  git push --all #  23  50 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

9分間のプッシュでローカルコンピューティングが実行され、その後14分間で転送されました。

二回目の実験

アイデアは、ビデオや写真を圧縮しないようにgitを調整することです。 見つからなかったファイルの種類ごとにオフにする方法、圧縮を完全に無効にする必要がありました。

空のリポジトリを複製して構成します。



クライアントで

 git clone git@my-server:Fotos-2013-03-02 cd 2013-03-02 git config core.bigFileThreshold 50m git config core.looseCompression 0 git config pack.compression 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのコマンドは、設定をローカルに保存します（現在のリポジトリ、つまり.git / configファイルに）

core.bigFileThreshold



-50メガバイト（デフォルトでは512メガバイト）を超えるファイルの部分的な変更（デルタ）の検索を無効にします

core.looseCompression



による「緩い」状態のオブジェクトのパッキングを無効にします。

pack.compression



パックされた状態のオブジェクトのアーカイバによるパッケージ化を無効にします。



クライアントで

 git add <> #  2  16  git commit #  47  git push --all #  7  20  #   2  43   4  37  .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーでプッシュコマンドを実行した後、リポジトリに追加の設定が含まれていませんでした（そうする必要があります）。 ローカルリポジトリは緩い状態のままでしたが、サーバーに圧縮されていました。 しかし、パケットサイズは3.7ギガバイトでした。 サーバーにpack.packsizelimit = 2gの設定はありませんでした（ただし、保存もされませんでした）。

sshで1つのパッケージに3.7Gリポジトリを複製する

 git clone git@my-server:Fotos-2013-03-02 #  46 .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クローン作成後、リポジトリはパックされ、パッケージのサイズは3.7ギガバイトでしたが、ローカルインストールでは2ギガバイトでした

クライアントで

 git config --system -l | grep packsize pack.packsizelimit=2g
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー移行

パケットのサイズの制限がない、bigFileThreshold、およびデルタを検索するためのメモリの使用に関する制限がないため、サーバーが対処していない（スワップで窒息している）という仮定。

サーバーでリポジトリを再パックしようとしました。 サーバーにインストール

 git config --system pack.packsizelimit 2g
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、再びサーバー上で起動しました

 git repack -A
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、最大2ギガバイトのサイズのパッケージが作成されましたが、巨大なパッケージは削除されませんでした。 ガベージを収集しようとすると、メモリ不足から落ちた、またはスワップで窒息しました。 一般に、システム設定を削除し、各リポジトリに登録することにしました。

新しい写真リポジトリに次のように記述します

 core.bigFileThreshold = 50m #       core.looseCompression = 0 #      pack.compression = 0 #      pack.depth = 10 #   10 ( 50)     pack.deltaCacheSize = 128m # -         pack.packSizeLimit = 2g #     pack.windowMemory = 128m #       transfer.unpackLimit = 2147483647 #   push       N  gc.auto = 300 #    300  ,  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらすべてを写真の各リポジトリに書き込みます。 これを行うには、gitoliteを構成します。

構成を追加する前に、 .gitolite.rc



ファイルで構成パラメーターを有効にする必要があります。 ここに行があります

 GIT_CONFIG_KEYS => '.*',
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これがgitolite configの外観です。

 # Repos to store photos, with name like 'Fotos-2013-03-13' repo Fotos-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] C = sam RW+ = CREATOR RW = WRITERS R = READERS config core.bigFileThreshold = 50m #       config core.looseCompression = 0 #      config pack.compression = 0 #      config pack.depth = 10 #   10 ( 50)     config pack.deltaCacheSize = 128m # -   ,     config pack.packSizeLimit = 2g #     config pack.windowMemory = 128m #       config transfer.unpackLimit = 2147483647 #   push       N  config gc.auto = 300 #    300  ,  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

大きなtransfer.unpackLimit



指定しない場合、3.7ギガバイトを含むプッシュを受け取ったgitは、1つのパッケージを残します。 pack.packSizeLimit = 2g



という制限にもかかわらず。

gc.auto 300



では、サーバー上のリポジトリにgc.auto 300



ルーズオブジェクトが蓄積されないようにする必要があります。 「 git gc --auto



」が機能する場合、長時間フリーズしません。 デフォルトでは、 gc.auto = 6700



です。

3番目の実験

新しい空のリポジトリを複製し、必要な設定がその中のサーバーに登録されていることを確認します。

お客様

 git clone git@my-server:Fotos-2013-03-03 cd 2013-03-03
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー

 cd repositories/Fotos-2013-03-03 cat config
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リポジトリのクライアントコピーはデフォルトで設定されます。 したがって、3.7ギガバイトの写真を追加する前に、再度構成する必要があります

お客様

 git config core.bigFileThreshold 50m git config core.looseCompression 0 git config pack.compression 0 #   git add <folder> #   2.5  #   git commit #   45  #    git push --all # 22.5  #     7.5 ,  15 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントとサーバーの両方がゆるいリポジトリを残しました。

sshを介して新しいリポジトリのクローンを作成しようとして失敗しました。 サーバー側では、git 1.7.1がメモリ不足でクラッシュしました。

3番目の実験の継続。

更新後、gitはメモリから落ちなくなりました。 しかし、クローン作成の最初に、すべてのメモリを選択しました-1ギガバイト、転送の開始後、250メガバイトに減らしました。

クローン作成自体は48分かかりました。 また、クライアントでは、リポジトリに3.7ギガバイトのサイズの1パックが含まれていました。

フェッチ用の静的HTTP

アイデアは、リポジトリをダウンロードするときにサーバーでの作業を拒否することです。

幸いなことに、gitはhttpを介してフェッチできます。 必要なのは、各リポジトリの更新後にgit update-server-info



です。 これは通常、フック/更新後で行われます。 そして、gitのこのフックの例でさえ、まさにこのコマンドを含んでいます。

例を挙げて、このフックをすべてのリポジトリに登録するようにgitoliteを構成します。

サーバー上

 cp repositories/testing.git/hooks/post-update.sample .gitolite/hooks/common/post-update gitolite setup --hooks-only
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、次の更新後、リポジトリがhttpで利用可能になります。

http設定の詳細を掘り下げないために、「おもちゃ」のWebサーバーを使用します。 フォルダー/home/git/http-root



作成します。 git->../repositories



を git->../repositories



追加し git->../repositories



。 そして、そこから「おもちゃ」サーバーを起動します

サーバー上

 python -m SimpleHTTPServer > ../server-log.txt 2>&1 &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントで

 git clone http://my-server:8000/git/Fotos-2013-03-05.git
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ランタイム4分！ 4分で3.7ギガバイト！ それは私たちに合っています。

おわりに

Gitで大規模なリポジトリを提供するには、httpを介してCloneとFetchを実行する必要があります。 多数の設定を規定し、できればgitを更新します。



サーバーリポジトリ

• git config core.bigFileThreshold 50m
  
  
  
  ＃ビデオのデルタを検索しない
• git config core.looseCompression 0
  
  
  
  ＃緩いオブジェクトをアーカイブしないために
• git config pack.compression 0
  
  
  
  ＃パックされたオブジェクトをアーカイブしない場合
• git config pack.depth 10
  
  
  
  ＃50個では​​なく10個のオブジェクトのみを使用して、デルタを検索します
• git config pack.deltaCacheSize 128m
  
  
  
  ＃デルタのキャッシュのある種はスワッピングにつながる可能性があります
• git config pack.packSizeLimit 2g
  
  
  
  ＃最大パケットサイズ制限
• git config pack.windowMemory 128m
  
  
  
  ＃パッケージのメモリ制限
• git config transfer.unpackLimit 2147483647
  
  
  
  ＃プッシュパケットにN個を超えるオブジェクトがある場合にのみ、プッシュパケットをアンパックしたままにします
• git config gc.auto 300
  
  
  
  ＃300を超える緩いオブジェクトが蓄積する場合、パック
• HTTP経由で読み取りアクセスを行う（ダムhttp、何らかのgitoliteスマートではありません）

クライアントリポジトリ

• httpによるクローンと更新
• コミットするには、プッシュ用のURLを構成する必要がありますgit remote set-url origin --push git@my-server:Fotos-2013-03-05
  
  
  
  
• git config core.bigFileThreshold 50m
  
  
  
  ＃ビデオのデルタを検索しない
• git config core.looseCompression 0
  
  
  
  ＃緩いオブジェクトをアーカイブしないために
• git config pack.compression 0
  
  
  
  ＃パックされたオブジェクトをアーカイブしない場合

これを整理するように私を励ましてくれてありがとう。