Visual Studio的源代码控制集成如何与Perforce一起使用？
我们正在使用Perforce和Visual Studio。 每当我们创build一个分支时，除非我们使用“从源代码pipe理打开”，否则一些项目不会被绑定到源代码控制，但是其他项目无论如何都可以工作。 从我的调查中，我知道一些涉及的事情：
在我们的.csproj文件中，有这些设置：
- <SccProjectName>
- <SccLocalPath>
- <SccAuxPath>
- <SccProvider>
有时候，他们都是“SAK”，有时候不是。 如果这些说“SAK”，似乎事情更有可能发挥作用。
在我们的.sln文件中，有很多项目的设置：
- SccLocalPath＃
- SccProjectFilePathRelativizedFromConnection＃
- SccProjectUniqueName＃
（＃是标识每个项目的数字。）SccLocalPath是相对于解决scheme文件的path。 通常是“。”，有时是项目所在的文件夹，有时候是“..”或者“.. \ ..”，看起来好像是指向上面的文件夹解决scheme 相对化的是从该文件夹到项目文件的path。 如果SccLocalPath指向项目的文件夹，它将完全丢失。 如果SccLocalPath中包含“..”，则此path可能包含分支之间不相同的文件夹名称，这是我认为会导致问题的原因。
所以，为了最终得到我想知道的细节：
- 当您执行“更改源代码pipe理”并绑定项目时会发生什么？ Visual Studio如何决定在项目和解决scheme文件中放置什么？
- 当你从“源代码pipe理”打开时会发生什么？
- SccLocalPath和SccProjectFilePathRelativizedFromConnection引用的这个“连接”文件夹是什么？ Visual Studio / Perforce如何挑选它？
- 是否有一些build议的方法来使源代码控制绑定继续工作，即使您创build解决scheme的新分支？
2012年6月增加：我不再使用Perforce，所以我不能保证它，但看看下面的KCD的答案 。 显然有一个新的P4 VS插件正在开发中。 希望它应该清除所有这一切！
介绍
我不同意在Visual Studio中Perforce集成是“可怕的”的说法。 相反，我将其定义为“开箱即用的体验不是最佳”:-)。 以下部分讨论了我对项目/解决scheme设置的集成和build议的理解。
如果你对源代码控制集成工作的细节不感兴趣，你可以跳过这个答案的结尾，我总结Weeble的问题的答案。
免责声明 ：以下部分只是基于我的实证经验的教育猜测，但是我在很多项目中使用了这项技术（每个项目有多个实验/干线/维护/发行分支，有时甚至是多个解决scheme文件，没有问题）。 缺点是你必须手动更新项目文件 – 但2分钟的投资是在一个项目的生命周期分摊很好恕我直言:-)。
解决scheme与项目
Visual Studio在初始解决scheme加载期间使用来自解决scheme文件和每个项目文件的源代码控制绑定信息。 这个绑定信息然后被存储在name.suo文件中（假设我们使用name.sln作为解决scheme） – 请注意， suo文件被标记为隐藏标志，因此它们在文件资源pipe理器中将不可见（除非您覆盖“Hidden文件和文件夹“选项）。
如果出现任何问题，重新绑定到源代码pipe理提供程序的最简单方法是删除相应的suo文件并重新打开解决scheme。 suo文件创build后，对<Scc *>元素的更改不起作用。
如果在最初的解决scheme打开过程中解决scheme文件中存储的绑定信息与存储在项目文件中的信息之间存在差异，Visual Studio将尝试解决此问题（有时甚至会提示您决定是select解决scheme中的信息还是项目信息应作为“主”来解决这个差异）：
为什么Visual Studio违反DRY（不重复自己）原则？ 我不知道。 我认为这是有历史的原因，并紧密结合这个叫做Visual Source Safe的噩梦的需求:-)。
如何设置“正确”？
在向Perforce添加新的或现有的解决scheme/项目时，我总是从创build一个空白的解决scheme开始（请参阅“源控制空白解决scheme”部分）。 然后，我会陆续向这个空白的解决scheme添加项目。 根据添加的项目是否已经存在（请参阅“源控制现有（未绑定）项目”和“源控制现有（绑定）项目”部分），或者需要创build一个新项目（请参阅“来源控制新项目”部分）。
来源控制一个空白的解决scheme
要向源代码pipe理添加新的空白解决scheme，请执行以下操作：
- 启动Visual Studio，“新build” – >“项目…” – >“其他项目types” – >“空白解决scheme”; 填写解决scheme的名称和位置，“确定”button
- “文件” – >“源代码pipe理” – >“添加源代码pipe理解决scheme…”
- 在连接对话框中input适当的P4服务器端口，客户端和用户（请注意，所选客户端的视图必须包含您在步骤1中select的位置）
- 在提交对话框中的“查看” – >“挂起检查” – >“检入” – >而不是点击“提交”button，使用“取消”。
原因 ：“检入”操作将创build一个新文件“name.vssscc”，然后将“name.sln”和“name.vssscc”添加到Perforce的默认更改列表中; 通过取消提交对话框，我们将保持“添加”操作未决，并能够在提交给P4之前编辑文件 - closuresVisual Studio
-
打开你最喜欢的编辑器（记事本，如果你真的绝望:-)）的name.sln文件，并添加两个新行（ SccProjectName0和SccProvider0 ） – 空白解决scheme文件现在应该有一个源代码pipe理部分，如下所示：
GlobalSection(SourceCodeControl) = preSolution SccNumberOfProjects = 1 SccLocalPath0 = . SccProjectName0 = Tutorial SccProvider0 = MSSCCI:Perforce\u0020SCM EndGlobalSection值应该select如下：
- SccProjectName0 ：将在“更改源代码pipe理”对话框中显示为“服务器绑定”的任意string。 此名称用于确定哪些项目/解决scheme文件可以共享相同的源控制连接。 我build议不要使用空格作为这个名字，因为在解决scheme和项目文件中空格的转义规则是不同的。
- SccProvider0 ：硬编码值“MSSCCI：Perforce \ u0020SCM”。
- 使用您select的Perforce客户端（p4.exe，P4Win，P4V）提交两个待定文件
您现在可以testing绑定：
- 确保Visual Studioclosures
- 删除除name.sln之外的所有*文件（特别是name.suo）
- 打开Visual Studio并使用它打开name.sln
- 应该出现连接对话框，使用适当的端口/客户端/用户，然后单击确定
- 解决scheme资源pipe理器现在应该显示带有挂锁图标的解决scheme节点：
- 您现在可以使用“文件” – >“源代码pipe理” – >“更改源代码pipe理…”来validation解决scheme的源代码pipe理状态：
注意：“服务器绑定”列显示了我们为“SccProjectName0”select的值。
源头控制新项目
如果您正在创build一个全新的项目，并希望立即开始在Perforce软件仓库中进行跟踪，请按以下步骤操作：
- 在Visual Studio中打开源代码pipe理的解决scheme
- “文件” – >“添加” – >“新build项目…” – select要添加的项目types，名称和位置（位置应该是存储解决scheme文件的目录的子目录）
- “文件” – >“全部保存”（这将提交所有内存中的更改解决scheme文件和新创build的项目文件到磁盘）
-
手动编辑你刚刚创build的项目文件，使用你select的编辑器（来吧，记事本再次？;-)）。 将以下属性元素添加到PropertyGroup（任何属性组）中：
<PropertyGroup> ... <SccProjectName>Tutorial</SccProjectName> <SccLocalPath>..\..</SccLocalPath> <SccProvider>MSSCCI:Perforce SCM</SccProvider> ... </PropertyGroup>值应该select如下：
- SccProjectName – 这是在“更改源代码pipe理”对话框中显示为“服务器绑定”的值; 应该与您在空白解决scheme中使用的SccProjectName0的值相同; 如果不一样，解决scheme和这个项目将无法共享相同的源代码pipe理提供程序连接
- SccLocalPath – 参考目录的相对path（在“更改源代码pipe理”对话框中显示为“本地绑定”）; 因为我build议使用解决scheme目录作为参考目录，这实际上是从包含项目文件的目录到包含解决scheme文件的目录的相对path（我的示例是将项目存储在“（solutionDir）/Source/ProjectName/projectName.csproj”中，因此相对path是“两个层面”）
- SccProvider – 硬编码值“MSSCCI：Perforce SCM”; 这用于确定哪些SCCAPI提供程序是Scc *绑定值有效的
-
切换回Visual Studio; 它应该自动检测到项目文件已被外部更新，并提供重新加载它（如果不是，手动卸载和重新加载项目）
- “查看” – >“挂起检查”
- “Check In” – >build议右键单击（solutionName）.vssscc文件，然后select“恢复，如果不更改”（即使Visual Studio打开它进行编辑，它保持不变）。 提供描述并提交更改
要validation新添加的项目是否正确绑定，可以执行以下步骤：
- 确保Visual Studioclosures
- 删除（solutionName）.suo文件以及MSSCCPRJ.SCC（在解决scheme目录中）
- 打开Visual Studio并使用它打开（solutionName）.sln
- 应该出现连接对话框，使用适当的端口/客户端/用户，然后单击确定
- 解决scheme资源pipe理器现在应该显示带有挂锁重叠图标的项目节点：
-
您现在可以使用“文件” – >“源代码pipe理” – >“更改源代码pipe理…”来validation解决scheme的源代码pipe理状态：
关于这个状态截图的一件事情是，当我select解决scheme行时，所有剩下的行也被“选中”（蓝色突出显示）。 这是因为所有这些条目具有相同的“服务器绑定”+“本地绑定”，因此共享相同的源控制提供商（P4）连接。
另请注意，两个项目的“相对path”有两个级别，并且与相同的“本地绑定”（即解决scheme文件所在的目录）相关。
控制现有（不受限制）项目的来源
如果您有任何其他Perforce解决scheme中尚未使用的项目，请按照以下步骤将它们添加到Perforce（即，导入之前没有受到源代码控制的项目（Internet下载等）或正在使用不同的源代码控制提供者（Visual Source Safe等）。
- 将项目复制到适当的位置
- 清理现有的源代码pipe理绑定（如果有的话）：
- 删除现有的项目文件绑定，即所有以“Scc”开头的属性
- 删除与项目文件相同目录中的文件（projectName）.vspscc（如果有的话）
- 在Visual Studio中打开源代码pipe理的解决scheme
- “文件” – >“添加” – >“现有项目…” – 浏览到项目（您在步骤1中创build的副本）
- “文件” – >“全部保存”（这会将所有内存中的更改提交到解决scheme文件）
- 按照“源代码pipe理新项目”中的步骤4-7（即您现在将“Scc *”属性元素添加到PropertyGroup中 ）
validation步骤与“源代码控制新项目”部分中的完全相同。
控制现有（受限）项目
如果您已经使用此处讨论的技术绑定了Perforce的项目，并且想要在不同的解决scheme（新分支，重复使用该项目的替代解决scheme等）中使用它们，请使用以下步骤：
- 将项目整合到所需的位置
- 在Visual Studio中打开源代码pipe理的解决scheme
- “文件” – >“添加” – >“现有项目…” – 通过集成浏览到在步骤1中创build的项目
- “查看” – >“挂起检查” – >“检入” – 添加说明并提交
概要
- 源代码pipe理绑定信息存储在解决scheme和项目中，必须同步（如果没有，Visual Studio将尝试修复任何差异）
- 我总是把项目文件作为绑定信息和解决scheme文件的主要来源，作为一次性文件，可以通过首先控制一个空白的解决scheme，然后添加所需的项目
- 解决scheme文件应始终有有效的SccProvider0和SccProjectName0值（必须手动添加新版本的P4SCC插件）
- 项目文件应始终有有效的SccProjectName （最好与SccProjectName0相同）， SccLocalPath和SccProvider值（也必须手动编辑，因为P4SCC默认值不好）
我还包括你原来的问题的答案：
当您执行“更改源代码pipe理”并绑定项目时会发生什么？ Visual Studio如何决定在项目和解决scheme文件中放置什么？
这会更新要重新绑定的项目文件中的“Scc *”元素; 解决scheme文件也会随之更新，以便与项目文件绑定同步
当你从“源代码pipe理”打开时会发生什么？
允许您select您想要打开的解决scheme。 之后，解决scheme中包含的所有项目都会自动同步到头。 我发现这个function在Perforce世界中并不是非常有用，无论如何您都必须创build一个客户端，而且您可能正在从P4V / P4Win / P4同步这个客户端，而不是依靠Visual Studio。 这在Visual Source Safe世界中非常有用，在这个世界中没有视图的概念，而且您正在定义资料库在结帐时的位置。
SccLocalPath和SccProjectFilePathRelativizedFromConnection引用的这个“连接”文件夹是什么？ Visual Studio / Perforce如何挑选它？
这是Visual Studio的记账。 它是根据每个项目文件中的绑定来确定的（我想在理论上，如果项目文件由于某种原因丢失了绑定信息，则可以从解决scheme信息中重新构build它）
是否有一些build议的方法来使源代码控制绑定继续工作，即使您创build解决scheme的新分支？
我希望上面的部分给你一些对我来说很好的方法的想法:-)。
米兰的这篇文章是经过深入研究，写得很好的，但篇幅不言而喻，P4SCC模型已经被打破了。 在项目和解决scheme文件中存储源代码pipe理绑定信息是荒谬的。 执行（通过sccprojectname）一个项目只是一个解决scheme的一部分同样荒谬。
此外，P4SCC在大型解决scheme中具有巨大的性能成本，因为它在启动时从每个文件的源代码控制中检索信息，并在整个开发阶段将该状态保持在内存中。 它会以无信息.vsscc＆vssscc文件的forms创build额外的垃圾邮件，以支持（AFAICT）Perforce不使用的某些SCCfunction。
理想的Perforce集成看起来像：
- 如果我创build新的解决scheme，项目或项目项目，请运行“p4 add”。
- 如果我更改文件，请运行“p4编辑”。
- 一些工具栏/上下文菜单整合的修订历史，修订图表，timelapse /责备，和'显示在P4 gui'。
- （很高兴）如果我重命名存在于软件仓库中的文件，请运行“p4 integrate”和“p4 delete”。 如果我重命名为添加打开的文件，请运行“p4 revert”和“p4 add”。
- 就这样
我们已经完全摆脱了P4SCC及其离奇的要求和负担。 相反，我们使用NiftyPerforce 。 有一些错误，但是我们发现解决这些错误的方法比解决Perforce < – > VSSCC模型中的devise缺陷要less得多。
只是为了保持目前的状况 – P4VS插件已被重写了大约2012年
现在，您可以自然地执行与Perforce的所有日常交互，如直接从IDE检入代码并查看文件历史logging。
如果您是一位高级用户，P4VS不会让人失望。 P4VS与Perforce Streams完全兼容，可以从IDE访问Stream Graph，以及Time-lapse View和Revision Graph。 如果你负责分支pipe理，你也可以从P4VS合并。
而且，如果您远程工作或想要做一些私有分支，可以通过P4VSconfigurationP4Sandbox。
- 在perforce.com上的P4VS页面
- 关于如何使用它的networking研讨会
在Visual Studio中使用Perforce可以通过使用P4CONFIG环境variables来简化。
基本上你进入Visual Studio，工具 – >选项 – >源代码pipe理 – >插件设置，高级button。 这将调出特定于SCC集成的Perforceconfiguration对话框。 切换到“连接”选项卡，然后选中标题为“绑定与Perforce环境设置相匹配的工作区”的单选button。 这将告诉perforce喜欢使用P4CONFIG环境variables来确定您所处的环境。 在“编辑” – >“首选项”下的P4V中存在相同的对话框，但仅影响p4v的行为。
如何设置P4CONFIG环境variables在某种程度上取决于您。 我喜欢让它们的命名相同，所以我设置了一个系统范围的环境variablesP4CONFIG来查找名为p4config.cfg的文件。 这个文件只是一个ini风格的文件，你可以在其中指定其他的variables，例如P4USER，P4CLIENT，P4HOST等等.Perforce会在当前目录和所有父目录中search这个文件，直到遇到这个文件。 基本上你把这个文件放在你的客户端映射到你的硬盘驱动器上的最根目录，并且保持独立。
这种方法大大降低了SCCconfiguration在Visual Studio中需要的“正确性”，以便正常工作。 （SAK绑定工作正常等）
如果在第一次将你的代码从perforce同步到完全干净的目录结构之后，得到一个抱怨想要临时脱机工作或删除绑定的对话框，仍然需要进行一些编辑。 主要是.sln文件本身需要被修改，所以它知道sln有自己的SCC绑定。 这是通过确保以下字段放在.sln文件中的SccNumberOfProjects之后来完成的。
SccProjectName0 = Perforce\u0020Project SccProvider0 = MSSCCI:Perforce\u0020SCM
如果您使用的是P4CONFIG方法，所有单个项目都应该使用默认的“SAK绑定”。 解决这个问题应该允许Perforce完美的工作在干净的同步，并且也消除了在每个项目目录中生成MSSCCPRJ.SCC cruft。
如果使用Visual Studio P4插件集成，支持重命名文件或将其移动到新的文件夹目录是非常可怕和痛苦的。 不存在警告P4重命名文件或已被移动的内置function。
问题在于重命名文件不仅需要更新关联的VS项目文件，而且如果要维护正确的修订历史logging，还需要通知Perforce以及更改。
目前，如果使用VS集成，我不会在单个操作中看到这两种方法。 相反，你必须：
- 在Perforce客户端中重命名/移动文件
- 删除VS中的项目文件中的旧文件名引用
- 在VS中的项目文件中添加新的文件名引用
- 提交您的更改
如果您使用持续集成构build过程，并且在最后一步之前的任何时候提交了更改，则可以保证构build中断。
问题显着扩大了需要重命名或移动的文件越多。 这不是一个平稳的过程。
经过对米兰Gardian非常丰富的答案的实验后，我想我可以提供一个更简单的解决scheme，以使其工作得很好。
正如Weeble提到的那样，SAK值在其他所有设置都正确的情况下工作正常，而且它们通常是默认值（但是我认为这取决于它是哪个项目types）。 如果他们没有出现在您的项目中，只需粘贴到此属性组中。
<PropertyGroup> <SccProjectName>SAK</SccProjectName> <SccProvider>SAK</SccProvider> <SccAuxPath>SAK</SccAuxPath> <SccLocalPath>SAK</SccLocalPath> </PropertyGroup>
将这两行添加到SourceCodeControl GlobalSection中的* .sln。 只要项目文件具有SAK值，就应该inheritance解决scheme中的名称。
SccProjectName0 = Perforce\u0020Project SccProvider0 = MSSCCI:Perforce\u0020SCM
没有* .vssscc，*。vspscc或* .SCC文件需要检入（虽然它们将在解决scheme打开时生成）。
很差。 我知道，这不是你正在寻找的问题的答案（将来，也许你可以缩小焦点？），但与Visual Studio的源代码控制集成只是糟透了。 原因是他们都必须使用微软可怕的SCC接口。 这是可悲的！ 他们把源代码控制信息放在项目文件中！ 他们为什么要那样做？
只要放弃Visual Studio集成并使用Perforce客户端即可。 这不是多余的工作。 您不能每天花30秒时间切换到Perforce客户端，并从那里检入/检出文件？
我可以回答最后一个。
为了在创build新分支时获得源代码控制绑定的function，请遵循严格的层次结构：
/Solution /library1 /library2 /product1 /product2 /subsolution /sublibrary1 /subproduct1
每个文件必须在一个.vcproj中。 您可以在同一个目录中有多个.vcproj，但如果它们共享文件，则共享文件必须放入它们自己的.vcproj中。
如果你在这里坚持不懈，所有的Scc的东西将是相对path，所以一个新的分支将工作（因为它只会改变最上面的目录）。
这不是Perforce问题，它是一个Visual Studio问题。 对于源文件进行修改以允许Visual Studio了解有一个SCM工具在使用的荒谬要求是愚蠢的。
简单的答案是“停止使用Visual Studio源代码控制集成”。 它只是简单的糟透了。 即使使用TFS，也很简单。
如果您希望能够从Visual Studio中检出，只需创build一个自定义工具即可。 只需要用适当的VSvariables简单地调用“p4编辑”即可。 想要恢复文件？ 同样的想法…调用p4恢复与适当的variables。 完成。
使用p4v来pipe理你的源代码控制需求（提交，历史，差异等）Visual Studio作为一个源代码编辑器。 它吸收作为一个SCM接口。
