序章
Visual Studio での Perforce の統合は「ひどい」という主張には同意しません。むしろ、私はそれを「すぐに使える経験は最適ではない」と定義します:-)。次のセクションでは、統合に関する私の理解と、プロジェクト/ソリューションのセットアップに関する推奨事項について説明します。
ソース管理統合がどのように機能するかの詳細に興味がない場合は、この回答の最後までスキップして、Weeble の質問に対する回答を要約することができます。
免責事項: 以下のセクションは、私の経験に基づく推測に過ぎませんが、私は長年にわたって多くのプロジェクトでこの手法を使用してきました (各プロジェクトには、複数の実験的/トランク/メンテナンス/リリース ブランチがあり、場合によっては複数のソリューション ファイルさえありますが、問題はありません)。 ）。欠点は、プロジェクト ファイルを手動で更新する必要があることです。ただし、2 分間の投資は、プロジェクトの存続期間にわたってかなりうまく償却されます :-)。
ソリューションとプロジェクト
Visual Studio は、最初のソリューションの読み込み中に、ソリューション ファイルと各プロジェクト ファイルの両方からソース管理バインド情報を使用します。このバインディング情報はname.suoファイルに保存されます (ソリューションとしてname.slnを使用していると仮定します) - suoファイルは隠しフラグでマークされているため、ファイル エクスプローラーでは表示されないことに注意してください ("Hiddenファイルとフォルダ」オプション)。
問題が発生した場合にソース管理プロバイダーに再バインドする最も簡単な方法は、適切なsuoファイルを削除してソリューションを再度開くことです。suo ファイルが作成された後は、 <Scc*> 要素を変更しても効果がありません。
ソリューションを最初に開いたときに、ソリューション ファイルに保存されているバインディング情報とプロジェクト ファイルに保存されている情報の間に不一致がある場合、Visual Studio はこれを修正しようとします (場合によっては、ソリューションの情報とプロジェクトの情報は、不一致を解決するための「マスター」として使用する必要があります):
Visual Studio が DRY (Don't Repeat Yourself) 原則に違反しているのはなぜですか? 何も思いつきません。これには歴史的な理由があり、Visual Source Safe と呼ばれる悪夢のニーズと密接に結びついていると思います :-)。
「正しく」設定する方法は？
新規または既存のソリューション/プロジェクトを Perforce に追加するときは、常に空のソリューションを作成することから始めます (「空のソリューションのソース管理」セクションを参照)。次に、この空のソリューションにプロジェクトを次々と追加します。追加するプロジェクトが既に存在するか (「既存の (バインドされていない) プロジェクトのソース管理」セクションと「既存の (バインドされた) プロジェクトのソース管理」セクションを参照)、または新しいプロジェクトを作成する必要があるか (「 「新しいプロジェクトのソース管理」セクション)。
ブランク ソリューションのソース管理
ソース管理に新しい空のソリューションを追加するには、次の手順を実行します。
- Visual Studio を起動し、"新規" -> "プロジェクト..." -> "その他のプロジェクトの種類" -> "空のソリューション"; ソリューション名と場所を入力し、「OK」ボタン
- 「ファイル」→「ソース管理」→「ソリューションをソース管理に追加...」
- 接続ダイアログで、適切な P4 サーバー ポート、クライアント、およびユーザーを入力します (選択したクライアントのビューには、手順 1 で選択した場所が含まれている必要があります)。
- [表示] -> [保留中のチェックイン] -> [チェックイン] -> [送信] ボタンを押す代わりに、[送信] ダイアログで [キャンセル] を使用します。
理由: 「チェックイン」アクションは、新しいファイル「name.vssscc」を作成し、「name.sln」と「name.vssscc」の両方を Perforce のデフォルト変更リストに追加します。送信ダイアログをキャンセルすると、「追加」操作が保留され、P4 に送信する前にファイルを編集できるようになります。
- Visual Studio を閉じる
name.sln ファイルをお気に入りのエディター (本当に絶望的な場合はメモ帳を使用してください :-) ) で開き、2 つの新しい行 ( SccProjectName0およびSccProvider0 ) を追加します。空のソリューション ファイルには、次のようなソース管理セクションが含まれているはずです。
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 1
SccLocalPath0 = .
SccProjectName0 = Tutorial
SccProvider0 = MSSCCI:Perforce\u0020SCM
EndGlobalSection
値は次のように選択する必要があります。
- SccProjectName0 : [ソース管理の変更] ダイアログに [サーバー バインド] として表示される任意の文字列。この名前は、同じソース管理接続を共有できるプロジェクト/ソリューション ファイルを決定するために使用されます。ソリューション ファイルとプロジェクト ファイルではスペースのエスケープ ルールが異なるため、この名前にスペースを使用しないことをお勧めします。
- SccProvider0 : ハードコードされた値 "MSSCCI:Perforce\u0020SCM"。
- 選択した Perforce クライアント (p4.exe、P4Win、P4V) を使用して、2 つの保留中のファイルを送信します。
バインディングをテストできるようになりました。
- Visual Studio が閉じていることを確認します
- name.sln (特に name.suo) を除く **すべて* のファイルを削除します。
- Visual Studio を開き、それを使用して name.sln を開きます
- 接続ダイアログが表示されます。適切なポート/クライアント/ユーザーを使用して、[OK] をクリックします。
- ソリューション エクスプローラーには、南京錠のオーバーレイ アイコンが付いたソリューション ノードが表示されます。
- "File" -> "Source Control" -> "Change Source Control..." を使用して、ソリューションのソース管理ステータスを確認できるようになり
ました
。 .
新しいプロジェクトのソース管理
まったく新しいプロジェクトを作成していて、すぐに Perforce デポで追跡を開始したい場合は、次の手順に従います。
- ソース管理されたソリューションを Visual Studio で開く
- "File" -> "Add" -> "New Project..." - 追加するプロジェクトの種類、名前、場所を選択します (場所は、ソリューション ファイルが保存されているディレクトリのサブディレクトリである必要があります)。
- "File" -> "Save All" (これにより、メモリ内のすべての変更がソリューション ファイルにコミットされ、新しく作成されたプロジェクト ファイルがディスクにコミットされます)
選択したエディターを使用して、作成したばかりのプロジェクト ファイルを手動で編集します (また、メモ帳を使いますか? ;-) )。次のプロパティ要素を PropertyGroup (任意のプロパティ グループ) に追加します。
<PropertyGroup>
...
<SccProjectName>Tutorial</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
...
</PropertyGroup>
値は次のように選択する必要があります。
- SccProjectName - これは、[ソース管理の変更] ダイアログに [サーバー バインド] として表示される値です。空白のソリューションで SccProjectName0 に使用した値と同じである必要があります。同じでない場合、ソリューションとこのプロジェクトは同じソース管理プロバイダー接続を共有できません
- SccLocalPath - 参照ディレクトリへの相対パス ([ソース管理の変更] ダイアログに [ローカル バインディング] として表示されます); ソリューション ディレクトリを参照ディレクトリとして使用することをお勧めするため、これは実質的に、プロジェクト ファイルを含むディレクトリからソリューション ファイルを含むディレクトリへの相対パスです (私の例では、"(solutionDir)/Source/ProjectName/projectName.csproj" にプロジェクトを格納しています。相対パスは「2 レベル上」です)
- SccProvider - ハードコードされた値 "MSSCCI:Perforce SCM"; これは、Scc* バインディング値が有効な SCCAPI プロバイダーを判別するために使用されます。
Visual Studio に戻ります。プロジェクト ファイルが外部で更新されたことを自動的に検出し、再読み込みを提案する必要があります (そうでない場合は、プロジェクトを手動でアンロードして再読み込みします)。
- 「表示」->「保留中のチェックイン」
- 「チェックイン」 -> (solutionName).vssscc ファイルを右クリックし、「変更されていない場合は元に戻す」を選択することをお勧めします (Visual Studio で編集用に開いても、変更されていません)。説明を提供し、変更を送信します
新しく追加されたプロジェクトが適切にバインドされていることを確認するには、次の手順に従います。
- Visual Studio が閉じていることを確認します
- (solutionName).suo ファイルと MSSCCPRJ.SCC (ソリューション ディレクトリ内) を削除します。
- Visual Studio を開き、それを使用して (solutionName).sln を開きます。
- 接続ダイアログが表示されます。適切なポート/クライアント/ユーザーを使用して、[OK] をクリックします。
- ソリューション エクスプローラーには、南京錠のオーバーレイ アイコンが付いたプロジェクト ノードが表示されます。
"File" -> "Source Control" -> "Change Source Control..." を使用して、ソリューションのソース管理ステータスを確認できるようになりました。
このステータスのスクリーンショットで注意すべき点は、ソリューションの行を選択すると、残りの行もすべて「選択」されていることです (青色のハイライト)。これは、これらのすべてのエントリが同じ「サーバー バインディング」と「ローカル バインディング」を持ち、同じソース コントロール プロバイダー (P4) 接続を共有するためです。
また、両方のプロジェクトの "相対パス" には 2 つのレベルがあり、同じ "ローカル バインド" (ソリューション ファイルが存在するディレクトリ) に相対的であることに注意してください。
既存の (バインドされていない) プロジェクトのソース管理
他の Perforce ソリューションでまだ使用されていない既存のプロジェクトがある場合は、次の手順に従ってそれらを Perforce に追加します (つまり、以前にソース管理されていないプロジェクト (インターネット ダウンロードなど) をインポートするか、別のソース管理を使用していたプロジェクト)。プロバイダー (Visual Source Safe など)。
- プロジェクトを適切な場所にコピーします
- 既存のソース管理バインディングをクリーンアップします (存在する場合):
- 既存のプロジェクト ファイル バインディング、つまり「Scc」で始まるすべてのプロパティを削除します。
- プロジェクト ファイルと同じディレクトリにあるファイル (projectName).vspscc を削除します (存在する場合)。
- ソース管理されたソリューションを Visual Studio で開く
- "File" -> "Add" -> "Existing project..." - プロジェクト (手順 1 で作成したコピー) を参照します。
- "File" -> "Save All" (これにより、メモリ内のすべての変更がソリューション ファイルにコミットされます)
- 「新しいプロジェクトのソース管理」の手順 4 ～ 7 に従います (つまり、「Scc*」プロパティ要素をPropertyGroupに追加します) 。
検証手順は、「新しいプロジェクトのソース管理」セクションとまったく同じです。
既存の (バインドされた) プロジェクトのソース管理
ここで説明する手法を使用して既に Perforce にバインドされているプロジェクトがあり、それらを別のソリューション (新しいブランチ、プロジェクトを再利用する代替ソリューションなど) で使用する場合は、次の手順を使用します。
- プロジェクトを目的の場所に統合する
- ソース管理されたソリューションを Visual Studio で開く
- "File" -> "Add" -> "Existing project..." - 統合を介してステップ 1 で作成されたプロジェクトを参照します
- 「表示」 -> 「保留中のチェックイン」 -> 「チェックイン」 - 説明を追加して送信
概要
- ソース管理バインディング情報はソリューションとプロジェクトの両方に保存され、同期している必要があります (そうでない場合、Visual Studio は不一致を修正しようとします)。
- 私は常に、プロジェクト ファイルをバインド情報の主要なソースとして扱い、ソリューション ファイルは、最初に空白のソリューションをソース管理してから目的のプロジェクトを追加することで簡単に再作成できる使い捨てファイルとして扱います。
- ソリューション ファイルには常に有効なSccProvider0とSccProjectName0 の値が必要です (新しいバージョンの P4SCC プラグインで手動で追加する必要があります)。
- プロジェクト ファイルには、常に有効なSccProjectName (できれば SccProjectName0 と同じ)、SccLocalPathおよびSccProvider の値が必要です (P4SCC の既定値は適切でないため、手動で編集する必要もあります) 。
元の質問への回答も含めます。
「ソース管理の変更」を行ってプロジェクトをバインドするとどうなりますか? Visual Studio は、プロジェクト ファイルとソリューション ファイルに何を入れるかをどのように決定しますか?
これにより、再バインドしているプロジェクト ファイル内の "Scc*" 要素が更新されます。その後、ソリューション ファイルも更新され、プロジェクト ファイルのバインドと同期されます。
「ソース管理から開く」とどうなりますか?
開きたいソリューションを選択できます。その後、ソリューションに含まれるすべてのプロジェクトが自動的に head に同期されます。とにかくクライアントを作成する必要があるPerforceの世界では、この機能はあまり役に立ちません.Visual Studioに頼るのではなく、P4V/P4Win/P4からこのクライアントを同期している可能性があります. これは、ビューの概念がなく、チェックアウト時にリポジトリがどこに移動するかを定義していた Visual Source Safe の世界では、ちょっと便利でした。
SccLocalPath と SccProjectFilePathRelativizedFromConnection が参照するこの「接続」フォルダは何ですか? Visual Studio/Perforce はどのように選択しますか?
これが Visual Studio の簿記です。各プロジェクト ファイルのバインドに基づいて決定されます (理論的には、プロジェクト ファイルが何らかの理由でバインド情報を失った場合、ソリューション情報から再構築できると思います...)。
ソリューションの新しいブランチを作成した場合でも、ソース管理バインディングが機能し続けるようにするための推奨される方法はありますか?
上記のセクションで、私にとって非常にうまく機能する方法のアイデアが得られることを願っています:-)。