I am developing a project with Xcode 4.1 using Subversion through Xcode's built-in source control menu and command line. When reverting/updating the source through command line, I can't get the Xcode editor to show the current version of the source files (as they appear in the Finder or any external editor). I guess this is generally the case when editing a source file with an external editor.
Eclipse would immediately warn you that the editor content is outdated (Xcode does it when you try to save the file). Then you would simply right click on the project tree to refresh the corresponding files/directories. There must be a similar feature in Xcode.
svn revert MyFile.m
will copy the old back and therefore also the old timestamp, making XCode think it is using the most recent version of the file (which is true, except that in this particular situation you would want it to use the older version again).
As a workaround you can "touch" all the reverted files, giving them a new timestamp.
touch MyFile.m
That will make XCode display the content as it is in the file and also include it in the next build iteration. This works for .h/.m files but also any project or meta data files used by XCode.
Do you mean Menue:File >> Source Control >> Refresh Status ?
Related
I have an iPhone application that is compiled under Xcode. I have a file which I shall call 'manual.pdf'. The app has a manual page that shows manual.pdf using WKWebView. The 'manual.pdf' file is generated from OfficeLibre.
When the UI has changed, I go through the original 'manual.odt' replacing the screen shots with new ones, and correcting the text. I then export a new 'manual.pdf'. I then have to...
delete the old 'manual.pdf' entry.
drag the new file to the Resources directory.
fill in the form to get it added.
I don't need a build-time copy script. Those look complicated, and this is not particularly labour intensive, and I don't necessarily want to do it every time the manual changes. But this feels wrong. I would be happy if Xcode just substituted the new file for the old file if it had the same name. But it doesn't.
I am running Xcode 14.1 building for an iPhone 12 running iOS 16.0 FWIW.
I found the answer. I had just edited the file, and I went to Xcode to update the reference. The new version was already there. I guess when I dragged the file, it created a link rather than copying the file.
Nice, once you know it is there.
PS:
I have made another discovery. Xcode used the latest 'manual.pdf' when building the application, but it did not save it when I committed the changes. I had to separately update the PDF file in the git archive to get it to update. However, the builds released to the TestFlight site all had the right PDF.
My minimal solution is to copy the file to the archive...
cp ~/Documents/manual.pdf ~/XcodeProjects/MyApp/MyApp/Resources/
This then gets committed with the next Xcode commit.
I have checked out a copy of a SVN project, I have modified some files and want to commit the changes. If I go to File > Source Control > Commit. I see an empty list and a button saying "Commit X files". I expected a list of the modified files.
Now, I use the command line tool (svn ...). But I want to bring back the Xcode commit window.
How may I fix it?
BTW. I'm using Xcode 4.6.1
That is a very very strange screen shot. Sometimes Xcode's svn integration can be a bit strange. If I were you I would just cancel out of the strange empty dialog and use svn at the command-line in Terminal instead.
In file > preferences there is a source control section. You probably have the check box checked to update the source control automatically. So, because it is already updating the source control, it doesn't let you do it.
So you can uncheck that box to make it not automatic, then change something in your project and try to commit the changes. You will probably see some files now.
I could select individual file when 'update' in SVN project in Xcode 4.3.
I could review which files were changed and committed.
But after I upgraded Xcode to 4.4, when I click 'File > Source Control > Update' from menu bar or click 'Update' in Organizer, no updated files list comes out and just tiny updating slide comes down.
It updates whole changed files without my selection.
I know I can update specific file by right clicking it and select 'Source Control > Update Selected Files' but I want to review the whole changed files in one window like before Xcode 4.4.
How can I do it?
Thank you.
It looks like you want to do "Update..." instead of "Update".
You can get that to show up under File-->Source Control and holding down the control key.
It looks like in XCode 4.4. the default source control options have been switched around as follows:
Xcode 4.4+ - default = "Update"
"Update" (Cmd+Opt+X) - Silently updates all files unless there is a merge conflict that needs to be manually corrected
"Update..." (Ctrl+Cmd+Opt+X) - Updates all files allowing you to verify/merge updated files
Xcode 4.3 - default = "Update..."
"Update..." (Ctrl+Cmd+Opt+X) - Updates all files allowing you to verify/merge updated files
"Update All" (Cmd+Opt+X) - Silently updates all files unless there is a merge conflict that needs to be manually corrected
This is again broken in XCode 4.5. Silently will update all files, ignoring your selected files. It doesn't matter if you control-click or right-click or File->Source Control... whatever the way you select it, xcode will update the whole project.
Bad, bad Apple!
I've been trying in vain for hours now to add a CoreData Data Model file to my XCode project, which is under SVN source control. Whenever I do, I get the following display in XCode:
I've followed at least 5 or 6 different articles now on ways to make subversion play nicely with xcdatamodeld files/folders in XCode 4 without much success. I'm about to just give up and leave my data model file outside of source control, but I can't even get subversion/xcode to ignore it. Winning is not an option.
Things I've tried so far:
command line add/commit of the Data.xcdatamodeld - this causes XCode 4.2
to go into a tiz and crash repeatedly
ignoring the file in XCode Organizer - this causes XCode to report build warnings about a missing Data.xcdatamodeld file, which isn't there in xcode, on the file system or SVN
I've followed the suggestion here: http://www.tmro.net/2010/10/subversion-and-core-data-versioning/ only to have XCode then start crashing during any SVN operation at all (I had to delete my local version completely and reload from the repository)
I can replicate this in a controlled environment outside of my project
Has anyone seen this before and resolved this issue in XCode?
I can't be the first person to try to add a CoreData Data Model file to an SVN controlled project!
Thanks
I saw this also for an otf font bundle.
My datamodel file was stored oddly. In my project directory I had:
./Model.xcdatamodeld/Model.xcdatamodeld/contents
i.e. doubled-up directories
I did a commandline svn on the inner folder only, i.e.
cd ./Model.xcdatamodeld; svn ci Model.xcdatamodeld
It added the inner directory and the contents file, the ? disappeared in XCode and it committed fine. Don't see how the nested directories could be a problem, but this worked for me.
I have no idea what these little A and ? mark mean, I do know that the ones with the ? are not in the budle, however they are in the xcode list, they are editable, they are not read only, i see them as marked to be copied into the bundle (as it is phonegap and the whole www dir should be copied)... but somehow it's not going.... what do these little icons mean? A (archive??!?!) ? = (no reference or something...?)
Those are for source control. If you've created a new project in Xcode 4 and not unticked the relevant box, you have a GIT repository automatically.
'A' means that the file is to be added to the repository when next you commit. '?' means that you've added the file to your project but you haven't yet told Xcode what you want to do with respect to source control. You can set what you want to do by right clicking the files or by selecting them and going to File -> Source Control.
In any case, they're completely unrelated to how the project is built.