This is, for the most part, just random useless trivia that hopefully won't really affect customers at all.

Over a year ago, RobCaron passed on the news of our (that is to say, Brian's ;) naming decision for what the project codenamed "Hatteras" was going to be officially called: Team Foundation Version Control

The (only) other realistic contender would have been "Team Foundation Source Control".  To many (hopefully all) people, they're relative synonyms.  The market doesn't have any (or at least not many) entities that would bother making a real differentiation between the two.  However, going with Version Control gave us the nice side effect that it made more obvious the fact that this is a product that handle more than just source code - we're ready to handle whatever you want to throw at us (including files as big as your filesystem can handle, binary files of whatever type, etc.).

Why is it, then, that the section in MSDN that groups a bunch of the documentation refers to it as Team Foundation Source Control? We made the naming decision over a year ago - why would anything on MSDN be using this other name? Even Chris's MSDN article on TFVC flips on the name on consecutive lines :)  Chris is one of our first MVP's, by the way.

    Branching in Team Foundation Source Control
    Merging in Team Foundation Version Control

The reasons center around existing customer experiences.  One of our main scenarios is focused around the existing customers that have been using Visual Studio 2003 and Visual SourceSafe.  It's important to try and make the transition from these versions to Visual Studio 2005 Team System with Team Foundation as smooth as possible. 

There are some impedance mismatches that already cause some pain.  For instance, we really want customers to use branching and merging and have made them both easier to use (IMHO) and more approachable concepts (hopefully) - for far too long they've been considered a black art, and many teams just go with a "mass copy" approach rather than using branching and merging since the tools weren't really there to make it a user-friendly feature.  Visual SourceSafe has the features "sharing" and "pinning" which we intentionally don't support because we feel branching and merging are the better tools for the problems that sharing and pinning were being used to solve (make sure to catch Channel9 videos from Doug and John which touch on this).  Since we already have issues like this, there's no need to make the transition to Visual Studio Team System and Team Foundation any more difficult than it has to be, so we'd like to try and build on their existing UI paradigms to increase discoverability when possible.

Even outside of trying to ease Visual SourceSafe / VS 2003 user migration, there's a precedent set in Visual Studio itself - the File | Source Control menu. It's been around longer than we have (obviously).  We actually had a tough decision to make because with Team Foundation there's the introduction of a new Team menu (this is where you'll find things like Add Work Item, Go To Work Item, etc.) - for solidarity among the parts of Team Foundation, it was considered that our version control operations should go into that Team menu, maybe even as a submenu called "Version Control".  However, that would be less discoverable for customers that are used to going to File | Source Control to do their source control operations.

Also, in a more general sense, Visual Studio considers this feature to be "Source Control" - a provider is called a "Source Control Provider", the API exposed is MSSCCI (MicroSoft Source Code Control Interface), etc. - this makes sense, for most of Visual Studio's life, their target user has been developers/coders.  It's only in VS 2005 with Team System that we're really expanding the roles that we expect to be using Visual Studio (or at least the Team Explorer SKU) for their daily work.

The fallout of trying to ease the transitions for these customers (which is a *very* good goal to have) and follow the pre-existing VS precedent is that we tried to strike a compromise that hopefully will work out fine for all involved:  When it's being referred to in the Visual Studio UI, we'll stick with "Source Control" (which is why the window is called "Source Control Explorer" instead of "Version Control Explorer").  All other times (at least in theory), we're our "real" name of Version Control.  For instance, our assembly names, namespaces, classes, all say VersionControl.

However, there are places where it wasn't so cut and dry which way to go.  For instance, one of our big extensibility points is the ability to customize the process methodology templates - these are sets of XML files first and foremost - ones you can edit to mold our existing out-of-the-box methodology sets ("MSF Agile" and "MSF CMMI for Process Improvement", I think) to something that matches either the processes your company/project already uses, or perhaps the ones you want to transition to.  In either case, it's very important that we're flexible on that.  Inside these templates, where the xml data is king, we're referred to as Version Control - our particular xml file (for how to configure the team project folder you want created, which permissions to assign it, which check-in notes to have associated with this team projects, whether the contents should force checkout locks, etc.) is named Version Control\VersionControl.xml - however, when you run the Project Creation Wizard to create a new team project, some of the strings in these xml files will be displayed to you, the user creating the team project, and that will include "Version Control task completed" (or something similar) which will have (sort of) violated our rule on when we should be "Source Control".  Of course, that's not a bad violation, as the Project Creation Wizard is new to Team Foundation and as such, there was no existing UI precedent for this wizard.

It's a very minor thing, and we did consider going with all one name or another, but hopefully what we chose will work out well for consumers.  Why even write this blog post?  Mainly because at some point someone somewhere is going to wonder which it is, and why they see both strings showing up.  Hopefully they'll find, read, and (ideally) accept this explanation :)