gitを使用してすべての写真を保存するという考え方です。
何を達成したいですか？
- 写真を1つのヒープ（DCIM）にダンプし、写真をフォルダーに分類する時間があります。
- 1台のコンピューターから写真を捨てて、別のコンピューターで操作します。
- すべてのコンピューターで魔法のように同期された写真とフォルダーの名前を変更します。
- 写真を編集できるように、元の写真を復元できるようにします。
- 編集の履歴を保持します。
判明したように、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
最初の実験（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 <>
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 <>
サーバーでプッシュコマンドを実行した後、リポジトリに追加の設定が含まれていませんでした（そうする必要があります）。 ローカルリポジトリは緩い状態のままでしたが、サーバーに圧縮されていました。 しかし、パケットサイズは3.7ギガバイトでした。 サーバーにpack.packsizelimit = 2gの設定はありませんでした（ただし、保存もされませんでした）。
sshで1つのパッケージに3.7Gリポジトリを複製する
git clone git@my-server:Fotos-2013-03-02
クローン作成後、リポジトリはパックされ、パッケージのサイズは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
これらすべてを写真の各リポジトリに書き込みます。 これを行うには、gitoliteを構成します。
構成を追加する前に、
.gitolite.rcファイルで構成パラメーターを有効にする必要があります。 ここに行があります
GIT_CONFIG_KEYS => '.*',
そして、これがgitolite configの外観です。
大きな
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
クライアントとサーバーの両方がゆるいリポジトリを残しました。
sshを介して新しいリポジトリのクローンを作成しようとして失敗しました。 サーバー側では、git 1.7.1がメモリ不足でクラッシュしました。
Gitの更新サーバーでGitを更新する
あらゆるバージョンのgitが必要（yum install git）
サーバー上
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 ＃パックされたオブジェクトをアーカイブしない場合
これを整理するように私を励ましてくれてありがとう。