9

Unlike Eclipse or other IDEs, Xcode will modify the .xcodeproj file anytime it finds that a file or group in the project is added, renamed or removed. This is very inconvenient when there is more than one developer working on the project.

Once my SCM tools complain of conflicts on the .xcodeproj file, all I can do is check out another copy of the entire project and merge all changes I made into it and praying that no one is 'faster' than I.

Is there a workaround to change the default strategy of Xcode?

glenstorey
  • 5,134
  • 5
  • 39
  • 71
Evan Wu
  • 236
  • 2
  • 5

7 Answers7

2

Unlike Eclipse or other IDEs, Xcode will modify the .xcodeproj file anytime it finds that a file or group in the project is added, renamed or removed.

Unlike Eclipse and some other IDEs, Xcode maintains the list of what files are in the project and the group structure as part of the project "file" (the .xcodeproj file is really a directory). The groups don't have to physically exist as directories and the files can actually be in all sorts of places and don't have to be named as they appear in Xcode.

If somebody adds a new file to a project, or removes a file from the project, or changes the name of a file or group, this needs to be reflected in your SCM because somebody else checking out a working copy or cloning the your repository or whatever tends to like it better if the project is in sync with what's on the disk. So for example, if somebody removes a file but that change is not reflected in the Xcode project file of others, they will get compilation errors after they update/sync/pull or whatever.

Having said that, the project file also contains a load of user settings that are not important. In Xcode 4.x I set the following directories to be ignored by my SCM:

foo.xcodeproj/project.xcworkspace/xcuserdata
foo.xcodeproj/xcuserdata

In earlier version project files I used to set the following to be ignored:

foo.xcodeproj/*.pbxuser
foo.xcodeproj/*.mode1v3

That seems to filter out unnecessary nonsense as far as SCM is concerned.

JeremyP
  • 84,577
  • 15
  • 123
  • 161
1

From what I understand, the .xcodeproj is actually a wrapper for several files, including the .pbxuser and .pbxproj. Don't know what SCM you are using, but this topic was touched on here for those using git, and the consensus seems to be that the .pbxuser file as well as many others shouldn't be included under version control.

Community
  • 1
  • 1
tronbabylove
  • 1,102
  • 8
  • 12
0

That's not your only recourse. .xcodeproj files are text. The format is not too difficult to understand. The usual way to resolve a conflict is to take both sets of additions (although there are, of course, exceptions).

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
0
  1. Quit xcode
  2. Open a terminal.
  3. Navigate to /.xcodeproj/project.xcworkspace
  4. type: mv contents.xcworkspacedata contents.xcworkspacedata.bak
  5. restart xcode
foo
  • 1
0

What we do in teams to avoid conflicts on this file, is to commit all the files except the project file. In this case everything remains safe. You can avoid updating if you want only your own project file, or even include it in .gitignore file so that it's ignored automatically. 

#########################
# .gitignore file for Xcode4 / OS X Source projects
#
# Version 2.0
# For latest version, see: http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects
#
# 2013 updates:
# - fixed the broken "save personal Schemes"
#
# NB: if you are storing "built" products, this WILL NOT WORK,
# and you should use a different .gitignore (or none at all)
# This file is for SOURCE projects, where there are many extra
# files that we want to exclude
#
#########################

#####
# OS X temporary files that should never be committed

.DS_Store
*.swp
*.lock
profile


####
# Xcode temporary files that should never be committed
#
# NB: NIB/XIB files still exist even on Storyboard projects, so we want this...

*~.nib


####
# Xcode build files -
#
# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "DerivedData"

DerivedData/

# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "build"

build/


#####
# Xcode private settings (window sizes, bookmarks, breakpoints, custom executables, smart groups)
#
# This is complicated:
#
# SOMETIMES you need to put this file in version control.
# Apple designed it poorly - if you use "custom executables", they are
# saved in this file.
# 99% of projects do NOT use those, so they do NOT want to version control this file.
# ..but if you're in the 1%, comment out the line "*.pbxuser"

*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
# NB: also, whitelist the default ones, some projects need to use these
!default.pbxuser
!default.mode1v3
!default.mode2v3
!default.perspectivev3


####
# Xcode 4 - semi-personal settings
#
#
# OPTION 1: ---------------------------------
# throw away ALL personal settings (including custom schemes!
# - unless they are "shared")
#
# NB: this is exclusive with OPTION 2 below
xcuserdata

# OPTION 2: ---------------------------------
# get rid of ALL personal settings, but KEEP SOME OF THEM
# - NB: you must manually uncomment the bits you want to keep
#
# NB: this is exclusive with OPTION 1 above
#
#xcuserdata/**/*

# (requires option 2 above): Personal Schemes
#
#!xcuserdata/**/xcschemes/*

####
# XCode 4 workspaces - more detailed
#
# Workspaces are important! They are a core feature of Xcode - don't exclude them :)
#
# Workspace layout is quite spammy. For reference:
#
# /(root)/
# /(project-name).xcodeproj/
# project.pbxproj
# /project.xcworkspace/
# contents.xcworkspacedata
# /xcuserdata/
# /(your name)/xcuserdatad/
# UserInterfaceState.xcuserstate
# /xcsshareddata/
# /xcschemes/
# (shared scheme name).xcscheme
# /xcuserdata/
# /(your name)/xcuserdatad/
# (private scheme).xcscheme
# xcschememanagement.plist
#
#

####
# Xcode 4 - Deprecated classes
#
# Allegedly, if you manually "deprecate" your classes, they get moved here.
#
# We're using source-control, so this is a "feature" that we do not want!

*.moved-aside


####
# UNKNOWN: recommended by others, but I can't discover what these files are
#
# ...none. Everything is now explained.
Neeku
  • 3,646
  • 8
  • 33
  • 43
0

As a tactics to avoid merge conflicts: You will get conflicts which require a painful manual merge if two users change the file in the same location. That happens for example if two users add a file at the end of a group, because both changes are in the same place. If everyone adds new files in a different place (for example in alphabetical order) then there will be no merge conflicts. Or at least fewer.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
0

Use swift packages. Changes in the swift package won't change the project file

Khaled Annajar
  • 241
  • 3
  • 5