With today's announcement of Visual Studio 2005 Beta 1 (aka “Whidbey“), I figured now was as good a time as any to start my blog. I'm one of the testers on the Hatteras project, which will deliver an enterprise-grade source control solution as part of Whidbey.


While Visual SourceSafe has its merits, virtually everyone I've spoken to or worked with over the last few years has wanted something more - most of them were members of teams with many developers, and SourceSafe just couldn't meet their needs. I'm confident that Hatteras will effectively step up to the plate, and I'm excited to be a part of it.


The parts of Hatteras that I'm most directly involved with are the diff, merge, and resolve features - so, in a nutshell, computing and presenting file differences, processing branch / merge operations, and resolving the various conflicts that can arise when attempting a get, checkin, or merge. So, if you want to know more about the branch model that Hatteras has chosen (there are notable differences than SourceSafe, and for good reasons), or about conflict resolution, ask away.


I'm also testing the “shelve / unshelve” feature - the ability to safely and reliably put a set of pending changes “on hold”. Imagine you're working on some feature work, and have to 'drop everything' to work on a critical bugfix; or you want to have a coworker test your changes before you check in; or you want to move your work-in-progress from your desktop to a laptop to take home for the night or the weekend. These are among the scenarios that shelve is designed to robustly solve, compared to the various alternatives people find themselves using (such as checking in changes that break the build, or even might break the build; or zipping up your local files but still only having them on a local machine or two, instead of in source control where they'll be backed up).


My job as a tester is to make sure these features work for the user. So, tell me how you use source control. Tell me how your current solution fails to meet your needs, or forces you to bend over backwards to get the job done. Together, we'll make sure Hatteras, Burton, and the rest of Visual Studio 2005 make it easier for you.

Comments (11)

  1. Andy says:

    hi Chris,

    Saw a demo of VSTS which I believe uses Hatteras, right?

    Anyhow, will Hatteras be the default Source Control system with VS 2005?

    Also, doesn’t Hatteras uses SQL Server 2005 as its backend datastore?


  2. Chris says:

    Hi Andy.

    Yes, the source code control shown in VSTS is Hatteras. Keep in mind that both Hatteras and SourceSafe 2005 utilize the Source Code Control Provider interfaces in Visual Studio, so you will still be able to choose Source Safe when appropriate.

    I honestly don’t know if either is "the default Source Control system with VS 2005" – that depends at least in part on which SKU of Visual Studio 2005 we’re talking about. I’m pretty sure it will be the default for installs of Team System, but probably not for an Express SKU (for example). I don’t want to give a false impression out of ignorance, however, so don’t hold me to that.

    Hatteras does use SQL Server as the backend datastore. Are you asking from a version perspective, or in terms of the product features/capabilities?

  3. Andy says:

    Hi Chris,

    Thanks for the info.

    Re: SQL Server 2005 as Hatteras’ backend, just curious, that’s all, so is it possible to use SQL 2000 (a la The Vault) or is Hatteras can only be used with SQL Server 2005?


  4. Brian Button says:

    Does Hatteras impose a locking or merging model on the development team? We’re an agile team, and a locking model of source control would be utterly useless to us.

    — bab

  5. Peter says:


    It is great that Hatteras people blog.

    Can I ask, if would be possible in some way to use Hatteras from VS.NET 2003?

    I think that even if VS 2005 will be released we still will use VS.NET 2003 for maintenance of old .NET Fx 1.1 code.



  6. Chris says:


    1) Andy, as far as I know, you’ll have to use SQL Server 2005. I assume there will be bundling or SKUs that wrap the package up, but that’s all outside of my knowledge.

    2) Brian, go into more detail if I don’t answer your question, but the short version is: We support concurrent checkout, 3-way content merges, and branching/merging (forwards and reverse).

    Now, I believe a team can create *policies* if they WANT exclusive checkout, but the default scheme allows anyone to checkout a file regardless of who else has it checked out – you’ll be notified at checkout time, and obviously you’ll have conflicts to merge/resolve if someone checks in before you. We also support locking items (for checkin or checkout), for special cases when you need exclusive checkout, or approved checkins, etc. This type of locking is item-granular but can be applied recursively from any level in the tree.

    These are areas we’re working hard on making as capable as possible – for example, there will be support for plugging in 3rd party diff/merge tools.

    3) Peter, I doubt you’ll be able to run Hatteras from within VS 2003. However, we (almost certainly) support side-by-side installs of VS 2003 and 2005, so you’d be able to open 2003 (if I say "Everett" anytime henceforward, VS 2003 is what I’m talking about) and build against items that are managed by Hatteras; you’d just have to run the command line interface or an instance of 2005 or the VS Shell interface in order to do Hatteras operations.

    You asked in the context of a more general problem – maintaining applications deployed on .Net 1.1 from within Whidbey. I’m going to look into the plan for this and (hopefully) post on the results; I can see people wanting to keep in 1.1 at least initially. I know that you can side-by-side install the 1.1 and Whidbey-generation frameworks; I just don’t know off hand if there’s a way to have Whidbey *build* for 1.1 or not.

  7. Olivier says:

    Is there a way to "convert" a Visual SourceSafe Database to Hatteras ?

    We have HUGE VSS "Databases" (200000 files – 4 GB, yes you read it correctly) and would be very interested to migrate as soon this product is available.

  8. Chris says:

    Last I heard, we will ship with a migration tool for SourceSafe (and possibly other source code systems out there, I don’t know for sure).

    Now, I’m not in the loop on the migration tool, so I’m not sure how exactly it can migrate your database. I know it will let you migrate most aspects of item history (and the items themselves, obviously). How it handles differences in architecture – e.g. shared files – I just don’t know accurately enough to be ‘informative’.

    It won’t be perfect, but it should be at least a lot better than only importing the current version of everything.

    We should be able to support a database that big, too. I say "should" because I’d hate to make a blanket statement but turn out to be wrong because of some particular quirk in the set of data you’re versioning.

    Suffice it to say that MS-internal requirements for rolling out Hatteras will demand at least that much capability.

  9. Buck Hodges says:

    You can find a quick overview of importing VSS into Hatteras at


  10. Pier says:


    nice blog!

    I’ve a question about branching on Sourcesafe.

    When you branch (share and branch) an entire solution you make a 1:1 copy of the files in it, .sln file too! inside .sln file there are absolute sourcesafe paths of the projects in it and .sln file on the branch still points to original projects on the trunk… I have to change them by hand.

    Does Hatteras resolve this strange problem?


  11. Chris says:


    I’ll look into this and answer (probably in a new post rather than another comment) when I know the answer.

Skip to main content