xcode 在VCS下是否应该忽略Xcode5中的*.xccheckout文件？

Should *.xccheckout files in Xcode5 be ignored under VCS?

提问by Artem Abramov

Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".

Apple 在 Xcode 5 中引入了一种新的与项目相关的文件类型：“xccheckout”。

This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.

该文件位于“.xcodeproj/project.xcworkspace/xcshareddata/”目录下，似乎与项目的版本控制系统有关。

An example file is here: http://pastebin.com/5EP63iRa

示例文件在这里：http: //pastebin.com/5EP63iRa

I suppose that this type of file should be ignored under VCS, but I'm not sure.

我想这种类型的文件在 VCS 下应该被忽略，但我不确定。

So here are the questions:

所以这里是问题：

1. Should "xccheckout" be ignored?
2. What is its purpose?

1. 应该忽略“xccheckout”吗？
2. 它的目的是什么？

采纳答案by Chris Hanson

You shouldcheck in an Xcode 5 .xccheckoutfile; in general, files in xcshareddatashould be committed.

您应该签入一个 Xcode 5.xccheckout文件；一般来说，文件 inxcshareddata应该被提交。

An .xccheckoutfile contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckoutfile in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.

一个.xccheckout文件包含哪些存储库工作空间中使用的元数据。对于单个存储库中的单个项目，没有太大区别。但是，如果您使用的工作区包含来自不同存储库的多个项目.xccheckout，则工作区中存在的文件允许 Xcode 知道构成工作区的所有组件是什么以及从何处获取它们。

回答by Berik

The *.xccheckoutfile contains VCS metadata, and should therefore not be checked into the VCS.

该*.xccheckout文件包含 VCS 元数据，因此不应检入 VCS。

On the other hand: checking in this file will probably not create merge difficulties or other problems.

另一方面：签入此文件可能不会造成合并困难或其他问题。

If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:

如果你想忽略这个文件（我推荐）你应该把这行添加到你的项目中.gitignore：

*.xccheckout

Abizern's solutionwill not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckoutfile will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.

Abizern的解决方案不适用于工作空间内的项目。因为，当您使用工作区时，*.xccheckout文件的路径将是：<workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. 它实际上忽略了比你想要的更多。

Edit:This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hansonanswer. For > 99% of the projects the .xccheckout file is configuration overkill.

编辑：此文件用于管理 Xcode 对您项目中可能有许多 VCS 系统的知识，请参阅Chris Hanson 的回答。对于 > 99% 的项目，.xccheckout 文件是配置矫枉过正。

回答by Tim Band

It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.

这取决于。该文件包含对您正在使用的远程存储库的引用。如果您使用的是 Perforce 或 Subversion 等集中式 VCS，则每个人的远程存储库都是相同的，因此您可以并且应该签入文件。

If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.

如果您使用的是分布式 VCS，例如 Mercurial 或 git，但将其用作 CVCS（换句话说，每个人都从共享存储库直接克隆到他们机器上的个人工作区），那么您仍然可能想要检查它在。

However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.

但是，如果您正在使用每个人都有自己的远程克隆的 DVCS，例如在其标准使用模式中使用 GitHub，则您不想签入此文件。如果您这样做了，那么您的拉取请求将要求您的存储库设置复制到其他人的 xccheckout 文件中，但是您的存储库设置将与其他人的不同，因为你们都使用不同的远程存储库。

回答by Calrion

Yes, the Project.xccheckoutfile should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copyrelative to the workspace, whether those repositories are Git, SVN, or both.

是的，该Project.xccheckout文件应该提交到您的存储库。Xcode 使用此文件告诉打开工作区的其他人工作区使用的源代码控制存储库的完整列表以及工作副本相对于工作区的位置，这些存储库是 Git、SVN 还是两者。

When you open the workspace, Xcode uses the Project.xccheckoutfile to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckoutfile was generated.

当您打开工作区时，Xcode 使用该Project.xccheckout文件通知用户还有其他存储库构成了工作区的一部分，并询问应检出哪些。签出其他存储库时，Xcode 会将工作副本放置在与Project.xccheckout生成文件时相同的工作区相关文件夹结构中。

As Chris Hansonsaid, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.

正如Chris Hanson所说，对于单个存储库、一个项目的工作空间来说可能无关紧要，但对于更复杂的事务，它确实会非常方便。

You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.

您可以在 WWDC 2013 会议视频Understanding Source Control in Xcode 中找到更多相关信息；相关部分从大约 15 分钟开始。

回答by Abizern

This is what I have in my .gitignore for Xcode.

这就是我在 Xcode 的 .gitignore 中的内容。

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

It keeps anything that relates to the local state of the way the projects looks for me out of the repository.

它保留了与项目从存储库中查找我的方式的本地状态相关的任何内容。

The xccheckout file is under here so it is not tracked on my system by default.

xccheckout 文件位于此处，因此默认情况下不会在我的系统上对其进行跟踪。

Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.

Xcode 已经变得更好，并且将需要共享的内容和需要保留在本地的内容分离开来。例如; 这些行将忽略默认的构建方案，这很好，因为您可以将特定的构建方案标记为共享，并将它们放在一个不被忽略的目录中。

Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.

断点被忽略，但您可以将特定断点标记为跨项目共享，并且它们也被放置在不被忽略的目录中。