Monday, January 05, 2009

Where do you go from here, and where is here exactly?

Developers have a love / hate relationship with version control systems. A related post is this one on 'Scar Tissue'. On one hand they either don't do something you desperately need regardless or any pleading or begging. On the other hand they do something that 'conveniently' adds to your workload and refuses to have it any other way. However maddening a VCS can be, software development would be a nightmare without one. Most shops have a preferred tool which is a polite way of saying "Use it or else!" That being said, developers typically learn to use the preferred tool and leave the administration to someone else.

Installing a VCS for my personal work has been on my todo list for a while now but always got pushed onto the back-burner. In the past I've actually worked in a serious development shop that didn't have any versioning system for the first few years I was there. They didn't collaborate much or have the need for branching and since it was my first gig out of college it didn't have that "working without a net" feeling that it would these days. That shop did finally move to Sorcerer's Apprentice before it was bought by black-hole of software known as Borland. After that was PVCS which was expertly configured and taught me a great deal about the benefits of a rationally conceived and executed version control system. Using promotion groups in an orderly way to move code changes along a path from 'only-seen-by-me' to 'ready-for-final-testing' was an arrangement that I wouldn't see again. From there was Visual Source Safe which was serviceable, which means I wasn't the admin, but wasn't very robust. Then there was RCS/CVS which work better than nothing but still leave something to be desired. At this point I realized that the thing I was searching for was not to be found in a tool but in the common understanding of a group of developers who share a development environment and work together to get the most out of the VCS and make each others jobs easier. There is a lot to be said for sitting down as a development team and hashing out a commonly understood development model.

Where am I going with all this? The company for which I work has a policy of buy over build which was served them well for the last 10 years. They've kept their IT costs down while still getting applications deployed for their internal customers. The vendor was trying to write applications it could turn around and sell to other companies in the same market and my employers got a discount on the work; everyone was happy. This arrangement went south when the development partner decided to get out of the business of writing and selling software. They parted ways without rancor but now my company is left with application code for which they have no experience in managing. That's where I come in, to help them with managing software, to advise them when vendors try to close a sale with marketing smoke and mirrors, and to detect when those vendors could be hiding important details about their product or service.

So, I ask for the code and am given a large ZIP file, I kid you not. Evidently the off-shore group of the development shop used by the vendor uses Visual Source Safe locally but it isn't used by anyone here in my office. That led to another nightmare when I researched how code was deployed to production but I'll save that story for another time. I've used VSS before but since most of the code is Java and we're not using Visual Studio, it didn't make sense to use VSS. After poking around on the Internet, I found some really good reasons not to use VSS. Evidence about corrupted databases, well documented issues, and stories from the trenches made it easy to decide to use some other tool.

My first thought was to install Subversion so I downloaded it at home and started learning how to manage a repository. Someone at work mentions a new VCS called 'Git' which is fairly new on the scene, so when I checked it out (there I go again) and at first figured we didn't need the multiple author patch model, where a change has an author and a submitter which is useful for accepting patches through email. After more thought the realization came that the strength of the tools like PVCS or IBM's Rational Clearcase were that they understood branches even if you didn't use them all that much. Subversion doesn't have a great track record with branching. Since the budget was tight that means sticking to free products which came down to Subversion or Git. I'm leaning towards Git.

Off into the wild blue yonder I go. If anyone has stories and/or advice on setting up a VCS for the first time, I'm all ears.
Delicious Bookmark this on Delicious


  1. Hi - you might want to look at another IBM product - Rational Team Concert (get it off an IBM web site called There is a free version (3 users), and you can try out the other versions for 60 days on eval. The install on the free version is two unzips (one on your server and one on your client). This software has a simple but elegant model where you have your own workspace, then when you are ready to "share" with everyone else, you deliver to a stream (and accept other bits from people who want to share with you). RTC does a lot more than version control, but it sounds like this part of it may get you started.

    I should declare my interest in all this - I work for IBM - but even outside work I am very keen on this software.

    Good luck with your VCS - whatever you choose.


    p.s Very active forum on so if the software looks suitable for you, and you install it - ask questions on the forum.

  2. Thanks for the suggestion. Due to a sales job gone bad before I arrived here, buying anything from IBM would be an uphill battle regardless of having no budget for software purchases. The Oil and Gas industry is cutting relentlessly.

    I will go check out jazz and do a follow-up post. I like getting as many data-points with which to do a comparison.

  3. You might like the price on this one - there is a free version (called Express-C). It supports 3 users ( you can pay money to bring it up to 10 users, and beyond).

    I look forward to any feedback you might have - we are looking for lots of datapoints too :-)

  4. terrence3:11 AM

    Keith Packard did much the same thing 2 years ago and gave a good summary of his results: Repository Formats Matter

    For what it's worth, back in college I worked with a copy of ns2 (a network simulator) from a local subversion repository. It was horrific to work on because touching the repository in any way took minutes (literally, about 2 in wall clock time to commit or checkout new code). Ns2 was only 135MiB and 6008 filesystem nodes. I know this because it's sitting of in the corner of my current git repository which weighs in at a hefty 3.5GiB, and 22540 nodes. Commits and checkouts on this repository generally take less than a second.

    I've been using git for about 3 years now and for my 2c I have to recommend it heartily, particularly in comparison to subversion.


I reserve the right to delete inappropriate comments at my discretion