web-dev-qa-db-ja.com

Visual Studioのソース管理統合はPerforceとどのように連携しますか？

PerforceとVisual Studioを使用しています。ブランチを作成するたびに、「ソース管理から開く」を使用しない限り、一部のプロジェクトはソース管理にバインドされませんが、他のプロジェクトは動作します。私の調査から、私は関係することのいくつかを知っています：

.csprojファイルには、次の設定があります。

  • <SccProjectName>
  • <SccLocalPath>
  • <SccAuxPath>
  • <SccProvider>

時にはそれらはすべて「SAK」に設定されますが、そうでない場合もあります。これらが「SAK」と言う場合、物事が機能する可能性が高いようです。

.slnファイルには、多くのプロジェクトの設定があります。

  • SccLocalPath＃
  • SccProjectFilePathRelativizedFromConnection＃
  • SccProjectUniqueName＃

（＃は各プロジェクトを識別する番号です。）SccLocalPathはソリューションファイルへの相対パスです。多くの場合、「。」であり、プロジェクトが入っているフォルダーである場合もあれば、「..」または「..\..」である場合もあり、そのフォルダーを指すのは悪いようですソリューションフォルダー。相対化されたのは、プロジェクトファイルへのパスfromフォルダーです。 SccLocalPathがプロジェクトのフォルダーを指す場合、完全に欠落します。 SccLocalPathに ".."が含まれている場合、このパスにはブランチ間で同じではないフォルダー名が含まれている可能性があり、問題が発生すると考えられます。

だから、最終的に私が知りたい詳細に到達する：

  • 「ソース管理の変更」を行ってプロジェクトをバインドするとどうなりますか？ Visual Studioは、プロジェクトファイルとソリューションファイルに何を入れるかをどのように決定しますか？
  • 「ソース管理から開く」を実行するとどうなりますか？
  • SccLocalPathとSccProjectFilePathRelativizedFromConnectionが参照するこの「接続」フォルダーは何ですか？ Visual Studio/Perforceはどのようにそれを選択しますか？
  • ソリューションの新しいブランチを作成する場合でも、ソース管理バインディングを引き続き機能させるための推奨方法はありますか？

2012年6月に追加：Perforceを使用しなくなったので、それを保証することはできませんが、 KCDのanswer 以下。どうやら 新しいP4 VSプラグイン が開発中です。うまくいけば、この混乱がすべて解消されるはずです！

visual-studioversion-controlperforce
71
Weeble

前書き

Visual StudioでのPerforceの統合が「ひどい」という主張には同意しません。むしろ、「すぐに使用できるエクスペリエンスは最適ではありません」と定義します:-)。以下のセクションでは、統合についての私の理解と、プロジェクト/ソリューションのセットアップに関する推奨事項について説明します。

ソース管理の統合がどのように機能するかの詳細に興味がない場合は、この回答の最後までスキップして、Weebleの質問に対する回答をまとめます。

免責事項：以下のセクションは、経験に基づいた単なる推測にすぎませんが、多くのプロジェクトで長年にわたってこの手法を使用しています（各プロジェクトは複数の試験的/トランク/メンテナンス/リリースブランチ、場合によっては複数のソリューションファイルも問題なく）。不利な点は、プロジェクトファイルを手動で更新する必要があることですが、2分間の投資はプロジェクトの存続期間にわたってかなりうまく償却されます:-) 。

ソリューションとプロジェクト

Visual Studioは、最初のソリューションの読み込み中に、ソリューションファイルと各プロジェクトファイルの両方からのソース管理バインディング情報を使用します。このバインディング情報はname.suoファイルに保存されます（ソリューションとしてname.slnを使用していると仮定）-suoファイルはhiddenフラグでマークされているため、ファイルエクスプローラーに表示されません（「非表示のファイルとフォルダー」オプションをオーバーライドしない限り）。

何か問題が発生した場合にソース管理プロバイダーに再バインドする最も簡単な方法は、適切なsuoファイルを削除してソリューションを再度開くことです。 suoファイルが作成された後、<Scc *>要素を変更しても効果はありません。

最初のソリューションを開くときに、ソリューションファイルに保存されているバインディング情報とプロジェクトファイルに保存されている情報に矛盾がある場合、Visual Studioはこれを修正しようとします（ソリューション内の情報を選択するか、プロジェクト内の情報は、不一致を解決するための「マスター」として使用する必要があります）。

alt text

Visual StudioがDRY（Do n't Repeat Yourself）原則に違反しているのはなぜですか？私にはわかりません。これには歴史的な理由があり、Visual Source Safeと呼ばれる悪夢のニーズと密接に結びついていると思います： -）。

「正しく」設定する方法は？

Perforceに新規または既存のソリューション/プロジェクトを追加する場合、I alwaysは空のソリューションを作成することから始めます（「空のソリューションのソース管理」セクションを参照）。次に、この空のソリューションにプロジェクトを次々に追加します。追加するプロジェクトが既に存在するか（「既存の（バインドされていない）プロジェクトのソース管理」セクションと「既存の（バインドされた）プロジェクトのソース管理」セクションを参照）、新しいプロジェクトを作成する必要があるかによって手順が若干異なります（ 「新しいプロジェクトのソース管理」セクション）。

空のソリューションのソース管理

ソース管理に新しい空のソリューションを追加するには、次の手順を実行します。

  1. Visual Studioを起動し、「新規」->「プロジェクト...」->「その他のプロジェクトタイプ」->「ブランクソリューション」;ソリューション名と場所を入力し、「OK」ボタン
  2. 「ファイル」->「ソース管理」->「ソース管理にソリューションを追加...」
  3. 接続ダイアログで、適切なP4サーバーポート、クライアント、およびユーザーを入力します（選択したクライアントのビューには、手順1で選択した場所が含まれている必要があります）
  4. [表示]-> [保留中のチェックイン]-> [チェックイン]-> [送信]ボタンを押す代わりに、送信ダイアログで[キャンセル]を使用します。
    理由：「チェックイン」アクションは新しいファイル「name.vssscc」を作成し、「name.sln」と「name.vssscc」の両方をPerforceのデフォルトチェンジリストに追加します;送信ダイアログをキャンセルすると、「追加」操作が保留され、P4に送信する前にファイルを編集できるようになります。
  5. Visual Studioを閉じます

  6. お気に入りのエディターでname.slnファイルを開き（メモ帳、本当に必死なら:-)）、2つの新しい行を追加します（SccProjectNameおよびSccProvider）-空白ソリューションファイルには、次のようなソース管理セクションがあります。

    GlobalSection(SourceCodeControl) = preSolution
    SccNumberOfProjects = 1
    SccLocalPath0 = .
    SccProjectName0 = Tutorial
    SccProvider0 = MSSCCI:Perforce\u0020SCM
EndGlobalSection

    値は次のように選択する必要があります。

    • SccProjectName：「サーバー管理」として「ソース管理の変更」ダイアログに表示される任意の文字列。この名前は、どのプロジェクト/ソリューションファイルが同じソース管理接続を共有できるかを決定するために使用されます。スペースのエスケープルールはソリューションファイルとプロジェクトファイルで異なるため、この名前にはスペースを使用しないことをお勧めします。
    • SccProvider：ハードコーディングされた値「MSSCCI：Perforce\u0020SCM」。
  7. 選択したPerforceクライアント（p4.exe、P4Win、P4V）を使用して2つの保留中のファイルを送信します

これで、バインディングをテストできます。

  1. Visual Studioが閉じていることを確認してください
  2. Name.sln（特にname.suo）を除く**すべて*ファイルを削除します
  3. Visual Studioを開き、それを使用してname.slnを開きます
  4. 接続ダイアログが表示され、適切なポート/クライアント/ユーザーを使用して、[OK]をクリックします。
  5. ソリューションエクスプローラーには、南京錠オーバーレイアイコンでソリューションノードが表示されます。 Source-controlled blank solution
  6. [ファイル]-> [ソース管理]-> [ソース管理の変更...]を使用して、ソリューションのソース管理ステータスを確認できるようになりました。 Source control status of blank solution 注：「サーバーバインド」列には、「SccProjectName0」に選択した値が表示されます。

新しいプロジェクトのソース管理

新しいプロジェクトを作成していて、Perforceデポですぐに追跡を開始したい場合は、次の手順に従ってください：

  1. Visual Studioでソース管理ソリューションを開きます
  2. [ファイル]-> [追加]-> [新しいプロジェクト...]-追加するプロジェクトの種類、名前、場所を選択します（場所はソリューションファイルが保存されているディレクトリのサブディレクトリである必要があります）
  3. [ファイル]-> [すべて保存]（これにより、メモリ内のすべての変更がソリューションファイルと新しく作成されたプロジェクトファイルにディスクにコミットされます）

  4. 選択したエディターを使用して、作成したプロジェクトファイルを手動で編集します（メモ帳をもう一度入力してください;-)）。次のプロパティ要素を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";これは、どのSCCAPIプロバイダーが有効なScc *バインディング値であるかを判別するために使用されます

  5. Visual Studioに切り替えます。プロジェクトファイルが外部で更新されたことを自動的に検出し、それをリロードすることを提案する（そうでない場合は、プロジェクトを手動でアンロードしてリロードする）

  6. [表示]-> [保留中のチェックイン]
  7. 「チェックイン」->（solutionName）.vsssccファイルを右クリックして、「変更しない場合は元に戻す」を選択することをお勧めします（Visual Studioで編集のために開いても、変更されないままです）。説明を提供し、変更を送信する

新しく追加されたプロジェクトが適切にバインドされていることを確認するには、次の手順を実行できます。

  1. Visual Studioが閉じていることを確認してください
  2. （solutionName）.suoファイルとMSSCCPRJ.SCC（ソリューションディレクトリ内）を削除します
  3. Visual Studioを開き、それを使用して（solutionName）.slnを開きます
  4. 接続ダイアログが表示され、適切なポート/クライアント/ユーザーを使用して、[OK]をクリックします。
  5. ソリューションエクスプローラーには、南京錠オーバーレイアイコンでプロジェクトノードが表示されます。 Source-controlled projects

  6. [ファイル]-> [ソース管理]-> [ソース管理の変更...]を使用して、ソリューションのソース管理ステータスを確認できるようになりました。 Status of source-controlled projects

    このステータススクリーンショットについて注意すべきことは、ソリューション行を選択したときに、残りの行もすべて「選択」されたことです（青のハイライト）。これは、これらすべてのエントリが同じ「サーバーバインディング」+「ローカルバインディング」を持ち、したがって同じソース管理プロバイダー（P4）接続を共有するためです。

    また、両方のプロジェクトの「相対パス」には2つのレベルがあり、同じ「ローカルバインディング」、つまりソリューションファイルが存在するディレクトリに関連していることに注意してください。

既存の（バインドされていない）プロジェクトのソース管理

他のPerforceソリューションでまだ使用されていない既存のプロジェクトがある場合は、以下の手順に従ってPerforceに追加します（つまり、以前にソース管理されていない（インターネットダウンロードなど）または異なるソース管理を使用していたプロジェクトをインポートします）プロバイダー（Visual Source Safeなど）。

  1. プロジェクトを適切な場所にコピーします
  2. 既存のソース管理バインディングをクリーンアップします（ある場合）：
    • 既存のプロジェクトファイルバインディング、つまり「Scc」で始まるすべてのプロパティを削除します
    • プロジェクトファイルと同じディレクトリにあるファイル（projectName）.vspsccを削除します（存在する場合）
  3. Visual Studioでソース管理ソリューションを開きます
  4. 「ファイル」->「追加」->「既存のプロジェクト...」-プロジェクト（手順1で作成したコピー）を参照します
  5. [ファイル]-> [すべて保存]（メモリ内のすべての変更をソリューションファイルにコミットします）
  6. 「新しいプロジェクトのソース管理」の手順4〜7に従います（つまり、「Scc *」プロパティ要素をPropertyGroupに追加します）

検証手順は、「新しいプロジェクトのソース管理」セクションとまったく同じです。

既存の（バインドされた）プロジェクトのソース管理

ここで説明した手法を使用して既にPerforceにバインドされているプロジェクトがあり、それらを別のソリューション（新しいブランチ、プロジェクトを再利用する代替ソリューションなど）で使用する場合は、次の手順を使用します。

  1. プロジェクトを目的の場所に統合する
  2. Visual Studioでソース管理ソリューションを開きます
  3. 「ファイル」->「追加」->「既存のプロジェクト...」-手順1で作成したプロジェクトを統合して参照します
  4. 「表示」->「保留中のチェックイン」->「チェックイン」-説明を追加して送信

概要

  • ソース管理バインディング情報は、ソリューションとプロジェクトの両方に保存され、同期する必要があります（同期しない場合、Visual Studioは矛盾を修正しようとします）
  • 私は常にプロジェクトファイルをバインディング情報の主要なソースとして扱い、ソリューションファイルは最初に空のソリューションをソース管理してから目的のプロジェクトを追加することで簡単に再作成できる使い捨てファイルとして扱います
  • ソリューションファイルには、常に有効なSccProviderおよびSccProjectNameの値が必要です（P4SCCプラグインの新しいバージョンでは手動で追加する必要があります）
  • プロジェクトファイルには、常に有効なSccProjectName（できればSccProjectNameと同じ）、SccLocalPathおよびSccProviderの値が必要ですP4SCCのデフォルトはダメなので、手動で編集してください）

また、元の質問への回答も含めています。

「ソース管理の変更」を行ってプロジェクトをバインドするとどうなりますか？ Visual Studioは、プロジェクトファイルとソリューションファイルに何を入れるかをどのように決定しますか？

これにより、再バインドするプロジェクトファイルの「Scc *」要素が更新されます。ソリューションファイルも更新され、プロジェクトファイルのバインディングと同期します。

「ソース管理から開く」を実行するとどうなりますか？

開きたいソリューションを選択できます。その後、ソリューションに含まれるすべてのプロジェクトが自動的にヘッドに同期されます。この機能は、とにかくクライアントを作成する必要があるPerforceの世界ではあまり役に立たず、Visual Studioに依存する代わりにP4V/P4Win/P4からこのクライアントを同期する可能性があります。これは、ビューの概念がなく、レポジトリがチェックアウト時にどこに行くかを定義していたVisual Source Safeの世界では、一種の有用なものでした。

SccLocalPathとSccProjectFilePathRelativizedFromConnectionが参照するこの「接続」フォルダーは何ですか？ Visual Studio/Perforceはどのようにそれを選択しますか？

これはVisual Studioの簿記です。各プロジェクトファイルのバインディングに基づいて決定されます（理論上、プロジェクトファイルが何らかの理由でバインディング情報を失った場合、ソリューション情報から再構築できる可能性があります...）

ソリューションの新しいブランチを作成する場合でも、ソース管理バインディングを引き続き機能させるための推奨方法はありますか？

上記のセクションが、私にとって非常にうまく機能している方法のアイデアを提供してくれることを願っています:-)。

102
Milan Gardian

ミラノの投稿はよく研究され、よく書かれていますが、その長さはP4SCCモデルが壊れているという疑いの影を越えて実証しています。プロジェクトとソリューションファイル内にソース管理バインディング情報を保存するのはばかげています。プロジェクトが1つのソリューションのみの一部であることを（sccprojectnameを介して）強制することも同様にばかげています。

さらに、P4SCCは、起動時に各ファイルのソース管理から情報を取得し、開発セッション全体を通じてその状態をメモリに保持するため、大規模なソリューションでは多大なパフォーマンスコストがかかります。情報なしの.vssccおよびvsssccファイルの形式で余分なクラフを作成して、（= AFAICT）Perforceが使用しない一部のSCC機能をサポートします。

理想的なPerforce統合は次のようになります。

  • 新しいソリューション、プロジェクト、またはプロジェクトアイテムを作成する場合は、「p4 add」を実行します。
  • ファイルを変更した場合、「p4 edit」を実行します。
  • 改訂履歴、改訂グラフ、タイムラプス/非難、および「P4 GUIで表示」用のツールバー/コンテキストメニューの統合。
  • （持っている必要があります）デポに存在するファイルの名前を変更する場合、「p4 integrated」および「p4 delete」を実行します。追加用に開いたファイルの名前を変更する場合は、「p4 revert」および「p4 add」を実行します。
  • それで全部です

P4SCCとその奇妙な要件と負担から完全に離れました。代わりに NiftyPerforce を使用します。いくつかのバグがありますが、Perforce <-> VSSCCモデルの設計上の欠陥を回避するよりも、これらのバグを回避する方がはるかにストレスが少ないことがわかります。

22
Timbo

これを最新に保つために-P4VSプラグインは2012年頃に書き直されました

IDEから直接、コードのチェックインやファイル履歴の表示など、Perforceとの日常的な操作をすべて自然に実行できるようになりました。

あなたがもう少し探しているパワーユーザーであれば、P4VSは失望しません。 P4VSはPerforceストリームと完全に互換性があり、ストリームグラフはタイムラプスビューとリビジョングラフとともにIDEからアクセスできます。ブランチ管理を担当している場合は、P4VSからもマージできます。

また、リモートで作業する場合、またはプライベートブランチを少し実行する場合は、P4VSを介してP4Sandboxを構成できます。

9
KCD

P4CONFIG環境変数を使用すると、Visual StudioでPerforceを簡単に使用できます。

基本的には、Visual Studioの[ツール]-> [オプション]-> [ソース管理]-> [プラグイン設定]、[詳細設定]ボタンを選択します。これにより、SCC統合に固有のPerforce構成ダイアログが表示されます。[接続]タブに切り替え、[Perforce環境設定に一致するワークスペースをバインド]というラジオボタンをオンにします。 P4Vの[編集]-> [設定]に同じダイアログがありますが、p4vの動作にのみ影響します。

P4CONFIG環境変数の設定方法は、ある程度あなた次第です。どこでも同じ名前を付けるのが好きなので、システム全体の環境変数P4CONFIGを設定して、p4config.cfgという名前のファイルを探します。このファイルはiniスタイルのファイルであり、P4USER、P4CLIENT、P4Hostなどの他の変数を割り当てることができます。Perforceは、現在のディレクトリとすべての親ディレクトリでこのファイルを検索します。基本的に、このファイルは、clientspecがハードドライブ上でマップされている場所の最もルートディレクトリに置き、そのままにしておきます。

このアプローチは、SCC構成が機能するためにVisual Studioで必要な「正確さ」の量を大幅に削減します。（SAKバインディングが正常に機能するなど）

コードを初めてperforceから同期するか、完全にクリーンなディレクトリ構造に同期した後、perforceが一時的にオフラインで作業するかバインディングを削除することを求めるダイアログを取得した場合、まだ編集が必要です。主に.slnファイル自体を変更して、slnにSCCバインディングがあることを認識させる必要があります。これは、.slnファイルのSccNumberOfProjectsの直後に次のフィールドを配置することで行います。

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

P4CONFIGアプローチを使用している場合、個々のプロジェクトはすべてデフォルトの「SAKバインディング」で正常に動作するはずです。これを修正することで、Perforceは完全な同期から完全に動作できるようになり、各プロジェクトディレクトリでのMSSCCPRJ.SCCクラフの生成もなくなります。

5
Zoner

ファイルの名前変更または新しいフォルダーディレクトリへの移動のサポートは、ひどいであり、Visual Studio P4プラグイン統合を使用する場合は苦痛です。 P4にファイルの名前変更または移動されたことを警告する組み込み機能はありません。

問題は、ファイルの名前を変更するには、関連するVSプロジェクトファイルを更新するだけでなく、適切な改訂履歴を維持する場合は、Perforceに変更も通知する必要があることです。

現在、VS統合を使用している場合、単一の操作で両方を実行する方法はありません。代わりに、次のことを行う必要があります。

  1. perforceクライアント内からファイルの名前を変更/移動する
  2. vS内のプロジェクトファイルの古いファイル名参照を削除します
  3. vS内のプロジェクトファイルに新しいファイル名参照を追加します
  4. 変更を送信する

継続的インテグレーションビルドプロセスを使用し、最後の手順の前の任意の時点で変更を送信すると、ビルドが破損することが保証されます。

この問題は、名前の変更や移動が必要なファイルが増えるほど大きくなります。これはスムーズなプロセスではありません。

4
Ray Vega

Milan Gardianの非常に有益な答えを試した後、それをかなりうまく機能させるための簡単なソリューションを提供できると思います。

Weebleが述べたように、SAKの値は、他のすべてが正しく設定されていれば正常に機能し、多くの場合デフォルト値です（ただし、プロジェクトの種類によって異なります）。プロジェクトに表示されない場合は、このプロパティグループに貼り付けてください。

<PropertyGroup>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>

これら2行をSourceCodeControl GlobalSectionの* .slnに追加します。プロジェクトファイルにSAK値がある限り、ソリューションから名前を継承する必要があります。

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

* .vssscc、*。vspscc、または* .SCCファイルをチェックインする必要はありません（ただし、ソリューションを開くときに生成されます）。

3
Dave Andersen

非常に悪い。それはあなたが探していたあなたの質問に対する答えではないことを知っています（将来、おそらく焦点を絞ることができるでしょうか？）が、Visual Studioとのソース管理の統合はただひどいものです。全員がMicrosoftのひどいSCCインターフェイスを使用する必要があるためです。これは哀れです！プロジェクトファイルにソース管理情報を入れています！なぜそうするのですか？

Visual Studioとの統合を放棄し、Perforceクライアントを使用するだけです。それほど余分な作業ではありません。 Perforceクライアントに切り替えてそこからファイルをチェックイン/チェックアウトするために1日あたり30秒を節約することはできませんか？

2
raven

最後の質問に答えることができます。

新しいブランチを作成してもソース管理バインディングが機能するようにするには、厳密な階層構造に従います。

/Solution
  /library1
  /library2
  /product1
  /product2
  /subsolution
    /sublibrary1
    /subproduct1

各ファイルは、正確に1つの.vcprojに存在する必要があります。同じディレクトリに複数の.vcprojを配置できますが、ファイルを共有する場合、共有ファイルは独自の.vcprojに移動する必要があります。

これに執lentであれば、すべてのSccスタッフは相対パスになり、新しいブランチが機能します（最上位ディレクトリのみが変更されるため）。

1
Thomas L Holaday