Partager via


Hatteras

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

  • Anonymous
    June 29, 2004
    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?

    -Andy
  • Anonymous
    June 29, 2004
    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?
  • Anonymous
    June 29, 2004

    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?

    -Andy
  • Anonymous
    June 29, 2004
    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
  • Anonymous
    June 30, 2004
    Hi!

    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.

    thanks,
    Peter.
  • Anonymous
    June 30, 2004
    The comment has been removed
  • Anonymous
    July 01, 2004

    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.
  • Anonymous
    July 01, 2004
    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.
  • Anonymous
    July 04, 2004
    You can find a quick overview of importing VSS into Hatteras at
    http://blogs.msdn.com/buckh/archive/2004/06/10/152609.aspx
  • Anonymous
    August 03, 2004
    hi!

    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?

    thanks


  • Anonymous
    August 03, 2004
    Pier,

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