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.