I don't think I understand the concept of "centralized development" except perhaps if there is a single developer. In our case we have 20 developers working on different aspects of maybe 10 different but related projects at any time out of a pool of around 40 projects, all of which share code. Using a distributed revision control system means that we can easily maintain central dev and stable versions of each repo. Developers use a local clone of the repos they are working on (we use Mercurial's sub-repo management facilities a lot!) and run it as a local sandbox repo, syncing from the central repos and workmates repos as they need.

It sounds like anarchy, but works very well. It also works very well with our nightly builds which build all projects against the central repos. For dev builds the nightly build can be against the tip version of each of the sub-repos involved. We may have almost any number of our developers working on a specific project at a time and we may have several developers updating the same file in the context of different projects at the same time - mostly it just works.

Doing this with a single central repo would be a nightmare! We were doing it with CVS and merges between branches were terrible with many manual checks and balances and much gnashing of teeth. SVN may have been a little better, but no where near as good as using a distributed system.

If you have the chance try moving one of your projects from SVN to Mercurial or Git. Mercurial (at least, don't know about Git) can even use an existing SVN repo, but I'm not sure what the down side may be doing that.

There is some pain moving from CVS and to a lesser extent from SVN in figuring out how to break up an existing repo. Mercurial at least doesn't allow you to cherry pick parts of a repo to generate a checkout that is a sub-set of the total repo. Using sub-repos fixes that to a large extent, but you are likely to end up moving stuff around between repos if you don't think hard about the structure up front.