Czy pliki * .xccheckout w Xcode5 powinny być ignorowane w VCS?

157

Firma Apple wprowadziła nowy typ pliku związany z projektem w Xcode 5: „xccheckout”.

Ten plik znajduje się w katalogu „.xcodeproj / project.xcworkspace / xcshareddata /” i wygląda na to, że jest powiązany z systemem kontroli wersji projektu.

Przykładowy plik jest tutaj: http://pastebin.com/5EP63iRa

Przypuszczam, że ten typ pliku powinien być ignorowany w VCS, ale nie jestem pewien.

Oto pytania:

  1. Czy „xccheckout” należy zignorować?
  2. Jaki jest jej cel?
xcode git version-control xcode5 Artem Abramov
źródło
To pytanie wydaje się być dość istotne; dlatego chciałbym, żeby był bardziej poprawny gramatycznie i składniowo. Jeśli jesteś native speakerem lub bardzo biegle władasz angielskim, chciałbym poprosić o pomoc w sprawdzeniu mojego języka. Dziękuję Ci!
Artem Abramov
1
Drobne sugerowane zmiany: „Apple wprowadził nowy”, „Przykładowy plik jest tutaj:”. W pytaniu 1 znajduje się niedopasowany cytat.
Sofi Software LLC
3
Zawsze odwołuję się do repozytorium github / gitignore, aby wiedzieć, które pliki należy zignorować -> github.com/github/gitignore/blob/master/Objective-C.gitignore
eliocs

Odpowiedzi:

109

Ty powinien sprawdzić w Xcode 5 .xccheckoutpliku; ogólnie rzecz biorąc, pliki w xcshareddatapowinny zostać zatwierdzone.

.xccheckoutPlik zawiera metadane o co repozytoria są używane w obszarze roboczym. Dla pojedynczego projektu w jednym repozytorium, to nie robi dużej różnicy. Ale jeśli używasz obszaru roboczego, który ma wiele projektów z różnych repozytoriów, obecność .xccheckoutpliku w obszarze roboczym pozwala Xcode wiedzieć, jakie są wszystkie składniki tworzące obszar roboczy i gdzie je zdobyć.

Chris Hanson
źródło
8
Gdyby nie był przeznaczony do udostępniania, Apple przechowywałby go, .xcuserdatawięc powinien zostać uwzględniony.
Joshcodes,
4
Jak powiedziałem w mojej odpowiedzi, plik xccheckout zawiera informacje o wszystkich repozytoriach używanych w obszarze roboczym. Dzieje się tak niezależnie od tego, jakiego systemu SCM używają - taki obszar roboczy może znajdować się w svn lub git, a jego projekty mogą być mieszanką repozytoriów svn i git.
Chris Hanson
72
Wygląda na to, że xccheckout zawiera klucze i nazwy, które są specyficzne dla każdego komputera programisty ... Gdy tylko uruchomię xcode, zmienia niektóre klucze w pliku i zmienia coś o nazwie IDESourceControlWCCName z <string> OurCompanyAPI </string> na <string > our_company_api / string> - ta ostatnia jest nazwą, której użyłem podczas klonowania repozytorium. Jeśli ten plik ma być udostępniony, Apple wykonał niezłą robotę.
Herr Grumps
7
Kiedy sprawdzamy ten plik, wszyscy moi współpracownicy otrzymują inny identyfikator IDESourceControlProjectIdentifier ... więc nasze .xccheckout jest modyfikowane przy każdym zatwierdzeniu. -_-
Cœur
9
Niezależnie od tego, do czego pierwotnie zamierzał Apple, .xccheckoutpliki powodują pewne szalone problemy w Xcode 6 beta i postanowiłem usunąć je z VCS. Wydaje się, że jest to związane z jakimś błędem buforowania i uważam, że Xcode może automatycznie regenerować je z VCS, za każdym razem.
eonil
63

*.xccheckoutPlik zawiera metadane VCS, a zatem nie powinny być sprawdzane w VCS.

Z drugiej strony: wpisanie tego pliku prawdopodobnie nie spowoduje trudności w scalaniu ani innych problemów.

Jeśli chcesz zignorować ten plik (co polecam), powinieneś dodać ten wiersz do swojego projektu .gitignore:

*.xccheckout

Abizern „s rozwiązanie nie będzie działać na projekty wewnątrz obszaru roboczego. Ponieważ podczas korzystania z obszaru roboczego, ścieżka do *.xccheckoutpliku będzie: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. I faktycznie ignoruje więcej, niż byś chciał.

Edycja: ten plik istnieje do zarządzania wiedzą Xcode o prawdopodobnie wielu systemach VCS w Twoim projekcie, zobacz odpowiedź Chrisa Hansona . W przypadku> 99% projektów plik .xccheckout to przesadna konfiguracja.

Berik
źródło
1
Byłoby wspaniale, gdybyś mógł rozwinąć stwierdzenie, że „tak naprawdę ignoruje więcej, niż byś chciał”. W szczególności kilka przykładów innych plików, które trafiają do tego folderu i powinny zostać zaewidencjonowane.
Mark Edington,
Kontynuacja: używam .gitignore od Adama z tego pytania . Jest ona dostępna jako GIST i ma jakiś opis xcshareddata zawartości folderu.
Mark Edington,
@ Mark : Ignoruje project.xcworkspace/. Na razie może to być w porządku, ale nie liczyłbym na to w nowych wersjach Xcode.
Berik,
6
Ta odpowiedź jest niepoprawna, a standard GitHub, .gitignorektóry zapewnia programistom, nie powinien określać*.xccheckout
Chris Hanson
2
Po włączeniu tego pliku do moich repozytoriów od momentu jego wprowadzenia, niedawno zacząłem usuwać go ze wszystkich moich repozytoriów. To tworzy konflikty scalania przez cały czas, głównie w projektach, które zawierają moje własne frameworki jako submoduły. A potem nic nie zyskuję z tego pliku, ponieważ używam gita do zarządzania submodułami. Niezła próba, Apple, dzięki, ale nie, dziękuję.
Pascal
38

To zależy. Plik zawiera odniesienia do zdalnego repozytorium, którego używasz. Jeśli korzystasz ze scentralizowanego VCS, takiego jak Perforce lub Subversion, zdalne repozytorium wszystkich osób będzie takie samo, więc możesz i powinieneś zaewidencjonować plik.

Jeśli korzystasz z rozproszonego VCS, takiego jak Mercurial lub git, ale używasz go tak, jakby był to CVCS (innymi słowy, wszyscy sklonowali się z udostępnionego repozytorium bezpośrednio do ich osobistego obszaru roboczego na swoim komputerze), nadal możesz chcieć to sprawdzić w.

Jeśli jednak używasz DVCS, a każdy ma swój własny zdalny klon, na przykład używając GitHub w jego standardowym wzorcu użytkowania, NIE CHCESZ sprawdzać tego pliku. Jeśli to zrobiłeś, wtedy żądania ściągnięcia będą pytać o ustawienia repozytorium aby zostać skopiowany do pliku xccheckout innych osób, ale ustawienia twojego repozytorium będą inne niż wszystkich innych, ponieważ wszyscy używacie różnych zdalnych repozytoriów.

Tim Band
źródło
1
Ta odpowiedź wydaje mi się najlepsza. Sprawdzanie ich powodowało niepotrzebną dyskusję na temat różnic w zatwierdzeniach naszego zespołu. Dodaję do .gitignore następujące informacje, aby ich nie ujawniać : * / .xcworkspace / xcshareddata / *. Xccheckout Nadal nie rozumiem, dlaczego Apple zdecydowało się na nadmiarowe przechowywanie tych informacji, które i tak znajdują się w folderze .git (moje jedyne przypuszczenie to spraw, aby wszystko działało konsekwentnie w VCS)
Juan Carlos Méndez
20

Tak, Project.xccheckoutplik powinien zostać zapisany w repozytorium. Xcode używa tego pliku, aby poinformować innych, którzy otwierają obszar roboczy, o całej liście repozytoriów kontroli źródła używanych przez obszar roboczy oraz o lokalizacji kopii roboczej względem obszaru roboczego, czy te repozytoria to Git, SVN, czy oba.

Po otwarciu obszaru roboczego Xcode używa Project.xccheckoutpliku, aby powiadomić użytkownika, że ​​istnieją inne repozytoria tworzące część obszaru roboczego i pyta, które powinny zostać wyewidencjonowane. Podczas wypisywania dodatkowych repozytoriów Xcode umieszcza kopie robocze w tej samej strukturze folderów względem obszaru roboczego, w jakiej były one w momencie Project.xccheckoutgenerowania pliku.

Jak powiedział Chris Hanson , prawdopodobnie nie ma to znaczenia w przypadku obszaru roboczego z jednym repozytorium i jednym projektem, ale w przypadku bardziej złożonych spraw będzie to naprawdę bardzo przydatne.

Możesz dowiedzieć się więcej na ten temat z sesji wideo WWDC 2013 Understanding Source Control in Xcode ; odpowiednia porcja zaczyna się po około 15 minutach.

Calrion
źródło
Ten plik jest przydatny tylko wtedy, gdy używasz Xcode dla SCM, w przeciwnym razie w ogóle nie potrzebujesz tego pliku. A jeszcze mniej, jeśli pracujesz z forkami git, w takim przypadku ścieżka repozytorium będzie unikalna dla każdego programisty
Carlos Ricardo
3

Oto, co mam w moim .gitignore dla Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Zachowuje z repozytorium wszystko, co odnosi się do lokalnego stanu sposobu, w jaki projekty szukają mnie.

Plik xccheckout znajduje się tutaj, więc domyślnie nie jest śledzony w moim systemie.

Xcode stał się lepszy i oddzielał to, co należy udostępniać, a co należy przechowywać lokalnie. Na przykład; te wiersze zignorują domyślne schematy budowania, co jest w porządku, ponieważ można oznaczyć określone schematy kompilacji jako udostępnione i są one umieszczane w katalogu, który nie jest ignorowany.

Punkty przerwania są ignorowane, ale można oznaczyć określone punkty przerwania jako współużytkowane w projektach, a także są one umieszczane w katalogu, który nie jest ignorowany.

Abizern
źródło