Open Radar

 
Summary:
I once again gave xccheckout files another try. The results:
- When using Xcode6-beta4, I cannot create xccheckout files in a workspace except manually writing it.
- When checking out a repo using Xcode6-beta4, the xccheckout file is ignored unless I directly select the workspace in the repo browser.
- When doing the same using Xcode5, this appears to work in trivial scenarios, in others this corrupts the working copies, and xccheckout file (le sigh).
- When checking out using any other tool (e.g. the command line), and then opening the workspace, Xcode6-beta4 ignores the xccheckout file, so there is no way to check out an optional working copy — which is arguably much better than…
- When checking out using any other tool (e.g. the command line), and then opening the workspace, Xcode5 corrupts the xccheckout file **deleting all optional entries** from it, instead of prompting whether these should be checked out, or (at the very least) keep them greyed out for later checkout in the “Source Control” menu.

This is extremely frustrating, as it breaks every promise these files make.

Steps to Reproduce:
Note: This is for the improper handling/corruption of xccheckout files only.
1. Create four SVN standard layout repositories called “root”, “mandatory_1”, “mandatory_2”, and “optional”.
2. On the command line run `svn checkout root_url/trunk root && svn checkout optional_url/trunk root/optional && svn propedit svn:externals root --editor-cmd=nano && svn update root`, and in the editor add the urls for the trunks of “mandatory_1” and “mandatory_2” as externals (using their logical names).
You will end up with a working copy that looks like this:

root/
  - mandatory_1/
  - mandatory_2/
  - optional/

3. In Xcode, create a new Workspace called “Umbrella” in the “root” folder, and add all those three folders as groups to the workspace.
(At this point, you may have to add at least one file to each of these folders, in order to have the three nested working copies show up in the “Source Control” menu. So let’s just do that.)
4. Edit the svn:ignore property of “root” to contain “optional”, and the same property of “root/Umbrella.xcworkspace” to contain “xcuserdata”.
5. In the “Source Control” menu, try to configure whether these working copies should be included as “Optional” or “Required” during checkout.
(For this to be possible in Xcode 5, I have to close the workspace, and delete its xcuserdata directory. But let’s assume that this just works.)
Set those to “Required” for “mandatory_1 — trunk”/“mandatory_2 — trunk”, and “Optional” for “optional — trunk”.
6. Commit these changes to the repository.
7. Successively check out the trunk of “root” repository using…
- Xcode5 as “xc5 root” (scenario 7a),
- Xcode6-beta4 as “xc6b4 root” (scenario 7b),
- the command line as “cli root”, and open Umbrella.xcworkspace — first using Xcode5 (scenario 7c), then Xcode6-beta4 (scenario 7d)

Expected Results:
- After step 3, you see all four working copies in the “Source Control” menu.
- In step 5, you can edit the “Include as … during checkout” of the three child working copies in Xcode 5/6 with our having to delete xcuserdata or the derived data for the workspace.
- In each scenario of step 7 you are presented with the “Check out additional working copies?” sheet, asking you whether or not you want to checkout “optional”.
- In each scenario of step 7, the Umbrella.xccheckout remains unmodified — regardless of what you selected from the dialog. In fact, performing an `svn status` on that respective checkout remains clean, only listing the two externals “mandatory_1”, and “mandatory_2”.
- Even after selecting to ignore “optional” in step 7, there is an entry for that checkout in the “Source Control” menu, offering to check out that working copy.


Actual Results:
- After step 3, you probably need to perform the workarounds described in parentheses.
- In step 5, you can only edit the “Include as…” option after performing the workaround described in parentheses, and only if you do so in Xcode 5—Xcode6-beta4 does not allow you to do so even after applying the hacks described. An xccheckout file is not generated.
- Scenario 7a opens the workspace, and yields the sheet, allowing you to check out or ignore “optional”. If you select “Ignore” the entry for “optional” is still contained in the “Source Code” menu — this is the only scenario that works as expected!
- The behavior in scenario 7b depends on the exact repository location you chose:
  - If you choose root/trunk/Umbrella.xcworkspace, there is some other dialog, asking whether or not to include “optional”. If you deselect it, the entry for “optional” in the “Source Control” menu is missing. Performing an `svn status` on the root working copy shows “mandatory_1” and “mandatory_2” as existing yet untracked. The xccheckout file is untouched. Performing an `rm -rf * && svn revert -R . && svn update` in that directory restores a consistent state of the working copy. If you left the item selected, you have all the checkouts and all the entries in the menu, but `svn status` also has the question marks next to “mandatory_1”, and “mandatory_2”.
  - If you choose root/trunk, then the workspace opens, and that’s it. `svn status` on that working copy shows a non dirty state, containing the two checked out externals “mandatory_1”, and “mandatory_2”.
- Scenario 7d does not yield the sheet or anything. Peforming an `svn status` on that checkout shows a non–dirty state.
- Scenario 7c does not yield the sheet either, but Xcode 5 deletes the entry for the “optional” from the xccheckout file, thus dirtying the working copy. If one now commits, one just destroyed the setup of each other team–member.

Version:
Xcode 6.0 (6A267n) and Xcode 5.1.1 (5B1008)

Notes:


Configuration:
## Corruption of the Checkouts Themselves
The setup where corruption of one checked out working copy (i.e. not “only” the xccheckout file!) happened was similar to the following:

root/
  - project1/
    - tagged_artifacts_of_project2/
    - tagged_artifacts_of_project3/
    - dependency1/
    - dependency2/
    - dependency3/
  - project2/
    - tagged_artifacts_of_project3/
    - dependency2/
    - dependency3/
  - project3/
    - dependency3/

Where each entry in this tree is an svn external, and equal names mean identical svn urls.
Note that this is a reduced version: in reality there were a total of 13 distinct dependencies (as in this tree, two being the tagged artifacts of the other source projects), and project2 and project3 had more overlap between them.

In this scenario, an error message had been displayed, warning there were different locations for the same checkout. (Which is not too far from the truth, but still…)