CODEWITHSUNDEEP
iphonesvnxcodeconflict
vcLwei
vcLwei

Reputation: 1947

How to merge conflicts (file project.pbxproj) in Xcode use svn?

There are two members in our team. We use Xcode's SCM (use SVN) to manger our source code files.
We all add files to our Xcode project. He has committed to SVN server. When I update, Xcode find there has conflicts in project.pbxproj file. Then I select quit Xcode and manually merge the conflicts. Then I start to edit my project.pbxproj, merge our changes. Actually I don't know how Xcode manage files, I just add some text that my project.pbxproj file did't have. When I finish, my project can't open. I guess that because the project.pbxproj file can't be edit by manual.

So, I want to know, when you find this problem, the project.pbxproj file have conflicts, how to solve it?

Thank you!

Upvotes: 86

Views: 116768

Answers (13)

Kendall Helmstetter Gelner
Kendall Helmstetter Gelner

Reputation: 75057

I use git but we see the same issue - if two people add files there's a merge conflict.

Usually the editing is very easy though. Simply go into the project.pbxproj file with a text editor, and look for the merge conflict section - usually this is marked by something like :

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

In 99% of Xcode project merge conflict cases, you simply want to accept both sides of the merge (because two people added different files) - so you would simply delete the merge markers, in the above case that would end up like:

Stuff 1
Stuff 2

Like I said, this works great in MOST cases. If Xcode will not read the project file when you are done, just take the most recent un-merged version and manually add your files again.

FOLLOWUP 2023

This advice still mostly holds, but in recent times I've been working on a very large and old application with a complex Xcode project file and several team members often working on large additions.

Manually examining merge conflicts is still the primary approach. Multiple people adding new files is often still just as easy as using both sides of a merge conflict.

There is still also always the fallback of simply taking in a project file you are attempting to merge into your branch, and using a copy of the Xcode project with conflicts to manually add back in your changes.

There are a few cases in particular though that I have found can present challenges, on scenario which has an extremely non-obvious solution...

The first is that sometimes, multiple people working on a file with the same name may result in multiple entires of the file with different identifiers. For this issue, look for file IDs within the group the file will be contained in, and pick which file ID to preserve, and which to discard.

The second is that introducing new groups in similar locations in your project might result in a conflict splitting up a group. In these cases you may need to take the contents of one side of the merge totally out of the merge conflict region, and introduce it correctly alongside other groups in the project file.

The last is the non-obvious solution that prompted me to update this answer. That is that sometimes, you may get a conflict where entries for all of your CoreData versions would have totally different identifiers. This might happen for example if two teams had bumped up the model version at the same time.

In that case it would seem that you can take one side or the other, using only those identifiers. This sometimes works.

However in some cases if I did that, on loading the project I would see no model versions at all - Xcode deleted them all.

The solution was again, to leave in BOTH sides of the merge which meant two entries for core data models! What happens if you do this is Xcode on loading the project, will choose valid identifiers for all of the models and save one correct version instead of allowing both to live.

For a large team using CoreData with multiple ongoing version bumps at once, one technique we found helped smooth thing over was to have a separate branch with CoreData model changes over. That way all teams would be using the same CoreData version with the same current model identifier, and internal Xcode project IDs ASAP. This branch only held the CoreData models themselves, not any classes related to the models (though it could).

Upvotes: 161

jamal zare
jamal zare

Reputation: 1209

I know that 90 percent of conflicts are clear and you can accept both changes in conflicts so you do not need to be worry you will resolve it if you will be patient the way I found that use tools like xUnique that will help you a lot

Upvotes: 0

Guilherme Vallone
Guilherme Vallone

Reputation: 39

You can open it on VSCODE and fix the conflicting merge there. look for some colored annotations on the IDE or look for <<< >>> in the text search.

Upvotes: 2

Ali Ers&#246;z
Ali Ers&#246;z

Reputation: 16086

So far the best visual merge tool I have used for pbx files is Visual Studio Code's merge tool. I open the pbx file in Code app and fix conflicts then open XCode again.

Upvotes: 4

magentaqin
magentaqin

Reputation: 2149

I happened to encounter this tricky problem.

Instead of manually dealing with these conflicts, you can try this.
Suppose you are on feature branch.

  1. Git checkout master.
  2. Copy content in project.pbxproj
  3. Git checkout to your feature branch, and paste it.(Override the current content in project.pbxproj)

  4. Run

    react-native link

Upvotes: 1

Manuel
Manuel

Reputation: 15072

To manually solve the merge conflicts, check the UUID of each conflicting item.

Example:

<<<<<<< HEAD
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
=======
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };
>>>>>>> branch_to_merge

Check each UUID:

  • If it occurs in both versions, remove it in one version: ExistingFile.swift
  • If it does not occur on the comparing branch, keep it: NewFileA.swift and NewFileB.swift
  • If it is not referenced anywhere else in the file, i.e. you can only find one occurrence in the whole project.pbxproj file, I would assume it is an artefact and safe to delete it.

The result would be:

    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };

Note: I don't recommend adding *.pbxproj merge=union to the .gitattribues file to basically ignore merge conflicts because a conflicting merge should alway be checked manually unless there is a sophisticated script doing that for you.

Upvotes: 12

realbusyman
realbusyman

Reputation: 21

Sometimes one or few files could be recreated (for example ManagedObjects) in different branches, so when you'll merge there may be two declarations for one file in one block. In this case you should delete one of the declarations.

Upvotes: 2

tommys
tommys

Reputation: 865

As stated above the most common way of handling the conflicts is to

  1. accept "everything"
  2. re-import the files into the project

I Wrote a bash-script that takes care of (1) above.

Note that this will only solve the most common case of merge conflicts!

#!/bin/bash
#
#
#
if [ $# -eq 0 ]
 then
    echo "File must be provided as argument, darnit!"
    exit 1
fi

if [ $# -eq 2 ]
 then
    echo "only ONE File must be provided as argument, darnit!"
    exit 1
fi


echo "Will remove lines from file:" $1
grep -v "<<<<<" $1  | grep -v ">>>>>>" | grep -v "====" > out.tmp;mv out.tmp $1
echo "Done removing lines from file:" $1

Upvotes: 2

mmilleruva
mmilleruva

Reputation: 2178

This solution is only for git, but you can add a .gitattributes file to your project then within that file add the following line:

*.pbxproj merge=union

This will tell git to keep both sides of the merge which will be what you want the vast majority of the time.

Upvotes: 23

lighter
lighter

Reputation: 11

I founded a tool "xUnique" https://github.com/truebit/xUnique, it works!

Upvotes: 0

G. Shearer
G. Shearer

Reputation: 2185

I was looking for a straightforward solution to this problem when I came across this other question/answer:

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

I was completely blown away by how simple this solution is, I was trying to merge in a disparate feature branch which was almost 200 revisions behind the trunk, XCode and Mercurial were not being happy campers about it. I tried manually merging the pbxproj file (which had over 100 conflicts) 8 times before trying this solution.

Basically the solution is as such (assuming you use Mercurial, because it's awesome):

  1. Attempt your merge in mercurial:

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

  2. Open Xcode

  3. From the top toolbar, select Xcode->Open Developer Tool->FileMerge
  4. On the left, open your conflicted 'project.pbxproj' file (the one with merge conflict markup in it)
  5. On the right side, open your 'project.pbxproj.orig'
  6. Select File->Save Merge and save over the 'project.pbxproj' file

  7. Then back at the command line:

    hg resolve -m ProjectName.xcodeproj/project.pbxproj
*merge any other broken files*
hg commit -m "manually merged with trunk"
  8. Eat Cake Because You Are Done

Upvotes: 3

Michael Hackner
Michael Hackner

Reputation: 8645

The best thing to do might be to simply accept either your version or his version in its entirety, without trying to combine the two. Also, consider whether the file in question is something that should be in the repository at all; it may be more appropriate to let each person have their own version of it.

Check out the documentation on how to resolve conflicts.

Upvotes: -26

Barry Wark
Barry Wark

Reputation: 107764

Unfortunately, there's not much you can do except to make the changes manually in one check out and then check-in the newly "merged" project.

Upvotes: 32

Related Questions