Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Phred (5358)

Phred
  fredNO@SPAMtaperfriendlymusic.org
http://www.redhotpenguin.com/

Fred is a Perl and PostgreSQL geek. He has made some very small contributions to a few cpan modules and mod_perl.

Journal of Phred (5358)

Wednesday July 18, 2007
03:51 AM

The fallacy of problematic future behavior (or cars and vcs)

[ #33836 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    As you suggest, this is a common way to miss the point. With distributed version control there can still be a central, canonical repository that can be backed up, controlled, etc. There's also always uncontrolled

    --
    rjbs
  • There has beeen a large amount of talk about distributed VCS recently, and git in particular. However talk of it (git in particular) penetrating corporate environments seems premature, until: Which, to be quite frank, is a crying shame.