Re: 4.3 question and old Developer folder
Re: 4.3 question and old Developer folder
- Subject: Re: 4.3 question and old Developer folder
- From: Fritz Anderson <email@hidden>
- Date: Sun, 19 Feb 2012 12:44:12 -0600
On 19 Feb 2012, at 12:53 AM, Joar Wingfors wrote:
>> I'm speaking a priori here, so the Xcode team may have done something that delights the customer and proves me wrong. However:
...
> Fritz: How would you like to be delighted here? What is the problem that you'd like for us to resolve?
I was speaking unironically here, on the chance that you'd done something for compatibility with users' legacy scripts that depended on /Developer being in some of the predefined build variables. That would be a bend-over-backwards thing to do, and not what I'd expect (my criteria for "delight"): The predefined values are, I believe, all predicated on the path to Xcode, and you'd have no way to know what the legacy directory was (/Developer? /Xcode4.3? /old_Xcode? What if the user had all of those?). That's also what I meant by /Developer no longer being privileged.
I think such a feature would have been more confusing than not, and as-good-as-impossible to do right, but sometimes Apple does something more ingenious than I'd imagined.
[FA rant about not being able to find current release notes, in part referring to the absence of fix notes. See Quincey's gentlemanly takedown, and my reservations.]
> We fixed thousands upon thousands of issues in Xcode 4.3. While we could list some or all of them, that has - as you probably know - not been our tradition.
If by tradition you mean "not in 2011." As recently as the 4.0dp6 notes, you selected major fixes (with radar numbers) and called them out. You might object that that's for private circulation, but they're in the released document. For public releases, it would be good to have something like:
"The source-control browser would proliferate separate listings for remote Git repositories. Fixed. Remotes are now reliably identified from the local repository settings, and you can delete all standalone remote entries. 12345678"
I still have some orphaned remotes in my organizer, because I still don't know whether it's safe to delete them (are the local-repo entries repaired?). It was a very visible bug, and I'd have liked to know whether I could break the habit I'd formed to work around it.
And no, you can't do everything.
> If you have any other comments on why you feel that you'd need to rummage through the developer directory to figure something out, and what we could do to make that task either unnecessary or easier in the new world where everything is relocated to inside of Xcode.app, again - please let us know.
There is surprisingly little need, but cloistering standalone applications was a fundamentalist adherence to the principle of everything-in-Xcode. Fundamentalism in design is a good place to start, but Xc4's development from WWDC 2010 was a story of softening those edges.
Very, very few developers want to spend a minute and a gigabyte of memory cranking up Xcode (and another half minute shutting it down), and lose their trains of thought, just to run FileMerge.
The "What's New" article offers a workaround, but it's a _workaround_. I find it significant that acknowledging a workaround is a departure from the usual "new-and improved" tone of "What's New." I don't imagine it would have cost you much to create /Applications/Developer for the apps, arguably including Xcode. (Colliding with an existing directory would be a problem, as would getting the App Store installer to play along. Uninstallation would be less intuitive.)
Yes, I should file bugs.
— F
_______________________________________________
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