random weekend source control babbling

  • Article

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

Comments

  • Anonymous
    July 11, 2004
    The comment has been removed

  • Anonymous
    July 11, 2004
    Brant - I think you're absolutely correct. Education is very much critical, and I can concur that my own undergrad and even grad education didn't include anything about version control - it was always just assumed that it had been explained earlier.

    In the CVS case, while there are a couple of decent places on "how to use cvs", the sourceforge doc (http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1) at least includes a little more theory so I tend to point people there if they're asking me for CVS primers.

    I'm sure Hatteras and all of VSTS will have excellent documents both helping explain SCM concepts and specific mechanics. Between Korby (http://blogs.msdn.com/korbyp/), Rob (http://blogs.msdn.com/robcaron/), myself, and many others, we're all working to try and bridge the gap between both those with previous source control experience and those without. :)

  • Anonymous
    July 11, 2004
    Ed - I'm glad to hear you like StarBase so much - I've never had the pleasure of using it, but I'll try to learn as much as I can about it to make sure we make TFS as user-friendly as you find StarBase.

    WRT the couple of questions/comments:
    - we branch in namespace, so you "branch source target" and "merge source target" later on (merging just particular changes as desired, doing more merges later, etc.) - I hate(d) how CVS doesn't do branches as new entries in the namespace, so I'm happy that with TFS if I have a main/ subdir, I can "branch main rel-1.0" and create a branch for my 1.0 release as desired and merge change(set)s in either direction with ease.
    - renames are supported in TFS as fully versioned operations that are full first-class pended changes, just like a pended add or pended delete (or pended undelete!). They're shown in history and you can treat them like any other pended change - they increment the item's version number like any other change (like an edit would). Yes, history is preserved - it's really the same item before and after rename, not a "clone" like some systems do with a branch/delete operation pair.

  • Anonymous
    July 12, 2004
    The comment has been removed

  • Anonymous
    July 12, 2004
    Wow, Stuart, thanks for the feedback!

    Because answering these questions is going to be lengthy, and others may find it helpful as well, I'm going to make it another post in my blog (should be posted in about half an hour or so).

    Short answers (post will be long answers):
    - not based on SourceSafe at all
    item 1) we do the right thing (pend rename or delete)
    item 2) I may be misunderstanding the situation you're describing, but source controlled files not checked out are read-only.
    item 3) no magic strings for Hatteras-controlled projects. If you branch/merge on a basis "above" your solution directories, you shouldn't really need to muck with the project files or solutions at all (most everything is local-relative-path)
    item 4) Hatteras merging is far more intelligent - already-merged changes won't be merged again.

  • Anonymous
    December 29, 2007
    PingBack from http://cars.oneadayvitamin.info/?p=698

  • Anonymous
    March 12, 2008
    PingBack from http://boxingfightblog.info/james-mannings-blog-random-weekend-source-control-babbling/

  • Anonymous
    June 15, 2009
    PingBack from http://workfromhomecareer.info/story.php?id=30223