random weekend source control babbling


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 (9)

  1. Ed King says:

    I think StarTeam is the best configuration management tool, bar none. Granted, CM is more than just version control, but I always found StarTeam to be great at basic version control., as well. ESPECIALLY w.r.t. branching. You’ve just got to get your mind around the ‘View’ metaphore which drvies StarTeam — no easy feat for anyone with an RCS (or RCS-like) upbringing.

    On the other hand, I find CVS to be painfully unintuitive when it comes to branching and tagging. I’ve screwed up CVS repositories with relative ease; never happened with StarTeam. I always thought it funny that people would say an advantage of CVS is that it uses text files, not some fancy, proprietary repository. "You can just edit the text files to fix things!" they proclaim. Well, I never NEEDED to fix things in StarTeam (or even ClearCase), but I have had to fix CVS lots of times. CVS NEEDS to be in plain text files, because it can be so screwy that you will HAVE to fix it at some point (IMHO).

    Now, all of that being said, I personally use CVS because I work for a small ISV and we cannot afford a full-blown StarTeam deployment right now (server + clients + SQL Server repository, backup agents, etc. It adds up quickly). We use CVSNT + WinCVS + CVS Proxy from PushOk software, for VS.NET integration THAT ACTUALLY WORKS.

    But I know we’ll have to abandon CVS soon. It’s a major pain-in-the-buut that CVS cannot handle something as ‘simple’ as a MOVE or RENAME command (unlike, say, StarTeam, which is a dream to use for these types of operations). We just live with it. [I’m sure someone will again say ‘but you can hand-edit those plain text files and do what you want!’ yeah, right…Google ‘cvs move’ and you’ll see a lot of ‘yeah, it can be done BUT…’ and then lots of warnings about screwing everything up.]

    But, given how refactoring will be so easy and routine in VS.NET 2005, CVS will no longer cut it — daily renaming of files, moving to new folders, etc. must be handled with ease by the underlying VCS. Giving the tight integration of Hatteras and the rest of VSTS, I assume it will have no problems whatsoever with these operations. [Right, MSFT? With full history and roll-back???]

    Call me crazy, but I had hoped for years and years that MSFT would buy StarBase (makers of StarTeam before Borland snatched it up). I just wanted to see VSS die. (And I can’t believe that’s still not happening…!)

  2. 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. :)

  3. 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.

  4. Stuart says:

    I don’t know whether this is on-topic or not, partly because I’m not sure exactly what the relationship is between VSTS and SourceSafe 2005. I’d hope that from a reduction-of-duplication standpoint that VSTS uses SourceSafe as its versioning layer, but I don’t want to assume so.

    I can’t make any specific comments about VSTS itself because I haven’t seen it yet, but I can comment on things that have driven me crazy about SourceSafe for some time. Mostly these are to do with the integration between SourceSafe and Visual Studio.

    The first is that in 2002 and 2003, basic file management in VStudio breaks when the project is in source control. Want to rename a file? Sorry, don’t use the rename menu item, I can’t handle that (even though SourceSafe itself is fully capable of it), you have to do ‘exclude from project’, ‘show hidden files’, ‘rename’, ‘include in project’, ‘hide hidden files’ or some equivalently silly procedure. (As an aside, having a dialog box that basically says "If you do this, everything will break – do it anyway?" is silly, because many users are trained to just press OK on dialog boxes without reading them.) Want to delete a file? Better fire up the SourceSafe standalone client if you don’t want your SourceSafe repository cluttered up with obsolete crap.

    The second is that on occasion I’ve seen people be able to drag-drop or cut-paste files into source controlled projects (in VStudio) *without* checking the files out, or any warnings popping up. This should NEVER be possible, obviously. In an environment where Source Code Control is being used, it should *never* be possible to get into a state where something in your local copy disagrees with source control and will be overwritten on the next ‘Get Latest’.

    The third is the silly magic string that has to be in the project file in order to enable source code control. You know the one I’m talking about – the CZVDAAAA (or whatever) string that identifies the location of the file in SourceSafe. We’ve scripted the creation of our solution files, and we frequently *branch* in SourceSafe, and both of these operations cause problems for VStudio. Basically, it turns out to be impossible to create a valid solution/project combination without this magic string (you’ll get a warning every time you open the project) but there’s no way to get the magic string through scripting. We just tell the first person working on the project to manually "Change source control", which forces VStudio to pick up the magic string and put it in the project file, so our script can pick it up there in future. The fix would either be to stop requiring/using the magic string in the project and solution files, or provide some programmatic way to find that string for a particular project path. Or (better yet) both.

    Finally, it would save me and my company a HECK of a lot of time if SourceSafe were capable of doing intelligent merging of branches. Okay, for starters, allow merging on a per-project level rather than per-file, but I’ve gotten away with scripting that bit. The important bit is remembering which branches have already been merged, and not giving conflicts for things that were already resolved on the last merge. It needs to be possible to have a baseline branch and (say) a customer development branch, and periodically move everything from the baseline to the customer’s branch, and have SourceSafe know which stuff has already been merged, not have to merge everything back to the beginning of time every time. Or repeatedly merge changes from a release branch back to the trunk.

    Hopefully all this stuff is already fixed. But you did ask for feedback 😉

    Stuart.

  5. 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.