Должны ли *.xccheckout файлы в Xcode5 игнорироваться в VCS?

Ответ 1

Вы должны проверить файл Xcode 5 .xccheckout; в общем случае файлы в xcshareddata должны быть зафиксированы.

Файл .xccheckout содержит метаданные о том, какие репозитории используются в рабочей области. Для одного проекта в одном репозитории, который не имеет большого значения. Но если вы используете рабочую область с несколькими проектами из разных репозиториев, присутствие файла .xccheckout в рабочей области позволяет Xcode знать, что все компоненты, составляющие рабочую область, и где их можно получить.

Ответ 2

Файл *.xccheckout содержит метаданные VCS и поэтому не должен быть проверен в VCS.

С другой стороны: проверка этого файла, вероятно, не создаст проблем слиянием или других проблем.

Если вы хотите игнорировать этот файл (который я рекомендую), вы должны добавить эту строку в свой проект .gitignore:

*.xccheckout

Abizern решение не будет работать для проектов внутри рабочей области. Поскольку при использовании рабочей области путь к файлу *.xccheckout будет следующим: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. И он фактически игнорирует больше, чем вы хотели бы.

Изменить: Этот файл существует для управления знаниями Xcode о возможно многих системах VCS в вашем проекте, см. Chris Hanson. Для > 99% проектов файл .xccheckout является перенасыщением конфигурации.

Ответ 3

Это зависит. Файл содержит ссылки на удаленный репозиторий, который вы используете. Если вы используете централизованный VCS, такой как Perforce или Subversion, каждый удаленный репозиторий будет таким же, и вы можете и должны проверить файл.

Если вы используете распределенный VCS, такой как Mercurial или git, но используете его, как если бы это был CVCS (другими словами, каждый клонировал из общего хранилища непосредственно в свою личную рабочую область на своей машине), то вы все еще может захотеть проверить его.

Однако, если вы используете DVCS со всеми, у кого есть собственный удаленный клон, например, используя GitHub в стандартном шаблоне использования, вы НЕ хотите проверять этот файл. Если вы это сделали, ваши запросы на Pull будут запрашивать ваши настройки репозитория будут скопированы в каждый файл xccheckout, но ваши настройки репозитория будут отличаться от всех остальных, потому что вы все используете разные удаленные репозитории.

Ответ 4

Да, файл Project.xccheckout должен быть привязан к вашему репозиторию. Xcode использует этот файл, чтобы сообщить другим, которые открывают рабочее пространство весь список репозиториев источника управления, используемых рабочей областью, и расположение рабочей копии относительно рабочей области, независимо от того, являются ли эти репозитории Git, SVN или и то, и другое.

Когда вы открываете рабочую область, Xcode использует файл Project.xccheckout, чтобы уведомить пользователя о том, что есть другие репозитории, входящие в рабочую область, и спрашивает, что нужно проверить. При проверке дополнительных репозиториев Xcode помещает рабочие копии в ту же структуру папок, что и при создании файла Project.xccheckout.

Как Крис Хэнсон сказал, это, вероятно, не имеет значения для однореакторного однопроектного рабочего пространства, но для более сложных дел это будет очень удобно на самом деле.

Об этом вы можете узнать в видео сессии WWDC 2013 Понимание управления версиями в Xcode; соответствующая часть начинается примерно через 15 минут.

Ответ 5

Это то, что у меня есть в моем .gitignore для Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Он сохраняет все, что связано с локальным состоянием того, как проекты ищут меня из репозитория.

Файл xccheckout находится здесь, поэтому по умолчанию он не отслеживается в моей системе.

Xcode стал лучше и отделяет то, что нужно разделить, и то, что нужно сохранить на локальном уровне. Например; эти строки будут игнорировать схемы построения по умолчанию, что прекрасно, потому что вы можете отметить определенные схемы сборки как общие, и они помещаются в каталог, который не игнорируется.

Точки останова игнорируются, но вы можете пометить определенные точки останова как общие для проектов, и они также помещаются в каталог, который не игнорируется.