Re: project.pbxproj and Subversion
Re: project.pbxproj and Subversion
- Subject: Re: project.pbxproj and Subversion
- From: Chris Espinosa <email@hidden>
- Date: Thu, 25 Oct 2007 15:43:58 -0700
On Oct 25, 2007, at 3:18 PM, Fritz Anderson wrote:
I am confused. What are people's experiences with keeping .xcodeproj
files in Subversion?
As I see it, there are two ways Subversion can treat the
project.pbxproj file inside an .xcodeproj:
- It can treat it as text. The file is in fact text (old-style
plist). But when conflicting text files are updated from the
repository, Subversion tries to resolve conflicts if it can by
diffing the two with the last-checked-out version, and merging the
results. This is a dynamite strategy for source code. But can it
result in a corrupted project file?
It it's text, and a three-way merge doesn't succeed, you're left
with auxiliary files showing the three versions, and project.pbxproj
gets marked up with conflict markers. The project file is definitely
unusable, and there's no sure or convenient way to edit it back into
shape.
So treat-as-text is bad, right? What about treat-as-binary?
- Treat project.pbxproj as binary. If you check out revision 10,
make changes to it (add a file to the project), and someone else
commits revision 11 (adding a different file to the project), you
get a conflict upon check-in, and must update In a binary, all
Subversion can do for you is to insert project.pbxproj.r10 and
project.pbxproj.r11 into the .xcodeproj package. None of the
alternatives are correct, and you have to break into the package to
get at them. Subversion more or less refuses to proceed unless the
conflict is resolved.
In general, you should not treat the project.pbxproj file as binary.
There is a lot of value in treating it as text, and most merges and
updates are successful. You lose a lot of transparency if you treat
it as binary.
Surely I am not the first person to notice all this; other people
must have different developers making simultaneous changes to
project files. Maybe I am missing something:
No. Back in Xcode 2.1 we did a substantial amount of work to
restructure the text layout of project.pbxproj files to be more
friendly to line-based diff/merge algorithms. For example, build
settings are broken onto separate lines, so that two different users
each changing one build setting in a target results in a successful
merge, rather than a conflict.
Under Subversion, in your own work, how do you treat project.pbxproj?
If you look in the .xcodeproj package, do you see the detritus of
failed merges?
Have you noticed conflicts? Inconsistent project files among
developers?
The primary conflict is when two developers each add a new source file
to a target. Since Xcode adds new files to the end of the list of
target files, both occupy the same line in the project file with
different information, and require a manual merge. Other than that,
most localized project changes are nicely mergable.
If so, what have you done about them?
Conflict markers are easy to find, and most of the time the action
needed to reconcile the conflict is obvious. Xcode notes with
comments what each functional part of the project file contains, so
it's relatively easy to see whether you're merging target contents,
build settings, etc.
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden