はじめに
先日、Plastic SCM の開発会社が Unity によって買収されたそうです。
Plastic SCM はバージョン管理ツールの一種で今回の買収によって Plastic SCM の機能改善が加速されることが期待されます。
ただこの Plastic SCM、日本ではあまりメジャーじゃありません。ネットで検索しても日本語の記事が全然出てこないんですよね。日本で有償の高性能バージョン管理ツールでいくとゲーム業界では Perforce のほうが有名かなーという印象です。
そんな Plastic SCM。以前個人的に調べていた時期がありまして、せっかくなので知っていることを記事にしようと思い書くことにしました。
ちなみに本記事の情報は 2020 年 8 月末時点での情報となります。ライセンスプランなどは今後変更になる可能性もありますので最新の情報は公式サイトでご確認ください。
Plastic SCM ってなに？
冒頭でも書きましたがバージョン管理ツールです。
無料では Cloud 版が使えます。Enterprise Edition のライセンスがあればオンプレミスサーバー版も使えます。自分はオンプレミス版を使って期間限定で試していました。
クライアントは GUI ツールとコマンドラインツールがあり、それらを使ってワークスペースやリポジトリを操作します。また、 Windows 版ではエクスプローラ拡張もあります。Subversion でいう Tortoise SVN みたいなやつですね。
リポジトリは Subversion のように集中型バージョン管理システムとしても使えますし、Git のように分散型にすることもできるそうです。自分は集中型でしか使ったことがないので分散型についてはよく把握していないです。
余談ですが、Plastic SCM という名前は長いので個人的には PSCM と略すことが多いです。今回の記事でも以降ところどころで PSCM と表記させていただきます。
Plastic SCM の良いところ
PSCM の良いところ。たくさんありますが分かりやすいところに絞って紹介します。
なお、既存のバージョン管理システムを把握している人がイメージしやすいように、フリーソフトウェアである Git や Subversion(SVN) との比較をしながら説明していきます。
大きなバイナリファイルの扱いが得意
ここでいう大きなバイナリファイル、というのは数十 MB 以上のサイズのファイルを指します。ゲーム開発では数百 MB 規模のファイルを扱うこともあるので大きなバイナリファイルが扱えるかどうかは必須条件だったりします。
Git(LFS) は大きなバイナリファイルが扱えなくはないですが、得意という印象ではありません。（個人的な印象です）
PSCM は SVN 同様に大きなバイナリファイルの扱いが得意です。リポジトリもクライアントも大きなバイナリファイルを扱う前提で設計されています。
更に SVN よりも良いところとして、ローカルのストレージ消費量が少ないことが挙げられます。
SVN はワークスペースの管理フォルダ .svn 以下に変更元のファイルを置きます。例えば 100MB のファイルがワークスペース内にある場合、 .svn 以下とワークスペース内の２カ所に 100MB のファイルが配置され、合計 200MB 必要となり２倍近くストレージを消費します。（※管理フォルダ以下は圧縮状態で保存されているかもしれないので厳密には違うかもしれません。）
一方 PSCM は管理フォルダに変更元のファイルを置かずワークスペース内だけに配置されるため、ストレージの消費量が SVN と比べて小さくなります。デメリットとしてローカルの変更を取り消す場合はサーバーからデータを再ダウンロードすることになるのですが、ローカルのストレージ消費量が節約できるのはかなり嬉しいです。
ダウンロードやアップロードにかかる時間が比較的高速
サーバーからのデータのダウンロード時間、サーバーへのデータのアップロード時間が SVN と比べて速いです。
詳しいアルゴリズムは分かっていないのですが、クライアント・サーバー間のデータのやりとりにおいて複数のファイル群を１つのまとめて送受信しているらしく、それが要因なのかなあという印象です。ちなみにこの「まとめて送受信」の機能はデフォルトでは OFF で、クライアントの設定ファイルである client.conf を編集すると ON になります。最新の環境では変わっている可能性がありますが以前調べたときは編集する必要がありました。
ちなみに SVN のほうはファイルのダウンロードやアップロードを１つずつ行っている？ようで、それが理由でファイル数が多い場合の処理時間が長い印象です。
ダウンロード時間についてもう１つ。PSCM の機能である Proxy Server を使うと場合によっては更に速くなります。
Proxy Server はリポジトリデータのキャッシュサーバーのようなもので、これを利用するとデータダウンロードが以下のような経路となります。
リポジトリのあるサーバー <---> ProxyServer <----> クライアント
もしクライアントがダウンロードしようとしているデータが Proxy Server 内にキャッシュされている場合、クライアントは Proxy Server からデータをダウンロードします。クライアントとリポジトリのあるサーバーが別拠点にある場合など Proxy Server をたてておくと高速化が期待できます。
非エンジニア（アーティスト、プランナなど）が使える GUI が付属している
ゲーム開発では色んな職種、色んなスキルレベルの人がバージョン管理操作をします。そういった人達でも使えるかどうかというのは大事な要素だったりします。
Git ではブランチを作り、編集をコミット＆プッシュ、Web 上でレビューしてマージする、といったフローが一般的かと思います。ただ、非エンジニアにこのフローを把握してもらい正確に実行してもらうのはなかなか大変です。
SVN では集中型リポジトリ方式を採用していることもあり、更新して編集してコミットする、というシンプルなフローになります。そのため非エンジニアさんへの導入もしやすいです。GUI ツールの Tortoise SVN のおかげでもあります。
PSCM も SVN 同様のシンプルなフローが実現できます。GUI ツールとしても Gluon という比較的とっつきやすいものが付属しています。
Gluon が Tortoise SVN より勝っているところとして部分的なデータダウンロードのしやすさにあります。ここでいう部分的なデータダウンロードというのはワークスペース全体をリポジトリからダウンロードするのではなく、一部のフォルダ以下や特定のファイルのみを選択してダウンロードする操作のことを指します。Gluon では部分的なデータダウンロードをする際，ダウンロードしたいファイルを名前で検索できたり，ダウンロードしようとしているデータのストレージ消費量が事前に確認できたりするところが優れている印象です。
Plastic SCM のもうちょいなところ
ドキュメント不足気味
公式のドキュメントを探すだけでは求めている情報にたどりつけないことが結構あります。サーバーまわりもそうですしコマンドラインツールの使い方とかもですね。一部の情報はリリースノートにしか掲載されていないこともあります。もうちょっと網羅されていると嬉しいなぁという印象です。
GUI ツールやエクスプローラ拡張がもう一息
自分は Gluon やエクスプローラ拡張を試していましたが、Tortoise SVN ではスッとできていたことが PSCM では方法が見つからなかったり直感的にできないということがそれなりにあり少しストレスでした。「ここで右クリックしたら出来そう」と思ったことができない、というケースが多かったですね。あと UI 全般的な話ですが使っている最中に「ここがこうなっているといいのになぁ」的なことが結構でてきます。このあたりは今後のバージョンアップに期待です。
GUI が日本語対応されていない
特に Gluon は非エンジニアも使うツールなので日本語対応されていると嬉しいなぁという印象です。一応ローカライズっぽいファイルがあるのでそこを自力でがんばれば日本語にできなくはないんですけどね。今回 Unity さんに買収されたこともありますし日本語化が進むといいなぁと思います。
他のバージョン管理ツールとの比較
公式のこちらが参考になります。
実際に使う用の Tips
自分が理解に時間がかかった部分を書いておきます。
ワークスペースの Full Mode と Partial Mode
ワークスペースは内部構造が Full Mode と Partial Mode の２種類あるんです。これが独特。
Full Mode は Plastic GUI を使ったりコマンドラインツールで cm update するとなるモードです。
ほぼ Git のようになる、と考えるとだいたい OK です。部分更新ができなくなる代わりに、ブランチ切ってコミット（チェックイン）つんでマージする、といったフローを実現する際は Full Mode で行います。
もう１つが Partial Mode。これは Gluon を使ったりコマンドラインツールで cm partial update するとなるモードです。
部分更新ができるようになりますが、ブランチを切ったり、別ブランチからマージできません。
以上のことから、ブランチを切って作業してマージをする運用をしたい場合は Full Mode を使うしかありません。
え？でもブランチ切りたいし部分ダウンロードもしたいじゃん？ってなると思うんですよね。私は思いました。
ここからは想像ですが、PSCM としてはエンジニアが操作するワークスペースと非エンジニアが操作するアセット用のワークスペースの２個用意して、前者は Full Mode、後者は Partial Mode で使ってくださいね的な思想なのかなーと想像しています。
フォルダ構成のイメージとしてはこんな感じ。
project
+ program （ここは Full Mode）
+ asset (ここは Partial Mode)
このあたり、どういう運用を想定しているんですかねー？
おわり
以上が Plastic SCM についてでした。
自分も十分に理解できているとは思っていないので、間違っているところなどツッコミありましたらぜひお願いいたします。