Team Foundation {Version,Source} Control - Which is it?
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 :)