I use svnX.
When importing project, I check "no ignore" option. (for importing libOAuth.a, ...)
But one file is causing a small problem.
UserInterfaceState.xcuserstate
What is this file?
Can I ignore this file? Is it important? Should I commit this file?
What is this file?
You can open it in property list editor and have a look -- It stores things like your workspace/project document layouts, nothing you would lose sleep over if lost.
Can I ignore this file?
You would ignore it in all but exceptional cases. It's easily reconstructed, and should be considered local to your system's user account. To stretch imagination or reason to track it: If you worked by yourself and mirrored your user accounts, then you might want this information synchronized among your machines. Sure, you could track it, but it would produce a lot of unnecessary revision control noise.
I recommend ignoring files that match these patterns:
*.xcuserstate
project.xcworkspace/
xcuserdata/
Basically, the only thing under MyProject.xcodeproj that you want checked in is project.pbxproj.
As of Xcode 7.3.1, UserInterfaceState.xcuserstate's are binary-formatted plist files that can exist in either of project files or workspace files. They are user-specific and many can be present in a given Xcode project or workspace.
Among other things they contain the current target your project is set to, the currently open file, and cursor position. These files can be saved to disk frequently if Xcode has the associated project open.
To convert the contents of the binary plist files to a more human-readable XML format you can use this plutil command in the terminal:
plutil -convert xml1 UserInterfaceState.xcuserstate
These files can safely be ignored in most cases.
Related
OK, here's my issue :
I'm using Xcode 4.6 under Lion
In my current project I've added several "real" folders (either with sources or with resources) which Xcode represents as "Groups"
However, whenever I add another file in one of my already-imported folders, the file doesn't show up (but instead I have to manually drag each new file to its appropriate location).
Well, given that my project is comprised of hundreds of different files, and that files are being added constantly, this seems like an overkill.
I realize this may have to do with Xcode's Group-centric approach, but it still bothers me.
So, is there any workaround? Any ideas?
As for many IDE, it won't scan changes of new files in included folder, to prevent accidental add of extra codes that will break the compile process. If you really want to do so, write a script to add all files in the folder and run it at pre-compile stage, i.e. in Xcode, "External Target"
See: https://stackoverflow.com/a/976459/188331
I code on 2 different computers with different username. Xcode makes a .pbxuser file for each one, making necesary replicate the config from each one.
This is error prone, and the files are not diff-friendly so everything must be carefully checked. Any way to avoid this?
The info in the .pbxuser file is not particularly important - it's just personal settings like window locations, breakpoints, etc. All the important stuff is in project.pbxproj and this is the only file you need to sync/back up/check into source control/etc. You can ignore or even delete the other files in the .xcodeproj directory - they will get re-created with default settings.
the .pbxuser file does contain custom executables in there. So if you use a custom executable as a unit test runner, (or some other executable) you might have to share that file
When I have Xcode projects I might have to work on on multiple computers, I just have my project live on Dropbox. Then it's in the same folder on any computer I might use to work on it, and the changes get synced every time files are modified. That way I'm literally working on the exact same project on each computer.
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.
I was looking at an open source Mac application, and they gave some suggested values for .gitignore. They were what I would expect...
However, they also suggested an entry into a .gitattributes file:
*.pbxproj -crlf -diff -merge
I'm not the most knowledgable in terms of git, so I was wondering - what exactly are the benefits of adding this line? What does do in particular? I've only seen this suggested in this one project, and if it was normal practice I would have expected to see it elsewhere right now. So I was curious about how it applies to the pbxproj file specifically.
The pbxproj file isn't really human mergable. While it is plain ASCII text, it's a form of JSON. Essentially you want to treat it as a binary file.
Here's what the individual flags do:
-crlf: don't use crlf <=> cr conversion
-diff: do not diff the file
-merge: do not attempt to merge the file
From the Pro Git book by Scott Chacon
Some files look like text files but
for all intents and purposes are to be
treated as binary data. For instance,
Xcode projects on the Mac contain a
file that ends in .pbxproj, which is
basically a JSON (plain text
javascript data format) dataset
written out to disk by the IDE that
records your build settings and so on.
Although it’s technically a text file,
because it’s all ASCII, you don’t want
to treat it as such because it’s
really a lightweight database — you
can’t merge the contents if two people
changed it, and diffs generally aren’t
helpful. The file is meant to be
consumed by a machine. In essence, you
want to treat it like a binary file.
A diff is oftentimes useful at commit time to check what has been changed. So I find it useful to keep the diffing ability but just prevent merging. So I use this in my .gitattributes file:
*.pbxproj -crlf -merge
On another note, has anybody tried using merge=union for pbxproj files? See: Should I merge .pbxproj files with git using merge=union?
I faced the problem of corruption *.pbxproj file after resolving merge conflicts manually. Or, more often, my files just 'disappeared' from the working tree after the merge. It drove me mad because we work in a team, so you can imagine how messy it can become very fast.
So, I have tested merge=union and it works well so far. I know that it can't help if files were deleted or renamed at the same time, but for adding new files it works as expected: there is no conflicts and files don't disappear after the merge. And it also saves quite a bit of time.
If you want to try it out, here is what I did.
1) Create a global .gitattributes file. Run in terminal:
touch ~/.gitattributes
git config --global core.attributesfile ~/.gitattributes
2) This command should open it in a text editor:
open ~/.gitattributes
3) When the file opens, add this line and save the file:
*.pbxproj binary merge=union
Done. Hope this will help new readers like it helped me.
I wrote a python script named xUnique to solve this merge conflicts problem.
This script do following things:
replace all 24 chars UUID to project-wide unique 32 chars MD5 digests, and remove any unused UUIDs(usually caused by careless merge before). This would prevent duplicate UUIDs because different machines/Xcode generate different UUIDs in this file. Xcode does recognize it and the project could be opened. During this process, remove all invalid lines in project file
sort the project file. I wrote a python version of sort-Xcode-project-file from Webkit team with more new features:
support to sort PBXFileReference and PBXBuildFile sections
remove duplicated files/refs
avoid creating new file even if no changes made, this makes less commits after using this script
More details and updates of xUnique, please refer to README
my app actually goes to different folders and takes each file into account and reads each file and does a lot of processing on them and marks the folder it has processed as done. but this is not happening as the system is immediately generating files like .DS_store and .localized and .trash. so is there any mechanism to skip processing hidden files or stop the os from generating these files programatically?
Thanks
Couldn't you change your app to just ignore files that start with "."? You've tagged this Cocoa, so using something like NSFileManager's contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error: seems appropriate. One of the options you can specify is NSDirectoryEnumerationSkipsHiddenFiles, which will skip hidden files.
Check the documentation for more details.
I'm not aware of any option that disables the generation of .DS_Store files locally. There is an option for remote, here.
Another way to do it could be to create a unix user for just that job and let him own the dirs, so that the Finder never can go there. Either start the job manually using sudo, or make it a setuid job.. or use launchd.