>>20
Much more would have to change to make svn distributed than you seem to think. One of the basic concepts in svn is the linear, chronological repository-wide revision numbering. You can't have non-linear revision history, and there's no easy way to add it. This is absolutely fundamental to svn, and its creators still firmly believe that this is a feature, not a design flaw.
Keep in mind that the simplest form of non-linear revision history in svn, that is merging branches, is still done in a completely backwards way: you merge the branches into your local copy, fix up any conflicts, then commit a giant patch which is all the branch changes. It appears as one revision in the logs, with at best some merge-tracking metadata and at worst no comment whatsoever regarding its source. Good luck to the poor souls who have to dig through your branch changes later on.
This is the same reason why hosting a local svn mirror does not really work. Access to old history locally is a very minor feature; what you really need is to commit locally and push later on. push/pull is simply not possible unless you manually merge each commit, because the revision history has to stay linear.
Sure, they could replace the numbers with hashes to support non-linear history, fix branch merging to link history properly, and finally support push/pull with mirrors, but then after all that work they'd basically end up with git. What's the point? Besides, you are never going to convince them that non-linear history is a good thing. They're simply not listening.