VisualStudio 的源代码控制集成如何与 Perforce 一起工作？

我们使用 Perforce 和 Visual Studio。每当我们创建一个分支时，除非我们使用“ Open from Source Control”，否则一些项目将不会绑定到源代码管理，但是其他项目可以正常工作。根据我的调查，我知道一些相关的事情:

在我们的. csproj 文件中，有以下设置:

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

有时它们都设置为“ SAK”，有时则不是。如果上面写着“ SAK”，看起来事情就更有可能成功。

在我们的.sln 文件中，有许多项目的设置:

  • SccLocalPath #
  • 连接 #
  • SccProjectUniqueName #

(The # is a number that identifies each project.) SccLocalPath is a path relative to the solution file. Often it is ".", sometimes it is the folder that the project is in, and sometimes it is ".." or "..\..", and it seems to be bad for it to point to a folder above the solution folder. The relativized one is a path 来自 that folder to the project file. It will be missing entirely if SccLocalPath points to the project's folder. If the SccLocalPath has ".." in it, this path might include folder names that are not the same between branches, which I think causes problems.

所以，为了最终得到我想知道的细节:

  • 当您执行“更改源代码管理”和绑定项目时会发生什么？VisualStudio 如何决定在项目和解决方案文件中放入什么？
  • 当您执行“ Open from source control”时会发生什么？
  • SccLocalPath 和 SccProjectFilePathRelativizedFromConnection 所指的“连接”文件夹是什么? Visual Studio/Perforce 是如何挑选它的？
  • 即使在创建解决方案的新分支时，是否有一些推荐的方法使源代码管理绑定继续工作？

2012年6月新增: 我不再使用 Perforce，所以我不能保证它，但是看看下面的 KCD 的答案。显然 一个新的 P4 VS 插件正在开发中。希望它能把这些乱七八糟的东西都清理干净！

56723 次浏览
小开

我可以回答最后一个问题。

为了让源代码管理绑定即使在创建新分支时也能正常工作，请遵循严格的分层结构:

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

每个文件必须正好在一个文件夹中。Vcproj.你可以有多个。Vcproj 放在同一个目录中，但是如果它们共享文件，那么共享文件必须放在它们自己的目录中。Vcproj.

如果您坚持这样做，那么所有的 Scc 内容都将是相对路径的，因此一个新的分支将会工作(因为它只改变最顶层的目录)。

小开

非常糟糕。我知道这不是你所寻找的问题的答案(将来，也许你可以缩小焦点范围?)但是 Visual Studio 的源代码控制集成实在是太糟糕了。原因是他们都必须使用微软糟糕的 SCC 界面。太可悲了！他们把源代码控制信息放在项目文件中！他们为什么要这么做？

只要放弃 VisualStudio 集成并使用 Perforce 客户端即可。也没有那么多额外的工作。您不能每天腾出30秒来切换到 Perforce 客户机并从那里签入/签出文件吗？

小开

支持重命名文件或将其移动到新的文件夹目录是 糟透了，如果使用 VisualStudioP4插件集成，则会非常痛苦。没有内置的功能存在，提醒 P4重命名文件或它已被移动。

问题是，重命名一个文件不仅需要更新相关的 VS 项目文件，而且如果您希望保持适当的修订历史，还需要将更改通知 Perforce。

目前，如果使用 VS 集成，我没有看到在单个操作中同时执行这两项任务的方法。相反，你必须:

  1. 在 Perforce 客户机中重命名/移动文件
  2. 删除 VS 中项目文件中的旧文件名引用
  3. 在 VS 中的项目文件中添加新的文件名引用
  4. 提交你的修改

如果您使用持续集成构建过程，并且在最后一步之前的任何时候提交更改，那么您肯定会有一个中断的构建。

这个问题显著地放大了更多需要重命名或移动的文件。无论如何，这都不是一个平稳的过程。

小开
最佳答案

简介

我不同意在 Visual Studio 中的 Perforce 集成是“可怕的”这种说法。相反，我会将其定义为“开箱即用的体验不是最佳的”: ——)。以下部分讨论我对集成的理解以及对项目/解决方案设置的建议。

如果您对源代码控制集成是如何工作的细节不感兴趣，可以跳到这个答案的最后，在那里我将总结对 Weeble 问题的答案。

免责声明 : 以下部分只是基于我的经验做出的猜测，但是我已经在许多项目中使用这种技术很多年了(每个项目都有多个实验/主干/维护/发布分支，有时甚至有多个解决方案文件，没有问题)。缺点是，你必须更新 手动操作的项目文件-但2分钟的投资是在一个项目的生命周期相当不错的摊销恕我直言: -)。

解决方案与项目

VisualStudio 在初始解决方案加载期间使用来自解决方案文件和每个项目文件的源代码管理绑定信息。这个绑定信息然后存储在 姓名，所文件中(假设我们使用 名字作为解决方案)-注意，所以文件被标记为 藏起来了标志，因此它们不会在文件资源管理器中可见(除非你覆盖“隐藏文件和文件夹”选项)。

如果出现错误，重新绑定到源代码管理提供程序的最简单方法是删除适当的 所以文件并重新打开解决方案。在创建 suo 文件之后，对 < Scc * > 元素的更改没有效果。

如果在最初的解决方案打开过程中，解决方案文件中存储的绑定信息和项目文件中存储的信息之间存在差异，Visual Studio 会尝试解决这个问题(有时它甚至会提示你选择解决方案中的信息还是项目中的信息作为“主”来解决这个差异) :

alt text

为什么 Visual Studio 违反了 DRY (不要重复自己)原则？我不知道。我认为这是有历史原因的，并且与“视觉源码安全: ——”这个噩梦的需求紧密相连。

如何设置“正确”？

向 Perforce 添加新的或现有的解决方案/项目时，我从创建空白解决方案开始(请参阅“源代码控制空白解决方案”一节)。然后，我将一个又一个项目添加到这个空白解决方案中。根据添加的项目是否已经存在(参见“源代码控制现有(未绑定)项目”和“源代码控制现有(已绑定)项目”部分)或者我需要创建一个新项目(参见“源代码控制新项目”部分) ，这些步骤略有不同。

源-控制空白解决方案

若要向源代码管理添加新的空白解决方案，请执行以下操作:

  1. 启动 Visual Studio，“ New”-> “ Project...”-> “ Other Project type”-> “ Blank Solution”; 填写解决方案名称和位置，“ OK”按钮
  2. “文件”-> “源代码管理”-> “向源代码管理添加解决方案...”
  3. 在连接对话框中输入适当的 P4服务器端口、客户端和用户(请注意，所选客户端的视图必须包括您在步骤1中选择的位置)
  4. 在提交对话框中点击“查看”-> “挂起的检查”-> “签入”-> 而不是点击“提交”按钮，使用“取消”。
    理由 : “ Check In”操作将创建一个新文件“ name.vssscc”，然后将“ name.sln”和“ name.vssscc”添加到 Perforce 的默认变更列表; 通过取消提交对话框，我们将保持“ add”操作挂起，并能够在提交到 P4之前编辑文件
  5. 关闭 VisualStudio

  6. 在你最喜欢的编辑器中打开 name.sln 文件(记事本，如果你真的很绝望的话: ——) ，添加两行新的代码(SccProjectName0和 SccProvider0)——空白的解决方案文件现在应该有一个源代码控制部分，如下所示:

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

    这些数值应选择如下:

    • SccProjectName0 : 一个任意字符串，将在“ Change Source Control”对话框中显示为“ Server Binding”。此名称用于确定哪些项目/解决方案文件可以共享相同的源代码管理连接。我建议不要为此名称使用空格，因为空格的转义规则在解决方案文件和项目文件中是不同的。
    • SccProvider0 : 硬编码值“ MSSCCI: Perforce u0020SCM”。
  7. 使用您选择的 Perforce 客户端(p4.exe，P4Win，P4V)提交两个挂起的文件

现在可以测试绑定:

  1. 确保 VisualStudio 已关闭
  2. 除 name.sln (特别是 name.suo)外，删除 * * 所有 * 文件
  3. 打开 Visual Studio 并使用它打开 name.sln
  4. 应该会出现一个连接对话框，使用适当的端口/客户端/用户，然后单击 OK
  5. 解决方案资源管理器现在应该用挂锁覆盖图标显示解决方案节点: Source-controlled blank solution
  6. 您现在可以通过使用“ File”-> “ Source Control”-> “ Change Source Control...”来验证解决方案的源代码管理状态: Source control status of blank solution 注意: “ Server Binding”列显示了我们为“ SccProjectName0”选择的值。

源代码控制新项目

如果你正在创建一个全新的项目，并且想要立即开始在 Perforce 仓库中跟踪它，请遵循以下步骤:

  1. 在 VisualStudio 中打开受源代码管理的解决方案
  2. “ File”-> “ Add”-> “ New Project...”-选择要添加的项目类型、名称和位置(location 应该是存储解决方案文件的目录的子目录)
  3. “ File”-> “ Save All”(这会将所有内存中的更改提交到解决方案文件，并将新创建的项目文件提交到磁盘)

  4. 手动编辑您刚刚创建的项目文件，使用您选择的编辑器(来吧，记事本再次？;-) ).将以下属性元素添加到 PropertyGroup (任何属性组) :

    <PropertyGroup>
...
<SccProjectName>Tutorial</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
...
</PropertyGroup>

    这些数值应选择如下:

    • SccProjectName -这是在“ Change Source Control”对话框中显示为“ Server Binding”的值; 应该与您在空白解决方案中为 SccProjectName0使用的值相同; 如果不相同，解决方案和该项目将不能共享相同的源代码管理提供程序连接
    • SccLocalPath -到引用目录的相对路径(在“ Change Source Control”对话框中显示为“ Local binding”) ; 因为我建议使用解决方案目录作为引用目录，这实际上是从包含项目文件的目录到包含解决方案文件的目录的相对路径(我的例子是将项目存储在“(solutionDir)/Source/ProjectName/projectName.csproj”中，因此相对路径是“上两级”)
    • SccProvider -硬编码值“ MSSCCI: Perforce SCM”; 这用于确定哪些 SCCAPI 提供程序是有效的 Scc * 绑定值

  5. 切换回 VisualStudio; 它应该自动检测到项目文件已经在外部更新，并提供重新加载(如果没有，则手动卸载和重新加载项目)

  6. “查看”-> “正在等待检查”
  7. “ Check In”-> 我建议右键单击(solutionName)。Vssscc 文件，然后选择“ Revt if without”(即使 Visual Studio 打开它进行编辑，它仍然保持不变) ; 提供描述并提交更改

要验证新添加的项目是否正确绑定，可以按照以下步骤操作:

  1. 确保 VisualStudio 已关闭
  2. 删除(solutionName) . suo 文件以及 MSSCCPRJ.SCC (在解决方案目录中)
  3. 打开 VisualStudio 并使用它打开(solutionName) . sln
  4. 应该会出现一个连接对话框，使用适当的端口/客户端/用户，然后单击 OK
  5. 解决方案资源管理器现在应该用挂锁覆盖图标显示项目节点: Source-controlled projects

  6. 您现在可以通过使用“ File”-> “ Source Control”-> “ Change Source Control...”来验证解决方案的源代码管理状态: Status of source-controlled projects

    关于这个状态截图需要注意的一点是，当我选择解决方案行时，所有剩余的行也都被“选中”(蓝色突出显示)。这是因为所有这些条目都具有相同的“服务器绑定”+ “本地绑定”，因此共享相同的源代码管理提供程序(P4)连接。

    还要注意，这两个项目的“相对路径”有两个级别，并且相对于相同的“本地绑定”——解决方案文件所在的目录。

源代码管理现有(未绑定)项目

如果您有现有的项目尚未在任何其他 Perforce 解决方案中使用，请按照以下步骤将它们添加到 Perforce (即导入以前未受源代码控制的项目(Internet 下载等)或正在使用其他源代码控制提供程序(Visual Source Safe 等))。

  1. 将项目复制到适当的位置
  2. 清理现有的源代码管理绑定(如果有的话) :
    • 删除现有的项目文件绑定，即所有以“ Scc”开头的属性
    • 在与项目文件(如果有的话)相同的目录中删除 file (projectName) . vspscc
  3. 在 VisualStudio 中打开受源代码管理的解决方案
  4. “文件”-> “添加”-> “现有项目...”-浏览到项目(您在步骤1中创建的副本)
  5. “ File”-> “ Save All”(将所有内存更改提交到解决方案文件)
  6. 按照“源代码控制新项目”中的步骤4-7(即，现在您将在 PropertyGroup中添加“ Scc *”属性元素)

验证步骤与“源代码控制新项目”部分中的步骤完全相同。

源代码管理现有(绑定)项目

如果您有已经使用这里讨论的技术绑定到 Perforce 的项目，并且希望在不同的解决方案中使用它们(新的分支、重用项目的替代解决方案等) ，请使用以下步骤:

  1. 将项目整合到所需的位置
  2. 在 VisualStudio 中打开受源代码管理的解决方案
  3. “文件”-> “添加”-> “现有项目...”-通过集成浏览到步骤1中创建的项目
  4. “查看”-> “待办签到”-> “签到”-添加描述并提交

摘要

  • 源代码管理绑定信息存储在解决方案和项目中，必须同步(如果不同步，VisualStudio 将尝试修复任何差异)
  • 我总是将项目文件作为绑定信息和解决方案文件的主要来源，将其视为可以通过源代码轻松重新创建的一次性文件——控制一个空白的解决方案，然后添加所需的项目
  • 解决方案文件应该始终具有有效的 SccProvider0和 SccProjectName0值(必须使用新版本的 P4SCC 插件手动添加)
  • 项目文件应该始终具有有效的 SccProjectName(最好与 SccProjectName0相同)、 SccLocalPath和 SccProvider值(也必须手动编辑，因为 P4SCC 缺省值不好)

我还附上了你最初问题的答案:

当您执行“更改源代码管理”和绑定项目时会发生什么？VisualStudio 如何决定在项目和解决方案文件中放入什么？

这会更新您正在重新绑定的项目文件中的“ Scc *”元素; 然后也会更新解决方案文件，使其与项目文件绑定同步

当您执行“ Open from source control”时会发生什么？

允许您选择要打开的解决方案。之后，解决方案中包含的所有项目都会自动同步到头部。我发现这个特性在 Perforce 世界中并不是很有用，因为在 Perforce 世界中，无论如何都要创建一个客户端，而且很有可能是从 P4V/P4Win/P4同步这个客户端，而不是依赖 Visual Studio。在 VisualSourceSafe 的世界里，这是非常有用的，因为那里没有视图的概念，而且您正在定义存储库的签出时间。

SccLocalPath 和 SccProjectFilePathRelativizedFromConnection 所指的“连接”文件夹是什么? Visual Studio/Perforce 是如何挑选它的？

这是 Visual Studio 的簿记。它是基于每个项目文件中的绑定来确定的(我猜想在理论上，如果一个项目文件由于某种原因丢失了绑定信息，那么可以根据解决方案信息重新构建它...)

即使在创建解决方案的新分支时，是否有一些推荐的方法使源代码管理绑定继续工作？

我希望上面的章节能够让你们了解一种对我来说非常有效的方法: ——)。

小开

米兰的帖子研究得很好，写得也很好，但是它的长度毫无疑问地证明了 P4SCC 模式已经被打破。在项目和解决方案文件中存储源代码管理绑定信息是荒谬的。强制(通过 sccprojectname)一个项目只是一个解决方案的一部分同样是荒谬的。

此外，P4SCC 在大型解决方案中具有巨大的性能成本，因为它在启动时从源代码管理检索每个文件的信息，并在整个开发会话期间在内存中维护该状态。它以无信息的形式制造了额外的麻烦。Vsscc & vssscc 文件来支持(AFAICT) Perforce 不使用的一些 SCC 特性。

理想的 Perforce 集成看起来是这样的:

  • 如果创建新的解决方案、项目或项目项，请运行“ p4 add”。
  • 如果我改变了一个文件，运行’p4编辑’。
  • 一些工具栏/上下文菜单集成，用于修订历史、修订图表、延迟/责备和“在 P4 gui 中显示”。
  • 如果我重命名一个存在于仓库中的文件，运行“ p4整合”和“ p4删除”。如果我重命名为 add 打开的文件，请运行‘ p4 return’和‘ p4 add’。
  • 仅此而已

我们已经完全摆脱了 P4SCC 及其奇怪的需求和负担。相反，我们使用 NiftyPerforce。虽然存在一些 bug，但是我们发现在 Perforce <-> VSSCC 模型中处理这些 bug 比处理设计缺陷要轻松得多。

小开

在试验了米兰加迪安非常丰富的答案之后，我想我可以提供一个更简单的解决方案，让它工作得非常好。

正如 Weeble 所提到的，当其他所有内容都正确设置时，SAK 值可以正常工作，而且它们通常是默认值(但我认为这取决于它是哪种项目类型)。如果它们没有出现在项目中，只需粘贴到此属性组中。

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

将这两行添加到 * 。在 SourceCodeControl GlobalSection 中的 sln。只要项目文件具有 SAK 值，它们就应该继承解决方案的名称。

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

没有 * 。Vssscc，* .Vspscc，or * .需要签入 SCC 文件(尽管它们将在打开解决方案时生成)。

小开

在 Visual Studio 中使用 Perforce 可以通过使用 p4CONFIG 环境变量来简化。

基本上你进入 Visual Studio，Tools-> Options-> Source Control-> Plug-in Settings，Advanced 按钮。这将打开一个针对 SCC 集成的 Perforce 配置对话框。切换到 Connection 选项卡，选中单选按钮“ Bind the workspace that match your Perforce 環境設置”。这将告诉 perforce 选择使用 p4CONFIG 环境变量来确定你所处的环境。同样的对话框存在于编辑-> 首选项下的 P4V 中，但是只影响 p4V 的行为。

如何设置 P4CONFIG 环境变量在某种程度上取决于你。我喜欢它们在任何地方都被命名为相同的名称，所以我设置了一个系统范围的环境变量 P4CONFIG 来查找一个名为 P4CONFIG.cfg 的文件。这个文件只是一个 ini 样式的文件，您可以在其中分配其他变量，如 P4USER、 P4CLIENT、 P4HOST 等。Perforce 将在工作目录和所有父目录中搜索这个文件，直到遇到一个。基本上，您把这个文件放在您的客户规范映射到的硬盘驱动器的根目录中，然后就不管它了。

这种方法极大地减少了视觉工作室中 SCC 配置需要的“正确性”，以便能够正常工作。(SAK 绑定工作良好等)

如果第一次将您的代码从 perforce 同步到一个完全干净的目录结构之后，出现了一个对话框，抱怨要么暂时离线工作，要么删除绑定，那么仍然需要进行一些编辑。主要是。需要修改 sln 文件本身，以便它知道 sln 本身具有 SCC 绑定。中的 SccNumberOfProjects 之后放置以下字段。档案。

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

如果您使用的是 P4CONFIG 方法，那么所有单独的项目都可以使用默认的“ SAK 绑定”。解决这个问题应该允许 Perforce 完美地从干净的同步中工作，并且还可以消除每个项目目录中 MSSCCPRJ.SCC cruft 的生成。

小开

只是为了保持这个最新的-P4VS 插件已经被重写大约2012年

现在你每天都可以表演了 自然地与 Perforce 交互，比如检入代码和查看文件历史, 直接从 IDE。

如果你是一个高级用户，寻找更多一点，P4VS 不会令人失望。 P4VS 完全兼容 Perforce 流和流图 可以从 IDE 访问，以及延时视图和修订 如果您负责分支管理，则可以进行合并 还有 P4VS。

如果您远程工作或者想要执行一些私有分支, 可以通过 P4VS 配置 P4Sandbox。

小开

这不是 Perforce 问题，而是 VisualStudio 问题。修改源文件以允许 VisualStudio 理解正在使用的 SCM 工具的荒谬要求是愚蠢的。

简单的答案是“停止使用 VisualStudio 源代码管理集成”。真是糟透了。即使是 TFS 也很糟糕。

如果希望能够从 VisualStudio 中签出，只需创建一个自定义工具。您只需使用适当的 VS 变量调用‘ p4 edit’即可。要恢复文件吗？同样的想法... 使用适当的变量调用 p4恢复。成交。

使用 p4v 来管理您的源代码控制需求(提交、历史、差异等) VisualStudio 作为源代码编辑器非常棒。作为一个单片机接口，它糟透了。


提交答案