Myself and a co-worker have moved to Webstorm for Angular development after years of Flex development using Flash Builder (Eclipse based IDE).
We also both do Java coding, and use Eclipse for that too.
Our company uses svn for version control and it's been doing everything we could want, and the subclipse plugin for Eclipse works very, very well in both standard eclipse and Flash Builder. It has a clear interface, showing incoming and outgoing changes, makes it very obvious when there are conflicts, and gives an easy to use merge tool. It also handles moving/deleting/renaming files with no problems. Move a file from one directory to another, and rename it? No problem. Do all that, then commit and you're good.
Then we moved to Webstorm.
What an absolute pain to use.
OK, I've been working for a while, as has my colleage, let's synchronise... oh, wait, there is no 'synchronise' button, so we can't see out outgoing and the incoming in one view. Well, that's a pain.
I guess I'll update... except I'm basically doing it blind as it'll do it and then tell me about any files I need to merge, instead of showing me what's going on ahead of time. And the files that need merging are shown as a flat list instead of in context within the file system tree.
Now I commit... except I better not have moved any files around, because if I did it'll complain that the file isn't where it used to be (xxx.js not under version control), even though I moved it within the webstorm interface so it should know where I put it, and so what svn commands to run.
So, if you get into a fix where Webstorm has completely screwed up its svn state and you can't commit because it hasn't kept track of where files have been moved to, you might be in the position of having to take all your changes and give them to a co-worker to copy over their working copy to get them into svn. Except you wouldn't want to do something as simple as drag and drop the folder onto the existing one in Webstorm, because that can't handle there being any folders with the same names (just refused to copy/replace), and even if you succeed, it still breaks on svn commit. So you're left with having to do it in multiple steps (delete everything, commit so it recognises the files are gone, then copy the new versions in, and commit them too... and then probably have svn get broken anyway and need to clean before it'll take the new files).
This played out the same for GIT too, because we were happy to move to that instead of svn if it were better supported.... but we tried it, found it to be just as lacking, so returned to svn to be in keeping with the other teams.
I'm amazed that this IDE is as popular as it is and yet has such terrible version control support when Eclipse shows how effortlessly it can be done... and it's been around for a very long time.