Helix Core（Perforce）の主な要素について
前回、Helix Core（旧称 Perforce）の基本構成についてまとめてみました。
今回は、ストリームやディポの種類などその他の要素についてp4miscさんに伺ったことを自分なりの理解でまとめてみたいと思います。
目次はこちら。
例によって私の理解が間違っていたらツッコミいただけるとありがたいです。。
ストリーム
公式ドキュメント「ソリューション概要: Helixバージョンコントロールシステム (2019.1)」のストリームの概要ページで基本的なことについて解説があります。
▲ 上記、公式マニュアルより引用
メインとなる開発がある際に、リリース候補（Release Candidate）を置いておく「本流」「メインストリーム」「メインブランチ」と呼ばれるストリームがあり、その子として開発を進めて安定したら本流にマージする開発ストリームに分岐させたりするそうです。
１つのプロジェクト内でも開発担当部分を分けたチームごとにストリームを切り出して、メインストリームに Read Only でインポートする‥といった形も可能とのことです。
ディポ
企業では多人数で開発を行うため、一般的にはサーバー管理者がまず Helix Core Server をインストール ⇒ ディポやストリームを用意 ⇒ 開発スタッフ分のユーザーを追加して準備を整えてからアナウンスという形になる模様です。
また、ディポを作成する際に２種類から選ぶのは私も体験しましたが‥
●Classic Depot
こちらは Perforce リリース当初からのタイプで、ブランチした際の各ストリーム間の関係や設定（Read Only であるなど）をユーザー自身で把握しておかないといけないそうです（ブランチスペックという機能で関係を登録することはできるがその分手間になるとのこと）。
●Streams Depot
こちらはブランチ間の関係を Stream View でフロー図で可視化してくれたり、それまでユーザー側で管理していた部分をある程度 Helix Core 側で負担してくれるタイプになるそうです。
では現在はほとんど Streams Depot が利用されているのかというと「Classic Depot に慣れているなどの理由から、クラシックディポを使っているケースは多いと思う」とのことです。
●ディポ以下のパスの構成について
上図デフォルト設定の場合、下記のようにフォルダが作成されました。
・P4ROOT ‥ Helix Core Server をインストールした場所
・streamsDepot ‥ ディポのルート
・mainline ‥ メインストリーム
・Content ‥ 私が最初に適当に追加したTOP階層のフォルダ
ただ、前回まとめたように１つのディポに複数のプロジェクトがあり、プロジェクトには複数のブランチストリームがあったりする訳で、そうするとmainlineフォルダ内にプロジェクトAとプロジェクトB双方のストリームのフォルダが並んでしまい混乱することも考えられる模様です。
そのため、プロジェクトやストリームをどの階層で管理するかといった設定が可能になっているということでした
●ディポのパスを後から移動する
こちらは可能とのことです。その際にユーザーはデータを取得し直しになるのか聞いてみたところ「取得し直しにはならない」ということでした。
企業では一般的にサーバー側のOSはパフォーマンスが出る Linux が多いと思われるが、シンボリックリンクを利用して別のストレージに逃がしたりといったことがWindowsより簡単にできるそうです。
●Helix Core Server のインストール先を後から変更する
余談ですが、Helix Core Server をデフォルト設定のまま C:\Program Files 内にインストールしてしまい、後から「やっぱり C:\P4ROOT に変えたい！」となった場合、コマンドプロンプトからも可能だそうです。ただし慣れないと多少ややこしいかもとのことで、簡単なのはアンインストール＆再度インストールになるとのことでした。
また、アンインストールする際に以前の設定を保持しておきたい場合は「db.～～」というファイルを退避しておき、再インストール時に置き換えればOKとのことです。
サーバー管理者による管理
こちらはコマンドプロンプトでも管理できますし、GUIで管理が可能な P4Admin を利用することも可能だそうです。ただ、ディポのパスを変えることは P4Admin ではできないそうなので、要件に応じて使い分ける模様です。
P4Admin の公式マニュアルはこちら。
●P4コマンドを打つ際の場所について
例えば Helix Core Server をインストールした先が「C:\P4ROOT」だった場合、コマンドプロンプトで「C:\P4ROOT」に移動して作業するのか伺ったところ「間違ってファイルを消したり変な操作をすると良くないので別の場所で行った方が良い」とのことでした。
Helix Core Server のインストール時に環境変数が設定されるため、カレントディレクトリがどこでも P4コマンドは通るとのことです。
ユーザー
私の場合は１台のマシンに Helix Core Server と P4V を両方インストールしましたが、その際に管理者としてのユーザー名と使用者としてのユーザー名のどちらを指定するのか混乱しました。
●Helix Core Server インストール時
ダイアログで求められる User 欄は、企業なら特権ユーザーのアカウント名（例えば汎用的な名称で super のような）にした方が良いとのことでした。
個人ユースなら管理者の実ユーザー名（ログイン時の名前）を入力するのでも良いようです。後にサーバーの設定を行おうとP4Adminを起動すると、Open Connectionダイアログが表示され、ユーザー名を入力した際に「このまま進めるとあなたはスーパーユーザーのアクセス権を持つ唯一のユーザーになります」とメッセージが表示され、OKを押すとそこで最も管理権限の高い super の状態になりました。
●P4V インストール時
こちらもダイアログで User 欄への入力を求められますが、それもそのPCの実ユーザー名を入力するので良いようです。
●クライアントでユーザーを複数追加
P4V 使用者は通常、個人に対してユーザーが紐づきますが、クライアントマシン内でユーザーを複数作成しても問題は無いということです。その場合、P4Vで Open Connection でユーザーを切り替えるのでOKとのことでした。
ワークスペース
ワークスペースは基本的にはクライアントマシンに依存するものの、単にファイルを取得するだけのマシンがあるならワークスペースをどのマシンでも使えるようにすることもできるそうです。
また、プロジェクトではなくストリームに対してワークスペースを作成することになるため、少人数開発で無償で Helix Core を使用している場合の注意点として、ストリームを使っていると簡単に20個に達してしまう可能性があり、やりくりが求められるようです。
ちなみに通常、バージョン管理下のファイルは自動で読み取り専用になり、チェックアウト操作によって読み取り専用が解除され編集が可能になります（うっかり編集してしまうのを防げる。また他の作業者はこのタイミングでチェックアウトできなくなりコンフリクトを防げる）。
ワークスペースの編集ウインドウで Advances タブに変えてオプション「Allwrite: ～～」にチェックを入れると、その後に追加するファイルは読み取り専用がONにならず、チェックアウトをしなくてもそのまま編集が可能になり、P4Vのフォルダ/ファイル上で右クリック「Reconcile（リコンシル）」を実行すると何が編集されたかサーバー側と照合・自動で識別してサーバーに反映してくれるそうです。
個人ユースだとこちらの方が快適そうですね！
‥という訳で今回は以上になります。
引き続き、実際にコマンドプロンプトや P4Admin を使って基本的な設定を行ったり、クライアント側として P4コマンドでファイルのチェックアウトやサブミットを行ってみたりしたいと思います。
.NET/C#で作ったツールからファイル操作を試すのはそのあたりが理解できてからですね。。