任何人都有成功让SVN合并由两个用户编辑的Visual Studio项目（.csproj）或解决方案（.sln）文件？实施例Visual Studio，svn和合并.csproj和.sln文件
在我看来，在步骤（6），svn，乌龟，安科或任何应该de引发冲突并自动合并两个项目文件，或者更有可能提示用户B解决冲突。目前，我们看到用户A在用户B签入时所做的更改，导致在最后一次签入之前添加的错误构建，部署等缺失功能。
由于项目文件是XML，为什么这是一个问题？我在这里错过了什么吗？我在这里搜索了档案，并且搜索到了我不能谷歌没有更多，但还没有拿出一个很好的解决方案。
你认为你怎么欺骗SVN执行第6步？看来你误解了错误。 SVN永远不会提交最新的工作副本，因此，如果用户B先前未更新和合并用户A的更改，则步骤＃6将不起作用。老实说。尝试一下。
我猜会发生什么，而不是是这样的：
我已经看到过这种情况偶尔会发生，通常与用户B不太了解SVN（或CVS'，FTM）工作流程。
所以这里有一些提示：
不要更新，除非你已经保存的一切（ “文件” - > “全部保存”;对我来说，这是按Ctrl + Shift + S）。如果你已经犯了那个错误，你就完蛋了，不重写磁盘上的更改，然后手动合并更改将丢失。 （它也可能会将项目/解决方案文件更新回N-1版本，然后再次更新到HEAD，以便让SVN执行合并。）
不提交而不检查哪些文件改变并具有快速看的diff看到的变化是否你所期望的。
提早提交，经常提交。越多的开发人员在相同的代码基础上工作，就越有可能发生冲突。您更改工作副本而不更新的时间越长，发生冲突的可能性就越大。由于开发商的数量通常是伸出你的双手，更新频率是一件事，你可以用它来减少冲突的可能性。
这也发生在我身上！ – Burnsys 2009-08-25 17:44:43
这听起来很熟悉。这可能更像是一个培训问题，而不是技术问题。 = / – 2009-08-26 15:13:57
一个相当激进而有效的解决方案是使用一种工具来生成元定义的解决方案文件，然后只把元定义源代码控制之下，而不是Visual Studio项目文件（这是合并的噩梦） 。
在我的球队，我们使用MPC做到这一点。我们有：
由于它们都是手动编辑的文本文件，因此我们不再在Visual Studio中混淆所有内容。
的缺点是一个额外的工具，并需要重新生成时，文件被添加或删除，但也有一些额外的好处太多了解决方案文件：
从我的经验来看，设置工具虽然有点痛苦（但这一切都取决于项目的大小和复杂性），这显然是值得的。
注意，MPC是不是为了这个目的的唯一工具。还有其他的，如CMake。
我第二SBI的答案。一种可能的解决方案是始终从Visual Studio中进行更新，至少如果您使用VisualSVN（我不确定AnkhSVN如何处理这种情况）。
VisualSVN将在更新操作期间阻止Visual Studio，并确保任何更改的项目都会自动重新加载，因此用户不能忽略外部更改。
您还可以尝试通过确保项目文件不列出项目中的每个单独文件来减少冲突。这将避免在用户添加文件时首先更改项目文件。
您可以自由使用项目文件中通配符：see MSDN
例子：
<ItemGroup>
<Compile Include="Src\**\*.cs" />
[...]
</ItemGroup>
可悲的是，Visual Studio中不鼓励这种项目设置的，而是选择采用上市单个文件。
这是非常单调乏味的，所以你只需要犁过它。您有时会保留本地工作副本，因为它已添加了所有自定义项目。但是，在其他情况下，您会希望从Base解决方案中合并所有新项目，以便最终解决两个解决方案文件中的所有问题。为了便于阅读，最好在添加定制之前添加所有基本产品。
不要担心项目的GUID的第一部分是相同的，但它是最后一部分将是唯一的。
Fissh
您是否在文件上正确设置了mime类型？ – 2009-08-25 16:59:16
用户B的提交应该被拒绝，因为他的文件已经过时，迫使他更新（并且合并 - 大多数更改实际上是自动处理的）。 – 2009-08-25 17:04:58
是的，在第6步，svn客户端应报告工作副本已过期。有些地方肯定是错的，因为这对我们很有用。 – crashmstr 2009-08-25 17:15:36