I have played a little with MS Access 2007, verifying that it's working with TFS Msscci 2008. In order to get SCC integration, you need to install Access Developer Extension - a add-in that allows Access to use any Msscci provider (and a few other goodies).

Access does not allow you to change SCC provider, so if you have installed a few of them on your machine, you may check my other blog post: http://blogs.msdn.com/michalma/archive/2006/03/01/541255.aspx

Everything seems to be working just fine - you can add tables, forms and queries to TFS, display History, Properties etc. The Source Control toolbar looks really cool.

The unfortunate problem, which we plan to fix in the next release of TFS Msscci is the fact that Access (the same way as VB6) verifies if item is checked out by somebody else, before allowing user to perform checkout. The problem is that we tell that file is checked out even if the pending change exists only in the shelveset, not in the actual workspace. This makes using Access and shelvesets in the same time very hard.

Brian published a few screen shots of tools that we are working on right now for the next major release of TFS (not SP1). The Branch Visualization (Scenario 2 and 3) are amazing but right now my personal favorite is improved history (Scenario 1). While working on my feature I was doing some forward merges and resolving conflicts (fun, fun, fun ;)). Being able to display history and track the changes in time to understand why a line of code changed in the way it did would be invaluable. Unfortunately it's utilizing new server calls so chances for powertool including this functional are smaaaaal.

"Check-in does not check-in". One of the most feared complains from the users. We all check-in files every day (or not, when gauntlet is in use ;)) and everything works fine.But customers are always right (vide Get Latest on Checkout)! So one theory explaining this phenomena say that user encounters conflicts doing check-in.He resolves the conflicts and expects that when Resolve Dialog disappears the files will be checked-in. This is very far from the truth - he needs to try checking in the files again himself.

Why we don't make his life easier by re-attempting to check-in files automatically? Whel, resolving conflicts most probably will change content of the files. Before doing check-in user should at least build sources again to avoid build breaks.

So what we improved in Orcas? It's very psychological feature :)  - Resolve Dialog contains label that inform user that check-in failed. Also, when Check-in Dialog is closed we show extra message box, telling user again that he need to try checking-in files again.

After Orcas shipped, many people blogged about new big features that were included there (http://blogs.msdn.com/jeffbe/archive/2007/11/19/visual-studio-team-system-2008-ships.aspx). However, there are also many small improvements, transparent at first to the user, but still allowing him to save time and avoid confusion.This blog post (and at leat one more) is dedicated to those invisible heroes of our day-to-day life :)

Consider workspace mappings. Usually we even don't want to be aware of there existence. Let's just set them (the best is single mapping for whole tree) and forget. Unfortunately sometimes it's not that easy. You work with a project and then you see typo in the local path. Or you have more complex mappings, and you mix to branches in the single workspace. So you type "tf workspace", edit mappings and click OK. The MessageBox is displayed that tells you to perform get in the workspace. If you are in the command line, it's possible that you will do it - it's just "tf get" and you are advanced if you use command line, right ? If you did this in Visual Studio, it's less likely - there is no GET button anywhere. Besides doing get on the whole workspace is really nontrivial - I learnt just recently that you do it by selecting root node in SCE and clicking Get Latest. So you don't do get, the mappings were updated and your files are in the not mapped location, but tfs is aware of them and just waits to move them, as soon as somebody calls get (Most likely surprising the user).

So what we do in Orcas? Very simple - as soon as you changed your mappings, we ask you if you want to do "Get Latest" instead of just warning you. Click Yes and life will be a little safer for you. Just to keep in mind - we will do "Get Latest" so if somebody checked in some changes and you are not ready to get them into your workspace, you probably want to reject doing "Get Latest", and instead sync to changeset that was before those breaking changes.
 

Because we are preparing Beta2 of Orcas, I started spending more and more time with the debugger and with tracing enabled in our OM (vide: http://blogs.msdn.com/michalma/archive/2006/12/08/tracing-in-tfs-msscci-provider.aspx). As we all know there are 2 listeners we usually use - file listeners, that dumps everything into file and perf listener that pops up cool dialog, but lacks details. You can imagine my surprise when I discovered that just by attaching the debugger to the running app, we add yet another listener - one that dumps everything into Output Window in VS. It's very cool, because while stepping through the code we can immediately see what kind of server calls where made. At first I wasn't sure if this is not some kind of magic Buck put into our OM. But no - even in the simplest application, when you put

Trace.TraceInformation("Hola Mundo!");

it will be written in the Output Window. Cool :) 

We recently discovered new IDE that works with TFS Msscci provider (well, almost ;) - eMbedded C++ 4. The only problem is that it displays often "Server Busy" message while doing SCC operations. The solution for this (until release of the new provider) is to create registry file (evc4fix.reg) with the following content:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider\Settings\Microsoft eMbedded Visual C++]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider\Settings\Microsoft eMbedded Visual C++\EVC.EXE]
"issues"=dword:00000011

Then run it. After the registry was updated, start eMbedded C++ 4 and enjoy source control with TFS :)

As Brian writes in his blog we released new version of TFS Msscci Provider. Nice improvements are fixes in the property (displaying local path) and checkin (saving the work items query list between the calls) dialog. We have also changed the provider in order to support Toad.

However the biggest change is supporting branched solutions in VS2003. Basically it means that now, after the solution was branched on the server, VS2003 should perform "Open from SCC" with no problems (in the previous versions it would still reference the original branch and mess with your workspace mappings). There are a few gotchas when playing with the branched solutions:

• As Brian writes, you need to do "Open from SCC" in order to get solution into your local workspace, you cannot download the files manually (using tf.exe or SCE) and open it directly from the disk. However this is the same behavior as SourceSafe and other msscci providers, so I hope it will not be confusing for the users.
• As we write in the readme (which I'm sure everybody reads before using the provider :) solutions which were bound to source control using old TFS Msscci Provider will need to be rebound.
• Opening from source control multi-rooted solutions can be challenging. Web projects are always referencing the original branch and unfortunately we don't see a way to change this. To fix it, you need to perform the following steps:
• Check out the branched sln file (using Team Explorer or command line) before you do Open from SCC in VS2003
• Manually fix SccPorjectName field which references the main branch
• Check in the file
• Opening multi-rooted a solution which has normal projects (not web projects) outside of the solution root will change the workspace mapping because VS2003 will create common root and the structure on the disk will not be the same as structure on the server. You can fix the workspace mappings manually after the "Open from SCC".

 I hope that these scenarios are rare enough that it will not bother you often :).

 Update 03/28/2008

One more scenario when project can still reference the original branch, is when somebody (or something) adds to source control the "mssccprj.scc" files. Those files are created during "Open from Scc" and they contain binding information. They should be local only, so every time user creates new project, downloading in from different branch, the mssccprj.scc will contain correct server path. If you already checked in those files, please delete them from SCC in all branches (by pending delete and then checking in the change), sync the workspaces, and perform "Open from Scc" operation again to recreate mssccprj.scc files on the disk.