Xcode mengubah storyboard dan file XIB yang tidak dimodifikasi


132

Storyboard agak sakit kerajaan dari perspektif alur kerja git ketika banyak orang berkolaborasi pada mereka. Misalnya, XML dalam file .storyboard memiliki <document>tag awal toolsVersiondan systemVersionatribut yang diubah oleh konfigurasi apa pun yang sedang dijalankan oleh manipulator file terbaru. Menyinkronkan semua versi Xcode tampaknya justru membantu toolsVersion, tetapi systemVersionperubahan apa pun yang terjadi, tergantung pada versi Mac dan / atau OS X tertentu yang sedang dijalankan pengembang.

Ini bodoh, tetapi kebanyakan tidak berbahaya. Yang membuat kami khawatir, adalah bahwa di waktu lain beberapa perubahan lain secara otomatis dibuat ke storyboard hanya dengan membukanya setelah a git pull. Dengan kata lain, Alice membuat perubahan pada storyboard, melakukan dan mendorongnya ke repositori. Bob kemudian menarik perubahan Alice dan membuka papan cerita untuk membuat perubahan lebih lanjut. Saat dia membuka storyboard, ikon file segera berubah ke keadaan yang dimodifikasi tetapi tidak disimpan, dan git statusmenunjukkan bahwa sejumlah perubahan aneh telah terjadi. Semua ini tanpa Bob telah mengubah apa pun atau menyimpan file sendiri.

Perubahan otomatis paling umum yang kami lihat adalah hilangnya atau kemunculan kembali seluruh <classes>hierarki tag di dekat akhir file storyboard. Kami belum menemukan apa yang menyebabkan ini. Kami mungkin memiliki beberapa versi lokal storyboard di berbagai direktori .lproj, dan ketika membukanya di dalam Interface Builder, hierarki kelas dapat secara spontan dihapus dari beberapa dan ditambahkan ke yang lain, atau dibiarkan sendiri di beberapa. Ini menyebabkan banyak kebisingan git diff, tetapi sebenarnya tidak merusak fungsionalitas apa pun. Kita akan sering secara selektif menambahkan perubahan aktual yang kita buat ke dalam indeks git, melakukan itu, dan kemudian hanya membuang spontan, tidak masuk akal<classes>perubahan. Ini untuk menjaga komitmen kecil dan baik, sebagaimana mestinya. Namun, pada akhirnya, itu menjadi terlalu merepotkan karena Xcode terus melakukan perubahan lagi, dan seseorang hanya memeriksanya bersama dengan beberapa hal lain ... yang baik-baik saja sampai Xcode orang lain memutuskan ingin mengubahnya kembali tanpa alasan yang jelas. (Riwayat komit kami memiliki banyak sumpah untuk ini.)

Adakah orang lain yang melihat perilaku ini? Apakah ini bug Xcode atau masalah konfigurasi pada satu atau lebih Mac pengembang kami? Kami telah melihat beberapa perilaku serupa ketika berkolaborasi dengan file XIB, tetapi storyboard tampaknya lebih rentan terhadap ini.


Memang proyek Xcode dan Git tidak berjalan dengan sangat baik. Saya tidak berpikir Anda bisa menghindari kekacauan ini selain membuang perubahan yang tidak perlu - yang hampir selalu file proyek berubah untuk saya dan file xml lainnya. Saya yakin saya tidak berubah. Akan senang jika ada semacam 'solusi'. Saya suka Perforce untuk fungsionalitas kunci yang mudah, tidak memungkinkan Xcode berubah terlalu banyak, yang mungkin dilakukan secara manual untuk file yang tidak akan Anda ubah tetapi hanya untuk meninjau.
A-Live

3
Tidak layak menggunakan storyboard dengan git atau apa pun. Mereka tidak dirancang untuk menjadi ramah. Kami menyerah dan pergi dengan .xib yang tidak terlalu bagus tapi setidaknya granular.
ahwulf

Kami telah menemukan storyboard cukup rapi untuk banyak hal sebenarnya, meskipun seringkali perlu mencampurnya dengan XIB. Jika bug ini diperbaiki, kami akan senang bekerja dengan mereka sebagian besar waktu.
JK Laiho

Saya hanya perlu mengomentari komentar ahwulf: apa maksudmu mereka tidak ramah? Itu adalah file XML / teks, itu tentang komit ramah yang bisa Anda dapatkan. Dan saya punya masalah 'tidak' dengan storyboard dan sistem versi, satu-satunya masalah adalah tentu saja xcode terkadang menghapus tag <class> dan kemudian membacanya lagi, tetapi Anda dapat melihatnya dengan mudah jika Anda melihat perubahan dengan a Git GUI atau git -p atau setara untuk DVD apa pun. Saya tidak pernah mengalami hal ini dengan file .pbxproj sebagai fyi.
mgrandi

Saya tidak mengerti mengapa xcode menempatkan blok-blok kelas di dalam storyboard jika dia bisa menghasilkan blok-blok itu dengan membaca file-file kelas? apakah mereka semacam "cache"? jika demikian mereka harus dimasukkan ke dalam file classes.cache sehingga kita dapat mengecualikannya dari versi ...
hariseldon78

Jawaban:


78

Ini bukan bug, ini adalah konsekuensi dari bagaimana Xcode memproses file storyboard. Saya menulis program diff dan gabung untuk file storyboard (tautan GitHub) dan saya telah menghabiskan waktu berjam-jam menganalisis logika file storyboard dan bagaimana Xcode memprosesnya. Inilah yang saya temukan:

  • Mengapa perubahan aneh terjadi pada file storyboard? Xcode menggunakan NSXML API untuk mem-parsing file storyboard menjadi beberapa NSSetstruktur pohon logis. Ketika Xcode perlu menulis perubahan, itu menciptakan sebuah NSXMLDocumentberdasarkan pada struktur pohon logis, menghapus file storyboard dan panggilan XMLDataWithOptions:untuk mengisi file lagi. Karena set tidak mempertahankan urutan elemennya, bahkan modifikasi sekecil apa pun dapat mengubah seluruh file XML storyboard.

  • Mengapa tag kelas hilang atau muncul kembali secara acak? The <class>Bagian tidak lebih dari cache Xcode internal. Xcode menggunakannya untuk menyimpan informasi tentang kelas. Cache sering berubah. Elemen ditambahkan ketika .h/.mfile kelas dibuka dan dihapus ketika Xcode menduga mereka sudah usang (setidaknya Xcode lama berperilaku seperti ini). Ketika Anda menyimpan storyboard, yang saat ini versi cache dibuang, yang mengapa <class>bagian sering berubah atau bahkan menghilang.

Saya belum melakukan rekayasa ulang Xcode; Saya melakukan pengamatan ini dengan bereksperimen dengan file Xcode dan storyboard. Namun demikian, saya hampir 100% yakin itu bekerja dengan cara ini.

Kesimpulan :

  • Bagian cache tidak penting; Anda dapat dengan aman mengabaikan perubahan apa pun di dalamnya.
  • Berlawanan dengan apa yang dapat Anda temukan di semua forum, menggabungkan file storyboard bukanlah tugas yang rumit. Misalnya, anggap Anda mengubah MyController1pengontrol tampilan dalam dokumen storyboard. Buka file storyboard, dan temukan sesuatu seperti ini <viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>. Anda hanya dapat melakukan perubahan di bagian ini dengan aman dan mengabaikan yang lainnya. Jika Anda mengubah segue atau kendala, lakukan juga apa yang ada “ory-XY-OBM”di dalamnya. Sederhana!

9
Adakah pembaruan pada alat xcode diff / merge? Kedengarannya akan sangat berguna untuk komunitas ini.
Tony

1
Anda bisa mendapatkan aplikasi dari halaman web saya (lihat profil). Aplikasi ini 100% gratis.
Marcin Olawski

1
Bagi saya membagi storyboard sebanyak mungkin == menggunakan XIB. Jika Anda ingin semua yang diiris, lebih mudah dan lebih baik menggunakan XIB
Marcin Olawski

7
"Saya belum melakukan rekayasa balik Xcode; saya melakukan pengamatan ini dengan bereksperimen dengan Xcode dan file storyboard." Itu adalah (dangkal) reverse-engineering, dan itu keren . :-)
Constantino Tsarouhas

13
"Ini bukan bug, ini adalah konsekuensi dari bagaimana Xcode memproses file storyboard." Dengan hormat, setengah kalimat ini sama sekali tidak menjelaskan atau merasionalisasi yang pertama. Saya akan mengubahnya menjadi: "Ini adalah bug. Ini adalah konsekuensi [n sayangnya tidak terselesaikan dan sangat mengganggu] dari bagaimana XCode memproses file .xib." Dari XCode 5.x hingga 6.2 (hari ini, 150311) file .xib sama sekali tidak dimodifikasi oleh pengembang, hanya dilihat di IB, mengalami perubahan xml serampangan. Ini adalah bug kotor yang memengaruhi produktivitas. Tanggapan seperti "NBD, hanya berurusan dengan potongan di git" biarkan aku terdiam.
setiap

18

Ini adalah bug di XCode 4.5+, saya harap itu diperbaiki, dan ya itu PITA.

Inilah bug lengkapnya di Apple

Bagaimana cara menghindari pengeditan Xcode gratis untuk file storyboard?


1
Hal yang sama di 4.6. Mungkin itu bukan bug.
Thromordyn

4.6.3 masih memilikinya. Tidak bisa mengatakan bahwa storyboard / xibs pernah bekerja dengan baik
houbysoft

1
"Ini bukan bug, ini fitur": -S
MrTJ

Tidak ada bukti bahwa ini adalah bug - gangguan ya, tapi mungkin saja Xcode melakukan sesuatu
Thomas Watson

1
7.0.1 belum membawa perubahan apa pun pada hal ini.
Andris Zalitis

11

Masalah ini dapat dikurangi dengan penggunaan yang sangat bijaksana git add -p pada setiap file yang dihasilkan Xcode, termasuk storyboard, XIB, model Data Inti, dan file proyek, yang semuanya menderita modifikasi sementara yang serupa yang tidak berdampak pada antarmuka / model yang sebenarnya / proyek.

Perubahan sampah yang paling umum yang pernah saya lihat di storyboard adalah nomor versi sistem (seperti yang Anda sebutkan) dan penambahan dan penghapusan <classes>bagian yang konstan , kelalaian yang belum pernah saya lihat menyebabkan masalah. Untuk XIB, ini adalah penambahan dan penghapusan<reference key="NSWindow"/> , yang bahkan bukan kelas di Cocoa Touch. Cuma wow.

Pikirkan itu seperti laut: ada air pasang dan surut. Biarkan itu menyapu Anda.

Ahh. Itu dia.

Anda dapat mengabaikan modifikasi ini saat melakukan perubahan, mereset perubahan sampah, dan melakukan commit bersih.

Keuntungan tunggal yang saya lihat dengan storyboard dibanding XIB dari sudut pandang teknis adalah bahwa Apple belum mensterilkan FileMerge untuk menolak menggabungkan storyboard yang bertentangan. (FileMerge digunakan untuk dapat menggabungkan XIB, tetapi versi yang lebih baru mematahkannya. Thxxxx guys 💜 !!!)

Silakan ajukan banyak bug tentang semua masalah ini di http://bugreporter.apple.com/ ! Dan jangan lupa untuk membuat entri di OpenRadar .


6

Melontarkan jawaban lain di sini karena situasi ini telah sangat meningkat. XML untuk file XIB yang mewakili StoryBoard telah sangat disederhanakan.

Saya juga baru saja menggigit peluru dan mulai menggunakan antarmuka dalam Xcode ke Kontrol Sumber. Saya telah berada di baris perintah selama bertahun-tahun dan senang di sana, tetapi antarmuka yang bagus dan memungkinkan Anda membagi komit, yang sangat penting jika Anda menggunakan sistem tiket yang menghubungkan ke komit.

Bagaimanapun, saya perhatikan hari ini bahwa ada perubahan pada storyboard dan diff built in menunjukkan kepada saya itu adalah atribut tunggal dalam tag dokumen (systemVersion). Jadi bukan masalah besar.

Saya telah membaca artikel di mana orang mengatakan SB dilarang di tim mereka karena masalah penggabungan. Kegilaan total. Mereka sangat menakjubkan, terutama sekarang karena mereka memiliki autolayout yang cerdas, Anda benar-benar kehilangan jika Anda tidak menggunakannya.


3

Sangat membantu untuk mengetahui mengapa kegilaan ini terjadi, tetapi bagi mereka yang percaya menjaga proyek mereka bebas dari peringatan dan yang hanya ingin yang cepat dan kotor untuk mengembalikan proyek mereka ke keadaan yang sehat:

  1. Jangan melakukan apa pun sampai diperintahkan secara eksplisit.

  2. Buka Xcode dan buat storyboard baru (Command + N> iOS> User Interface> Storyboard). Saya akan menganggap Anda menyebutnya nama default Storyboard.storyboard.

  3. Buka storyboard yang dilanggar Xcode. Saya akan menganggap ini Base.lproj/Main.storyboard.

  4. Pilih dan salin semua yang ada di storyboard (Command + A lalu Command + C).

  5. Terbuka Storyboard.storyboard.

  6. Salin dan rekatkan semuanya ke Storyboard.storyboard.

  7. Tutup Xcode.

  8. Buka terminal dan ubah direktori ke repositori Anda.

  9. Ganti Main.storyboarddengan Storyboard.storyboard( mv Storyboard.storyboard Base.lproj/Main.storyboard).

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

  11. Abaikan perubahan project.pbxprojmelalui git checkout -- project.pbxproj. Jika Anda git difffile, Anda akan melihat bahwa itu baru saja menambahkan informasi tentang storyboard sementara kami (yang tidak ada lagi).

  12. Buka Xcode cadangan dan lihat bahwa peringatan telah menghilang.

  13. Bernafas.


0

Bekerja di storyboard yang sama bukanlah masalah. Tetapi bekerja pada viewcontroller yang sama yang menciptakan konflik pada tarikan / penggabungan menakutkan. kita tidak bisa benar-benar menghindari itu bekerja di viewcontroller yang sama untuk tim besar.

Untungnya, sebagian besar waktu kita dapat memperbaiki konflik viewcontroller yang sama jika kita memahami struktur xml. Saya tidak pernah gagal menggabungkan ini saat bekerja dalam tim. Misalkan Anda bekerja dengan viewcontroller. Tampilan Anda kosong saat ini. Silakan, lihat struktur xml viewcontroller dari opsi kode sumber.

masukkan deskripsi gambar di sini

Storyboard dibatasi xml oleh tag jenis dokumen. Semua yang ada di storyboard berisi adegan sceneID = tag. tag pemandangan memegang setiap viewcontrollers. Itulah dasar.

Sekarang kami menambahkan UILabel dan UIButton pada tampilan. Juga mengatur autolayout elemen. Sekarang sepertinya:

masukkan deskripsi gambar di sini

Menambahkan level / tombol ke viewcontroller menambahkan beberapa kode baru di dalam tag tampilan subview. Hal yang sama akan berlaku untuk penambahan elemen lebih lanjut atau perubahan UI apa pun. Hati-hati memeriksa struktur tag yang benar-benar penting untuk memperbaiki konflik.

Sekarang kita menambahkan viewcontroller lain dalam nama storyboard Homeviewcontroller. Menambahkan viewcontroller baru berarti menambahkan adegan baru di bawah tag adegan. Lihat ini:

masukkan deskripsi gambar di sini

Pada titik ini, kami akan mengubah struktur secara acak dan mengamati masalah / peringatan. Kami mengubah tag akhir label viewcontroller pertama dan menyimpan file. Sekarang jalankan dan lihat peringatannya. Kesalahan mengatakan tag akhir tidak benar yang dibuat dari baris 23. Pada baris 23, kita melihat batasan label diatur tanpa tag akhir. Itulah masalahnya. Sekarang kita meletakkan tag akhir dan membangun proyek. Setelah mengatur tag akhir, kita dapat melihat storyboard dengan sukses.

masukkan deskripsi gambar di sini

Saat menghadapi peringatan konflik, silakan bandingkan dengan sumber Anda sebelumnya dan sumber perubahan. Kami menghapus kode lama / redundan, menyimpan kode baru dengan tag awal yang benar dan menyelesaikan masalah.

[NB, saya akan memperbarui jawabannya dengan beberapa test case lagi ketika mendapat waktu]

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.