*.Xccheckout fichiers Xcode5 ne doivent être ignorés dans VCS ?

Question

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

Ce fichier est situé dans le ".xcodeproj/projet.xcworkspace/xcshareddata/" répertoire, et il semble que c'est lié au projet de système de contrôle de version.

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

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

Donc voici les questions:

1. Devrait "xccheckout" être ignoré?
2. Quel est son but?

Answer 1

Vous devriez vérifier dans un Xcode 5 .xccheckout le dossier; en général, les dossiers, en xcshareddata devrait être engagée.

Un .xccheckout le fichier contient des métadonnées sur les référentiels sont utilisés dans un espace de travail. Pour un projet unique dans un référentiel unique qui n'a pas beaucoup de différence. Mais si vous utilisez un espace de travail qui a plusieurs projets de différents dépôts, la présence d'un .xccheckout le fichier dans l'espace de travail permet d'Xcode pour savoir ce que tous les composants qui constituent un espace de travail et où les trouver.

Answer 2

L' *.xccheckout le fichier contient des VCS métadonnées, et ne devrait donc pas être vérifié dans le VCS.

D'autre part: la vérification dans ce fichier ne sera probablement pas créer de difficultés de fusion ou d'autres problèmes.

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

*.xccheckout

Abizern's solution ne fonctionne pas pour les projets à l'intérieur d'un espace de travail. Parce que, lorsque vous utilisez un espace de travail, le chemin d'accès à l' *.xccheckout fichier: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. Et en fait elle ignore plus que vous souhaitez.

Edit: Ce fichier existe pour la gestion de Xcode de la connaissance, éventuellement, de nombreux VCS systèmes de votre projet, voir Chris Hanson réponse. Pour > 99% de la projets les .xccheckout fichier de configuration surpuissante.

Answer 3

Il dépend. Le fichier contient des références sur le dépôt distant que vous utilisez. Si vous utilisez une centralisation de la VCS comme Perforce ou de Subversion, tout le monde à distance de référentiel sont les mêmes, de sorte que vous pouvez et devriez vérifier le fichier.

Si vous utilisez un VCS distribués comme Mercurial ou git, mais de l'utiliser comme s'il s'agissait d'un CVC (en d'autres termes, tout le monde clonés à partir d'un référentiel partagé directement à leur espace de travail personnel sur leur machine), alors vous pourriez encore envie de le vérifier.

Toutefois, si vous utilisez un DVCS avec tout le monde d'avoir leur propre distance clone, par exemple à l'aide de GitHub dans ce standard du mode d'utilisation, vous NE voulez PAS vérifier ce fichier. Si vous n'avez alors votre Pull Demandes de demander votre référentiel paramètres sont copiés dans tous les autres xccheckout fichier, mais votre référentiel paramètres seront différents de ceux de tous les autres parce que vous êtes tous à l'aide de différents dépôts distants.

Answer 4

Oui, l' Project.xccheckout le fichier doit être commis à votre référentiel. Xcode utilise ce fichier pour dire aux autres qui ouvrent l'espace de travail de l'ensemble de la liste de référentiels de contrôle de source utilisé par l'espace de travail et l' emplacement de la copie de travail par rapport à l'espace de travail, que ces dépôts Git, SVN, ou les deux.

Lorsque vous ouvrez l'espace de travail, Xcode utilise l' Project.xccheckout le fichier pour avertir l'utilisateur qu'il existe d'autres référentiels faisant partie de l'espace de travail, et de la demande qui doit être vérifié. Lors de la vérification des dépôts supplémentaires, Xcode endroits les copies de travail dans le même espace de travail relatifs à la structure de dossier comme ils l'étaient lors de l' Project.xccheckout fichier qui a été généré.

Comme Chris Hanson dit, il n'a probablement pas d'importance pour un seul référentiel, d'un espace de travail de projet, mais pour les plus complexes des affaires, il va être très pratique en effet.

Vous pouvez en savoir plus à ce sujet dans la WWDC 2013 session vidéo Compréhension de Contrôle de Source dans Xcode; la partie pertinente commence à environ 15 minutes.

Answer 5

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

#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/

Il garde tout ce qui se rapporte à l'état local de la façon dont les projets regarde pour me sortir du dépôt.

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

Xcode a obtenu mieux et de séparer ce qui doit être partagé et ce qui doit être gardé à l'échelle locale. Par exemple, ces lignes à ignorer le défaut de construire des schémas, ce qui est bien parce que vous pouvez la marque spécifique de construire des systèmes 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 spécifique des points d'arrêt comme étant partagés entre les projets et ils sont aussi placés dans un répertoire qui n'est pas ignoré.