The do-all-be-all IDE

Hi.

I went yesterday to the Microsoft Visual Studio 2005 launch event.

In the new Visual Studio, Microsoft integrated a source control system,
team collaboration (tasks and bug tracking), load testing and functional
testing.

There are 2 problems with this approach IMHO:

1. This goes against best-of-breeds environments, where people want to
use the best source control system, best IDE, best bug and task tracking
systems, etc. For example, I would prefer having good integration of my
IDE with the source control system I choose to use.

2. Multi-disciplinary environments suffer. For example, in a combined
C++ and Java environment one can't use the source control system and bug
tracking in Visual Studio 2005 as it is a one-off solution rather than
integration with a source control system from both the C++ and Java IDEs.

With that in mind I have to question the Demetra quest to have source
control and other components of the software development life cycle
embedded. I doubt it will be of use to our heterogeneous environment,
and I have to question whether a version 1 component (in IDEA or Visual
Studio) will be better and more reliable than existing tools
(Subversion, StarTeam, Perforce, etc.) or if a task and bug tracking
system will be better than existing products (e.g. Rally).

What I really want to know is if the source control API will stop being
developed, if I should expect the Subversion or Perforce integration
become stale and if I shouldn't hope for integrating with any bug
tracking or task tracking system as a result of this new do-all-be-all
policy.

Thanks,
Amnon

3 comments

Hello Amnon,

AG> With that in mind I have to question the Demetra quest to have
AG> source control and other components of the software development life
AG> cycle embedded. I doubt it will be of use to our heterogeneous
AG> environment, and I have to question whether a version 1 component
AG> (in IDEA or Visual Studio) will be better and more reliable than
AG> existing tools (Subversion, StarTeam, Perforce, etc.) or if a task
AG> and bug tracking system will be better than existing products (e.g.
AG> Rally).
AG>
AG> What I really want to know is if the source control API will stop
AG> being developed, if I should expect the Subversion or Perforce
AG> integration become stale and if I shouldn't hope for integrating
AG> with any bug tracking or task tracking system as a result of this
AG> new do-all-be-all policy.

There is no such policy. We have absolutely no plans to develop our own source
control system in Demetra, and we have a number of plans to improve our existing
source control integrations. There have been discussions to include some
kind of task tracking system in Demetra, and even some prototypes were created,
but we also don't plan to create a full-featured bugtracker that would compete
with JIRA or similar tools.

The only tool we do want to replace in Demetra is the continuous integration
tool (for example, CruiseControl). Note that we won't replace your build
scripts (Ant, Maven or something else) either - you'll be able to use your
existing build scripts with our build server. And we think that our build
server will be as good, or better, than the tools currently on the market,
and will provide superior integration with the IDE.

We're definitely keeping heterogenous environments in mind (think Resharper).
And of course, you'll be able to create plugins that will integrate our build
server with other IDEs, and you're already able to create plugins that will
integrate our IDE with other continuous integration tools.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Demetra quest to have source control and other components of the software

development life cycle embedded.
No way.

Just like previous IDEA versions it will integrate with existing VCSes, issue
trackers etc. Well, there's kinda difference between "integrated environment"
and "all-in-one" environment indeed.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

Dmitry Jemerov (JetBrains) wrote:

Hello Amnon,

There is no such policy. We have absolutely no plans to develop our own
source control system in Demetra, and we have a number of plans to
improve our existing source control integrations. There have been
discussions to include some kind of task tracking system in Demetra, and
even some prototypes were created, but we also don't plan to create a
full-featured bugtracker that would compete with JIRA or similar tools.

The only tool we do want to replace in Demetra is the continuous
integration tool (for example, CruiseControl). Note that we won't
replace your build scripts (Ant, Maven or something else) either -
you'll be able to use your existing build scripts with our build server.
And we think that our build server will be as good, or better, than the
tools currently on the market, and will provide superior integration
with the IDE.

We're definitely keeping heterogenous environments in mind (think
Resharper). And of course, you'll be able to create plugins that will
integrate our build server with other IDEs, and you're already able to
create plugins that will integrate our IDE with other continuous
integration tools.


That's great to know, I was starting to feel the walls close on me and
oxygen shortage... OK, I was just a little worried :)

I'm happy JetBrains didn't adopt the same vision as Microsoft.

While on the subject, have you ever tried Rally (www.rallydev.com)? It
would be great to integrate with that, though probably not very straight
forward due to the complexity of the tool.

Thanks for clarifying this. I guess that I should continue and trust
JetBrains to do the right thing, which it usually does.

Amnon

0

Please sign in to leave a comment.