Les fichiers * .xccheckout dans Xcode5 doivent-ils être ignorés sous VCS?

157

Apple a introduit un nouveau type de fichier lié au projet dans Xcode 5: "xccheckout".

Ce fichier se trouve dans le répertoire ".xcodeproj / project.xcworkspace / xcshareddata /", et il semble qu'il soit lié au système de contrôle de version du projet.

Un exemple de fichier est ici: http://pastebin.com/5EP63iRa

Je suppose que ce type de fichier doit être ignoré sous VCS, mais je ne suis pas sûr.

Voici donc les questions:

  1. "Xccheckout" doit-il être ignoré?
  2. Quel est son objectif?
xcode git version-control xcode5 Artem Abramov
la source
Cette question a tendance à être tout à fait pertinente; ainsi je voudrais qu'il soit plus grammaticalement et syntaxiquement correct. Si vous êtes de langue maternelle anglaise ou si vous maîtrisez parfaitement l'anglais, j'aimerais demander de l'aide pour vérifier ma langue. Je vous remercie!
Artem Abramov
1
Modifications mineures suggérées: "Apple a introduit un nouveau", "Un exemple de fichier est ici:". Il y a une citation qui ne correspond pas à la question 1.
Sofi Software LLC
3
Je me réfère toujours au repo github / gitignore pour savoir quels fichiers doivent être ignorés -> github.com/github/gitignore/blob/master/Objective-C.gitignore
eliocs

Réponses:

109

Vous devriez vérifier dans un 5 Xcode .xccheckoutfichier; en général, les fichiers xcshareddatadoivent être validés.

Un .xccheckoutfichier contient des métadonnées sur les référentiels utilisés dans un espace de travail. Pour un seul projet dans un seul référentiel, cela ne fait pas beaucoup de différence. Mais si vous utilisez un espace de travail qui contient plusieurs projets de différents référentiels, la présence d'un .xccheckoutfichier dans l'espace de travail permet à Xcode de savoir quels sont tous les composants qui composent un espace de travail et où les obtenir.

Chris Hanson
la source
8
S'il n'était pas destiné à être partagé, Apple le stockerait .xcuserdata, il devrait donc être inclus.
Joshcodes
4
Comme je l'ai dit dans ma réponse, le fichier xccheckout contient des informations sur tous les référentiels utilisés dans un espace de travail. C'est le cas quel que soit le système SCM utilisé - un tel espace de travail peut être dans svn ou git, et ses projets peuvent être dans un mélange de référentiels svn et git.
Chris Hanson
72
Il semble que xccheckout contient des clés et des noms spécifiques à la machine de chaque développeur ... Dès que j'exécute xcode, il change certaines clés du fichier et change quelque chose appelé IDESourceControlWCCName de <string> OurCompanyAPI </string> à <string > our_company_api / string> - ce dernier étant le nom que j'ai utilisé lors du clonage du repo. Si ce fichier est censé être partagé, Apple a fait un travail plutôt médiocre.
Herr Grumps
7
Lorsque nous archivons ce fichier, tous mes collègues obtiennent un IDESourceControlProjectIdentifier différent ... donc notre .xccheckout est modifié à chaque validation. -_-
Cœur
9
Indépendamment de ce à quoi Apple était destiné à l'origine, les .xccheckoutfichiers causent des problèmes insensés sur Xcode 6 beta, et j'ai décidé de les supprimer de VCS. Semblent être liés à un bogue de mise en cache, et je pense que Xcode peut les régénérer automatiquement à partir de VCS, à chaque fois.
eonil
63

Le *.xccheckoutfichier contient des métadonnées VCS et ne doit donc pas être archivé dans le VCS.

D'autre part: l'archivage de ce fichier ne créera probablement pas de difficultés de fusion ou d'autres problèmes.

Si vous souhaitez ignorer ce fichier (ce que je recommande), vous devez ajouter cette ligne à votre projet .gitignore:

*.xccheckout

La solution d' Abizern ne fonctionnera pas pour les projets à l'intérieur d'un espace de travail. Parce que, lorsque vous utilisez un espace de travail, le chemin vers le *.xccheckoutfichier sera: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. Et il en ignore plus que vous ne le souhaiteriez.

Edit: Ce fichier existe pour gérer les connaissances de Xcode sur les nombreux systèmes VCS de votre projet, voir la réponse de Chris Hanson . Pour plus de 99% des projets, le fichier .xccheckout est une configuration excessive.

Berik
la source
1
Ce serait formidable si vous pouviez développer cette affirmation «en fait, il en ignore plus que vous ne le souhaiteriez». Plus précisément, quelques exemples d'autres fichiers qui vont dans ce dossier qui devraient être archivés.
Mark Edington
Suivi: J'utilise un .gitignore d' Adam de cette question . Il est disponible en tant qu'essentiel et contient une description du contenu du dossier xcshareddata.
Mark Edington
@ Mark : Il ignore le project.xcworkspace/. Cela pourrait être un problème pour le moment, mais je ne compterais pas dessus pour les nouvelles versions de Xcode.
Berik
6
Cette réponse est incorrecte et le standard de GitHub .gitignorequ'il fournit aux développeurs ne doit pas spécifier*.xccheckout
Chris Hanson
2
Après avoir inclus ce fichier dans mes dépôts depuis son introduction, j'ai récemment commencé à le supprimer de tous mes dépôts. Cette chose crée des conflits de fusion tout le temps, principalement dans des projets qui incluent mes propres frameworks en tant que sous-modules. Et puis je ne gagne rien de ce fichier puisque j'utilise git pour la gestion des sous-modules. Bien essayé, Apple, merci, mais non merci.
Pascal
38

Ça dépend. Le fichier contient des références au référentiel distant que vous utilisez. Si vous utilisez un VCS centralisé tel que Perforce ou Subversion, le référentiel distant de tout le monde sera le même et vous pouvez et devez donc archiver le fichier.

Si vous utilisez un VCS distribué tel que Mercurial ou git, mais que vous l'utilisez comme s'il s'agissait d'un CVCS (en d'autres termes, tout le monde cloné à partir d'un référentiel partagé directement dans son espace de travail personnel sur sa machine), vous voudrez peut-être toujours le vérifier dans.

Cependant, si vous utilisez un DVCS avec tout le monde ayant son propre clone distant, par exemple en utilisant GitHub dans son modèle d'utilisation standard, vous NE souhaitez PAS archiver ce fichier. Si vous l'avez fait, vos Pull Requests vous demanderont les paramètres de votre référentiel pour être copié dans le fichier xccheckout de tout le monde, mais les paramètres de votre référentiel seront différents de ceux de tous les autres car vous utilisez tous des référentiels distants différents.

Bande de Tim
la source
1
Cette réponse me semble la meilleure. Les enregistrer provoquait des discussions inutiles sur les différences pour les commits de notre équipe. J'ajoute à .gitignore ce qui suit pour les empêcher d'entrer: * / .xcworkspace / xcshareddata / *. Xccheckout Je ne comprends toujours pas pourquoi Apple a choisi de stocker de manière redondante ces informations qui se trouvent de toute façon dans le dossier .git (ma seule supposition est de faire fonctionner les choses de manière cohérente dans le VCS)
Juan Carlos Méndez
20

Oui, le Project.xccheckoutfichier doit être validé dans votre référentiel. Xcode utilise ce fichier pour indiquer aux autres utilisateurs qui ouvrent l'espace de travail la liste complète des référentiels de contrôle de source utilisés par l'espace de travail et l' emplacement de la copie de travail par rapport à l'espace de travail, si ces référentiels sont Git, SVN ou les deux.

Lorsque vous ouvrez l'espace de travail, Xcode utilise le Project.xccheckoutfichier pour informer l'utilisateur qu'il existe d'autres référentiels faisant partie de l'espace de travail, et demande lesquels doivent être extraits. Lors de l'extraction de référentiels supplémentaires, Xcode place les copies de travail dans la même structure de dossiers relative à l'espace de travail que lors de la création du Project.xccheckoutfichier.

Comme Chris Hanson l'a dit, cela n'a probablement pas d'importance pour un espace de travail à référentiel unique et à un projet, mais pour des affaires plus complexes, ce sera très pratique.

Vous pouvez en savoir plus à ce sujet dans la vidéo de la session WWDC 2013 Présentation du contrôle de code source dans Xcode ; la partie concernée commence à environ 15 minutes.

Calrion
la source
Ce fichier n'est utile que si vous utilisez Xcode pour SCM, sinon vous n'avez pas du tout besoin de ce fichier. Et encore moins si vous travaillez avec git forks, dans ce cas, le chemin du repo sera unique par développeur
Carlos Ricardo
3

C'est ce que j'ai dans mon .gitignore pour Xcode.

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Il garde tout ce qui concerne l'état local de la façon dont les projets me recherchent hors du référentiel.

Le fichier xccheckout est sous ici, il n'est donc pas suivi sur mon système par défaut.

Xcode s'est amélioré et a séparé ce qui doit être partagé et ce qui doit être conservé localement. Par exemple; ces lignes ignoreront les schémas de construction par défaut, ce qui est très bien car vous pouvez marquer des schémas de construction spécifiques comme partagés, et ils sont placés dans un répertoire qui n'est pas ignoré.

Les points d'arrêt sont ignorés, mais vous pouvez marquer des points d'arrêt spécifiques comme partagés entre les projets et ils sont également placés dans un répertoire qui n'est pas ignoré.

Abizern
la source