I'm going to answer this from the point of view of git, since that's what I use.
Firstly, if "the source itself takes up over 100MB" then obviously even with your existing centralised system new users are moving in excess of 100MB of data just to get started, and because you're using Subversion the .svn directory keeps an extra 100MB of data on each user's hard disk (this is one reason svn is faster than cvs for some operatons). So it's not as though your problem is currently tiny and will become huge, it's currently large and you're worried it would be enormous. Your concerns about disk space are touching, but, it's 2010, and you presumably value your programmers' time, so I'm guessing they aren't using a Pentium II PC with a 20GB hard disk, you can afford to "splash out" a bit on disk space.
So how enormous would it be? The main factor would be how "different" those 68000 revisions are in terms of the deltas stored by the revision control system. If you have 68000 changes made by a programmer with a text editor, you're probably fine - programmers can't type that fast and using deltas and compression they would only be costing you say 1kb in each change, and an extra 68MB download to get started isn't a big change from where you are now.
On the other hand, if you have a team of artists who check in Photoshop layer files, or whatever flavour of 3D models, that's a problem, because those deltas will be enormous (and the branch and merge strategy is much less powerful when software can't actually merge because the data formats are opaque). Another common source of huge binary deltas is a certain mindset of developer who says "Everything needed for a build must be checked in". So in goes the source code, of course, the build scripts too, but then also the compiler binaries, vendor provided DLLs, drivers for the new 3D card he bought...
Most projects will be somewhere in between these extremes.
I suggest as a first glance, you take a look to see how big the Subversion repository actually is. Maybe it's 100GB, and in that case yeah, you should be very cautious about trying to use distributed version control directly (but see below). However it could be that even with Subversion your whole repository is only 1GB. Git (and any halfway decent distributed version control) compresses that a lot better than Subversion, sent over the wire to a new user cloning the repository, the 1GB could shrink to only a few hundred megabytes. A price well worth paying for the benefits of distributed version control, even if said user is a home-working employee who puts their satellite bandwidth on expenses.
Finally, if you decide distributed version control can't feasibly replace Subversion, get your programmers (since they tend to benefit most) to look at using it locally. As Joel explains, many programmers, even experienced ones, are reluctant to check stuff into a conventional shared repository until it's finished, perhaps even well tested, which defeats part of the value of version control. Using git (for example) locally, either within a team or even just for an individual gets you some benefits while still allowing you to push the "finished" code into the traditional centralised repository. You may find some of them are doing it already.
In this way I think distributed version control is like mobile telephones. Some people got rid of their landline or stopped using it. Some people bought a mobile to use as well as the fixed line. In some countries nobody had a landline anyway. But whatever the case, mobile telephones were a good idea, it's just a matter of finding what works for you.
