Xcode 4 + git (part 2)
Xcode 4 + git (part 2)
- Subject: Xcode 4 + git (part 2)
- From: Quincey Morris <email@hidden>
- Date: Wed, 23 Mar 2011 12:13:43 -0700
(continued from part 1)
8. ** Really important step **
At least I think it's important. Nothing subsequent was working until I started wondering why Xcode had changed the ":" in my pasted URL to a "/". OK, Mac OS doesn't like colons in paths. I tried changing it to :, and I got a bit further -- I got an error message complaining about "email@hidden::/repository.git". So here's the really important step:
Before clicking Next, change the URL to:
ssh://email@hidden/repository.git
with only one slash after the domain name, and no colon before it. Apparently Xcode 4 is clever enough to supply the colon all on its own!
9. Click Next. Now you're on a different sheet which is asking your for a "Name". The name of what? It doesn't say. It turns out this is the name of the "repository" entry that's going to be added to the Repositories tab. You can type whatever you want to call it here, but as you'll see Xcode is going to go round in circles before it ever uses this name.
10. Click Clone. Then you'll get a Save sheet allowing you to choose a location and name for the project folder. When you're done choosing, click Clone.
11. Xcode will now access the server (and even retrieve the project from the server, as you can see by looking in the new folder from the Finder), and then ... fail. It failed at this point in the process every time I tried it.
12. Don't bother with Try Again, just cancel this sheet (JUST THIS SHEET) and let Xcode go back one step. It now displays a different sheet, containing the two text fields it displayed in separate sheets earlier. (Go figure!) The two fields are the Repositories tab repository entry name and the remote URL, and they're about to be used for real.
13. Click the Clone button. Again, you'll get a Save dialog. However, you should see in it that your entire project folder is there. (If you cancel all the way out of this process now, Xcode will delete this retrieved project folder, so don't even get any ideas.)
14. Leave the Save dialog hanging, and go to the Finder. Move the project folder that Xcode recently created into the trash. (I didn't try letting Xcode write over the top of it, maybe that works. The only other alternative is to continue the Save with a different folder name, and trash this folder later.)
15. Back in Xcode, enter the project folder name again, and click Clone again. It always worked for me the second time.
What's different the second time, I've noticed, is that the little amber dot next to the repository name has, somewhere along the way, changed to green. Once it's green, access to the remote repository works properly. Don't ask me why it won't go green until things have failed once. Just be glad it goes green at all.
16. Hurrah! At the end of this, Xcode should give you the option of opening your project right away, and everything's good to go, with commits, pulls and pushes! Isn't it?
Well, not entirely. There's still more you have to deal with:
A. You're going to end up with an extra entry in the Repositories tab that corresponds to the remote repository as a whole, which gets automatically named "origin" in my case. It looks like you can clone from this, to get other projects that you've somehow gotten into the remote repository, but it doesn't seem to have any other useful functionality. It just has to be there.
B. You can pull from the Repositories tab, but you can't push. I don't know why. To push, you have to go to the project window and use the damn menu.
C. If you do something stupid like try to add this Xcode project to a workspace (I mentioned this four or five chapters ago, above), you *cannot* commit, pull or push from the workspace window, or even from the repository window while the workspace window is open. (IIRC. It was very late by the time I got to this point, and I wasn't taking notes.) You have to close the workspace, open the individual project, then do your SCM operations, close the project and open the workspace. Good luck with that.
I think it's even a bad idea to try and put the workspace "file" (i.e. package) under SCM control, because Xcode changes it too often. At least several times during my marathon, when I *did* have the workspace package under SCM, I couldn't push to the remote server because something part of getting to the menu item dirtied one of the private state files, so I just got told to commit first, which just took me round in a circle. But maybe that was a different problem.
D. If you thought Xcode 3's handling of files *not* under SCM in the project folder was confusing, Xcode 4 is worse. Now, you can't avoid the list of files when you commit (you didn't have to look at them in Xcode 3, just commit anyway), and the list is hierarchical, so it's not only cluttered with stuff you don't care about it's also impossible to read.
There's an icon above the list to change it to a flat list, but this *displays different files*. Go figure!
Not only that, but both versions of the list are buggy. There's now a checkbox against some things (files and folders), though mysteriously not against everything. It looks like you're supposed to be able to check and uncheck items already under SCM control to manage whether they're committed *this time*. However, it looks like you can check an entry with "?" status to add it to the repository. That half makes sense, except it means you need to think very hard about what to check, in case you add something you didn't mean to add. (See slso C above, under "files Xcode dirties so often that you can never stop committing".)
In addition, some items with "M" or "A" status aren't checked by default, inexplicably. Some items with "?" status (such as .DS_store files, which Xcode *really* ought to have learned how to handle gracefully by now) show up checked and cannot be unchecked. For a while. Then disappear. Or not.
I don't think a lot of this weirdness is by design. It kind of looks like a bug.
Finally, I have to editorialize, as if I haven't done enough of that along the way. I cannot believe that Xcode was released with SCM in this state. We're all (well, mostly) developers on this list. How red would our faces be if we release a major new product that was:
-- badly designed (Xcode has never understood that SCM is a 3-way affair between a project, a local repository and a remote repository, and *not* a simple marriage)
-- poorly implemented (see above -- it took me 16 steps to get it limping along, and even then Beanstalk did some of the work; um, workspaces, anyone?)
-- deeply buggy (those damn checkboxes)
all at the same time!? If anyone has a different tale to tell, or wants to correct my conceptual or practical understanding of what's going on, I'd love to hear it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden