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.
Related
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.
Note: I am relatively new to Git / GitHub. I understand my way around, but I am confused with this corner case
Background
I created an IntelliJ color scheme git repo and pushed it to github online. The directory structure was ad hoc and made up of only output. This was actually fine and worked well.
I noticed that people would not get updates from me this way, and decided to create a JetBrain Repo plugin. This also works well; however, my github location and plugin location on my PC are different.
Issue
I looked over Change Git repository directory location. but was not sure if this fit my usecase.
Since my github is just output files and my plugin files are all input files, can I simply just copy over my .git files (along with README files and such) , and expect it to work correctly?
The linked SO question seems to relate to JUST moving the same directory structure and files over to another location. I am dealing with different directory structure, different files, and directory location; however, it IS the same project.
Update
Before, my workflow was:
Modify Color Scheme in IDE
Export settings from IntelliJ
Place in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
Now it is
Modify Color Scheme in IDE
Run project and autogenerate output in \IdeaProjects\ChroMATERIAL
Place output in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
What I want
Modify Color Scheme in IDE
Run project in \IdeaProjects\ChroMATERIAL
Windows GitHub Client: \IdeaProjects\ChroMATERIAL merge
GitHub
I'm assuming that the generated output matches the structure you need for your Github repository. If so you could easily move your .git folder from
\Documents\Github\ChroMATERIAL
to
\IdeaProjects\ChroMATERIAL
What you should check:
Will the generated output directory be cleared if you clean the project into Intellij? If so you should stick to your current workflow since you could easily delete your local copy.
The other thing which could be a problem is the Github Desktop Client since I don't know how it behaves nor how or if it must be configured in a special way to reflect your changes. (if you just call it from the inside of the repository it should not be a problem at all)
For your explanation:
Git uses relative paths. So it is irrelevant where the repository lives inside your system. The important part is the structure inside the repository since this will be cloned to the remote repository.
I recommend that you copy your .git folder rather than move it. If something goes wrong you can easily revert.
Hi I am relatively new to Maven and intelliJ IDEA.
While trying to import the Maven project, IDE is asking for adding *.iml files to SVN control.
I wanted to know what does it mean ? and what are the merits and demerits of doing so?
The iml files are used by intellij to store module specific settings and other information relating to the module. Usually teams do not add *.iml files to svn. Typically these files change rapidly, and for no important reason, meaning that if you perform something as simple as a search you'll change the iml file and you'll have a difference with the repo that'll need to be submitted or reverted, and you'll always be in this position. Plus, if a developer does check in the iml, the next developer will have their personal settings overridden whenever they do an update.
Adding files to svn (subversion) is done to maintain a history of a project and to share source files amongst a team. Most teams don't want to share intellij's personal module configuration.
I have several projects which use code from a large set of component libraries. These libraries are under source control.
The libraries repository contains all the libraries used by all my projects and contains multiple versions of multiple libraries. Each library/version pair lives in its own folder. Each of my projects identifies the specific library/version pairs it needs through the folder paths of the references in its project file.
For example $(LibraryPath)\SomeLibrary\v1.1.5
Please note that the libraries repository is only ever added to. No changes are made to stuff already in the repository. Ever.
I have been of course been able to configure my build plan to pull the libraries repository to a libraries subfolder of the working directory. So far so good. However, using the auto branch management feature of Bamboo, this setup means that the libraries repository is cloned for each and every branch in all projects.
Not funny. No, really, not funny...
What I would like to do is:
pull the libraries repository in each build plan
but pull it to a fixed location that is the same for all build plans
it doesn't have to be an absolute path
but it does need to be outside the working directory of the current build plan to avoid unnecessary duplication
Unfortunately the Checkout Directory of the Source Code Checkout configuration task in a Bamboo build plan doesn't allow me to specify either an absolute path or a relative one that goes "up" for one or more levels from the working dir. The hint text explicitly states "(Optional) Specify an alternative sub-directory to which the code will be checked out." And indeed, specifying something like ..\Library gets punished with the message "Checkout to parent directory is forbidden".
I have seen information on the "artifact sharing" feature of Bamboo. This will probably work, but it seems like overkill for what I want to achieve.
What would be the easiest and least complicated way to achieve my goal using Atlassian's Bamboo Continuous Integration?
Out-of-the-box alternatives are welcome, but please don't direct me to any products that require intimate CLI use and/or whose documentation assumes (extensive) knowledge of 'nix and/or Java setup. I am on Windows and spoiled rotten by powerful (G)UI's.
I have the same problem - with a repository weighing in at around 2GB.
I'd like to simply "git checkout myBranch" and "git clean -fxd" instead of cloning every time (which should save a lot of time and disk space). However I also like Bamboo's automatic trigger with new branches showing up.
Like the OP, I'd love to be able to put "..\SharedDirectory" in the "CheckoutDirectory" for the
"Source Code Checkout" task but it won't let me go out above the \JOB_KEY\ folder
One possible solution is: replacing the "Source Code Checkout" task with the two git commands above. That way I can specify exact when/where/how to do the checkout. I think there may be problems with the initial checkout in this case - but once that is solved, all subsequent branches would use the same shared folder, and no more pulling down 2GB every time.
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... ;)