为什么C＃设计器生成的代码（如Form1.designer.cs）会破坏Subversion？

Question

我的工作室最近从SourceSafe切换到Subversion，让我们从自动锁中解脱出来。这导致了对Forms的并发编辑，这很精彩。但是当多个开发人员提交更改时，设计人员创建的代码文件（所有名为TheFormName.designer.cs的文件）都会导致很难解决的冲突。

据我所知，这是因为设计师生成的代码会在用户修改时重新安排，无论实际更改有多少。

• 如何让这些冲突更容易解决？
• 有没有办法告诉设计师少修改代码？
• 您是如何经验丰富的C＃团队处理并发修改表单的？

Answer 1

以下是一些尝试：

• 使事物更加模块化。使用用户控件等组件将表单拆分为多个较小的物理文件。
• 使用表达层设计模式（如MVP）将代码移出视图并转换为标准POCO类。
• 最新版本的SVN允许您使用硬锁 - 使用它来避免复杂的合并方案。

希望有所帮助。

Answer 2

我很确定这个问题没有灵丹妙药，因为设计师在整个designer.cs上踩踏。

我所能建议的是尽量减少设计师的使用。就个人而言，我只挂钩代码中的事件，只使用设计器进行初始化和定位。因此，在变更集中理解差异并不太难（“哦，有人添加了一个按钮”，“哦，有人改变了它的外观”）。

Answer 3

我不熟悉C＃或Windows窗体设计器，但查看我在网上找到的一些designer.cs文件，它们没有特别复杂的结构。

它的哪些部分正在重新安排？我想这主要是InitializeComponent()方法中属性的顺序混乱了吗？

如果是这种情况，您可以编写一个简单的脚本，按字母顺序重新排序这些行，比如说（特别是如果您从不手动编辑这些文件），并在Subversion中将其用作pre-commit hook script

嗯，对吧......划伤那个。该部分底部的大红色框表示您不应该在钩子脚本中修改事务。但是，您可能能够找到另一种方法在正在更改的designer.cs文件和提交的文件之间的某个位置运行该脚本。

编辑：

实际上，鉴于scraimer对此的评论：

  

完全破解，但在最糟糕的情况下，就在合并之前，我可以对BOTH文件进行排序，并使合并只是一个逐行的事情...

难道你不能让Subversion设置外部合并程序吗？我一直在使用KDiff3 run a preprocessor command before doing diffs or merges，因此您可以自动执行该过程。

Answer 4

是的，设计师的随机重新安排肯定是恼人的。 Microsoft是否使用自己的工具？ Microsoft会查看他们检查版本控制的内容吗？它令人难以置信。

我们团队的“解决方案”是在我们完成编辑后手工编辑Designer文件，将事物放回原处，以便基于文本的差异可读，因此可以合并并发更改三立。幸运的是，Visual Studio的大部分重新排列都很简单，所以这很有用。

可悲的是，我们发现这一步是验证正确性的必要步骤 - 我们发现了Designer静默删除所需内容的情况，导致代码损坏。因此，必须完成此步骤才能解决潜伏在内的任何数据破坏性错误。叹息。

由于微软在修复错误方面的记录不佳，唯一的解决方案可能是改进Mono's WinForms Designer，以便它能够在黄金时段完成。

Answer 5

在使用合并样式源控制系统（如subversion）时，我所知道的唯一方法是真正避免此问题，即手动编码表单而不使用设计器。显然，这不会很好，因为手工编码这些表格可能需要一段时间。

发生这种情况的原因是设计者按照它们在表单上的删除顺序来序列化控件属性。剪切和粘贴可以影响此顺序以及移动控件以使其具有新的父级（例如，当控件直接在表单上时将控件移动到面板上）。

我在一个大项目中遇到了这个问题，不得不采用一种相当丑陋的方法 - 将designer.cs文件与签入目标修订版区分开来，并使用合并工具手动合并它们。这并不理想，但这是我看到它与svn或其他合并样式源代码控制工具一致的唯一方法。

另一种选择是使用带有源控制的锁定方法，正如其他人所指出的那样，但这也带来了令人不快的副作用。