Disappointment in Subversion’s Schema Changes
I was working with a subversion workarea (the check-out of the repository) today and tried to do a simple 'svn status' and got the following on the console:
svn: This client is too old to work with the working copy '.';
please get a newer Subversion client
What?! I had been using subversion version 1.3.2 (FedoraCore 5) for a while, I've used 1.4.4 (Mac OS X 10.5.6), even 1.4.3 on a shared install for Linux at the Shop - but I've never seen this.
So I do some digging. First, upgrading the FedoraCore 5 subversion install to 1.4.x is virtually out of the question. There are so many links to that RPM that it's possible to build from source and put it in /usr/local/bin/, but it's just as easy to soft-link the shared drive version (1.4.3) into /usr/local/bin/ and leave it at that.
So why the horrible upgrade path? Sure, subversion uses the apache libraries and such to provide functionality so that they didn't need to write it. That makes sense - to a point. But if I have links to 50 different shared libraries and I want to update my source control client - I shouldn't have to upgrade my OS. It should be something relatively simple. But it's not.
OK, RedHat (Fedora) can take a bit of the blame and the package management. But not all. There's not reason for this. CVS doesn't need it. Git doesn't need it. There's nothing that requires it. It's just the way they decided to do it. Freeze subversion at the OS level (by RedHat), and build it on so many shared libraries (subversion). Together, they make it ridiculous to upgrade the subversion client on a Fedora Core box.
But the big issue was not that the update was exceptionally hard, it was that is was required at all! What were they thinking? Honestly. What version control system makes a repository or workarea schema change that locks out an older version of the client? Amazing. I understand that they are trying to bring better features to the system. That's great. But they have a schema that's been established for a long time. They decide to change it now? I'm blown away.
Don't get me wrong. I understand progress. I understand new features. Xcode updates the old files and makes them unreadable by the previous version. Got it. But Xcode is not a source control system. The problem domain didn't change on them. If that didn't change, they they either did a very poor job putting the schema together in the first place, or they believe source control needs to have new bells and whistles for some reason.
In either case, I am re-affirming my stance with subversion. Won't use it except where I'm forced to. And then, only if there's no possible better alternative. CVS still wins, in my book, for centralized SCM, and Git wins for decentralized SCM. This isn't something that needs to have fancy new features. You need to have stability and reliability. Period.
Want to change the schema? Fine, make it part of the schema - XML does it. Then the client doesn't have to change as it reads all the descriptive information about the repo at runtime. Again, the client doesn't need to change.
I am forced to believe they are either poor designers or interested in shiny buttons. Neither of which is never a good thing. More than anything else I'm stunned that they'd mistakenly design the schema. This was an update of CVS, they knew all the 'limitations' of CVS, and set out to 'fix' them. That they missed the primary reason for source control -- stability, is beyond me. It's just amazing.
I'll keep my distance from subversion, thanks. There are plenty of other, better, alternatives out there.