Sunder Raman, a program manager for TFS, has written a series of posts on the changes to the warehouse and the cube for 2010.
Reporting
Cube
John Socha-Leialoha, a developer on TFS, wrote a series on upgrading your reports.
If you are interested in writing your own warehouse adapter, you’ll find the sample adapter in the SDK to be very helpful.
If you have any questions about these topics, please contact Sunder and John.
Enjoy!
Taylor Lafrinere, a developer on Team Foundation Server who wrote a significant part of the new core server infrastructure APIs, has written a series of posts explaining some of the different parts. If you have other parts of the API that you are interested in, be sure to leave a comment on one of his posts.
Here are a few of his posts to get you started.
Years ago, I posted an msbuild task to run tests without test lists for VSTS 2005. That functionality made it into VSTS 2008. Then Pierre Greborio added support for test categories. That test category capability is now available in VS 2010. Using test categories is now the preferred way of running groups of tests, and you no longer need to deal with tests lists (.vsmdi files), which are tedious to maintain and very difficult to merge.
Here’s the documentation on MSDN to show you how to make use of test categories in the 2010 release.
Defining Test Categories to Group Your Tests If you have created automated tests using Microsoft Visual Studio 2010, you can manage these tests by categorizing them with test categories. When you run these automated tests using Visual Studio, Team Foundation Build, or mstest.exe, you can use these test categories to easily select which tests you run. You add test categories as attributes to your test methods. Test categories provide more flexibility than the test lists functionality from earlier versions of Microsoft Visual Studio. You can use logical operators with test categories to run tests from multiple categories together or to limit the tests that you run to tests that belong to multiple categories. Also test categories are easy to add as you create your test methods and you do not have to maintain test lists after you have created your test methods. By using test categories, you do not have to check in and check out the <solution name>.vsmdi file that maintains the test lists. more…
Defining Test Categories to Group Your Tests
If you have created automated tests using Microsoft Visual Studio 2010, you can manage these tests by categorizing them with test categories. When you run these automated tests using Visual Studio, Team Foundation Build, or mstest.exe, you can use these test categories to easily select which tests you run. You add test categories as attributes to your test methods.
Test categories provide more flexibility than the test lists functionality from earlier versions of Microsoft Visual Studio. You can use logical operators with test categories to run tests from multiple categories together or to limit the tests that you run to tests that belong to multiple categories. Also test categories are easy to add as you create your test methods and you do not have to maintain test lists after you have created your test methods. By using test categories, you do not have to check in and check out the <solution name>.vsmdi file that maintains the test lists.
more…
UPDATE [6/12/2010] The patch is now available on MSDN Code Gallery here. You must install it after you complete the MSI setup portion (the files need to be on the machine and registered in Windows first) and before the upgrade wizard (it’s the upgrade process, not setup that needs to be patched).
--
We discovered a couple of bugs in version control when upgrading to TFS 2010. They affect labels and future merges, and whether or not you are affected depends on what renames you have done on files in labels and branches. We are currently testing a fix that we expect to release shortly. The fix, when released, must be installed before upgrading to TFS 2010.
The issues are described in a KB article, which Matt published today. Here are the symptoms that manifest after an upgrade without the fix.
If you’ve already upgraded to 2010 from a previous release, you’ll need to decide whether there are labels that are critical for you. If there are, fixing the label problem after an upgrade without the fix will likely require access to the original version control database prior to the upgrade. You’ll need to contact customer support to get help with fixing the affected labels (customer support will not charge for incidents related to this upgrade bug).
The merge issue is simpler to recover from, and it’s largely an annoyance. You can read the KB article to understand what must happen. The fix for the issue of merge targets not showing up in the merge wizard is to do a non-recursive baseless merge of the source to the target via the command line (e.g., tf merge /baseless dirA dirB). Then the target will show. The children will end up being baselessly merged, which will be annoying and tedious, but you will be able to recover and move forward.
The underlying cause of both problems is the handling of renames during the upgrade, as described by the KB article. In TFS 2010, we changed the schema of version control to change something called an item ID to effectively become a path ID. In both 2005 and 2008, every item added or branched in version control got a unique item ID forever. So no matter what name or path changed to, the item ID never changed. This allowed for completely tracking renames forever, no matter how complex. However, it came at the price of introducing the confusing concept of a deletion ID, since a path could have more than one item at a time if there were at least one deleted item, and the concept of a namespace conflict, which occurs when two different non-deleted items (each has a different item ID in 2005/2008) tried to occupy the same path at the same time. If you’ve ever had to resolve namespace conflicts in 2005 or 2008, particularly as a result of a merge, you know the pain I’m talking about. It also resulted in significant complication of the SQL, resulting in lower performance and scalability than otherwise would have been possible.
So, we changed the schema such that a path uniquely identifies an item, turning the item ID into a path ID. Matt talks about some of the implications of that in his post, Changing to Slot Mode in TFS 2010 Version Control. Having used the server with the schema change for more than a year now internally, the change produced a faster, more scalable version control server, and the elimination of things like namespace conflicts has made merging less painful.