Re: SCM in XCode 3.0 Leopard
Re: SCM in XCode 3.0 Leopard
- Subject: Re: SCM in XCode 3.0 Leopard
- From: Chris Hanson <email@hidden>
- Date: Mon, 29 Oct 2007 15:06:27 -0700
On Oct 29, 2007, at 1:26 PM, Timothy Reaves wrote:
All you need to do is use something like Eclipse to understand how
horrible it is in XCode. Or Wing. Or IntellaJ. Or SlickEdit Or
even Microsoft's IDE's. The deficiencies are too many to innumerate,
and I shouldn't have to (to Apple, who should have researched it).
Please keep in mind that there are a lot of Mac developers who have
not also spent a large amount of time living in Eclipse, Wing,
IntelliJ, SlickEdit, Visual Studio, etc. and won't know what features
or capabilities you're referring to in them. Please actually specify
what you find wrong about how Xcode SCM works (and file specific,
actionable bugs for each issue) instead of saying "It's bad and you
should know why."
Saying that is not specific, and it is not actionable; similarly,
saying "spend a bunch of time living in this other IDE" is not
specific, and is not actionable. I'm sure you would rather that time
be spent actually addressing the actual problems you are running into,
and the easiest way to start doing that is to describe what those
problems are.
The SCM support in Xcode 3.0 is hugely improved over previous releases
and, in my opinion, is quite usable and *quite* good -- it's my
preferred way to interact with Subversion now. I'd really like to
know exactly why we appear to have such extremely divergent experiences.
Yes, I've filed defects. No, Apple has said they won't act.
Do you mean to say "No, Apple has not said they won't act."? Or are
you specifically saying Apple has refused to act on a specific,
actionable request for an improvement?
One thing I'll point out again -- I know I do this a lot -- is that
"duplicate" does not mean "not to be fixed" and that the bug reporter
is in no way, shape or form a black hole. "Duplicate" means there is
already a case in Apple's tracking system that covers the issue. I
know I say this a lot, too, but: Don't let a resolution of
"duplicate" keep you from filing bugs. Information from duplicates
can be *critical* to actually resolving a bug; one duplicate with a
reproducible case, or that occurs in a slightly different but easier-
to-investigate case can make all the difference.
As to data loss, the integration itself hasn't caused it, but
the way
it acts has. Unfortunately with Subversion, it can be easy to do
something unintentional that causes data loss (even in Eclipse, where
the integration is incredible).
Specifically what have you done with Xcode 3's SCM support that has
led to data loss? That sounds like a very serious issue.
Without specific details that can be used to categorize or mitigate a
problem you've discovered, it is less than useful to say "Xcode SCM
can cause data loss!" because it doesn't tell people how to prevent it
or what recoverability steps they may be able to take.
The source control integration in XCode is kinda like the unit
testing, and even Python; in all cases, I've filed bugs against 3.0,
asking for more features or fixes to broken code (SenTestKit will not
work in XCode 3 if you use all of Objc2's features).
What features of SenTestingKit have you found not to work with
Objective-C 2.0, and what are the Radar numbers for these? Even
Objective-C garbage collection works, though /Developer/Tools/otest
itself is *not* built GC-enabled, since it would run with GC on by
default if that were the case.
It is straightforward, however, to build your own test rig that uses
OCUnit and that runs under GC, and to use that with Xcode's unit
testing infrastructure. Note that this is *only* required to test a
framework or bundle that runs under GC; applications will work out-of-
the-box.
To build a custom test rig, just create a tool that links
Cocoa.framework and SenTestingKit.framework, that sets the user
default whose key is SenTestToolKey to [NSNumber numberWithBool:YES],
and that then invokes SenSelfTestMain() (defined in <SenTestingKit/
SenTestProbe.h>). When you want to use this custom test rig binary
from your test bundle's target, just define the OTEST build setting in
your target to point to your custom test rig binary's path. That
should be all you need to do.
Again, building such a custom test rig is only required to test
frameworks or bundles that will be run under garbage collection.
Testing applications that run under garbage collection will just work
with the provided Xcode infrastructure, since SenTestingKit.framework
is built GC-supported rather than GC-required (like almost all of the
frameworks applications and tools can use in Leopard) and application
tests are injected into the application to be tested instead of hosted
by otest.
If ALL cases,
Apple's response (I have it in writing) is that they consider the
issues closed and I should contact the open source community. But,
wait a minute: Apple was the one that announced the integration of
testing (which is why Sen:te dropped support), Python (why are they
telling me to ask the Python community for why the XCode templates
don't work?) and source control (but they've never actually compared
the support to other IDE's).
It is certainly incorrect for the response to a unit testing or SCM
bug to be "contact the Open Source community" since unit testing and
SCM are supported features of Xcode that Apple maintains. That may
just be an inaccurate characterization of the bug's disposition from
ADC (for example, a bug may be marked closed/duplicate, but ADC may
have inaccurately said "contact the Open Source community" instead of
"this is a duplicate of XXX" -- mistakes happen, after all). Do you
have Radar numbers for bugs you feel have been responded to
incorrectly? Thanks.
-- Chris
_______________________________________________
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