问Visual、svn和合并.csproj和.sln文件

EN

你认为你是如何诱骗SVN执行第6步的？你好像误解了哪里出了问题。SVN将永远不会从不最新的的工作副本提交，因此步骤6将在没有用户B之前更新和合并用户A的更改的情况下无法工作。老实说。试试看。

我想现在发生的事情是：

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

我偶尔也会看到这种情况，通常是因为用户B并不真正理解SVN(或CVS'，FTM)工作流。

以下是一些提示：

不要更新，除非您保存了所有的 ("File"->"Save All“，对我来说，这是Ctrl+Shift+S)。如果您犯了这个错误，并且被困住了，请重写磁盘上的更改，然后手动合并丢失的更改。(它还可以将项目/解决方案文件更新回版本N-1，然后再进行一次，以便让SVN执行合并。)

如果不检查哪些文件更改了，并进行了快速检查，查看差异，以确定这些更改是否符合您的预期，则不要提交。

早提交，经常提交。开发人员在同一代码基础上工作的越多，冲突的可能性就越大。更改工作副本而不进行更新的时间越长，冲突的可能性就越大。由于开发人员的数量通常超出了您的控制范围，所以更新频率是您可以用来降低冲突概率的一件事。

I履行机构第二次答复。一个可能的解决方案是始终在VisualSVN中进行更新，至少如果您使用VisualSVN(我不确定AnkhSVN如何处理这种情况)。

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

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

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

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

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

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

• 项目配置是集中的:例如，更改编译标志是在一个地方而不是在每个项目的基础上进行的，
• 这可以容纳多个构建系统(我们目前使用Visual 2003和2005，但这也适用于gcc和其他人)。

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

请注意，MPC并不是实现此目的的唯一工具。还有一些存在，如CMake。