Xcode thay đổi tập tin cốt truyện và tập tin XIB chưa sửa đổi


132

Bảng phân cảnh là một nỗi đau hoàng gia từ góc độ công việc git khi nhiều người đang hợp tác với họ. Ví dụ: XML trong tệp .storyboard có <document>thẻ bắt đầu toolsVersionsystemVersioncác thuộc tính được thay đổi bởi bất kỳ cấu hình nào mà trình thao tác tệp gần đây nhất đang chạy. Đồng bộ hóa chính xác các phiên bản Xcode của mọi người có vẻ hữu ích toolsVersion, nhưng systemVersionthay đổi bất kể điều gì, tùy thuộc vào phiên bản Mac và / hoặc OS X cụ thể mà nhà phát triển đang chạy.

Điều này là ngu ngốc, nhưng chủ yếu là vô hại. Tuy nhiên, điều khiến chúng tôi lo lắng là vào thời điểm khác, một số thay đổi khác sẽ tự động được thực hiện cho bảng phân cảnh chỉ bằng cách mở chúng sau một git pull. Điều đó có nghĩa là, Alice thực hiện các thay đổi cho bảng phân cảnh, cam kết và đẩy chúng vào kho lưu trữ. Sau đó, Bob kéo các thay đổi của Alice và mở bảng phân cảnh để thực hiện các thay đổi tiếp theo. Khoảnh khắc anh mở bảng phân cảnh, biểu tượng tập tin ngay lập tức chuyển sang trạng thái đã sửa đổi nhưng chưa được lưu và git statuscho thấy rằng bất kỳ số lượng thay đổi kỳ lạ nào đã xảy ra. Tất cả điều này mà không có Bob đã thay đổi bất cứ điều gì hoặc tự lưu tập tin.

Thay đổi tự động phổ biến nhất mà chúng tôi thấy là sự biến mất hoặc xuất hiện lại của toàn bộ <classes>thẻ chữ tượng hình gần cuối tệp bảng phân cảnh. Chúng tôi đã không tìm ra những gì gây ra điều này. Chúng tôi có thể có một số phiên bản được bản địa hóa của một bảng phân cảnh trong các thư mục .lproj khác nhau và khi mở chúng trong Trình tạo giao diện, hệ thống phân cấp lớp có thể tự động bị xóa khỏi một số và thêm vào một số khác hoặc để lại một mình. Điều này gây ra nhiều tiếng ồn git diff, nhưng nó không thực sự phá vỡ bất kỳ chức năng nào. Chúng tôi thường sẽ chọn lọc thêm các thay đổi thực tế mà chúng tôi đã thực hiện vào chỉ mục của git, cam kết những thay đổi đó và sau đó chỉ loại bỏ các thay đổi tự phát, vô nghĩa<classes>thay đổi. Điều này là để giữ cho các cam kết nhỏ và tốt đẹp, như họ nên được. Tuy nhiên, cuối cùng, mọi thứ trở nên quá bận tâm vì Xcode tiếp tục thực hiện lại các thay đổi và ai đó chỉ sử dụng chúng cùng với một số nội dung khác ... sẽ ổn cho đến khi Xcode của người khác quyết định không muốn thay đổi lại lý do rõ ràng. (Lịch sử cam kết của chúng tôi có rất nhiều lời chửi thề về điều này.)

Có ai khác nhìn thấy hành vi này? Đây có phải là lỗi Xcode hoặc sự cố cấu hình trên một hoặc nhiều máy Mac dành cho nhà phát triển của chúng tôi không? Chúng tôi đã thấy một số hành vi tương tự khi cộng tác với các tệp XIB, nhưng bảng phân cảnh có vẻ dễ bị ảnh hưởng hơn.


Thật vậy, các dự án Xcode và Git không hoạt động tốt với nhau. Tôi không nghĩ bạn có thể tránh được mớ hỗn độn này ngoài cách loại bỏ những thay đổi không cần thiết - hầu như luôn luôn là các tệp dự án thay đổi cho tôi và các tệp xml khác Tôi chắc chắn tôi đã không thay đổi. Sẽ vui mừng nếu có bất kỳ loại "giải pháp" nào. Tôi thích Perforce vì chức năng khóa tiện lợi không cho phép Xcode thay đổi quá nhiều, điều đó có thể được thực hiện thủ công cho các tệp mà bạn sẽ không thay đổi mà chỉ để xem xét.
A-Live

3
Không đáng sử dụng bảng phân cảnh với git hoặc bất cứ điều gì khác. Họ không được thiết kế để thân thiện. Chúng tôi đã từ bỏ và đi với .xib, điều đó cũng không tuyệt vời lắm nhưng ít nhất đó là dạng hạt.
ahwulf

Chúng tôi đã tìm thấy bảng phân cảnh khá gọn gàng cho khá nhiều thứ thực sự, mặc dù thường cần phải trộn chúng với XIB. Nếu lỗi này đã được sửa, chúng tôi sẽ rất vui khi làm việc với chúng trong phần lớn thời gian.
JK Laiho

Tôi chỉ cần bình luận về nhận xét của ahwulf: ý bạn là gì trên thế giới không thân thiện? Chúng là các tệp XML / văn bản, đó là về sự thân thiện như bạn có thể nhận được. Và tôi đã gặp vấn đề 'không' với bảng phân cảnh và hệ thống phiên bản, vấn đề duy nhất là dĩ nhiên xcode đôi khi xóa thẻ <class> và sau đó kiểm tra lại, nhưng bạn có thể thấy điều này dễ dàng nếu bạn nhìn vào các thay đổi với GUI git hoặc git -p hoặc tương đương với bất cứ dvcs nào. Tôi chưa bao giờ có điều này xảy ra với tệp .pbxproj dưới dạng fyi.
mgrandi

Tôi không thể hiểu tại sao xcode đặt các khối lớp bên trong bảng phân cảnh nếu anh ta chỉ có thể tạo các khối đó bằng cách đọc các tệp lớp? chúng có phải là một loại "bộ đệm" không? nếu vậy chúng nên được đặt trong tệp class.cache để chúng tôi có thể loại trừ nó khỏi phiên bản ...
hariseldon78

Câu trả lời:


78

Đây không phải là một lỗi, đây là hậu quả của cách Xcode xử lý các tệp bảng phân cảnh. Tôi đang viết một chương trình khác và hợp nhất cho các tập tin bảng phân cảnh (liên kết GitHub) và tôi đã dành hàng giờ để phân tích logic tập tin bảng phân cảnh và cách Xcode xử lý nó. Đây là những gì tôi khám phá ra:

  • Tại sao những thay đổi kỳ lạ xảy ra trong các tập tin bảng phân cảnh? Xcode sử dụng API NSXML để phân tích các tệp bảng phân cảnh thành NSSetcấu trúc cây logic dựa trên một số cơ sở. Khi Xcode cần ghi thay đổi, nó tạo ra một NSXMLDocumentcấu trúc dựa trên cấu trúc cây logic, xóa tệp bảng phân cảnh và gọi XMLDataWithOptions:để điền lại tệp. Bởi vì các tập hợp không bảo toàn thứ tự các phần tử của chúng, ngay cả sửa đổi nhỏ nhất cũng có thể thay đổi toàn bộ tệp XML của bảng phân cảnh.

  • Tại sao thẻ lớp biến mất hoặc xuất hiện lại ngẫu nhiên? Các <class>phần là gì khác hơn là một bộ nhớ cache Xcode nội bộ. Xcode sử dụng nó để lưu trữ thông tin về các lớp. Bộ nhớ cache thay đổi thường xuyên. Các phần tử được thêm vào khi .h/.mcác tệp lớp được mở và xóa khi Xcode nghi ngờ chúng đã lỗi thời (ít nhất là các Xcodes cũ hoạt động như thế này). Khi bạn lưu bảng phân cảnh, phiên bản hiện tại của bộ đệm sẽ bị hủy, đó là lý do tại sao <class>phần này thường thay đổi hoặc thậm chí biến mất.

Tôi đã không thiết kế ngược Xcode; Tôi đã thực hiện những quan sát này bằng cách thử nghiệm với các tệp Xcode và bảng phân cảnh. Tuy nhiên, tôi gần như chắc chắn 100% nó hoạt động theo cách này.

Kết luận :

  • Phần bộ nhớ cache là không quan trọng; bạn có thể yên tâm bỏ qua mọi thay đổi trong đó.
  • Trái với những gì bạn có thể tìm thấy trên tất cả các diễn đàn, việc hợp nhất các tập tin bảng phân cảnh không phải là một nhiệm vụ phức tạp. Ví dụ: giả sử bạn đã thay đổi trình MyController1điều khiển xem trong tài liệu bảng phân cảnh. Mở tập tin bảng phân cảnh và tìm một cái gì đó như thế này <viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>. Bạn chỉ có thể cam kết thay đổi một cách an toàn trong phần này và bỏ qua mọi thứ khác. Nếu bạn thay đổi sự khác biệt hoặc ràng buộc, cũng cam kết bất cứ điều gì có “ory-XY-OBM”bên trong. Đơn giản!

9
Bất kỳ cập nhật nào trên công cụ diff / merge xcode? Âm thanh như nó sẽ siêu hữu ích cho cộng đồng này.
Tony

1
Bạn có thể lấy ứng dụng từ trang web của tôi (xem hồ sơ). Ứng dụng này miễn phí 100%.
Marcin Olawski

1
Đối với tôi, chia bảng phân cảnh càng nhiều càng tốt == sử dụng XIB. Nếu bạn muốn mọi thứ được cắt lát, sử dụng XIBs sẽ dễ dàng và tốt hơn
Marcin Olawski

7
"Tôi chưa thiết kế ngược Xcode; tôi đã thực hiện những quan sát này bằng cách thử nghiệm với các tệp Xcode và bảng phân cảnh." Đó kỹ thuật đảo ngược (nông), và nó thật tuyệt . :-)
Constantino Tsarouhas

13
"Đây không phải là một lỗi, đây là hậu quả của cách Xcode xử lý các tập tin bảng phân cảnh." Trân trọng, nửa sau của câu này không có cách nào giải thích cũng như không hợp lý hóa phần đầu tiên. Tôi đã sửa đổi nó thành: "Đây là một lỗi. Đây là hậu quả [không may không được giải quyết và rất khó chịu] về cách XCode xử lý các tệp .xib." Từ XCode 5.x đến 6.2 (ngày nay, 150311) .xib không bị sửa đổi bởi nhà phát triển, chỉ xem trong IB, chịu những thay đổi xml vô cớ. Đây là một lỗi tổng thể ảnh hưởng đến năng suất. Những phản hồi như "NBD, chỉ cần xử lý w / chunk trong git" khiến tôi không nói nên lời.
vào

18

Đây là một lỗi trong XCode 4.5+, tôi hy vọng nó đã được sửa và có Pita.

Đây là lỗi đầy đủ tại Apple

Làm cách nào để tránh các chỉnh sửa Xcode miễn phí cho các tập tin bảng phân cảnh?


1
Điều tương tự trong 4.6. Có lẽ nó không phải là một lỗi.
Thromordyn

4.6.3 vẫn có nó. Không thể nói rằng bảng phân cảnh / xibs đã từng hoạt động tốt
houbysoft 15/07/13

1
"Đó không phải là một lỗi, đó là một tính năng": -S
MrTJ

Không có bằng chứng nào cho thấy đây là một lỗi - có phiền toái, nhưng đó có thể chỉ là cách Xcode thực hiện
Thomas Watson

1
7.0.1 đã không mang lại bất kỳ thay đổi nào cho việc này.
Andris Zal viêm

11

Vấn đề này có thể được giảm bớt phần nào bằng cách sử dụng cực kỳ thận trọng đối git add -pvới bất kỳ tệp nào được tạo bởi Xcode, bao gồm bảng phân cảnh, XIB, mô hình Dữ liệu lõi và tệp dự án, tất cả đều chịu các sửa đổi tạm thời tương tự không ảnh hưởng đến giao diện / mô hình thực tế / dự án.

Những thay đổi rác phổ biến nhất tôi từng thấy trên bảng phân cảnh là số phiên bản hệ thống (như bạn đã đề cập) và việc thêm và xóa <classes>phần liên tục , thiếu sót mà tôi chưa bao giờ thấy có vấn đề. Đối với XIB, đó là sự bổ sung và loại bỏ <reference key="NSWindow"/>, thậm chí không phải là một lớp trong Cacao Touch. Chỉ là wow.

Hãy nghĩ về nó giống như biển: có cả thủy triều cao và thấp. Hãy để nó rửa qua bạn.

À Đó là nó.

Bạn có thể bỏ qua những sửa đổi này khi sắp xếp các thay đổi của mình, đặt lại các thay đổi rác và thực hiện một cam kết rõ ràng.

Ưu điểm duy nhất tôi thấy với các bảng phân cảnh trên XIB theo quan điểm kỹ thuật là Apple vẫn chưa xử lý FileMerge để từ chối hợp nhất các bảng phân cảnh bị xung đột. (FileMerge đã từng có thể hợp nhất XIB, nhưng các phiên bản mới hơn đã phá vỡ điều đó. Thxxxx guys 💜 !!!)

Vui lòng gửi nhiều lỗi về tất cả các vấn đề này tại http://bugreporter.apple.com/ ! Và đừng quên tạo các mục trên OpenRadar .


6

Ném vào một câu trả lời khác ở đây vì tình trạng này đã được cải thiện rất nhiều. XML cho tệp XIB đại diện cho StoryBoard đã được đơn giản hóa rất nhiều.

Gần đây tôi cũng đã cắn viên đạn và bắt đầu sử dụng giao diện trong Xcode để Kiểm soát nguồn. Tôi đã ở trên dòng lệnh trong nhiều năm và hạnh phúc ở đó, nhưng giao diện rất tuyệt và nó cho phép bạn phân chia các cam kết, điều này thực sự quan trọng nếu bạn sử dụng một hệ thống bán vé liên kết với các cam kết.

Dù sao, tôi nhận thấy rằng có một sự thay đổi trên bảng phân cảnh và sự khác biệt được xây dựng cho tôi thấy đó là một thuộc tính duy nhất trong thẻ tài liệu (systemVersion). Vì vậy, không phải là một vấn đề lớn.

Tôi đã đọc những bài báo mà mọi người nói rằng SB bị đặt ra ngoài vòng pháp luật trong đội của họ vì các vấn đề hợp nhất. Tổng số điên rồ. Chúng thật tuyệt vời, đặc biệt là bây giờ chúng có tính năng tự động thanh toán thông minh được tích hợp, bạn thực sự đang bỏ lỡ nếu bạn không sử dụng chúng.


3

Thật hữu ích khi biết lý do tại sao sự điên rồ này xảy ra, nhưng đối với những người tin vào việc giữ cho các dự án của họ không bị cảnh báo và những người chỉ muốn nhanh chóng và bẩn thỉu để đưa các dự án của họ trở lại trạng thái khỏe mạnh:

  1. Đừng cam kết bất cứ điều gì cho đến khi được hướng dẫn rõ ràng.

  2. Mở Xcode và tạo bảng phân cảnh mới (Command + N> iOS> Giao diện người dùng> Bảng phân cảnh). Tôi sẽ giả sử bạn gọi nó là tên mặc định của Storyboard.storyboard.

  3. Mở bảng phân cảnh mà Xcode đã vi phạm. Tôi sẽ cho rằng đây là Base.lproj/Main.storyboard.

  4. Chọn và sao chép mọi thứ trên bảng phân cảnh (Command + A rồi Command + C).

  5. Mở Storyboard.storyboard.

  6. Sao chép và dán mọi thứ vào Storyboard.storyboard.

  7. Đóng Xcode.

  8. Mở một thiết bị đầu cuối và thay đổi thư mục vào kho lưu trữ của bạn.

  9. Thay thế Main.storyboardbằng Storyboard.storyboard( mv Storyboard.storyboard Base.lproj/Main.storyboard).

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

  11. Bỏ qua những thay đổi project.pbxprojthông qua git checkout -- project.pbxproj. Nếu bạn git difflà tệp, bạn sẽ thấy rằng nó vừa thêm thông tin về bảng phân cảnh tạm thời của chúng tôi (không còn tồn tại).

  12. Mở Xcode sao lưu và thấy rằng các cảnh báo đã biến mất.

  13. Thở đi.


0

Làm việc trên cùng một bảng phân cảnh không phải là một vấn đề. Nhưng làm việc trên cùng một trình điều khiển tạo ra xung đột khi kéo / hợp nhất thì thật đáng sợ. chúng tôi thực sự không thể tránh việc làm việc trong cùng một trình điều khiển cho một nhóm lớn.

Điều tốt là, hầu hết thời gian chúng ta có thể sửa các xung đột trình điều khiển tương tự nếu chúng ta hiểu cấu trúc xml. Tôi không bao giờ thất bại trong việc hợp nhất những thứ này khi làm việc trong nhóm. Giả sử bạn đang làm việc với một trình điều khiển xem. Quan điểm của bạn hiện đang trống. Xin vui lòng, hãy xem cấu trúc xml của khung điều khiển từ tùy chọn mã nguồn.

nhập mô tả hình ảnh ở đây

Storyboard là xml giới hạn bởi thẻ loại tài liệu. Mọi thứ trong bảng phân cảnh đều chứa trong cảnh SceneID = tag. thẻ cảnh giữ mọi viewcontrollers. Đó là cơ bản.

Bây giờ chúng tôi đã thêm một UILabel và một UIButton trên khung nhìn. Cũng thiết lập tự động thanh toán của các yếu tố. Bây giờ nó trông giống như:

nhập mô tả hình ảnh ở đây

Thêm một mức / nút cho trình điều khiển khung nhìn đã thêm một số mã mới bên trong thẻ xem phụ của khung nhìn. Điều tương tự sẽ được bổ sung thêm phần tử hoặc bất kỳ thay đổi UI nào. Kiểm tra cẩn thận cấu trúc thẻ thực sự quan trọng để khắc phục mọi xung đột.

Bây giờ chúng tôi thêm một trình điều khiển khung nhìn khác trong tên bảng phân cảnh Homeview điều khiển. Thêm một trình điều khiển khung nhìn mới có nghĩa là nó thêm một cảnh mới dưới thẻ cảnh. Nhìn vào cái này

nhập mô tả hình ảnh ở đây

Tại thời điểm này, chúng tôi sẽ thay đổi cấu trúc một cách ngẫu nhiên và quan sát các vấn đề / cảnh báo. Chúng tôi thay đổi thẻ kết thúc nhãn điều khiển đầu tiên và lưu tệp. Bây giờ chạy nó và nhìn vào cảnh báo. Lỗi cho biết thẻ kết thúc không đúng được tạo từ dòng 23. Trong dòng 23, chúng tôi thấy các ràng buộc nhãn được đặt không có thẻ kết thúc. Đó chính là vấn đề. Bây giờ chúng tôi đặt thẻ kết thúc và xây dựng dự án. Sau khi thiết lập thẻ kết thúc, chúng ta có thể xem bảng phân cảnh thành công.

nhập mô tả hình ảnh ở đây

Khi gặp bất kỳ cảnh báo nào về xung đột, vui lòng so sánh với nguồn trước đó và thay đổi nguồn. Chúng tôi xóa mã cũ / dự phòng, giữ mã mới với đầu bắt đầu thẻ thích hợp và sửa lỗi.

[NB, tôi sẽ cập nhật câu trả lời với một số trường hợp kiểm tra khác khi nhận được thời gian]

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.