我已经彻底阅读了这篇文章:Visual Studio 的源代码控制集成如何与 Perforce 一起工作?并发现它非常有用。但是,我有一个特定问题阻止我在 VS 中使用 Perforce。
在大多数情况下,我对插件没有任何抱怨(我仍在使用 P4VSCC 插件,因为新插件需要整个团队进行转换,目前无法进行)。一旦我了解了这些特质,我在使用插件时就遇到了一个问题。
我们的解决方案包含许多内置于单个部署包中的项目。因此,每个程序集的版本都是相同的。为了适应这一点和其他常见方面,我们定义了一个通用的“SharedVersionInfo.cs”文件,其中包含通常在 AssemblyInfo.cs 文件中找到的 AssemblyVersion 和 AssemblyFileVersion 属性。此文件存储在解决方案文件夹下的 Assets 文件夹中,并作为链接文件添加到每个项目的 Properties 文件夹中。从版本管理的角度来看,这非常有效,因为我们只需要在一个地方更改版本并且所有程序集都会更新。但是,当新开发人员首次打开解决方案或添加新项目时,Perforce 会遇到此问题。
当我们添加一个新项目时,这并不是什么大问题,但解决方案包含 80 个项目(并且还在增加),所以这对于新开发人员来说不是一个可行的补救措施!
我的理解是,问题与 VS 认为每个项目的绑定根在哪里有关。经过一番研究,我被引导找到项目的 MSSCCPRJ.SCC 文件在哪里。我发现整个解决方案结构中散布着许多 SCC 文件。所以...
第一个问题:为什么我的解决方案结构中有多个 MSSCCPRJ.SCC 文件?
我们还有几个在我们的解决方案中使用的共享/通用项目。这导致以下文件夹结构:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
ProjectA 和 ProjectB 都是 MySolution.sln 的一部分
第二个问题:如何设置绑定以便将 /Source 文件夹视为根目录?这将确保解决方案中包含的所有项目都在同一个绑定根目录下。Perforce 认为这个文件夹是根目录,我如何让 VS 和插件做同样的事情?