Make the alternative look worse than it really is. In fact, go one better – don’t make it look worse, just describe it as being worse. Some may consider it unfair to pick on one specific post, but I am increasingly disappointed with how the SVN integration in the new RAD Studio XE is being hailed as some great new addition to the IDE and don’t think it’s fair to paint it in such flattering shades without doing a fair comparison.
In the linked blog post, there is a set of “oh look how clunky it used to be” steps describing how you would previously have performed a check-out from SVN prior to opening a project or file when working with RAD Studio.
Except for one thing: The steps described are unnecessarily cumbersome and make a reference to having to do task switching.
There is no need to do any task switching with TortoiseSVN and the RAD Studio IDE. The steps are simply:
- File -> Open (from within the IDE)
- In the file open dialog right-click : SVN Checkout (or Tortoise -> SVN Checkout if you really can’t be bothered to configure your explorer Tortoise context menu)
- Wait for SVN
- Navigate to and select project to open
No task switching and really not much different from the integration.
Well, actually there is one notable difference…. with the integration if you go to “Open from Version Control” and then find that you already have the required files checked-out you have to back-out from the Version Control specific operation you erroneously embarked upon.
With “vanilla” Tortoise there is less chance of running down that blind alley… you will either open the file you need or realise you need to check out from SVN first, and you can do both and/or either from the regular old File->Open dialog without having to switch modes, let alone tasks.
Oh but that’s not fair, this is only one aspect of the integration!
True, but it’s also the one and only aspect of the integration addressed by the blog post that I am referencing. Sauce for the goose.
Come on.
People keep criticising me for complaining, but if there are benefits and Great New Things™ in a release then for pity’s sake can’t we find some to talk about instead of having to mis-respresent the alternatives (deliberately or otherwise, perhaps through simply being unaware) to try make the new features look better than they are?
It is surely especially important to have something genuinely positive to focus on given the great disappointment of not seeing delivery on expectations set by the previous roadmap?
(I can’t comment on other things that are in XE that others are not perhaps talking about because I don’t have access to XE yet – I wish I did. I am sure there must be something valid in there to be praising)
I support you. You have the guts to speak up and even if you can be occasionally wrong, you are usually right 🙂
I get the impression that EMB made the management shake-up because it failed to fulfill the promise of 64-bit and/or cross-platform support in the XE release.
I have a gut feeling that a conspiracy was in the works by some EMB competition (you know how one important Delphi architect was lured to move out of Borland to some dreadful company and start a new delphi-like language, which was devastating to Borland!)
This new conspiracy’s motto?
– Stall and Delay Delphi’s Return –
Unfortunately many people will do anything for money these days.
Do you agree this could be true?
@Mowat: “Never attribute to malice that which can be adequately explained by incompetence”. 🙂
EMB’s best choice of actions is to admit that something went wrong and commit to fixing it going forward. A smokescreen of this and that will not fool many folks. So far XE is D2010 R2.
If they were missing the deadline with putting 64 bit into XE, then just release it later (did not stop them from doing it with v2008, they just skipped it). The message is “we did not get it in, so we’ll just move it to the next release”. The insult is we’ll still charge them for the current deficient release.
I also noticed the complaining level has been going way down. I don’t think that is a good thing for EMB. I think the BUYING public has quit caring. I think a message needs to be sent to just skip this release and update when they finally get the product right.
I personally want to see the 64 bit stuff put into the product so I personally know there is a serious commitment to the product. Instead of milking it for the yearly revenues. The strategy has not worked with me since they lost out on the D2009, D2010 and now the XE update dollars.
I think the truth is once 64 bit and cross platform is done, the really BIG, across the board ideas, are limited. So I guess they will try to stretch them out for years…
Also checking out a project is someone you do once, unless you switch to a new project everytime it is rarely something annoying even if it requires two step more and switching to a different application. Instead of talking about an operation performed once in a while, it would have been far better to show how the SVN integration works in everyday operations.
BTW: I find more annoying to have to switch to a different application to code and debug Oracle packages (you can do it within VS with the Oracle plug-in).
Actually, having SVN integrated in Eclipse helps very much with Java projects – although it is not working as well as TortoiseSVN. Commits, updates and especially version history integration can be done context sensitively, and more automatic.
So, although I have never felt that I need CVS or SVN integration in Delphi, it may be cool, if it works well in there.
Nevertheless, it is not one of those big enhancements that one would especially wait for a new release. I understand, though, that writing a new compiler does not happen when you want it to happen – it takes its time.
64-bit promises have dragged on so long that the community is beyond impatient. But Win7 64 is becoming the norm (my company will only be getting 64-bit versions).
Doesn’t Embi use Delphi to develop their own products? So surely they must feel the same pressure that we, the Delphi community, do?
Integrated version control – MS Visual Studio allows integrating SourceSafe, so for a while we tried that feature. But in practice we ran into unforeseen annoyances for minimal gain, so we run SourceSafe separately again. I think users will have the same experience with Delphi XE.
To me, an intermediate release in line with the product line name change is OK. I would welcome some streamlined IDE productivity aids (code formatting).
But it all depends on how much it will cost.
Clearly there has been a shakeup in the company, so I’m cutting Embi some slack.
@Brett: On the other hand, do you want to pay for a rushed 64-bit version? Let them concentrate on it now and get something decent out. There will be enough of the inevitable Version 1.0 bugs anyway.
I have the feeling for a long time that there is someone at Emba who has the task to prevent a Delphi 64 bit release….
Well said!
I didn’t renew my delphi SA.
I love dephi but I think EMB is doing the same that was done from inprise and borland.
I think it’s useful WHILE a new version (= 64bit) is written, marketing give the current a lower price and for free to schools.
Peter: Why on earth would anyone at Embarcadero want to prevent “a Delphi 64 release” beyond the obvious fact it is not ready?
@Jeff et al: Just for the record, I approve these comments. This does not mean I approve OF or agree with the comments. 🙂
I think the idea that there is some sort of conspiracy at work to be utterly beyond belief, but people are entitled to their opinion.