More XCode fun

Perhaps those developer shops with > 1 programmer can benefit from our experience using XCode in a source controlled environment.
– When an XCode project is modified by someone else (i.e. file added, etc), you need to (1) quit XCode, (2) run your source control, (3) re-launch XCode. If you simply close the project but keep XCode running, the changes may not get picked up by XCode. It has a very good memory.
– Some project settings that you might not expect are saved *with* the project file. This includes breakpoints. If you’re making changes to a project, before checking it in make sure to clear *all* your breakpoints before checking-in, otherwise everyone will er… benefit from your settings (hint: this is not a good way to make friends).
You can clear breakpoints using the Debug > Breakpoints window. If you have some difficulties clearing a breakpoint by clicking on it, select the Debug > Remove Breakpoint command. However…
– Breakpoints are *per project*. So, if you (or someone else, see above) set a breakpoint, say, in a core library project, you will not be able to clear it while you are in the client project. How can you tell which project you’re in? When you bring the Breakpoints window up, the title bar of the window will start with the name of the project. Note that this is the case even if the project is closed. To clear a breakpoint set in another project, open that project, then with the project window frontmost, select Debug > Breakpoints. You can now remove those breakpoints (select them in the Group and Files column and press the Delete key).
– Finally, since breakpoints are saved with the project, once you’ve added or removed a breakpoint the project file is now dirty. When closing the project you will be asked if you want to save the changes. Say yes.

Comments are closed.