We're doing development for both .NET (Using VS 2008) and Java (using eclipse)
Currently, we're using CVS, but there isn't really a good plugin for Visual Studio 2008, so I'm looking at changing to something that has better support for VS 2008 and Eclipse.
My initial thought was SVN, as it is really close to CVS, but I'm a bit tempted to use something like Mercurial. I'm looking for something that is simple to use, and has good plug-in support for both platforms.
I can tell you that there are really nice plugins for Subversion for Eclipse and Visual Studio 2008 (AnkhSVN for Visual Studio). You have to make sure to download the daily builds of AnkhSVN if you plan to use it with the most recent subversion version. Additionally there are tools (http://cvs2svn.tigris.org/) to migrate your data from CSV to SVN.
For Mercurial oder Git - I don't have got any experience with those.
I think SVN will give you the smoothest transision - but it won't give you the "big revolution" (if this is what you are after)
We use both VSS (and now subversion) for both J2EE and .NET on different projects. Both seem to work OK.
Why are you so hung up on IDE pulgins? Personally, I could take'em or leav'em... I put them in the "kitch which doesn't add any real value" bucket.
Cheers. Keith.
There is an ongoing debate between AnkhSVN and VisualSVN, if you decide to go with SVN.
Personally, I like Ankh. It is free, more intuitive for me, and provides more useful feedback on my project's state. I have had some corruption issues, though, but nothing that cost me more than a few minutes.
I use Vault from SourceGear. It's simple to use and has great IDE integration with Visual Studio and Eclipse. It's also fully tested on Linux using Mono.
It's free to use for single users, so you can try before you buy.
Check it out and see what you think. http://www.sourcegear.com/vault/
Having used svn with both Eclipse and Visual Studio, I find that the eclipse plugins (especially subversive) are generally more seamlessly integrated into the IDE. Ankh and VisualSVN both do a very good job, but I tend to prefer ToirtoiseSVN when working with .net. In Eclipse I almost never resort to ToirtoiseSVN.
To be honest though, I think the IDE plugin shouldn't drive your decision too much.
We're a .NET, Java, and Rails shop
We used Subversion for years and its a fantastic system, did everything we thought we needed from an SCM. About 9 months ago we started playing around with Github.com whilst developing a Rails application (unavoidable in the Rails community).
Since then we've shifted over to Github.com completely using private repos for our closed-source commercial software developments.
Git has made us not break a build or clobber code in months - something that used to happen from time to time and made us loose a day's work trying to rectify the problem. Subversion doesn't provide you with the flexibility in your working methods that Git does. If you're in trouble (a broken build or a hot fix), Subversion won't help you it'll even work against you. Its branch/merge mechanism is very difficult to use because it doesn't keep track of the origin of the branch. Also when you merge back, your change history is modified such that all changes by the team in a particular branch are attributed to the user performing the merge. Git is also lightning fast as the whole repo that you work on is local, something that is very noticable when you're working from remote locations.
That said, Subversion will take you a week or two to get proficient in, Git takes at least a month, especially if you're coming from Subversion or CVS. If you pretend its just a more modern SVN or CVS, you'll get frustrated by the lack of improvement in your coding workflow and you'll become annoyed by the multitude of commands.
We have a 3-branch setup: hotfix<->master<->development. In normal conditions the dev team will work in the development branch. For each user story the developer will create a branch off development: development<->user story. When the story is finished the user story is merged with development and the user story branch may be deleted. This goes on and on, and master stays stable and unaffected until the build manager decides its safe to merge all the changes in development back into master. If in the mean time a customer phones and requires a hotfix, that too is done in isolation from master and can be merged into the rest of the codebase (master&development) at a suitable point in the future.
Now wrt to GUIs and SCM. We avoid them like the plague. GUIs are bad for working with SCMs. I know - controversial, but hear me out. The command line will slow you down more than a GUI does and when you're working with an SCM and there's a high-chance that you're going to do something bad or destructive to your central repo, slow is a good thing. Slow makes you think about your actions. All the typical GUIs that I've seen (EclipseSVN, TortoiseGit/SVN) all preselect your recent changes as being part of the commit you're about to make, whether those changes are ready to be committed or not. BAD!!!! You need to think about your commits and how lumpy or granular they need to be - command lines do a better job than GUIs in this regard. All our .NET coders, who are naturally drawn to performing tasks via GUIs, use command line Git and used command line SVN before that, just for those reasons outlined above. It gave them a greater sense of control.