Xcode изменяет немодифицированные файлы раскадровки и XIB

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



это идиотизм, но в основном безобидные. Однако нас беспокоит то, что в других случаях некоторые другие изменения автоматически вносятся в раскадровку, просто открывая их после git pull. То есть, Алиса вносит изменения в раскадровку, фиксирует и толкает их в репозиторий. Затем Боб вытаскивает изменения Алисы и открывает раскадровку, чтобы внести дальнейшие изменения. Как только он открывает раскадровку, значок файла немедленно изменяется на a измененное, но несохраненное состояние, и git status показывает, что произошло какое-то количество странных изменений. И все это без того, чтобы Боб сам что-то изменил или сохранил файл.



наиболее распространенным автоматическим изменением, которое мы видим, является исчезновение или повторное появление всего <classes> тег hierachy в конце файла раскадровки. Мы еще не выяснили, что является причиной этого. У нас может быть несколько локализованных версий раскадровки в различных .каталоги lproj, и при их открытии внутри Interface Builder иерархия классов может быть спонтанно удалена из некоторых и добавлена в другие или оставлена в покое в некоторых. Это вызывает много шума в git diff, но на самом деле это не нарушает никакой функциональности. Мы часто будем выборочно добавлять фактические изменения, которые мы внесли в индекс git, фиксировать их, а затем просто отбрасывать спонтанные, бессмысленные <classes> изменения. Это должно держать коммиты маленькими и приятными, как и должно быть. В конце концов, однако, это просто становится слишком много, чтобы беспокоиться поскольку Xcode продолжает повторно делать изменения, и кто-то просто ragecommits их вместе с некоторыми другими вещами... это нормально, пока кто-то другой Xcode не решит изменить их обратно без видимых причин. (Наша история фиксации имеет много ругательств по этому поводу.)



кто-нибудь еще видит это поведение? Это ошибка Xcode или проблема конфигурации на одном или нескольких наших Mac-компьютерах разработчиков? Мы видели некоторое подобное поведение при сотрудничестве с файлами XIB, но раскадровки кажутся больше восприимчивы к этому.

671   5  

5 ответов:

это не ошибка, это следствие того, как Xcode обрабатывает файлы раскадровки. Я пишу программу diff и merge для раскадровки файлов (ссылка на 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” внутри. Просто!
75  
2014-06-12 16:03:35

Это ошибка в XCode 4.5+, я надеюсь, что она будет исправлена, и да его Пита.

вот полная ошибка в Apple

Как избежать безвозмездных правок Xcode в файлы раскадровки?

17  
2017-05-23 14:47:10

эта проблема может быть несколько смягчена чрезвычайно разумным использованием git add -p на любом из сгенерированных файлов Xcode, включая раскадровки, XIBs, модели основных данных и файлы проекта, все из которых страдают от подобных переходных изменений, которые не влияют на фактический интерфейс/модель/проект.

наиболее распространенными нежелательными изменениями, которые я видел на раскадровках, являются номера версий системы (как вы упомянули) и постоянное добавление и удаление <classes> раздел, пропуск из которых я никогда не видел проблем. Для XIBs, это добавление и удаление <reference key="NSWindow"/>, который даже не является классом в Cocoa Touch. Просто вау.

думайте об этом как о море: есть как прилив, так и отлив. Пусть он омывает тебя.

Аааа. Вот и все.

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

единственное преимущество, которое я видел с раскадровки над XIBs с технической точки зрения заключается в том, что Apple еще не кастрировала FileMerge, чтобы отказаться от слияния конфликтующих раскадровок. (FileMerge раньше мог объединять XIBs, но более новые версии сломали это. Thxxxx ребята !!!)

пожалуйста, напишите много ошибок обо всех этих проблемах в http://bugreporter.apple.com/! и не забудьте создать записи на OpenRadar.

11  
2012-11-20 16:33:49

бросив на другой ответ здесь, потому что эта ситуация значительно улучшилась. XML для файла XIB, который представляет раскадровку, был значительно упрощен.

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

во всяком случае, сегодня я заметил, что на раскадровке произошло изменение, и встроенный diff показал мне, что это один атрибут в теге документа (systemVersion). Так что ничего страшного.

Я читал статьи, где люди говорят, что SBs были вне закона в своих командах из-за слияния проблем. Полное безумие. Они настолько удивительны, особенно теперь, когда у них есть встроенный интеллектуальный автозапуск, вы действительно упускаете, если не используете их.

5  
2013-11-01 20:14:13

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

  1. не совершайте ничего, пока явно не проинструктированы.

  2. откройте Xcode и создайте новую раскадровку (команда+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.pbxproj через git checkout -- project.pbxproj. Если вы git diff файл, вы увидите, что он только что добавил информацию о нашей временной раскадровке (которая больше не существует).

  12. откройте резервную копию Xcode и убедитесь, что предупреждения исчезли.

  13. дышать.

3  
2015-07-11 19:26:05

Comments

    Ничего не найдено.
Click here to cancel reply.