Rant: I found Subversion immature
I just had a frustrating hour or so with Subversion. No, it's not that I have problems with its functionality (well, I actually do, but today isn't time to talk about that.) It's the lack of craftsmanship that bothers me.
Firstly, the proxy support. One of the big benefits of Subversion is that it can use HTTP to talk to the server. So one would hope that the network connection set up with Subversion is easier than CVS, right?
Well, not at all, I found.
First, as a Windows program, it should be using the platform proxy setting (the one you set through IE's connection setting dialog.) It's a fairly sophisticated mechanism that covers wide range of use cases. It's also reasonably easy to use from programs --- you just need to use WinInet library instead of the socket library. Or as an Unix program, you can take $http_proxy variable, which seems to be the de-facto standard of setting up a proxy. Instead, Subversion decided to invent its own way of setting proxy information. This makes it really painful to switch one network configuration to another.
Second problem. Network connection problems are one of the most common problems, because there are just so many things that can go wrong. So a program should be able to help users diagnose the problem. With CVS, you can use the -t option to trace the network access of the CVS program. You can see which host/port it's connecting to (if it's pserver), or you can see how CVS spawns the connect program (if it's ext.)
Subversion doesn't have any such option (in fact it doesn't seem to have any global option, so I might be missing something.) When there are so many places you can set network configuration (~/.subversion, registry, ...) this is just poor craftsmanship. If Subversion had a trace option to cause it to print where it's loading proxy information, how it's connecting, and what repsonse it's getting, it would save a lot of time for many users.
Third problem. In theory, HTTP-based connection support would have improved the connectivity. But in practice, because Subversion decided to use the WebDAV protocol, it uses many HTTP methods (like PROPFIND) that are often not allowed by a proxy server. A simple Google search reveals how pervasive this problem is. While I'm sure the use of WebDAV makes some technical sense, it would have been a lot easier to us users if it just uses a standard GET or POST method coupled with the Subversion-Action header or something (guess SOAP-Action header is done for a reason!)
Fouth problem. Of all the modern programming languages you can choose to implement Subversion with, they chose C. I mean C, the least productive programming language of all kind, that only second to the assembly language. Sure, it's necessary sometimes, like when you are writing a kernel, or a really high-performance computing. But Subversion is neither.
Users would have been served much better if the time of Subversion developers are spent on improving the tool itself, instead of fixing string manipulation bugs, tracking down core dumps, and etc. I really don't understand why they didn't pick Python, Ruby, or even Java. It makes Subversion runs on more platforms, it improves the productivity of developers.
You see, none of those are critical to the architecture of Subversion or anything. It's just the rough edges that you need to smooth out. It's really nothing but a lack of craftsmanship to be unable to remove this many issues after so many years of development (I hit all those problems within an hour.)
Well, now that I said all I wanted to say, at least I feel much better!