I've discussed this at some length with a few of the original Subversion implementors. The short version is that they didn't go back and do a slight rethink whe

I've discussed this at some length with a few of the original Subversion implementors. The short version is that they didn't go back and do a slight rethink when they came up with changeset objects, and that causes part of the problem. The rest of the problem is that branches aren't a first class thing in the system, leaving no good way to mark mergeinfo. Hindsight being what it is, you could probably build a Subversion-like system with almost the same filesystem by making the notion of branches and tags first class, and their just-a-copy nature being somewhat hidden from the user. Sadly (on some level, I'm a huge DVCS advocate, but see the need for CVCS in corporate environments), that's largely water under the bridge - many of the original team have moved on to using DVCS tools. Subversion 2.0 as a completely clean break with the past to fix some flawed design decisions feels very unlikely due to the political forces at work.