views:

275

answers:

7

I've personally always used some type of external application for my SCM work; these days, that means tortoiseSVN on windows and versions.app on the mac. However, I keep running up against developers (namely eclipse users) who argue that SCM is better done within the IDE itself. I've yet to hear any really compelling arguments in favor of this workflow, and I personally like a degree of "separation" between the IDE and SCM operations. This has been burned into me from using unstable SVN plugins in Visual Studio, and the sub-standard SVN support in Xcode in years past when working offline.

Which way promotes the better workflow in your opinion?

+4  A: 

For basic operations - Check in Check out I like it right in the IDE, for anything much more advanced, (branch/merge) I prefer to use the external tools.

External tools seems to give better control/options in those circumstances. Your choices seem to be limited or non-existent when working directly in the IDE.

Brian Schmitt
A: 

It very much depends on the IDE/SCM combination. I'm currently using IntelliJ with SVN, and find that IntelliJ's SVN plugin is generally much more pleasant to use than Tortoise. Not that I have any particular complaints about Tortoise -- IntelliJ is just better.

Randy Hudson
+2  A: 

I definitely prefer outside. That being said, my primary IDE is Visual Studio, and I haven't used eclipse or intellij (although I have used cvs-mode in emacs...), so your mileage may vary...

  • Making changes and committing changes are separate tasks - having them both be easily available in the IDE means you don't clearly delineate between completing a set of changes and committing them. Quite often it's a case of type type type, compile, test, test, commit...'oh, wait - I forgot to foo the bar as well. Context switching from IDE mode to SCM mode tends to trigger the 'oh, wait' before the commit.

  • Keeping related files for commits together - it's all too easy to commit source changes, then remember the related SQL scripts and commit those separately and then add the new image files as you forgot those because they're new to the repository and so on.

  • Similar to the above, it tends to be a lot easier to commit things at the wrong level/directory in the repository when in the IDE. (e.g. I should have committed at solution level, not project level)

  • It tends to be easier to get a complete diff of your workspace against the repository outside the IDE, which is often worthwhile.

  • It also probably makes your IDE that extra bit faster

I also agree with a previous poster - all non-trivial SCM tasks tend to be easier outside development IDE integration.

To be honest, as long as you're avoiding messy commit situations described above, do whatever you find most comfortable. In terms of workflow - the separation has to be 'cleaner', whether this cleanliness outweighs the convenience is going to be in the eye of the beholder - we're largely reacting to our personal experience (I suspect mine is similar to yours).

Whatever you do, use anything but SourceSafe... I have to at the moment for legacy code - I find it abhorrent that files are made read only and that the SCM integration physically alters the contents of files...

Gordon Hartley
A: 

Building should be possible without IDE so SCM should be possible without IDE.

On other hand, having IDE support the SCM can be convenient. It is nice to be able for example check the file history easily and maybe revert it.

iny
+2  A: 

One advantage to having the integration is in refactoring. If I renamed a class in Java (and thus the file name), your SCM integration would automatically handle the rename operation (a delete and then an add in svn, for example).

It also is very handy to be able to say, "show me the history of this file" or whatever while you are working on it, without having to drop to Windows Explorer or the command line or whatever.

But I like being able to have both available, honestly.

Travis B. Hartwell
+1  A: 

I almost always use external tools. The only exception is when I need to rename a source file. It is just so much easier for the IDE to update its project references at the same time.

Ferruccio
A: 

I like internal SCM for.

  • Renaming files, rather than having to do the rename in the IDE and the SCM tools
  • Adding files to a project - see above

I find with an internal SCM it is less common for developers to forget to add new files to the SCM system.

For any complex operation, e.g. merge, branch, etc I tend to use an external SCM GUI or command line.

Ian Ringrose