Чи слід ігнорувати * .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щоб воно було включене.

— Joshcodes

4

Як я вже говорив у своїй відповіді, файл xccheckout містить інформацію про всі сховища, що використовуються в робочій області. Так відбувається незалежно від того, якою системою SCM вони користуються - така робоча область може бути у svn чи git, а її проекти можуть знаходитись у поєднанні сховищ svn та git.

— Кріс Хансон

72

Схоже, xccheckout містить ключі та імена, які є специфічними для машини кожного розробника ... Щойно я запускаю xcode, він змінює деякі ключі у файлі, і він змінює щось з назвою IDESourceControlWCCName з <string> OurCompanyAPI </string> на <string > our_company_api / string> - останнє є ім'ям, яке я використав під час клонування репо. Якщо цей файл повинен бути загальним, то Apple зробила досить погану роботу.

— Herr Grumps

7

Коли ми перевіряємо цей файл, усі мої співробітники отримують інший IDESourceControlProjectIdentifier ... тож наш .xccheckout змінюється з кожним комітом. -_-

— Cœur

9

Незалежно від того, для чого Apple спочатку призначався, .xccheckoutфайли викликають деякі божевільні проблеми на Xcode 6 beta, і я вирішив видалити їх з 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

— Chris Hanson

2

Після включення цього файлу до мого репортажу з моменту його введення, я нещодавно почав видаляти його з усіх своїх репост. Ця річ створює конфлікти злиття весь час, переважно в проектах, які включають мої власні рамки як підмодулі. І тоді я нічого не отримую з цього файлу, оскільки використовую git для управління підмодулями. Приємна спроба, Apple, дякую, але не дякую.

— Паскаль

38

Це залежить. Файл містить посилання на віддалений сховище, яке ви використовуєте. Якщо ви використовуєте централізований VCS, такий як Perforce або Subversion, віддалене сховище всіх буде однаковим, і ви можете і повинні перевірити файл.

Якщо ви використовуєте розподілений VCS, такий як Mercurial або git, але використовуєте його як би CVCS (іншими словами, всі клонувались із спільного сховища безпосередньо в особисту робочу область на своїй машині), то ви все одно можете перевірити це в.

Однак якщо ви використовуєте DVCS з усіма, хто має власний віддалений клон, наприклад, використовуючи GitHub у його стандартному шаблоні використання, ви НЕ хочете перевіряти цей файл. Якщо ви це зробили, ваші запити на виклик запитають ваші налаштування сховища. щоб скопіювати у файл 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 хвилин.

— Кальріон
джерело

Цей файл корисний лише якщо ви використовуєте Xcode для SCM, інакше цей файл вам взагалі не потрібен. А ще менше, якщо ви працюєте з git forks, у такому випадку шлях репо буде унікальним для розробника

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

3

Це те, що у мене є .gitignore для Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Він зберігає все схоже на місцевий стан те, як проекти шукають мене із сховища.

Файл xccheckout знаходиться тут, тому він не відстежується у моїй системі за замовчуванням.

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

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

— Абізерн
джерело