I want to upload my xcode project to git, but only needed files. I see different files that i'm sure are created during build, but about others i'm not. I'm talking about *pbx* and *.oa files.
I'm using git. And want to configure an "exclude" file with patterns of files to be ignored. Is it safe to add the following patterns: *pbx* and *.oa?
Maybe someone can share an exclude file..
When using Git, I use the following .gitignore file:
.DS_Store
build/
*.xcodeproj/*
!*.xcodeproj/project.pbxproj
That's for Xcode 3.x. There may be additional files generated by Xcode 4 that should be ignored (maybe someone else will kindly provide that information).
No it is not safe for pbx because project.pbxproject is very important (and a real pain with version control). I am unsure about *.oa but here is a list of items I currently exclude in svn.
*.pbxuser,
*.mode*,
build,
.DS_Store,
*.perspectivev*,
*.xcworkspace,
xcuserdata
Related
So I have a .gitignore created, which I have basic files included in there, but when it comes to a Swift and .xcodeproj project..
Which one of these files are the only ones that I need inside Github?
Actually, you need both .pbxproj and .xcworkspace, however, it depends:
.pbxproj file contains metadata, file references, configuration... which use to execute/build the project.
.xcworkspace contains and manages subprojects. A common scenario is using cocoapods. If you're developing a small project that's don't need to depend on any 3rd parties, you don't have to create xcworkspace.
xcuserdata folder is safe to ignore. It contains some temporary info like user state, files opened, folders opened.
I'm in the process of converting a handful of projects from ripple to Paket. The way I do this is install Paket, then take my ripple.config and copy my sources and nugets over to my paket.dependencies, taking care to == the versions that I have fixed. Then I .paket/paket install over and over and over again trying to resolve versioning errors that come up from that.
After that, I open all my .csproj files and add an extra ..\ to all the HintPaths before opening my project and manually resolving whatever errors pop up.
Is there a better way to do this? I know there's a ripple-to-paket converter but I not only couldn't get it to work, but many people I work with say that it's terrible.
Thank you.
1 add a paket.references file in each project's folder
In each of your project files' folder, you should create a paket.references and list there the package name (only, the other info is kept consistent in your paket.dependencies in your root folder).
2 make sure the actual reference are handled with paket
you can manually remove the reference in the project files (either from VS or edit the project file), and call paket install which will add them (according to paket.references in the project's folder) with an additional <Paket>True</Paket> node (making it clear that this reference is handled by paket itself)
I think this is it.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.
I'm working with an open source library that's made available as a git repository (XML-RPC) and I'd like to use it in an iPad application. As I understand it, iOS applications should use static libraries for their linking.
Since this comes as a dynamic library, how can I convert it to something I can link with my app and use?
Maybe naive answer but why not just add all the relevent files in the repository to your app and just build it?
Put the files in a seperate folder obviously so you can update them to a newer version if you need to etc. Lots of projects I've done have an 'external' folder that just contains codethat I use from 3rd party sources. I've usually got the source so just compile it into my app and don't bother with making it a library.
Or are there tricky conditions that need to be met to compile this code?
I ended up doing this in several steps:
First, I opened the library project in Xcode and created a new target for the static library. I then made a directory in the project folder called "XMLRPC" and moved all the header files to it. I deleted the now-red invalid references to the header files, and re-added them (but kept the box for copying them to the current folder unchecked).
I added this Xcode project to my main project with a relative reference. I opened my main app's target and added the library project as a direct dependency, and checked the "Always search user paths" option on my main app's target settings.
Lastly, I modified the general Xcode preferences to use a shared build directory. I haven't tried it without that since it was something I wanted anyways; it might not be necessary.
My revision control has two folders in it: one's my project, and the other's the library. The library is still under git control within mercurial; I'm hoping this doesn't cause any issues.
I believe svn externals is what I want to use but would like some clarification on setting it up. I've never done so.
My environment is:
Mac 10.6.2
Xcode
Cornerstone
Subversion 10.6 (file based/single developer)
Single repository
My svn folder structure is:
\projects\projectA
\projects\projectB
\projects\projectC
\projects\projectX (.lib file)
\projects\projectY (images)
All projects have trunk, tags, and branches folders (just as Subversion suggest). Projects X & Y are really shared code. What I'm wanting to share in them are images and .lib files. For example, projectY will contains PSDs for images plus the product, which is a PNG. projectX will contain Xcode source files plus the product, which is a .lib file.
In projects A thru C, I want to reference the PNG and .lib files and would like to have the option of either referencing latest or a particular version, which I understand externals will do. projectY will contain all of its PNG files. However, projectX will output its .lib to a common build folder that all Xcode projects use.
If I create an external property from projectA to images in projectY, doesn't that mean all of projectY is an external, source code (PSDs) and all? I'm just interested in the PNGs.
Additionally, if I want to reference particular versions of the .lib file in projectX from projects B and C, how is that done since projectX outputs its .lib file to a common Xcode build folder?
When I update an image in projectX, how does projectA get the latest image? Just by doing an update?
If I put all of projectY's images into a product folder and only need three of its say 50 images in projectA, will all 50 still show up in projectA? Is that a performance issue?
You can set an externals reference to any folder in Subversion - you can point to the folder containing the PNGs only. As for particular built versions, you should consider committing the build output, and tagging each version, then setting an svn:externals reference to the tag.
Yes, an upate to projectA will pick up the updated image in projectX via the externals link (as long as you didn't check it out with the option to ignore externals...).
Tagging is quite useful for such scenarios (depending on whether the complexity of your requirements warrants it). The practice I use at work for shared resources is to tag each version (1.0, 1.1, 2.0, etc.) of the code to be distributed via externals, and point the externals at the latest tagged version.
This means that, for whatever reason, should I need to check out an old version of some project, it's always referencing the same shared files, not just the latest revision.