I started using new Xcode 11 which integrates SPM.
I added first dependency to my project:
but detected that files are not fetched into my project folder but into Xcode's cache:
I would like to commit all my dependencies files into my main project repository so my question is:
Is it possible to change location of fetched packages via SPM using Xcode 11?
It's somewhat possible, although the solution isn't necessarily a good or great practice, so I can't recommend.
Set the DerivedData in workspace settings to be relative to the workspace.
Add gitignore rules such that the workspace/WORKSPACE_NAME_DIR/SourcePackages/checkouts and related files are includes. Maybe best to ensure repositories directory is not included.
Add a Run Script phase to remove .git and .gitignore files in the checkouts directory.
Obviously, this is fragile largely through fighting the way SPM works. The workspace settings are per person so it's not great in teams.
SwiftPM integration has been setup to prevent this. It clones the files into a DerivedData/ProjectName-[RandomStuff]. You should commit your Package.resolved into the repo to ensure that you get the same version of each dependency across clones of the project.
Related
It's possible to store Checkout and Build directories when using CocoaPods and Carthage.
Is this possible using Xcode 11's SPM?
Or, if I could modify the location SPM uses for Checkouts, then I think this could work by setting this directory to somewhere in the workspace's directory structure.
(I'm in the camp that prefers to keep all assets required to build projects in the same Git repo as the project itself. Don't hate me :) )
You can't do this.
See my previous response to this question here.
How do you work in team on react native projects?
I'm working in Team of 2 people and having a lot of issues with working on the same project.
I don't understand how to properly create an environment so we can sync our code between each other while working on the same project. Now, we create a git repo with /ios and /android folders, but the thing is: the /ios folder always needs to be changed, because it links to the computer that was last building the project.
For example: we are working at the same time on different .js files and add a new npm dependency and we wish to sync our changes, so we commit changes to the Git repo and try to sync, this is where our pains begin.
The one need downloading the changed has to go to Xcode and manually update all the Framework Search Paths, Header Search Paths, delete libraries that Xcode doesn't see and then add them again.
I know it's moreof an Xcode problem, but I didn't see any detailed guide about team syncing in projects. I know that at Facebook people are doing a lot of cooperative work and I'd appreciate some input over our issues!
If you are using git, you can configure your .gitignore-file to prevent committing xcode-specific stuff and other configuration files.
I can highly recommend gitignore.io, which is a "web service designed to help you create .gitignore files for your Git repositories" [Source].
You can for example type in XCode (or AndroidStudio, ReactNative, Gradle, etc.) and it will automagically generate a .gitignore file for you.
I am currently working on a project which is included in a versions(svn)repository. Although I'm not sure, I think I might have changed some settings in Xcode, affecting the way the source control saves the build folder in the repository. I was told it is a bad practice to commit the build folder, and asked why have I done that, but I had no answer at the moment. A screen will elucidate this more clear:
Even if I tried to delete (or ignore) those files from the repository, they are still created after I build the project. How should I proceed in order to prevent those build folders appear in versions' project tree?
Adding versioned folder to ignore-pattern does not affect data in SVN
You must ignore and remove folder from SVN, but keep it locally
For CLI it will be svn pe ... in the parent of build folder and svn rm build --keep-local (I don't know XCode GUI's equivalents)
Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".
This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.
An example file is here: http://pastebin.com/5EP63iRa
I suppose that this type of file should be ignored under VCS, but I'm not sure.
So here are the questions:
Should "xccheckout" be ignored?
What is its purpose?
You should check in an Xcode 5 .xccheckout file; in general, files in xcshareddata should be committed.
An .xccheckout file contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckout file in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.
The *.xccheckout file contains VCS metadata, and should therefore not be checked into the VCS.
On the other hand: checking in this file will probably not create merge difficulties or other problems.
If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:
*.xccheckout
Abizern's solution will not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckout file will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.
Edit:
This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hanson answer. For > 99% of the projects the .xccheckout file is configuration overkill.
It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.
If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.
However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.
Yes, the Project.xccheckout file should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copy relative to the workspace, whether those repositories are Git, SVN, or both.
When you open the workspace, Xcode uses the Project.xccheckout file to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckout file was generated.
As Chris Hanson said, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.
You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.
This is what I have in my .gitignore for Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
It keeps anything that relates to the local state of the way the projects looks for me out of the repository.
The xccheckout file is under here so it is not tracked on my system by default.
Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.
Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.
This is about outdated repo details inside XCode. The case is:
I'm reusing a supporting library from an old project in a new one.
I used "Add files to X project..." functionality to copy them to the new place.
"Automagically" the files were copied with a reference to an old SVN repo, that don't exit anymore.
So... Now I have a project with 2 repos visible, incl. one inactive. I can't commit changes to copied files, as the old repo is still linked.
Two question here:
Is there a way to edit old repo data?
Is there a way to move the copied files to the new repo, where the rest of the project is?
Ultimately I need to commit both parts ;)
Thank you.
OK. So resolving this issues required several steps to be performed. Not sure if all were required, but the eventually I got it right.
Commit all changes you can (in my case all but the folder that was linked with the old repo). Archive your projects.
Go to the root folder of your project and use svn switch --relocate command to merge repos. Details: how to change svn settings
Remove the project from XCode (via Organizer) delete the entire project folder
Remove repos in the Organizer
Fetch whatever was committed in the SVN again. Do that and create a new project. If you see any missing files highlighted in red, like my folder that couldn't be committed, delete it.
Manually add the missing files / folder that to the project, from a local copy.
Now you can commit to the repo!
Tiresome, like most things in XCode... ;)