Monday, December 22, 2008

Am I the only person who doesn't trust an IDE for Source Control?

My current assignment uses Eclipse as the blessed IDE. Nothing new there, it works pretty well and it fits the budgetary constraints, i.e., it's free.

The team also use Eclipse's source control tools to manage source control, e.g. commits, updates, merges, and branches. I'm not such a huge fan of this. I prefer to keep some separation between the development tools and the source control tools.

For performing simple source control operations like updates, and simple commits I think that Eclipse is a perfectly capable tool.

For anything more, though, I prefer to keep my source control tools separate. As a source control interface, I just don't think that eclipse is that great. I don't think that it can be. It's a heavyweight Java application that is designed for developing Java projects.

Eclipse does get the job done, but it doesn't do it as well as other clients. Many of the available specialized tools require only a fraction of the computing power to run than Eclipse and they just do the job better. I also like the fact that most of the source code client allow their users to use their favorite diff tool instead of forcing users to use their own diff and merge tools.

Usability is a big concern. I prefer having a separate source control tool from my development environment because I trust source control tools more than I trust my development environment's ability to manage source control functionality. Eclipse, even in the Team Synchronization perspective, isn't as good at managing files as tools that are made solely for the purpose of managing files. I'll take a command line or Windows Explorer over a file viewer in Eclipse because the command line and Windows Explorer aren't trying to present anything beyond the files to me.  When it comes time to dealing with source control, I only want to know about files, versions, mod dates, etc. 

Finally, I like having separate tools as a final set of checks and balances. Ideally, I prefer to review my changes before I commit them. I'd rather do that with tools other than the ones that I use to edit those files. In a way it preserves the principle of orthogonality. Developing files on a local system and submitting changes to a centralized repository are tasks that are different enough that they deserve different tools. The chances of unintended side effects are much greater when you create a tool gap between their actions.

I find that even viewing the files in a different tool and from a different perspective gives me the ability to review my changes from a clean perspective and potentially catch mistakes before they move to the source control repository.

That's my opinion for commits. If I'm going to branch and/or merge a repository, I'd much rather do it outside of Eclipse. The performance of other tools out there is much better than Eclipse's. Consider the reputation that branching/merging can be one of the most trouble prone actions in source control management, doesn't it make sense to use the best tools for the job. I've had just enough trouble with Eclipse to cast enough doubt whether it's doing what I want it to that I trust other tools more.

3 comments:

Reckless Abandon said...

While I can appreciate your point and I can see you've found a diff tool you think highly off, I'd have to disagree.

I think good IDE support for source control is a MUST and I think Eclipse and IDEA have excellent support for it. In particular, I appreciate the IDEs understanding of refactoring (primarily move and rename) as well as being able to view the history of a file and instantly diff it within the IDEA. Finally (and probably most important) I like the ability to see what changes are "incoming" and handle merging of differences all within the tooling I'm already comfortable with.

But... that's just me... perhaps I'm the only one who _likes_ having tight integration with source control :-)

Paul Wiedel said...

Reckless, you raise a very valid point. The "I" in IDE is integration.

I must confess that working with CVS has conditioned me to be a little shy of moving and renaming files--having a rename/move fail at my former gig could take weeks to resolve, not fun. Do you have any experience using those IDEs with CVS?

I go back and forth on this topic. On one hand having tight integration with source control reduces the resistance for commits, which is usually a very nice thing.

My own preference is to review my commits outside of the context of my development environment. Some of this comes from beginning my career with a completely unintegrated set of tools.

You like IDEA. What source control do you prefer?

Reckless Abandon said...

I prefer Subversion over CVS. While far from perfect, it does handle moving/renaming/deleting much better than CVS. IDEA's support for it is very good. Eclipse has very good support as well with Subversive (or Subclipse, but Subversive works better IMHO).

If the IDE has poor integration... then no integration is better. And, in that case I'd fall inline with your opinion.

In general, I've been very impressed with the CVS integration in Eclipse and IDEA. Eclipse's tag/branch/merge support is really, really nice. It can save hours of painful work.

All of this said, the biggest problem I've found is that few organizations know how to properly manage there CVS and Subversion repositories.

When tagging/branching aren't done properly, both IDEs aren't of much help.