我已经使用 XCode 和 subversion 一段时间了，当我作为单个开发人员使用它时没有引起任何问题（我只使用 2 个命令，提交和添加）。
但现在我必须与另一位开发人员（从未使用过任何类型的版本控制）共享代码，集成/合并代码已成为一场噩梦。当我们集成/合并 .h/.m 文件时不会出现问题，但一旦涉及 ".nib"、"xcodeproj" > 和 ".xcdatamodeld" 文件，我们真的不知道该怎么办。
每当我们尝试合并 "xcodeproj" 时，项目就会损坏，而合并 ".xcdatamodeld" 对我们来说是不可能的。
所以我想知道是否有人可以分享他/她在多用户环境中如何在 XCode 4.0 中有效使用 subversion/git/mercurial 的经验？或者分享一个链接，它可以解释如何在多用户环境中有效地使用 subversion。
谢谢。
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
发布评论
评论（3）
您是否使用 Subversion 执行此操作？对于存储库中 90% 到 99% 的文件，检出、编辑、提交的标准 Subversion 工作流程效果很好。但是，对于某些类型的文件（例如 JPEGS 和 GIFS），根本无法很好地合并。在这种情况下，您必须按照我们在旧 SCCS 和 RCS 时代使用的方式进行操作：在编辑和提交文件之前，必须锁定它。
锁定文件可防止其他人在您处理该文件时编辑同一文件并提交更改。这很粗糙，但很有效。在 Subversion 中，您始终可以锁定正在编辑的任何文件，但如果该文件具有
svn:needs-lock属性，它将被检出为只读。您必须在编辑文件之前锁定文件以使其可写，并且除非文件被锁定，否则不允许提交文件。因此，对于这些文件，请为其设置 svn:needs-lock 属性。
您可以通过设置 自动属性 在您的 Subversion 客户端配置中。
而且，如果您真的非常想确保所有 .nibs 和 xcodeproj 以及所有其他这些类型的苍蝇都设置了 svn:needs-lock ，您可以使用我的 预提交挂钩 除非设置此属性，否则将阻止这些文件被提交。
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property
svn:needs-lockon it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.So, for those files, set the
svn:needs-lockproperty on it.You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
据我所知，没有任何故障安全方法可以合并这些类型的文件。所以你必须
尽量确保一次只有一个人更改这些文件。这并不总是有效，因此只需使用提交消息在文件中记录您所做的更改即可。然后，如果存在冲突，您可以通过采用更改了更多文件的版本来手动解决它，并手动重做其他人所做的事情。
这通常不是什么大问题，就像向 .xcodeproject 添加新的源文件，或更改 .nib 中元素的对齐方式一样。如果您的项目很大或者您的笔尖包含整个界面，这就会成为一个问题。为了使其正常工作（实际上确实如此），如果项目变得太大，您需要将其拆分为子项目。
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
我与其他 2 个开发人员使用 Xcode 和 git 遇到了同样的问题。不幸的是，Xcode 项目文件是一个 XML 文件，跟踪项目中包含的文件以及设置。我不确定，但我认为 .nib 文件也是 XML 文件。有人可以纠正我这一点。
Git 在合并 Xcode 项目文件方面做得非常出色，而且我们的 *.nib 文件也从未真正出现过任何问题。我们唯一遇到问题的时候是我们都添加/删除了具有相同名称的文件，或者有人做了很多繁重的删除和添加大量文件的操作。
我们解决这个问题的唯一方法是在添加/删除文件后立即互相推送和拉取。这样，该人就拥有最新的文件，并且没有将它们添加到自己的存储库中，然后提取其中包含相同文件的最新提交。或者他们会向已删除或重命名的文件添加更改。
这是我们发现的最佳解决方案，一旦我们添加或删除文件，团队中的其他人就会拉动。顺便说一句，这不是一个很好的解决方案。然而，无论如何，你应该经常做出承诺。
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.