hg や git などのDVCSツールを使用して、大きなアセット(つまり、数千の画像、フラッシュムービーなど)を処理する良い方法はありますか?私が見ているように、4 GBのアセットで満たされたリポジトリのクローンを作成すると、ファイルをチェックアウトするため、不要なオーバーヘッドのように見えます。アセットファイルとソースコードが混在していると、かなり面倒に思えます。
これをWeb開発のコンテキストで行うことについて、何か考えや経験はありますか?
これらは私がこの主題の問題について持っていたいくつかの考えです。最終的には、アセットとコードをできるだけ分離する必要があるかもしれません。私はいくつかの可能な戦略を考えることができます:
1つのリポジトリ内のアセットともう1つのリポジトリ内のコード。
DVCSツールは独自のリポジトリを追跡しないため、直接のBOM(Bill of Materials)サポートはありません。つまり、両方のリポジトリが同期していることを明確に示す方法はありません。 (これが git-submodule または repo の目的であると思います)。
例:アーティストが1つのリポジトリに新しい画像を追加し、プログラマーがその画像を使用する機能を追加しますが、誰かがバージョンをバックトラックする必要がある場合、どういうわけか保持することを強いられますこれらの変更を自分で追跡します。
アセットリポジトリのオーバーヘッドは、それを使用する人にのみ影響します。
アセットとコードは同じリポジトリにありますが、2つの別々のディレクトリにあります。
上記の両方の戦略には、大きなアセットリポジトリのクローンを作成する必要があるため、オーバーヘッドが大きいという欠点があります。この問題の1つの解決策は、上記の最初の戦略の変形である2つのリポジトリです。コードは分散型VCSリポジトリに、アセットは集中型VCSリポジトリ(SVN、Alienbrainなど)に保持します。
ほとんどのグラフィックデザイナーがバイナリファイルをどのように処理するかを考えると、本当に必要な場合を除いて、通常は分岐する必要はありません(多くのアセットを必要とする新しい機能で、後で必要になるものはありません)。欠点は、中央リポジトリをバックアップする方法を見つける必要があることです。したがって、3番目の戦略:
通常どおりリポジトリにコードがあり、アセットはリポジトリにありません。アセットは、代わりにある種のコンテンツ/メディア/アセット管理システムに配置するか、少なくとも定期的にバックアップされるフォルダーに配置する必要があります。これは、バージョンをグラフィックでバックトラックする必要性がほとんどないことを前提としています。バックトラッキングが必要な場合、グラフィックの変更は無視できます。
考え、経験なし:確かにデータからコードを分離します。アプリケーションに属する一連のイメージがあると仮定すると、それを集中サーバーに保持します。コードでは、アプリケーションがローカルまたはリモートの両方のアセットを統合できるように(明示的なコーディングによって)調整します。貢献者は、最初に新しい画像をローカルストアに配置し、必要に応じて承認されたときに、ある種の(明示的な)アップロード手順と中央ストアに統合できます。
私自身、これに苦労しました。あなたが言ったように、GBのアセットのバージョン管理は大変な苦痛になり得ます。
外部からの参加を必要とするプロジェクトの場合、Mercurialはworkingソリューションであることがわかりましたが、優れたソリューションではありません。大きなファイルのディスク領域を消費し、状況によってはかなり遅くなる可能性があります。
私の社内設計作業では、シンプルな同期ツール(rsync、synctoyなど)を使用して、サーバー/マシン間のディレクトリを最新の状態に保ち、手動でバージョン管理を行います。メジャーリビジョン以外のバージョン管理はほとんど必要ありません。