Gee, time flies when you are having fun.  I can’t believe it’s been another 4 months since my last post on Orcas features. At this point TFS 2008 is basically done!  We’ve got a few bugs left to fix and we are still taking feedback from Beta 2 but we’re focusing on quality, stability and ensuring TFS works in a wide array of configurations at this point.  As such, I expect this to be my final feature list post for TFS 2008.  I hope you are happy with what we’ve done.  Hopefully you’ve picked up Beta 2 and tried it out for yourself.  We’ve really tried to focus on addressing things that are most important to you.  Most of the feedback I’ve seen on Beta 2 so far has been very positive. From here on out, I’ll be doing separate posts on our Rosario feature list as that unfolds. I’ve marked significant additions since the last roadmap report with (new).  I’ve marked things that did not make Beta 2 but will be in RTM as (RTM). Administration, Operations & Setup

• Share Point 2007 support
• Enable use of Sharepoint on any server and any port
• Support for MOSS 2007
• Enable support for Reporting Services on any server and any port (new) (RTM)
• Support for SQL Named Instances – This will allow customers to share a SQL server between multiple TFS instances, or with other applications.  This has been a commonly requested feature by enterprises.
• “Longhorn” server support – TFS will support the next version of the server (and corresponding new version of IIS) that is currently under development.
• Sync Large Groups – This is a set of work to improve the performance and robustness of TFS’s handling large groups of users (~30,000 or more) granted permission to a TFS instance.  Today this can result in a support call to recover from it.
• Non-default ports – We’ve gotten a bunch of feedback from enterprise customers about TFS’s limited support for alternate web sites and ports running afoul of data center policies.  We are going to be improving TFS’s configurability in this respect in Orcas.
• Simplify installation – In Orcas, we will be doing a variety of things to attempt to make installing TFS easier and quicker than it is now.  Improvements include eliminating the separate data-tier installation, simplifying the requirements around required domain accounts by supporting the built in machine accounts (like Network Service) where we can, etc.
• Official testing and support for more configurations – This includes clustering, mirroring, log shipping, Virtual machine deployment, and more.
• Support for client certificates
• Upgrade from TFS 2005
• Support for SQL 2008 (aka Katmai) (new) (RTM)
• TFSDeleteProject now permanently deletes (destroys) version control content (new) (RTM)
• New role for many operations activities (new) (RTM) – You don’t have to be server administrator to run many of the admin utilities any longer.
• Enhancements to tfsadminutil (new) (RTM) – New capability to configure accounts, connections, etc on both TFS and the TFS proxy.

Build (more detail)

• Support multi-threaded builds with the new MSBuild.
• Continuous Integration – There are many components to this, including build queuing and queue management, drop management (so that users can set policies for when builds should be automatically deleted), and build triggers that allows configuration of exactly how when CI builds should be triggered, for example – every checkin, rolling build (completion of one build starts the next), etc.
• Improved ability to specify what source, versions of source, and other build properties.
• Improved extensibility of the build targets – such as ability to easily execute targets before and after each solution/project is built.
• Improved ability to manage multiple build machines.
• Stop and delete builds from within VS.
• .NET Object model for programming against the build server.
• Simplified ability to specify what tests get run as part of a build.
• The ability to store build definitions anywhere in the version control hierarchy.
• Scheduled builds – You can schedule builds to happen at specified times.
• Improved build agent communication – We replaced .NET binary remoting with WCF web services, simplifying some configuration and security aspects.
• Ability to run GUI tests as part of a build – Automated builds used to run tests in such a way as to prevent access to a GUI desktop.
• New checkin policy for broken CI builds – Preventing checkin while the CI build is broken.
• Support for HTTPS communication to the TFS server (new)
• Continuous Integration build checkin policy (new)
• Support for incremental gets and builds (new)

Data Warehouse

• Add support for checkin policy overrides to the warehouse – an oversight from V1.

Migration

• Migration toolkit – A toolkit for building conversion and mirroring solutions between TFS and other systems.  In addition, we will release one or more new tools to integrate with popular alternative systems. 

Version Control

• Annotate – This is based on the TFS Annotate Power Tool but includes numerous improvements.
• Folder Diff – Also based on the TFS Tree Diff Power Tool with numerous improvements.
• Destroy – The ability to permanently delete version control files/folders from TFS.  It can also be used to destroy the file contents while preserving the change set history.
• Get Latest On Checkout – There have been many requests for this feature (which was a change in behavior from SourceSafe).  There is now an option that allows you to specify that you want TFS to download the latest version of files when you check them out.
• Workspace improvements – Workspaces will now support mapping a folder or file under a cloaked folder and wildcard mappings so that you can map all files in a folder without mapping sub folders.  Based on experience with large projects, this will simplify workspace definitions for many people.
• Performance improvements – A variety of Version Control performance enhancements that will improve virtually all aspects of version control performance.  The gains for smaller servers/projects (< 10,000 files) will be modest.  The gains for larger projects (particularly where the file count approaches 100,000’s) will be substantial.
• Scale improvements – Fixed out of memory problems on the server when operating on more than a few hundred thousand files at a time.
• Offline improvements – We’ve signficantly improved the experience going offline and integrated the tfpt online capability into the IDE for going back online.
• Extranet support for the TFS Proxy – allowing you to access a local TFS proxy with a different set of credentials than the TFS server.
• Command line help – You can now type “tf command /help” and get a console dump of the usage of that command.  This is much more convenient than always being launched into the richer GUI hypertext help when you just want to remember what the options for a command are.  You can still launch the GUI help by running “tf msdn”.  You can get a console dump of available commands by just typing “tf help”.
• Source Control Explorer refresh improvements – This includes less redrawing and reloading but even more important it enables updates based on changes made in other instances of TeamExploror or the command line.  That’s right, if you checkout a file from the command line, any instances of TeamExplorer you have running on the same machine will automatically refresh.
• Async loading of the Source Control Explorer (new)
• The SCE local path can now be selected and copied (new)
• Merge improvements (new) – Improved the logic that detects merge conflicts to generate fewer false positives and handle more scenarios.

Work Item Tracking

• Performance & Scale improvements – A variety of improvements that will make both the work item server and client faster and able to handle larger servers.
• Query builder usability improvements – Drop down filtering based on current project, better MRU lists, column drag & drop, shift-click mouse based multi-column sorting, etc.
• Attachments improvements – Save button, drag & drop for adding an attachment, multi-select for attaching files.
• Tooltips on field names contain the field name used for querying
• Server side support for deleting work items & work item types – We didn’t have time to do client UI support for it but we plan to release a Power Tool that will take advantage of the new server side feature.
• Support for security on the iteration hierarchy (new)

Web Access

• Adding Web Access UI to TFS – As you’ve seen many places, we acquired devBiz and their TeamPlain Web Access product.  We are releasing it as a Power Tool in the next few months and plan to release it as an official product in the Orcas timeframe.  We have not figured out how the release date will line up with the Orcas date but it will be in the same general timeframe.

Bug fixes

• In addition to all of the feature work, we’ve spent months testing the product and fixing any bugs we’ve found.  We expect Orcas will have even better stability and robustness than TFS 2005.

Compatibility (no change since last time)

As Orcas is an adoption focused release, we have put a lot of emphasis on compatibility with VS2005.  We are striving for near 100% compatibility.  The Orcas client will be able to work with a VS2005 server and a VS2005 client will be able to work with an Orcas server.  There are only a few compatibility issues.

• Client side VS add-ins will need to be recompiled (or have policy changed) because the TFS OM assembly versions will change and add-ins will need to bind to the new assemblies.  The APIs themselves are generally not changing, so we don’t expect much in the way of code changes – just recompilation.
• Build is the only area where we plan to have some compatibility disconnects.  In general, most build operations – listing build definitions, starting and stopping builds, examining build reports, etc. will work both with 2005 client -> Orcas server and Orcas client -> 2005 server.  However, here are a few caveats:

1. An Orcas TFS server will only work with an Orcas build server – so you’ll need to upgrade your build server when you upgrade your TFS server.
2. For an VS2005 client to start a build on an Orcas server, the build definition needs to be stored at $/<TeamProject>/TeamBuildTypes/<name>.  In Orcas, you have more flexibility as to where to put them.
3. Changes made to properties in the .proj file that are in the database in Orcas will not be updated in the database and will no longer be in sync.
4. VS2005 will be able to start a build, but it can’t queue a build, see the list of builds in the queue, see the list of build agents, etc.
5. An Orcas client will not be able to create a new build definition on a TFS2005 server.
6. When starting a build, an Orcas client will not be able to change any parameters in the dialog for a TFS2005 Server.

Brian