Playing “devil’s advocate” is very much in my nature, so in the absence of external input, I’ll have debates with myself.  I’ve been in a constant debate lately as to the role of source control in the development process.  Necessary evil?  Useful tool?  Glorified backup mechanism?  Thin layer over diff/patch and friends?

 

Projects like Arch (Sorry, GNU Arch these days) go a long way toward proving that “thin layer on top of other existing tools” can be an accurate description (well, and CVS being a layer on RCS and many other such systems).  Does that mean anything though?  Is source control just whatever can keep versions of files?

 

I’ve had times in the past (especially using CVS, which I still have a love/hate relationship with) where trying to use my source control’s branch/merge support was infuriating – I fell back to tools I knew (patch/diff/etc) that worked as expected with simpler command-lines (mainly because I had more work to do, and no time to play around until I got the desired results - if you don't do an operation much, you forget the command-line structure for it easily).

 

So source control is a conceptual layer on existing tools, the first layer that adds file revision as a concept.  Maybe it also adds things like the concept of pended changes, maybe it adds atomic changesets, maybe it adds versioned renames (yeah, yeah, we have all those), whatever, but you have a tree (or set of trees) with versioned contents.  The mechanics of these concepts  aren’t really interesting for the typical user.  I’m slowly starting to realize that it’s the usability of the features that really make or break a system. 

 

I think I learn this lesson slowly because I’ve spent so much (too much) time evaluating software systems like many people do cars or other types of purchases – bullet points of capabilities.  Yes, based on all the listed bells and whistles.  Far too little focus on actual usability of said bells and whistles.  Our development of Hatteras both is and has been very scenario-based, thankfully, so we’re always trying to make sure the end user usage is as nice as possible.

 

One thing that’s often said (by myself in the past, and many others) is that Eclipse makes CVS not only usable, but somewhat enjoyable.  I’ve used Eclipse at multiple previous jobs and really enjoyed it as something that made CVS much easier to work with.  Is that the secret to source control?  Make the end source control user’s experience actually enjoyable?  Maybe those wacky Eclipse guys are onto something J  Of course, Eclipse is far more than just a nice CVS interface, but stick with me here.

 

Now, the major pitch of VSTS is obviously the tighter integration of our development software stack and more importantly, the easier, less repetitive workflow it enables.  Integration between source control and bug work item tracking, integration between requirements gathering and creation of work items, etc., etc. – these are all great features and I am very much looking forward to them making the lives of project managers, developers, testers, and everyone involved in the software development process better.  

 

But, I still hope that Hatteras honestly makes source control itself a joy for our customers.

 

More to the point, though: What do you think?  How do you regard source control?  How about particular source control systems?  Which do you hate?  Which do you love?  Which features of whatever source control systems make your development lives better or worse?  Most other source control systems have had a few to dozens of releases to get lots of great customer feedback.  We do a lot to get some feedback so we should hopefully get a 1.0 that’s really close, but it still keeps us up at night. J