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

157

Apple представила в Xcode 5 новый тип файла, связанный с проектом: «xccheckout».

Этот файл находится в каталоге «.xcodeproj / project.xcworkspace / xcshareddata /», и, похоже, он связан с системой управления версиями проекта.

Пример файла находится здесь: http://pastebin.com/5EP63iRa

Я предполагаю, что этот тип файла должен игнорироваться в VCS, но я не уверен.

Итак, вот вопросы:

Следует ли игнорировать «xccheckout»?
Какова его цель?

— Артем Абрамов
источник

Этот вопрос имеет тенденцию быть весьма актуальным; таким образом я хотел бы, чтобы это было более грамматически и синтаксически правильно. Если вы являетесь носителем английского языка или очень хорошо владеете английским языком, я хотел бы попросить помощи в проверке моего языка. Спасибо!

— Артем Абрамов

1

Незначительные изменения: «Apple представила новый», «Пример файла здесь:». Есть несоответствующая цитата в вопросе 1.

— Sofi Software LLC

3

Я всегда ссылаться на GitHub / gitignore репо , чтобы узнать , какие файлы должны быть проигнорированы -> github.com/github/gitignore/blob/master/Objective-C.gitignore

— eliocs

109

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

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

— Крис Хансон
источник

8

Если он не предназначен для совместного использования, Apple сохранит его, .xcuserdataпоэтому его следует включить.

— Джошкодес

4

Как я уже сказал в своем ответе, файл xccheckout содержит информацию обо всех репозиториях, используемых в рабочей области. Это имеет место независимо от того, какую систему SCM они используют - такое рабочее пространство может быть в svn или git, а его проекты могут быть в смеси svn и git-репозиториев.

— Крис Хэнсон

72

Похоже, xccheckout содержит ключи и имена, характерные для каждого компьютера разработчика ... Как только я запускаю xcode, он меняет некоторые ключи в файле и меняет что-то с именем IDESourceControlWCCName с <string> OurCompanyAPI </ string> на <string > our_company_api / string> - последнее имя, которое я использовал при клонировании репо. Если предполагается, что этот файл будет распространен, Apple проделала довольно плохую работу.

— Герр Грампс

7

Когда мы проверяем этот файл, все мои коллеги получают разные IDESourceControlProjectIdentifier ... поэтому наш .xccheckout изменяется с каждым коммитом. -_-

— Cœur

9

Независимо от того, для чего изначально предназначалась Apple, .xccheckoutфайлы вызывают некоторые безумные проблемы в бета-версии Xcode 6, и я решил удалить их из VCS. Кажется, что это связано с некоторой ошибкой кэширования, и я считаю, что Xcode может автоматически восстанавливать их из VCS каждый раз.

— eonil

63

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

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

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

*.xccheckout

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

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

— Берик
источник

1

Было бы замечательно, если бы вы могли расширить это утверждение «оно фактически игнорирует больше, чем вы хотели бы». В частности, некоторые примеры других файлов, которые попадают в эту папку, должны быть проверены.

— Марк Эдингтон

Продолжение: я использую .gitignore от Адама из этого вопроса . Он доступен в виде гистограммы и содержит некоторое описание содержимого папки xcshareddata.

— Марк Эдингтон

@ Марк : игнорирует project.xcworkspace/. Это может быть хорошо на данный момент, но я бы не стал рассчитывать на это для новых версий XCode.

— Берик,

6

Этот ответ неверен, и стандарт GitHub, .gitignoreкоторый он предоставляет разработчикам, не должен указываться*.xccheckout

— Крис Хэнсон,

2

После включения этого файла в мои репозитории, так как он был представлен, я недавно начал удалять его из всех репозиториев. Эта вещь постоянно создает конфликты слияния , в основном в проектах, которые включают мои собственные фреймворки в качестве подмодулей. А потом я ничего не получаю от этого файла, так как я использую git для управления субмодулями. Хорошая попытка, Apple, спасибо, но нет, спасибо.

— Паскаль

38

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

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

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

— Тим Бэнд
источник

1

Этот ответ кажется мне лучшим. Регистрация их вызывала ненужную болтливость на разногласиях для коммитов нашей команды. Я добавляю в .gitignore следующее, чтобы не пускать их: * / .xcworkspace / xcshareddata / *. Xccheckout. Я все еще не понимаю, почему Apple решила избыточно хранить эту информацию, которая в любом случае находится в папке .git (мое единственное предположение - заставить вещи работать последовательно через VCS)

— Хуан Карлос Мендес

20

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

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

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

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

— Calrion
источник

Этот файл полезен, только если вы используете Xcode для SCM, в противном случае вам вообще не нужен этот файл. И даже меньше, если вы работаете с git-форками, в этом случае путь репо будет уникальным для разработчика

— Карлос Рикардо

3

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

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

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

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

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

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

— Abizern
источник