Comment les conflits de fusion (fichier de projet.pbxproj) dans Xcode l'utilisation de svn?

Question

Il y a 2 membres de notre équipe. Nous utilisons Xcode SCM (utiliser SVN) pour manger nos fichiers de code source. Nous sommes tous d'ajouter des fichiers de notre projet Xcode. Il a commis de serveur svn. Quand je l'ai mise à jour, Xcode trouver, il y a des conflits dans le projet.pbxproj fichier.Puis-je choisir de quitter Xcode et manuel de fusionner les conflits. Puis je commence à modifier mon projet.pbxproj, de fusion et de nos changements. En fait je n'ai pas connaître comment Xcode gérer les fichiers, j'ai juste ajouter un peu de texte que de mon projet.pbxproj fichier n'a pas eu. Quand j'ai fini, mon projet ne peut pas ouvrir. Je suppose que parce que le projet.pbxproj fichier ne peut pas être modifier par le manuel.

Donc, je veux savoir, quand vous trouvez ce problème, le projet.pbxproj fichier des conflits, comment le résoudre?

Merci!!!!

Answer 1

J'utilise git, mais nous voyons la même question - si deux personnes ajouter des fichiers il y a un conflit de fusion.

Habituellement, le montage est très facile, cependant. Il suffit d'aller dans le projet.pbxproj fichier avec un éditeur de texte, et de chercher le conflit de fusion de la section - habituellement, cela est marqué par quelque chose comme :

>>>>>>>
Stuff 1
======
Stuff 2
<<<<<<<<

Dans 99% des Xcode projet de conflit de fusion des cas, vous voulez simplement accepter les deux côtés de la fusion (parce que deux personnes ont ajouté des fichiers différents) - de sorte que vous pouvez tout simplement supprimer la fusion des marqueurs, dans le cas ci-dessus qui finirait comme:

Stuff 1
Stuff 2

Comme je l'ai dit, cela fonctionne très bien dans la PLUPART des cas. Si Xcode ne vais pas lire le fichier de projet lorsque vous avez terminé, il suffit de prendre les plus récentes de l'onu-version fusionnée et ajouter manuellement vos fichiers à nouveau.

Answer 2

Malheureusement, il n'y a pas beaucoup que vous pouvez faire, sauf à faire les changements manuellement dans une check-out et check-dans la nouvelle "fusionné" du projet.

Answer 3

Je cherchais une solution simple à ce problème lorsque je suis tombé sur cette autre question/réponse:

http://stackoverflow.com/a/14180388/307217

J'ai été complètement époustouflé par la façon simple, cette solution est, j'ai essayé de fusionner en une disparates branche qui était près de 200 révisions derrière le tronc, XCode et Mercurial, n'ont pas été campeurs heureux à ce sujet. J'ai essayé manuellement la fusion de la pbxproj fichier (qui a fait plus de 100 conflits) 8 fois avant d'essayer cette solution.

Fondamentalement, la solution est en tant que tel (en supposant que vous utilisez Mercurial, parce que c'est génial):

1. Tentative de fusion dans mercurial:

   hg update FEATURE_BRANCH
   hg merge default
   *mercurial gives you a ton of crap about the pbxproj file having merge conflicts*
   

2. Ouvrez Xcode

3. À partir de la barre d'outils, sélectionnez Xcode->Ouvrir le Développeur de l'Outil->FileMerge
4. Sur la gauche, ouvrez votre en conflit projet.pbxproj fichier (celui avec le conflit de fusion de balisage en elle)
5. Sur le côté droit, ouvrez votre projet.pbxproj.orig'
6. Sélectionnez Fichier->Enregistrer Fusionner et enregistrer le projet.pbxproj' fichier

7. Puis de retour à la ligne de commande:

   hg resolve -m ProjectName.xcodeproj/project.pbxproj
   *merge any other broken files*
   hg commit -m "manually merged with trunk"
   

8. Manger Du Gâteau Parce Que Vous Êtes Fait

Answer 4

Parfois, un ou quelques fichiers peuvent être reproduites (par exemple ManagedObjects) dans les différentes branches , de sorte que lorsque vous aurez fusion il y a peut être deux déclarations pour un seul fichier dans un bloc. Dans ce cas, vous devez supprimer l'un des déclarations.

Answer 5

La meilleure chose à faire pourrait être de simplement accepter soit votre version ou de sa version dans son intégralité, sans essayer de combiner les deux. Aussi, examiner si le fichier en question est quelque chose qui devrait être dans le référentiel à tous; il peut être plus approprié de laisser chaque personne ont leur propre version de celui-ci.

Consultez la documentation sur la façon de résoudre les conflits.