IDE生成的USEFORM宏调用改变了它们的顺序 [英] IDE generated USEFORM macro calls changing their order
问题描述
我们有一个C ++ Builder XE项目（VCL Forms Application），里面有几十个表单和单元。每当添加，删除或重命名属于项目的文件时，IDE都应该做两件事：
We have a C++Builder XE project (VCL Forms Application) that has a few dozen forms and units in it. Whenever a file belonging to the project is added, deleted, or renamed, the IDE should do two things:
- 对USEFORM宏的调用是如果受影响的单元是表单或框架，则在项目源文件（ProjectName.cpp）中添加或更改
- 添加或更改项目文件（ProjectName.cbproj）中的CppCompile元素
然而，IDE不是仅仅进行必要的更改，而是对现有的一些USEFORM和CppCompile记录进行洗牌，即使它们不是受变化的影响。如果我添加一个单元（cpp和头文件），即使不需要对项目源进行任何更改，USEFORM也会被洗牌，只有cbproj文件。
However instead of just doing the necessary changes, the IDE shuffles some of the existing USEFORMs and CppCompile records, even if they aren't affected by the changes. If I add a Unit (cpp and header file), the USEFORMs are shuffled even when that wouldn't require any changes to the Project Source, only to the cbproj-file.
我没有看到关于新订单如何形成的具体模式。如果我编辑或重命名一个单元，大约一半的USEFORMs似乎改变了位置，只改变了几个或没有CppCompile记录。如果在两台不同的机器上对项目副本进行了更改，则大多数更改似乎都相似，但并非全部。这表明重新排序不是随机的。
I don't see a specific pattern on how the new order is formed. If I edit or rename a single unit, about half of the USEFORMs seem to change position and just a couple or none of the CppCompile records. If a change is made to a copy of the project in two different machines, most of the changes seem to be similar, but not all. This indicates that the reordering is not random.
使用Subversion合并更改时，该行为会导致问题，因为它会强制手动解决更改顺序造成的冲突。
The behaviour causes problems when using Subversion to merge changes, because it forces to manually resolve conflicts inflicted by the changing order.
所以问题是：可能导致上述行为的原因以及如何摆脱它？
So the question is: What might be causing the foregoing behaviour and how to get rid of it?
推荐答案
我一直无法找到问题的正确解决方案，但这里有一个简单的方法让它稍微不那么烦人：
I haven't been able to find a proper solution to the problem, but here's a simple method for making it slightly less annoying:
采用永远不会将随机IDE生成的更改提交到版本控制存储库的策略。每当您对触发混合文件的代码进行更改时，请在 ProjectName中还原所有不必要的更改.cpp 和 ProjectName.cbproj 。此时它仍然相当容易，因为您知道文件的哪些部分实际上应该已经更改。这样，手工劳动是在仍然需要最少量的工作时进行的。此外，工作只需执行一次，而不是保持不变，所以每次有人合并更改时都必须重复工作。
Adopt a policy of never committing the random IDE-generated changes to the version control repository. Whenever you make changes to code that trigger mixing up the files, revert all unnecessary changes in ProjectName.cpp and ProjectName.cbproj. At this point it is still fairly easy, as you know which parts of the files actually should have changed. That way, the manual labour is carried out when it still requires the minimal amount of work. Additionally, the work has to be carried out only once, in contrast to leaving the changes untouched, in which case the work has to be repeated every time someone merges the changes.
这篇关于IDE生成的USEFORM宏调用改变了它们的顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
