On Sunday I already enjoyed a full day of interesting MVP to MVP sessions and I do want to highlight one particular session from Sven Hubert, a German Visual Studio ALM MVP. He did a nice talk on extended dependency management with Team Foundation Server. Many of us will certainly have been in the situation where a custom solution was required to manage internal/external dependencies, but this type of automated solution really rocks. Be sure to check out his blog article where he described his solution to manage dependencies with Team Foundation Server. If you understand German, you might also want to have a peek at the AIT TFS blog.

The other days were filled with a bunch of interesting sessions about the (near) future of Microsoft’s ALM offering, given by the ALM/TFS product team. Good to see that the people at Microsoft are really listening to the customer/community feedback. They are also extremely passionate about the new features they want to introduce in the product. I had a blast to be part in this gathering at Microsoft and made a few extra important connections.

Meanwhile, a few important releases have been made:

• Release of new TFS Power Tools
• Release of new Load Testing Feature Pack which brings unlimited load testing for MSDN Subscriptions with Visual Studio Ultimate.
• Release of VS/TFS 2010 Service Pack 1
• Release of TFS Project Server Integration Feature Pack

A few Visual Studio ALM MVPs and Microsoft people have been working hard to publish new ALM books:

• Software Testing with Visual Studio 2010 (Jeff Levinson)
• Inside the Microsoft Build Engine (Sayed Ibrahim Hashimi, William Bartholomew)
• Professional Team Foundation Server 2010 (Ed Blankenship, Martin Woodward, Grant Holliday, Brian Keller)
• Agile Software Engineering with Visual Studio (Sam Guckenheimer, Neno Loje)

Really exciting times to be involved in the ALM space!

At a customer where I made use of the TFS2010 Backup/Restore Power Tool we ran into the (known) timeout issue during a TFS Backup execution.

Active backup plan configuration: full backup each week, differential backup each day, transactional backup each 30 minutes.

The timeout (600 seconds) was caused by very big transactional log files (> 15 GB) that couldn’t be stored in time to the backup location. No matter what backup plan configuration you choose, the transactional log files of all TFS databases are continuously growing because the recovery mode of the TFS databases is set to "Full". To keep it short here, the Full recovery mode is used because it provides greater protection for data than the Simple recovery model. It relies on backing up the transaction log to provide full recoverability and to prevent work loss in the broadest range of failure scenarios. More details on SQL Server recovery modes can be found here.

As a quick fix, I changed the recovery mode of the involved databases from Full to Simple and shrunk the log files. After that I switched the recovery mode back to Full. But the issue with the growing transactional log files (+ timeout) will continue to pop up in the (near) future …

So, I was thinking about setting the recovery mode of the TFS databases to Simple permanently and switching to a nightly full backup each day. I assumed that we will always be able to do a restore to one of those full backups (maximum loss of data = 1 day) … No! Just don’t do this! The Backup/Restore Power Tool relies on SQL marked transactions to keep consistency across the TFS (and dependency products) databases. The SQL marked transaction implementation in the Backup/Restore Power Tool requires the SQL recovery mode to be set to Full. Thanks to the TFS product team for making this clear to me! Switching permanently to a Simple recovery mode could possibly result in a rollback to inconsistent TFS databases. More details on marked transactions can be found here.

A temporary solution is to manually switch to Simple recovery mode, shrink the log files and then switch back to Full recovery mode. The problem is that you would need to do this sometimes when the log files are getting "too big". A better solution might be to automate and schedule these actions for all involved TFS databases.

Here’s a sample SQL script that you might use:

ALTER DATABASE [<DatabaseName>] SET RECOVERY SIMPLE WITH NO_WAIT

USE [<DatabaseName>]

GO

DBCC SHRINKFILE (N’<DatabaseName>_log’ , 0, TRUNCATEONLY)

GO

ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL WITH NO_WAIT

Timeout issues + log file sizes will be fixed in the next TFS Power Tool release (probably Q1 2011).

[Update March 13, 2011]

With the release of the new TFS Power Tools (March 2011), the timeout issue has been resolved. Note that you must not forget to disable the workaround script to shrink the logfiles.

Your local workspace may not contain pending changes on files that are included in the shelveset. However, there is a way to unshelve with local pending changes. Therefore, you need to have the Power Tools installed for Team Foundation Server.

From the command-line you can execute the tfpt unshelve command with the name of the shelveset to accomplish that.

tfpt unshelve allows a shelveset to be unshelved into a workspace with pending changes. Merges content between local and shelved changes. Allows migration of shelved changes from one branch into another by rewriting server paths.

Like in a normal get latest scenario, you will be asked to resolve conflicts and eventually be redirected to the well known TFS merge window.

The Visual Studio Team System 2008 Team Foundation Server Power Tools is a set of enhancements, tools and command line utilities that improve the Team Foundation Server 2008 experience.

3 major new components are included in this release :

• Team Members
• Windows Shell Extension
• PowerShell Support

Read more about this release on the blog of Brian Harry.

Download the release here.