Xcode更改未修改的故事板和XIB文件 [英] Xcode changes unmodified storyboard and XIB files

问题描述

当多人合作时，故事板从git工作流角度来看是一种巨大的痛苦。例如，.storyboard文件中的XML的起始< document> 标记的 toolsVersion 和 systemVersion 由最近的文件操作符正在运行的任何配置更改的属性。精确地同步每个人的Xcode版本似乎有助于 toolsVersion ，但 systemVersion 无论如何都会发生变化，具体取决于特定的Mac和/或开发人员正在运行的OS X版本。

Storyboards are rather a royal pain from a git workflow perspective when multiple people are collaborating on them. For example, the XML in the .storyboard file has its starting <document> tag's toolsVersion and systemVersion attributes altered by whatever configuration the most recent file manipulator happens to be running. Synchronizing everybody's Xcode versions precisely seems to help with toolsVersion, but systemVersion changes no matter what, depending on the specific Mac and/or OS X version the developer is running.

这是愚蠢的，但大多是无害的。但令我们担心的是，在其他时候，只需在 git pull 之后打开它们，就会自动对故事板进行一些其他更改。也就是说，Alice对故事板进行了更改，提交并将它们推送到存储库。鲍勃然后拉出爱丽丝的变化并打开故事板进行进一步的更改。当他打开故事板时，文件图标立即变为修改但未保存的状态， git status 表示发生了任何数量的奇怪变化。所有这一切都没有鲍勃改变任何东西或自己保存文件。

This is idiotic, but mostly harmless. What worries us, though, is that at other times some other changes are automatically made to the storyboard just by opening them after a git pull. That is to say, Alice makes changes to a storyboard, commits and pushes them to the repository. Bob then pulls Alice's changes and opens up the storyboard to make further changes. The moment he opens the storyboard, the file icon immediately changes to a modified-but-unsaved state, and a git status shows that any number of weird changes have occurred. All this without Bob having changed anything or saved the file himself.

我们看到的最常见的自动更改是整个< classes> 在故事板文件末尾附近标记层次结构。我们还没弄清楚造成这种情况的原因。我们可能在各种.lproj目录中有几个本地化版本的故事板，当在Interface Builder中打开它们时，类层次结构可能会自动从某些层次结构中删除并添加到其他版本中，或者单独留在某些层次结构中。这会在 git diff 中引起很多噪音，但它实际上并没有破坏任何功能。我们通常会选择性地将我们所做的实际更改添加到git的索引中，提交这些更改，然后只丢弃自发的，无意义的< classes> 更改。这是为了保持提交的小而好，因为它们应该是。然而，最终，由于Xcode不断重新进行更改，所以它变得太麻烦了，有人只是愤怒地提交它们以及其他一些东西......这很好，直到其他人的Xcode决定要将它们更改为否明显的原因。 （我们的提交历史对此有很多咒骂。）

The most common automated change we're seeing is the disappearance or reappearance of the entire <classes> tag hierachy near the end of a storyboard file. We haven't figured out what is causing this. We may have several localized versions of a storyboard in various .lproj directories, and when opening them inside Interface Builder, the class hierarchy may spontaneously be removed from some and added into others, or left alone in some. This causes a lot of noise in git diff, but it doesn't actually break any functionality. We will often selectively add the actual changes we made into git's index, commit those, and then just discard the spontaneous, nonsensical <classes> changes. This is to keep commits small and nice, as they should be. Eventually, though, it just becomes too much to bother with since Xcode keeps re-doing the changes, and someone just ragecommits them along with some other stuff... which is fine until someone else's Xcode decides to want to change them back for no apparent reason. (Our commit history has a lot of swearing over this.)

还有其他人看到这种行为吗？这是我们的一个或多个开发者Mac上的Xcode错误还是配置问题？我们在与XIB文件协作时看到了一些类似的行为，但故事板似乎更容易受此影响。

Is anyone else seeing this behaviour? Is this an Xcode bug or a configuration issue on one or more of our developer Macs? We've seen some similar behaviour when collaborating with XIB files, but storyboards seem more susceptible to this.

推荐答案

这不是错误，这是Xcode处理故事板文件的结果。
我正在为故事板文件编写差异和合并程序（GitHub链接）我已经花了小时分析故事板文件逻辑以及Xcode如何处理它。这就是我发现的：

This is not a bug, this is a consequence of how Xcode processes storyboard files. I am writing a diff and merge program for storyboard files (GitHub link) and I have spent hours analyzing the storyboard files logic and how Xcode processes it. This is what I discovered:

• 为什么故事板文件会发生奇怪的变化？
  Xcode使用NSXML API将故事板文件解析为一些基于 NSSet 的逻辑树结构。当Xcode需要编写更改时，它会根据逻辑树结构创建 NSXMLDocument ，清除storyboard文件并调用 XMLDataWithOptions：再次填写文件。因为集合不保留其元素的顺序，即使最轻微的修改也可能会改变整个故事板XML文件。

• Why do weird changes occur in storyboard files? Xcode uses the NSXML API to parse storyboard files into some NSSet-based logical tree structure. When Xcode needs to write changes it creates an NSXMLDocument based on the logical tree structure, clears the storyboard file and calls XMLDataWithOptions: to fill the file again. Because sets do not preserve the order of their elements, even the slightest modification could change the whole storyboard XML file.

为什么类标记会消失或者随机重新出现？
< class> 部分只不过是一个内部Xcode缓存。 Xcode使用它来缓存有关类的信息。缓存经常更改。当类 .h / .m 文件被打开并在Xcode怀疑它们过时时被删除时添加元素（至少较旧的Xcodes表现得像这样）。保存故事板时，会转储当前版本的缓存，这就是< class> 部分经常更改甚至消失的原因。

Why does the class tag disappear or reappear randomly? The <class> section is nothing more than an internal Xcode cache. Xcode use it to cache information about classes. The cache changes often. Elements are added when class .h/.m files are opened and removed when Xcode suspects they are outdated (at least older Xcodes behave like this). When you save the storyboard, the current version of the cache is dumped, which is why the <class> section often changes or even disappears.

我没有反向设计Xcode;我通过试验Xcode和storyboard文件来做出这些观察。尽管如此，我几乎100％确定它是这样工作的。

I have not reverse-engineered Xcode; I made these observations by experimenting with Xcode and storyboard files. Nevertheless, I am almost 100% sure it works this way.

结论：

• 缓存部分不重要;您可以放心地忽略其中的任何更改。


• 与您在所有论坛上可以找到的内容相反，合并故事板文件并不是一项复杂的任务。例如，假设您在故事板文档中更改了 MyController1 视图控制器。打开storyboard文件，找到类似这样的内容
  < viewController id =ory-XY-OBMsceneMemberID =MyController1> 。
  您可以安全地仅提交此部分中的更改并忽略其他所有内容。如果您更改了segues或约束，也可以在里面提交任何ory-XY-OBM的内容。简单！

• Cache section is unimportant; you can safely ignore any change in it.
• Contrary to what you can find on all forums, merging storyboards files is not a complicated task. For example, let’s assume you changed MyController1 view controller in a storyboard document. Open the storyboard file, and find something like this <viewController id="ory-XY-OBM" sceneMemberID="MyController1">. You can safely commit only changes in this section and ignore everything else. If you changed segues or constraints, also commit anything that has "ory-XY-OBM" inside. Simple!

这篇关于Xcode更改未修改的故事板和XIB文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！