Xcode змінює немодифіковану табло та XIB-файли

Дошка розказок - це скоріше королівський біль з точки зору робочого процесу, коли на них співпрацюють кілька людей. Наприклад, XML у файлі .storyboard має свій початковий <document>тег toolsVersionта systemVersionатрибути, змінені залежно від конфігурації, що працює останній файловий маніпулятор. Синхронізувати всі версії Xcode точно, здається, допомагає toolsVersion, але systemVersionне змінюється, незалежно від конкретних версій Mac та / або OS X, якими працює розробник.

Це ідіотично, але в основному нешкідливо. Тим не менш, нас хвилює те, що в інший час деякі інші зміни автоматично вносяться на дошку розгортання, просто відкриваючи їх після git pull. Тобто, Аліса вносить зміни в дошку розкадрувань, здійснює зйомки та переміщує їх у сховище. Потім Боб витягує зміни Аліси і відкриває дошку розкадрів, щоб зробити подальші зміни. Щойно він відкриває дошку розкадрування, піктограма файлу негайно переходить у модифікований, але не збережений стан, і git statusпоказує, що будь-яка кількість дивних змін відбулася. Все це без того, щоб Боб нічого змінив або сам зберег файл.

Найпоширеніша автоматизована зміна, яку ми спостерігаємо, - це зникнення або повторне поява всієї <classes>ієрахії тегів біля кінця файлу розкадровки. Ми не з'ясували, що це викликає. У нас може бути кілька локалізованих версій розкадровки в різних каталогах .lproj, і при відкритті їх всередині Interface Builder ієрархія класів може мимовільно видалятися з одних і додаватися до інших, або залишатись одна в одній. Це викликає багато шуму git diff, але насправді це не порушує жодної функціональності. Ми часто вибірково додаватимемо фактичні зміни, які ми внесли до індексу git, зробимо ці, а потім просто відкинемо спонтанне, безглузде<classes>зміни. Це потрібно, щоб доручення було малим і приємним, як вони повинні бути. Зрештою, однак, це стає занадто багато для того, щоб турбуватися, оскільки Xcode продовжує повторно робити зміни, а хтось просто демонструє їх разом із деякими іншими речами ... що добре, поки чужий Xcode не вирішить захотіти змінити їх назад ні очевидна причина. (Наша історія вчинення багато присягається на це.)

Хтось ще бачить таку поведінку? Це помилка Xcode або проблема конфігурації для одного або декількох наших Macs для розробників? Ми бачили деяку подібну поведінку під час співпраці з файлами XIB, але дошки розповідей здаються більш сприйнятливими до цього.

Це не помилка, це наслідок того, як Xcode обробляє файли розкадрівки. Я пишу програму "diff" та "злиття" для файлів розкадровки (посилання GitHub), і я витратив години на аналіз логіки файлів розкадровки та на те, як Xcode обробляє її. Ось що я виявив:

• Чому в файлах розкадровки відбуваються дивні зміни? Xcode використовує API NSXML для розбору файлів розкадровки в деяку NSSetструктуру логічного дерева. Коли Xcode потребує внесення змін, він створює NSXMLDocumentгрунтується на логічній структурі дерева, очищає файл розкадровки та закликає XMLDataWithOptions:заповнити файл ще раз. Оскільки набори не зберігають порядок їх елементів, навіть найменша модифікація може змінити весь XML-файл.

• Чому тег класу зникає або знову з’являється випадковим чином? <class>Розділ не більше , ніж внутрішній кеш Xcode. Xcode використовує його для кешування інформації про класи. Кеш часто змінюється. Елементи додаються при .h/.mвідкритті та видаленні файлів класу , коли Xcode підозрює, що вони застаріли (принаймні, старі Xcodes поводяться так). Коли ви зберігаєте дошку розкадрувань, поточна версія кешу скидається, через що <class>розділ часто змінюється або навіть зникає.

Я не реверсував Xcode; Я зробив ці спостереження, експериментуючи з файлами Xcode та раскадровки. Тим не менш, я майже на 100% впевнений, що це працює так.

Висновки :

• Розділ кеша - це неважливо; ви можете сміливо ігнорувати будь-які зміни в ньому.
• На відміну від того, що ви можете знайти на всіх форумах, об’єднання файлів розповідей не є складним завданням. Наприклад, припустимо, що ви змінили MyController1контролер перегляду в документі. Відкрийте файл раскадровки і знайдіть щось подібне <viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>. Ви можете сміливо вносити лише зміни в цьому розділі та ігнорувати все інше. Якщо ви змінили смуги чи обмеження, також виконайте все, що є “ory-XY-OBM”всередині. Просто!

Це помилка в XCode 4.5+, я сподіваюся, вона виправляється, і так, це PITA.

Ось повна помилка в Apple

Як уникнути безплатних редагувань файлів Xcode у файлах розкадрувань?

Цю проблему можна дещо пом'якшити надзвичайно розумним використанням git add -pбудь-якого із створених файлів Xcode, включаючи дошки розкадрів, XIB, моделі Core Data та файли проектів, які страждають від подібних перехідних модифікацій, які не впливають на фактичний інтерфейс / модель / проект.

Найпоширеніші зміни сміття, які я бачив на дошках роздач, - це номери версій системи (як ви вже згадували) та постійне додавання та видалення <classes>розділу, опускання якого я ніколи не бачив, викликає проблеми. Для XIB - це додавання та видалення <reference key="NSWindow"/>, що навіть не є класом у Cocoa Touch. Просто вау.

Думайте про це як про море: тут є і високий, і низький прилив. Нехай воно помиється над тобою.

А-а-а. Це воно.

Ви можете ігнорувати ці модифікації під час постановки змін, скидання небажаних змін та чистого вчинення.

Єдиною перевагою, яку я бачив із дошками розкадрів над XIB з технічної точки зору, є те, що Apple ще не сканувала FileMerge відмовитись від об'єднання конфліктних мов. (Раніше FileMerge змогла об'єднати XIB, але нові версії зламали це. Thxxxx, хлопці! !!!)

Будь ласка, подайте багато помилок про всі ці проблеми на http://bugreporter.apple.com/ ! І не забудьте створити записи на OpenRadar .

Тут викиньте іншу відповідь, оскільки ця ситуація значно покращилася. XML для файлу XIB, який представляє StoryBoard, значно спрощено.

Нещодавно я також покусав кулю і почав використовувати інтерфейс у Xcode to Source Control. Я вже багато років працюю в командному рядку і там радію, але інтерфейс є приємним, і він дозволяє розділяти комісії, що дуже важливо, якщо ви використовуєте систему квитків, яка посилається на коміти.

У всякому разі, я сьогодні помітив, що на дошці розкадрівок відбулася зміна, і вбудований розріз показав мені, що це єдиний атрибут у тезі документа (systemVersion). Тож не велика справа.

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

Корисно знати, чому таке божевілля трапляється, але для тих, хто вірить у те, щоб утримувати свої проекти без попереджень і хто просто хоче, щоб швидше і брудно повернути свої проекти до здорового стану:

1. Не робіть нічого, поки не буде чітко прописано.

2. Відкрийте Xcode та створіть нову дошку (Command + N> iOS> Інтерфейс користувача> Розгортка). Я припускаю, що ви називаєте це ім'ям за замовчуванням Storyboard.storyboard.

3. Відкрийте рекламну дошку, яку Xcode порушив. Я припускаю, що це так Base.lproj/Main.storyboard.

4. Виберіть і скопіюйте все на дошці повідомлень (Command + A, потім Command + C).

5. Відкрити Storyboard.storyboard.

6. Скопіюйте та вставте все Storyboard.storyboard.

7. Закрити Xcode.

8. Відкрийте термінал і змініть каталоги у ваше сховище.

9. Замініть Main.storyboardна Storyboard.storyboard( mv Storyboard.storyboard Base.lproj/Main.storyboard).

10. git add Base.lproj/Main.storyboard; git commit -m "Fix Xcode's insanity."

11. Нехтуйте змінами на project.pbxprojvia git checkout -- project.pbxproj. Якщо ви git diffфайл, ви побачите, що він тільки що додав інформацію про нашу тимчасову табло (що вже не існує).

12. Відкрийте резервну копію Xcode і переконайтеся, що попередження зникли.

13. Дихайте.

Робота над однією розкадровкою не є проблемою. Але робота над тим же контролером перегляду, який створює конфлікти при потягуванні / злитті, лякає. ми не можемо уникнути того, що працюємо в одному оглядовому контролері для великої команди.

Хороша річ, що більшу частину часу ми можемо виправити ті ж конфлікти перегляду контролера, якщо ми розуміємо структуру xml. Мені ніколи не вдалося їх об'єднати під час роботи в команді. Припустимо, ви працюєте з контролером перегляду. Наразі ваше перегляд порожнє. Перегляньте структуру xml viewcontroller з параметра вихідного коду.

Дошка розгортання обмежена xml тегом типу документа. Все, що знаходиться в дошці розповідей, містить у сцені sceneID = тег. Тег сцени вміщує кожен контролер перегляду. Це основне.

Тепер ми додали UILabel та UIButton на подання. Встановіть також автоматичне розташування елементів. Тепер це виглядає так:

Додавання рівня / кнопки до диспетчеру перегляду додало новий код у тег субпрогляду подання. Те саме стосується подальшого додавання елементів або будь-яких змін інтерфейсу користувача. Уважно перевірте структуру тегів, яка дійсно важлива для виправлення будь-яких конфліктів.

Тепер ми додаємо ще один контролер перегляду в назву аркуша розкадровки Homeviewcontroller. Додавання нового контролера перегляду означає, що він додає нову сцену під тегами сцени. Подивись на це:

На цьому етапі ми змінимо структуру випадковим чином і будемо спостерігати за проблемами / попередженнями. Змінюємо кінцевий тег мітки першого контролера і зберігаємо файл. Тепер запустіть його і подивіться на попередження. Помилка говорить, що кінцевий тег не є правильним, що створено з рядка 23. У рядку 23 ми бачимо, що обмеження мітки встановлюються без кінцевого тегу. У цьому проблема. Тепер ми ставимо кінцевий тег і будуємо проект. Встановивши кінцевий тег, ми можемо успішно переглядати розкладочку.

Якщо ви стикаєтеся з будь-яким попередженням про конфлікти, будь ласка, порівняйте його з попереднім джерелом та змініть джерело. Ми видаляємо старий / надлишковий код, зберігаємо новий код з належним початковим тегом і виправляємо речі.

[Примітка, я оновлю відповідь ще деякими тестовими випадками, коли отримаю час]