iPhone Developer Tips Visitor Stats:
122,631 Pageviews and 90,229 visitors in the past 30 days.
|
If you don’t take the necessary steps to prepare for subversion, you will run into problems using it in XCode. This is because XCode produces files that “confuse” Subversion because it either thinks they are text files when they are really binary files or the reverse. To overcome these limitations, you need to make some simple changes to the subversion configuration file in your user home directory. Here are some steps you can follow to ensure that you will be able to use Subversion within XCode without any issues.
Step 1. Open the subversion configuration file
NOTE: If the “.subversion” directory doesn’t exist yet then run this command which fails but will create the necessary files to get you started:
Step 2. Enable “global-ignores” and add new things to ignore
Find the line that contains the text “global-ignores” and append the following text:
build *~.nib *.so *.pbxuser *.mode* *.perspective*
Step 3. Enable “auto-properties”
Located and uncomment (e.g. remove the leading “#” character) the line that looks like this:
# enable-auto-props = yes
Step 4. Add additional properties
Then go to the end of the file, in the [auto-props] section, and append these lines:
*.mode* = svn:mime-type=text/X-xcode
*.pbxuser = svn:mime-type=text/X-xcode
*.perspective* = svn:mime-type=text/X-xcode
*.pbxproj = svn:mime-type=text/X-xcode
Comments
8 Responses to “How to “fix” Subversion in XCode 3”
Leave Comment
Surely ignoring nibs is a bad idea? Many applications have vital parts contained in nibs that won’t work if their nibs aren’t included with the source checkout…
@Jasarien The pattern is not for all NIB files … its for “*~.nib” files (note the ‘~’). I don’t know what creates this file but it is garbage and I found that leaving them in caused issues with teams trying to work on the same project.
After making these changes, how do I force svn to reload the file?
Thanks!
Two things raised a red flag for me:
(1) In step 4, why bother to set the mime type for the first 3 types, since they’re already ignored by SVN?
(2) Where did you get the MIME type text/X-xcode from? I can’t find it documented anywhere, and I doubt that either svnserve or Apache will do anything intelligent with it. I use text/plain for *.pbxproj files.
@mz — Since svn only applies auto-props when you `svn add` or `svn import`, changes won’t be applied after the fact. You don’t have to “force” it to reload, either; the next svn operation will consult the changed file without any effort on your part.
If you want to apply properties to files already in a repository, check out svn_apply_autoprops.py — just run it in a working copy and everything down the hierarchy will be affected. You can modify/revert files as desired before committing.
I’m late to this conversation, but it seems a strange idea to me to ignore the build directory. Rather, point your project to place its build files outside your SVN checkout. In other words, this is a build problem not a Subversion problem and I believe it would be better to solve the correct root issue.
Also, according to Apple docs re: .pbxuser files
“You should include your user file in your commits and updates if you want to safeguard your personal settings for the project in the repository or if you work on the project on more than one computer and want to use the same settings on all of them.”
Wholesale ignoring of these files could have side effects for some, depending on their development workflow.
@Christopher
The issue of where to place build directories is interesting, but specifying someplace else can have its own dangers. On another system or for another user, writing to an arbitrary path outside the project directory or the working copy can have unintentional effects, including permissions issues, overwritten files, or just not knowing where to find built products. Whether I’m working with Xcode, Ant, or another language/build system, I always opt to svn:ignore the build directory. Most developers expect this approach.
Re: .pbxuser files… You can go either way, but even if I’m the only one using a repository, it still exclude them. I found that the per-user Xcode files changed frequently enough that unless one is careful, a commit can easily include changes unrelated to the code modification, and tend to gunk up the history when examining logs and diffs. (Even an Xcode-file-only commit is unrelated to the project at hand and tends to be a distraction more than anything.) YMMV, but I tend to use Transmit and the Synchronize feature if I really need to keep per-user Xcode files synchronized. Most of the time, I don’t bother — the “if” in Apple’s guidance is a big one, and most of the time I don’t care to preserve my personal settings (which includes position and size of every open window), particularly when going between a 15″ laptop and a 24″ cinema display. :-)
The nice thing is that even if you set svn:ignore for a resource, you can still `svn add` the ignored resource to your repository. Subversion just avoids bothering the user about such files, so it becomes opt-in. It may be tempting to say this isn’t a Subversion problem, but regardless of the version control system one uses, there are perennial issues like this, and IMHO, any SCM tool worth its salt should have some mechanism for dealing with it.
I’ve tried following these instructions and even some different variations, and I keep getting a ‘Option expected’
any thoughts?