There's something really satisfying about centralised servers. But things tend to go wrong from time to time, and great big central servers just become great big single points of failure. So think twice before you centralise things and make sure the benefit outweighs the risk.
The version control system you've already got in place can probably shoulder the burden of synchronising data across multiple users in a lot of cases. Not to mention all sorts of other useful goodies it provides - branches, merging, check-in comments, possible issue-tracker integration, an existing backup strategy and of course...version history! So if you've got data you need to share, consider just using plain files under version control.
The other drawback of centralisation is the increased complexity of your project infrastructure. It makes things more brittle, it's harder to set up new users, it's harder to diagnose and fix when things go wrong and it's harder to duplicate the development environment at a different site if the need arises. For example, how easy would it be set up another team working on a separate project but using the same tools and technology? How about an off-site developer or team? Could you provide your publisher with enough of a development environment to do full localisation (and corresponding testing) without your involvement? Does your infrastructure discourage prototyping? What if your central server blows up? Can people work offline until a replacement is in place?
This is not to say centralised services don't have their place - they do. Just make sure you think carefully about their goals and possible ramifications first.
Most experienced people in the games industry these days probably have a great story about some amazing tool or uber-editor that spent months in development, lovingly crafted byte by byte by a programmer who really cares. And when it finally arrives it's a thing of beauty - slick, smooth, featuring the loveliest modern user-interface widgets known to mankind and packed with a million useful features the programmer thoughtfully added.
And it's totally unsuited to the task.
There are three big problems:
So just don't bother. Hack something up quickly and get it in use as soon as you can. Use feedback from users to direct your development. Note down which particular atrocities people yell about the loudest and fix them first. You'll end up with a much better tool in the long run.
There are probably some Agile practices which are relevant here, but I don't really have enough experience to comment further. But please feel free to insert your favourite methodology-related buzzwords here.
Make your release process as simple as possible. Automate everything so that all you have to do is hit a button to pack up a new build of your tools and email everyone who needs to know. Use a packager to pack things up so your users don't have to do anything manually except run the setup program. For windows, Innosetup or the Nullsoft installer are nice easy options.
Be careful to increment your version numbers and make them easy to check. When problems occur, there's nothing more annoying than not knowing what version of a tool the user has installed.
Don't force upgrades. It's tempting to just push tool updates out automatically, but there are often valid reasons for users to retain older versions. For example, a user working on a critical piece of work under a tight deadline won't want to risk introducing potential problems by installing a new version of the tool. If the old tool does the job, let them delay their update until later.
Maintain change logs so users can find out what the new version fixes (and what it might potentially break). Maybe you can generate change logs directly from your source control check-in comments.