I've been a configuration manager and tools administrator for two decades now so hopefully you'll trust my judgement.
First, don't use svn or CVS. They're antiquated. That would be like walking around with an iPhone 1 right now in 2015. Actually, worse than that. It would be like walking around with a Blackberry. CVS and svn are previous generation tools, they don't hold up to modern code needs nor do they scale at all. Just say no to svn and CVS (but especially CVS.)
Git is modern, it works, it's reliable, it's used by everyone, is supported by just about every other tool that needs a version control hook, and you should consider it first if it fits your needs. It's distributed but it doesn't have to be used that way. Pair it up with GitLab and you have a lot more control (or more accurately, your users have more control, and you can enjoy less admin overhead) over what people can do with the code, and who can access what. It has lightweight bug tracking and pull/merge requests. Your inexperienced (which I assume is a euphemism for 'recent college grads') developers don't know anything, so you would be doing them a favor by teaching them a tool that people actually use instead of saddling them with 15 year-old knowledge. In its basic form, git isn't any more 'difficult' than svn or cvs. I personally would put up a very strong argument that you would be doing your developers actual harm in using an outdated version control tool. Mercurial falls into this category, too.
That being said, my main quibble with git is that it doesn't scale very well. I'm talking about the overall size or your stored code history. If you plan on submitting a lot of binaries, and keeping history of them, git will break down for you after a while without the help of third-party tools or clever 'shallow' cloning, etc. If it's just code, it all compresses well and it'll be a long time before you outgrow it (if ever), but there are ways to make git unbearable by putting lots of binary content in it.
Full disclosure, I'm a Perforce admin professionally. I don't work for the company, I'm just a cheerleader. If you're keeping lots of binary data in your version control tool, Perforce is hard to beat. I won't go into detail about it, but suffice to say it scales very, very large, with little to no performance degradation. The current server I maintain (several of them replicated, actually) have over 2 million changes on it with data that is approaching 14 TB. Perforce chews through that like it's nothing.
Tying it all together, Perforce has a tool called GitFusion that acts as a layer between Perforce and git clients. This is especially useful when you have a business that stores large binary files but not everyone needs access to them. Your git users can use git for their smaller repos, your documentation folks can use Perforce for their big docs (or images, or iso's or ROMs or whatever), and everyone's happy. And all your assets are backed by Perforce, regardless of whether they choose to use git or Perforce as a client.
Perforce also has a product that's based on GitLab with a Perforce storage engine.
Under certain circumstances (up to 20 users) Perforce is free, so it should at least be on your short list of tools to evaluate.
So in summary, if you're mostly going to be storing code with not a lot of big binaries and their history, go with git. If you think you'll have heavier storage needs, take a look at Perforce+git.
Lastly, if I ever worked somewhere that was adamant about supporting only one platform (even if it was Linux or Solaris), I'd quit immediately. This Windows mandate is ridiculous and points to a pretty amateur IT team. Some of the things you have in your requirements sound fishy to me and I wonder if the organization is forward-thinking enough to keep the place afloat. Linux, Windows, Solaris, BSD, they all have their strengths and saddling someone with a mandate on the back-end platform is, to be blunt, asinine. If I didn't know any better, I'd think your marketing team calls the shots with IT. Ungh.