A year ago when I worked for a Large Software Corporation we used CVS to manage our codebase. It was definitely not as productive as subversion which I use on my own projects, and have been using now for over 3 years. It has it's pain points also, but using subversion is like driving a sports car whereas cvs is like driving a pie wagon (no offense intended for any readers who drive pie wagons).
I took svk for a ride today briefly (thanks for the elbow grease schwern), and am going to take git for a test drive later this week. I like driving the sports car (subversion), but lately I've been doing a lot of driving and I am more aware of when the car dies and I have to get out and jumpstart it (I find some race condition related to doing a complicated file move, then changing my mind or something similar and it gets unhappy).
Also, I've had to work on a branch, and rather than put myself through the pain of doing a proper branch I made a tag, and use 'svn cp' to do my merging (yeah I know, I deserve to be hit with a stick). But I remember back to a year ago, when I was driving the pie wagon and needed to do some branch work. Well, the pie wagon took a lot of patience and wrangling to get it to turn those sharp corners.
So rather than take the pain of turning the corner I would park the wagon right before the corner, then get out with my pies and run around the corner where I had a station wagon parked (I would make a copy of a HEAD checkout, strip the cvs files, and put it in a separate directory so I could mutilate it without fear of screwing up HEAD). Yeah, I know, bad practice, but believe it or not it was actually easier to use a few shell commands to commit everything at the end to HEAD rather than risk screwing something up with cvs's scary merging commands.
So today I talk to one of my former colleagues and I tell him that I'm trying out git and svk and how it is going to solve my problems. He said it sounds cool but it would probably never fly in a corporate environment where they want everything centralized so it can be controlled, backed up, etc. To that I replied, "well remember when whats his name the cvs admin screwed up and deleted most of the main repository and there were no backups and everything had to be restored from developers' copies?" I also mentioned how the cvs server had a less than stellar uptime record, especially when shared storage crashed (this was even worse).
He conceded those two points to me, but then offered a third. "Well then we would likely end up with developers each having stuff on their own boxes in version control that wasn't tracked, and management wouldn't like that".
I conceded that one. Then later in the day I realized that this would actually be a better situation then having developers with stuff on their own boxes that _wasn't_ in version control (and I wasn't the only one who had my own kludged test directories). That sealed the deal for me, and made me realize two things. One, I'm definitely going distributed with my version control system. Two, not trying or doing something because it might lead to problematic future behavior is a real good way to never get out of current problematic behavior.
So today I talk to one of my former colleagues and I tell him that I'm trying out git and svk and how it is going to solve my problems. He said it sounds cool but it would probably never fly in a corporate environment where they want everything centralized so it can be controlled, backed up, etc.
