Removed xccheckout and xcscmblueprint from Swift/Objc/Xcode

[czechboy0]

I believe it should not be encouraged to ignore .xccheckout and .xcscmblueprint files in Xcode project/workspaces. They are a shared resource, which should be committed into the git repository, just like the project file and schemes. It does makes sense to ignore user-specific files, like the state of the user interface, but this is not the case.

Ignoring these files can cause issues when multiple people are using CI tools like Xcode Server across one team. That's why I believe this should be removed from the standard .gitignore for these languages/IDE.

[shiftkey]

@czechboy0 apologies for not getting back to this sooner. Are you interested in resolving the merge conflict here, or should I close this out?

Also cc @Coeur who proposed this rule - I'd love to see if you agree with the above comments.

[Coeur]

@shiftkey, I did not propose the rule, as far as I can remember. I've just harmonized the three .gitignore files.

But there is a major issue with those two Xcode files, so allow me to quote myself:
http://stackoverflow.com/questions/31584297/xcode-7-ignore-xcscmblueprint-in-repository/31644396#comment57794663_32707458

You should always .gitignore .xccheckout. From http://stackoverflow.com/questions/18340453/should-xccheckout-files-in-xcode5-be-ignored-under-vcs/19260712#comment29617170_19260712: "It looks like xccheckout contains keys and names which are specific to each developer's machine... As soon as I run xcode it changes some keys in the file [...]. If this file is supposed to be shared, then Apple have done a pretty poor job." – Cœur Jan 27 at 10:38

Those files will be automatically modified by whoever opens Xcode last, resulting in being added to every commit if you don't ignore these. On the other hand, I've never heard of issues regarding ignoring those files, so I believe we should keep ignoring these.

[shiftkey]

@Coeur apologies, I should have seen that it was a merge commit.

It looks like this goes back further, all the way to #703 which was from 2013. As that original PR indicated, and @Coeur says above, this file has sensitive information in it. I'd love to see if there's any official guidance about whether these files should be version-controlled at all.

[czechboy0]

That's not the case, there's no confidential information in those files, those keys are generated based on the project, so all developers should get the same ones for the same project. That's why it's in shared files in the project.

I haven't seen it being modified, can you please provide any up to date evidence?

Again, I'm for removing these files from gitignore for the reasons I've outlined above.

[jolson474]

For what it is worth... ignoring the .xccheckout file does cause problems (as I've found several times using the .gitignore master branch). I was actually going to go create a merge request before I saw this one sitting here.

If you have a workspace that pulls in projects from multiple repositories (can even mix/match git and svn), Xcode has the ability to pull in those other dependencies. But only if your shared .xccheckout file is present. If it isn't, then you have to manually go check each one out yourself (which is a pain because you have to make sure you get the right sources and put them in the exact same folder paths). So, it is a lot better if that .xccheckout file version controlled.

Details for how this works can be found in WWDC 2013 Session #414 . The relevant topic is "Advanced checkout" and starts at about 14:50 in.

[shiftkey]

Alright, barring any further objections I'm happy to take this in.

@czechboy0 apologies for this taking so long - it seems like there's a merge conflict now 💔

[czechboy0]

@shiftkey No worries, I'm glad we ended up agreeing. Okay let me resolve it.

[czechboy0]

@shiftkey Done

[shiftkey]

@czechboy0 thanks!

[Coeur]

Maybe it does help for @jolson474 for his edge case of multiple repositories, but a load of people on StackOverflow were complaining, as I linked above 16 days ago: "It looks like xccheckout contains keys and names which are specific to each developer's machine." You will likely see PR in the future from people wishing to revert this change for sanity.

[czechboy0]

@Coeur I've heard people spreading that, but can you point me at any evidence of that? Those are not keys, but hashes as far as I understand, and they are designed to be dependent on the server/project, not the developer machines (from observation). If you have any evidence on the contrary, I'd love to see it.

Because again, these files are in the shared data section of Xcode project, hinting that they should be checked in.

[Coeur]

An interesting answer, http://stackoverflow.com/a/20633780/1033581:

• if you are using SVN, you DO NOT want to ignore .xccheckout
• if you are using GITHUB, you DO want to ignore .xccheckout

[czechboy0]

Hmm, the answer you linked says that YES you should check it in. Only don't check it in if every member of your team has a separate fork, thus a different remote.

[Coeur]

Maybe this can reproduce an instable .xccheckout:

• computer A is using HTTPS for the git repository
• computer B is using SSH for the git repository

[czechboy0]

Yes it could, but Xcode doesn't change the files once they're checked in AFAIK. But the checkout files are used mainly for Xcode Server anyway and there the remote is just a field, it has unique identifiers to tell remotes apart.

Anyway, I think it's important we keep it the way Xcode was designed, so I'm glad this is gone. But, to top it all off, I think the checkout files are getting phased out anyway.

[robertibiris]

Hey there guys @czechboy0, @shiftkey @Coeur. A simple way of proving what @Coeur says is as follows:

1. developer A clones a repo, and gives it a custom name (in my case I changed the destination directory from "MyProject" to "my_project" on my local machine, and proceed to cloning it to that directory.
2. developer B also clones it and does the same thing, except he names his local directory "some_other_name_project".
3. they both work on their stuff, and then the .xcscmblueprint is always changed when they pull from each other's code or from a branch pushed to origin by the other developer.

at least, this is the case for my own experience, and if there's dev-specific info on that file, it would be best to ignore it. as for the specific case of .xccheckout, I can't offer evidence on the subject right now.
I hope this helps sort things out a little
BTW, this is true for XCode 8.0 (8A218a)