100 を超える「プロジェクト」を含むバージョン管理リポジトリに、バイナリ ファイル (ほとんどの場合、サイズが数 KB から数 MB の MS Word ドキュメント) を格納する必要があります。現在、Visual Source Safe を使用していますが、データベースが時々クラッシュしたり、アクセスが遅いなどの問題があります。
Git または Subversion への移行を検討しており、バイナリ ファイルを処理するにはどちらが適しているかを考えていました。
100 を超える「プロジェクト」を含むバージョン管理リポジトリに、バイナリ ファイル (ほとんどの場合、サイズが数 KB から数 MB の MS Word ドキュメント) を格納する必要があります。現在、Visual Source Safe を使用していますが、データベースが時々クラッシュしたり、アクセスが遅いなどの問題があります。
Git または Subversion への移行を検討しており、バイナリ ファイルを処理するにはどちらが適しているかを考えていました。
Subversion は、バイナリ ファイルを自動的に検出しようとします ( SVN FAQを参照)。これが失敗した場合は、自分で指定する必要があります (SVN の検出方法も変更できません)。
Git も同じことを行い、ソース リポジトリに.gitattributesファイルを含めることで、どのファイルを自動的にバイナリとして扱うかを指定できます。
Git と SVN のバイナリ ファイル処理の比較を次に示します。
これは、他のスタック オーバーフロー メンバーがGitとバイナリ ファイルで行っていることです。
お役に立てれば!
すべてに git を使用します。文字通り。私たちの管理オフィスのファイル共有全体でさえも git に保持されています (システム管理者が毎日コミットしています)。
その共有は、ほぼ完全にバイナリ ファイルです。Word 文書、クイックブックなど...
私たちはすべてのことについて 100% 正確な履歴を持っています。そして、時折git gc
、レポのサイズを管理しやすくします。
また、git は非常に高速です。 SVN から切り替えたときは、使用パターン (20,000 以上のファイルを含む大規模プロジェクト)git
よりも ~ 10 倍高速でした。subversion
転覆、間違いなく。今日 (2009 年)、TortoiseSVN は、エクスプローラーに統合された Subversion リポジトリのナビゲーションを提供します。特に、任意の Word ドキュメントの差分をサポートします (差分は Word 自体に委ねますが、この機能は非常にうまく機能します)。
TortoiseGit がこれと同じ機能を持てない理由はありませんが、現在、そのような機能は安定した形で存在しません。幸いなことに、将来いつでも Subversion リポジトリを Git に移行するのは簡単です。
更新: 2011 年現在、TortoiseGit には明らかに TortoiseSVN と同じドキュメント管理機能があります。ただし、Subversion はドキュメントをロックする勧告をサポートしているため、他のユーザーが他のユーザーと同時にドキュメントを編集しようとすると通知されます。私の知る限り、TortoiseGit は Git の分散型の性質のため、この機能をサポートできません。
TortoiseGit は、差分を Office 自体に委譲する Office ドキュメントの完全な git ワークフローをサポートしています。また、OpenOffice for OpenDocument 形式への委任にも機能します。