はじめに
ゲーム開発のようなコードとバイナリデータが混在し, 企画, アーティスト, エンジニアなどがチーム作業するプロジェクトを想定して比較したいと思います.
Perforceに関しては合計で2年ほどの経験ですので, 間違いも多いと思います.
定性的分析に基づきますので, 感想セクションに限らず全て私見と思っていただけると幸いです.
バージョン管理システム
バージョン管理システム（VCS）の, 次のような項目を比較します.
| 項目 | 説明 |
|---|---|
| ライセンス | 価格や導入のコスト |
| バイナリ | バイナリファイルの運用 |
| 運用コスト | 多プロジェクトも含めた運用コスト |
| 学習コスト | 主にエンジニア以外の使用が容易か |
| ワークフロー | ブランチなどのワークフローの柔軟さ |
| GUIクライアント | エンジニア以外に最重要 |
次のようなVCSがサポートする（べき）範囲外は含めません.
- コードレビューなどの他のシステムをサポートする機能
- ホスティングソフトウェアやその他のツールの機能なので比較しません
バージョン管理システム
Subversion
中央集権型のシステム, ブランチなどの複雑な概念がなくファイルとディレクトリのバージョンを管理する, シンプルなシステムです.
| 項目 | 説明 |
|---|---|
| ライセンス | Apache License |
| NFSなどでリポジトリを共有すればサーバ要らず, エンジニアなら特別な知識は不要. | |
| バイナリ | ファイルの変更履歴がバイナリ差分のリストになるため, 差分が大きくなりがちなバイナリファイルが苦手. |
| 運用コスト | プロジェクトごとにリポジトリを作ってしまえば事が足りる時代, ほぼトラブルが起きないし, 専門の知識を持った人もいらない. |
| ファイルのバイナリ差分を積み重ねるため, 長く運用するとリポジトリ全体の肥大化, チェックアウトが重い問題が出ます. | |
| 要は持っているファイルの更新差分を順次適用する, という動作のためにおきます. | |
| 履歴を全て捨ててしまうコマンドもありますので, 別のバックアップ手段と合わせて長く運用することはできます. | |
| 学習コスト | 出社したらUpdate, 退社前にCommit, 分からないエラーが出たらエンジニアに相談, これだけで使用できます. |
| ワークフロー | 単純な構造のためやろうと思えばできます, 外部ツール（GUIクライアント）次第と思います. |
| Gitのstashのようなものはないですし, 少しずつ未完成の機能を足していくより, ウォーターフォールのような, 完成された機能を追加するスタイルの方が向いていると思います. | |
| GUIクライアント |
TortoiseSVN, SmartSVNとVersionsの３強というより, これ以外がメンテナンスされていないです. |
エンジニア以外はTortoiseSVN, コンテキストメニューを汚されたくないエンジニアはSmartSVNです. |
Subversionにおいて, ディレクトリのコピー, タグ, ブランチは通常全て同じ簡易コピーと呼ばれるもので, 実体のコピーは行われません. その代わり, どこからコピーされたかの履歴は残っています. このため, 変更履歴のストリームや分岐のような追跡ができています.
過去に, 全エクスポートしてコミットしなおすというトンデモに出会ったことがあるため補足しておきます.
感想
CVSから移行した人にとっては, やっとプロジェクトの変更を管理をすることができると感動した覚えがあります.
次のことをファイルのバイナリ差分付きで管理しているイメージが近いのですが, 単純で分かり易いです.
--- 最新ディレクトリ
|- 旧いディレクトリ１
|- 旧いディレクトリ２
プロジェクトの規模が大きく（履歴が長く）なると, 動作が重くなる問題については, 大きなサイズのファイルは差分ではなくコピーにしてしまうというハックをした人がいました.
Git
| 項目 | 説明 |
|---|---|
| ライセンス | GPL Ver.2 |
| NFSなどでリポジトリを共有すればサーバ要らず, エンジニアなら特別な知識は不要. | |
| バイナリ | Git LFSを使用すればリポジトリサイズの肥大化・動作が重くなる問題は緩和されます. |
| 運用コスト | Git LFSを確実に運用しなければいけません |
| 学習コスト | 分散リポジトリがエンジニア以外には全く利点がありません. |
commitとpushの２段階になっている理由など, 自分たちに利益がないのに理解しろと言う方がおかしいと思います. |
|
commit/pushを不可分にするツールを作った企業があるらしいです, そこまでする意味があるのかはわかりません. |
|
| ワークフロー | ブランチの概念がシステム自体にあるので, 柔軟性があります. |
| 見方を変えれば扱うエンジニア（チーム）の技能次第ということです. | |
commit/push問題を解決できたとしても, エンジニア以外のワークフローを統合する必要があります. |
|
| GUIクライアント | TortoiseGitが最有力と思われますが, commit/push問題やワークフロー問題を解決する必要があります. |
感想
私は実際のプロジェクトで運用したことないのでわかりませんが, 専用ツールを作ってしまうのが最適解なのかもしれません. 今はメインラインにcommit/pushしてほしい, 今はサブラインにcommit/pushしてほしい, などはエンジニア以外にとっては自分に利益のないことですので興味がないことが普通です.
コードをGit, リソースを他のVCSというハイブリットは, 手間をいい感じに自動化できるエンジニアがいる場合に考慮したい案です.
Perforce
| 項目 | 説明 |
|---|---|
| ライセンス | プロプライエタリ |
| ５ユーザ, ２０ワークスペース（プロジェクト）まで無料. | |
| インストーラでクライアントの導入コストは少ないです. | |
| バイナリ | ローカルを最新の状態にする動作が速い. |
| 運用コスト | サーバの管理に専門の知識が必要ですが, 単純ですし, 困ったらサポートに丸投げもできます. |
| 学習コスト | 作業前に該当ファイルを（排他）ロック, 退社前にロックしたファイル群をサブミットないし解放, の運用で事故は起きやすいですが簡単です. |
| ワークフロー | ブランチはただのコピーで, コピー元の追跡などはありません, その操作がされたという履歴が残るだけです. |
| ブランチに近い機能は, ストリームがあります. バイナリのマージや, チームメンバへの布教のコストを考えると, 面倒という感想です. | |
| 私の見解では, 本質はCVSを改良し続けたものと思います. | |
| GUIクライアント | 公式にp4vがあり, インストーラを使えば同時に導入されるため, 初期設定の仕方と, 各職種がやるべきプロセスを決めて置けば問題ないです. |
感想
2009年頃は現在より単純だった記憶があります. Subversion, Gitなどの競合が登場していく過程で機能の建て増しを繰り返し今の形になっているのかなと思います.
"バイナリファイルを最新の状態に更新する"速度は圧倒的ですので, その部分を生かす運用をすべきだと思います.
GUIクライアントのp4vが, 本当に残念なソフトウェアと思います. ファイルにつくアイコンが非常に小さい, 変更があったファイルは控えめな青, ディレクトリ以下に変更があったかわからない, などUIが分かり辛いです.
プロジェクトホスティングソフトウェア
オンプレミスのものを羅列するだけです.
Subversion
Savannahの基盤になるSavaneがありますが, 私は運用したことがないため語れません.
Google Codeがありましたがサービス終了ですし, SourceForgeは申請が面倒くさいなどがあります. 非難する気はありません, そういう時代だったのです.
Git
GitHub, GitLab, Bitbucket, Gitea, Gogsあたりが有力候補だと思います.