Visual Studio、SVN和合并.csproj和.sln文件

你认为你如何欺骗SVN执行步骤6?似乎你误解了哪里出了问题。 SVN永远不会从非最新的工作副本提交 ,因此,如果没有用户B以前更新和合并用户A的更改,步骤6将无法工作。说真的?试试看。

我猜会发生的情况是:

1. 签出项目。
2. B签出同一个项目。
3. A添加文件。
4. a提交更改。
5. b添加文件,但忘记保存项目/解决方案。
6. B试图提交更改,并得到一条他应该首先更新的消息。
7. B更新。
8. b切换回vs.vs.告诉他项目/解决方案在磁盘上发生了更改,并询问他是否希望a)从磁盘重新加载并丢失更改b)重写磁盘上的版本。
9. B不理解,不尝试理解,认为他的更改有价值,然后选择B),覆盖磁盘上的更改。
10. B仍然不试图理解,因此也不会将磁盘上的版本与上一个提交的版本进行区分,从而忽略了A的更改。
11. B签入,覆盖A的更改。

我偶尔会看到这种情况发生,通常是因为用户B并不真正了解SVN(或CVS,FTM)的工作流程。

以下是一些提示:

除非保存了所有内容,否则不要更新 (“文件”->“全部保存”;对于我来说,这是ctrl+shift+s)。如果您犯了这个错误,并且卡住了,请重写磁盘上的更改,然后 手动合并丢失的更改 . (也可以将项目/解决方案文件更新回版本n-1,然后再次返回头部,以便让SVN执行合并。)

不检查更改的文件就不要提交 而且很快 看看区别 看看这些变化是否是你所期望的。

尽早承诺,经常承诺 . 开发人员在同一代码基上工作的越多,冲突的可能性就越大。在不更新的情况下更改工作副本的时间越长,发生冲突的可能性就越大。由于开发人员的数量通常不在您的控制范围之内,所以您可以使用更新频率来减少冲突的可能性。

我同意SBI的回答。一种可能的解决方案是始终在Visual Studio中更新,至少在使用VisualVN时是这样(我不确定AnkhsVN如何处理这种情况)。

VisualSVN将在更新操作期间阻止Visual Studio,并确保自动重新加载任何更改的项目,因此用户不能忽略外部更改。

一个相当激进但有效的解决方案是使用一个工具从元定义生成这些解决方案文件,然后只将元定义置于源代码管理下,而不是Visual Studio项目文件(这是一个合并的噩梦)。

在我的团队中我们使用 MPC 这样做。我们有:

• 一堆用于项目描述的.mpc文件,
• 用于工作区/解决方案描述的.mwc文件,
• 生成Visual Studio文件的小.cmd。

因为它们都是手工编辑的文本文件,所以我们不再有Visual Studio混淆所有内容的问题。

缺点是有一个额外的工具,需要在添加或删除文件时重新生成解决方案文件,但也有一些额外的好处:

• 项目配置是集中的:例如,更改编译标志是在单个位置而不是在每个项目的基础上完成的。
• 这可以适应多个构建系统(我们目前使用的是Visual2003和2005,但这也适用于GCC和其他系统)。

根据我的经验,尽管设置这个工具可能有点痛苦(但这一切都取决于项目的大小和复杂性),但这显然是值得的。

请注意,MPC并不是实现此目的的唯一工具。其他存在,如 CMake .

您还可以尝试通过确保项目文件不列出项目中的每个单独文件来减少冲突。这将避免在用户添加文件时首先更改项目文件。

您可以在项目文件中自由使用通配符: see MSDN

例子:

<ItemGroup>
  <Compile Include="Src\**\*.cs" />
  [...]
</ItemGroup>

令人遗憾的是,Visual Studio不鼓励这种项目设置,而是选择列出单个文件。

这是非常乏味和令人厌烦的,所以你只需要努力克服它。您有时会保留本地工作副本,因为它添加了所有自定义项目。但是,在其他情况下,您将希望合并基本解决方案中的所有新项,以便最终得到两个解决方案文件中的所有内容。为了可读性,最好在自定义添加之前放置所有基础产品添加。

不要担心,对于项目来说,guid的第一部分是相同的,但最后一部分是唯一的。

费什