Visual Studio，svn和合并.csproj和.sln文件

Question

有人成功地让SVN合并两个用户编辑过的Visual Studio项目(.csproj)或解决方案(.sln)文件吗？例如：

1. 用户A检出项目
2. 用户B检出同一项目
3. 用户A添加一个文件
4. 用户A提交更改
5. 用户B添加一个文件
6. 用户B提交更改

在步骤(6)中，svn、Tortoise、Ankh或其他应该检测到冲突，并自动合并两个项目文件，或更可能是提示用户B解决冲突。目前，当用户B提交时，由用户A所做的更改被抹掉，导致构建、部署等出问题，缺少在最后一次检入之前添加的功能。

由于项目文件是XML格式，为什么会出现这样的问题？我有什么遗漏吗？我在这里搜索了存档，并谷歌了一下，但没有找到好的解决方案。

- 3Dave

---

你是否正确设置文件的MIME类型？ - Timo Geusch

由于User B的文件过时，他提交的内容应该被拒绝，迫使他更新文件（并合并——大多数更改确实会自动处理）。 - Tom Mayfield

是的，在第6步，svn客户端应该报告工作副本已过期。某些地方肯定出了问题，因为这对我们有效。 - crashmstr

我确实遇到过这种情况，如果用户A和B在不同的功能分支上，并且使用添加项目到解决方案（而不是添加文件到项目）的方式进行操作。虽然这可能是一个单独的话题... - Chris R. Donnelly

Answer 1

你认为你如何欺骗SVN执行第6步？看起来你误解了出现的问题。SVN永远不会从一个未更新的工作副本提交更改，因此在用户B之前未更新并合并用户A的更改时，第6步将无法完成。老实说，试试看。

我猜发生的情况是这样的：

1. A 检出项目。
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的更改。

我偶尔看到这种情况发生，通常发生在不太理解SVN（或CVS，FTM）工作流程的用户B身上。

因此，以下是一些提示： 不要更新除非你已经保存了所有内容（“文件”->“全部保存”；对我来说，是Ctrl+Shift+S）。如果犯了这个错误而卡住了，请覆盖磁盘上的更改，然后手动合并丢失的更改。（也可以将项目/解决方案文件更新回版本N-1，然后再更新到HEAD，以便让SVN执行合并。） 不要在检查更改的文件并快速检查差异之前提交，以确定更改是否符合预期。

早提交，经常提交。当越来越多的开发者在同一代码库上工作时，冲突的可能性就越大。如果你改变工作副本而不更新时间越长，冲突的可能性也越大。由于开发者数量通常不受你控制，因此更新频率是你可以利用的唯一方式来减少冲突的概率。

- sbi

---

这听起来非常熟悉。这可能更多是一个培训问题，而不是技术问题。 =/ - 3Dave

Answer 2

我支持sbi的答案。一个可能的解决方案是始终在Visual Studio中更新，至少如果您使用VisualSVN（我不确定AnkhSVN如何处理此情况）。

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

- jeroenh

Answer 3

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

您可以在项目文件中使用通配符：参见 MSDN。

示例：

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

很遗憾，Visual Studio不鼓励这种项目设置方式，而是选择列出单个文件。

- Stefan Sieber

Answer 4

一种相当激进但高效的解决方案是使用工具从元定义生成这些解决方案文件，然后仅将元定义放在源代码控制下，而不是Visual Studio项目文件（这些文件很难合并）。

在我的团队中，我们使用MPC来完成这项任务。我们有：

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

由于它们都是手动编辑的文本文件，因此我们不再遇到Visual Studio混淆一切的问题。

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

• 项目配置是集中管理的：例如，在单个位置更改编译标志，而不是按项目进行更改，
• 这可以适应多个构建系统（我们目前使用Visual 2003和2005，但这也适用于gcc和其他系统）。

根据我的经验，尽管设置该工具可能有点痛苦（但这完全取决于您的项目的大小和复杂性），但这绝对值得一试。

请注意，MPC并不是唯一可用于此目的的工具。还有其他工具，例如CMake。

- Stéphane Bonniez

Answer 5

这非常繁琐和乏味，所以你只能耐心地完成它。有时候你会保留本地工作副本，因为它包含了所有自定义项目。然而，在其他情况下，你将希望合并来自基础解决方案的所有新项，以便你拥有两个解决方案文件中的所有内容。为了可读性，最好将所有基础产品添加放在定制添加之前。

不要担心项目GUID的前一部分是相同的，但是最后一部分将是唯一的。

Fissh

- gadildafissh