Last week I was in Seattle for the MVP Summit where I was one of the present 78 Visual Studio ALM MVPs to explore the future of the Application Lifecycle Management platform.

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.

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.

You might already have been in the situation where you wanted to unshelve a stored shelveset when having local changes to files that were also changed in the stored shelveset. Out-of-the-box with TFS 2008, this is not possible and you will get the following error dialog :

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.