2012-03-29 34 views

回答

3

这个问题没有无痛的解决方案。原因在于微软做出了将源代码控制信息嵌入到.NET解决方案和项目文件中的极其糟糕的决定。

假设迪克想要使用SCC插件,而简不这样做。

GlobalSection(SourceCodeControl) = preSolution 
    SccNumberOfProjects = 2 
    SccLocalPath0 = . 
    SccProjectUniqueName1 = someApp\\someApp.csproj 
    SccLocalPath1 = someApp 
EndGlobalSection 

和一些像这样的垃圾将被添加到该项目(或多个)文件:

<SccProjectName>SAK</SccProjectName> 
<SccLocalPath>SAK</SccLocalPath> 
<SccAuxPath>SAK</SccAuxPath> 
<SccProvider>SAK</SccProvider> 
迪克通过插件和信息像这样将被写入解决方案文件添加一个项目到版本控制

此外,一些文件将散布有关项目文件夹树(解决方案和项目文件夹中的MSSCCPRJ.SCC文件,解决方案文件夹中的* .vssscc和项目文件夹中的* .vspscc文件)。

只要Dick不检查它们到源代码管理中(尽管插件总是要检查这些.vssscc和.vspscc文件),额外的文件并不是问题。然而,写给解决方案和项目文件的源代码控制信息对Jane来说总是令人烦恼。

enter image description here

,然后这一个:每当她打开解决方案,她将这个消息唠叨

enter image description here

她应该选择的选项为“永久删除源代码控制的关联绑定“,源代码控制信息将从解决方案和项目文件中删除,她会很高兴。然而,迪克的SCC插件将不再工作,他可能会重新绑定项目来源控制和办公室骚乱将随之而来。总结一下,你可以在使用SCC插件的人和不使用SCC插件的人之间共享.NET项目,但是一方或多方将不得不忍受一些烦恼,因为微软决定添加源代码控制信息到.NET项目文件(这是一个糟糕的决定,这在Visual Studio 6中不是问题)。

+0

我非常了解这一点,但我想我想让其他人告诉我同样的事情。瘸。 – poindexter12 2012-04-09 18:23:51

0

我不完全相信如果我把你的权利。我假设你的一半团队想要使用Visual Studio插件来访问Perforce,而另一半则不需要。

这是可能的。您必须确保从不检入由插件创建的MSSCCPRJ.SCC文件。这是本地绑定信息,并不适用于每个人的工作站。

另一方面,* .vssscc文件可以并应该进入Perforce。

虽然使用插件有一个很大的优点:插件知道要检入哪些文件以及要省略哪些文件。特别是在添加新项目时,在使用Perforce可视客户端而不是插件时忘记检查新创建的文件是一种常见的错误。

0

您必须确保永不检查插件创建的MSSCCPRJ.SCC文件 。

我删除了* .scc文件,但Visual Studio阻止我使用其他源代码控件插件除保存到解决方案和项目文件外。

相关问题