Team System

A Visual Guide to Backing Up a Team Foundation Server database

Microsoft's How to: Back Up a Team Foundation Server is a great resource, but there's so much of that tedious reading. For the truly lazy, here's a quick visual guide to backing up your TFS databases:

First, launch SQL Server Management Studio. Within the treeview on the left, expand the Management node and right click on the Maintenance Plan folder.

Give the backup a good name and description, so we can remember it later.

We're going for a plain vanilla full backup.

Select the Team Foundation Server databases. If you have a dedicated SQL Server instance, it's everything except master, model, and msdb. The full list of tables is available in the MSDN article.

I chose to do this on demand, but you could easily set up a daily or weekly backup schedule if you so desired.

After you complete the wizard, the new maintenance plan entry will appear as expected. Right click it and select Execute to run it.

Here's the result of a run I did on a new TFS install; this is using the default paths:

And there you have it. Stay tuned for my next post: restoring Team Foundation Server databases! Same bat-time, same bat-.. er.. blog!

Team System and Sarbanes-Oxley compliance

Vertigo is in the midst of writing a short whitepaper on how Team System can help public companies achieve Sarbanes-Oxley compliance.

Vertigo is uniquely positioned to write a whitepaper like this, because we have a lawyer, a CPA, and a MBA on our Team System "team". I don't have any TLAs* attached to my title, but I'm tagging along for the ride anyway.

However, before we start, we want to make sure we're addressing the most frequently asked questions about Sarbanes-Oxley and Team System.

All of this is a roundabout way of saying I need your help. If you, or your company, have any specific Sarbanes-Oxley questions that you would like the whitepaper to address, please email me directly at jatwood@vertigosoftware.com

Thanks!

* Three Letter Acronyms

Team Explorer now available for free download!

Microsoft launched CodePlex last week, their free, hosted Team Foundation Server site for open or shared source development. That's fantastic news, and it beats the pants off gotdotnet, which has been fraught with problems for years.

But the most exciting part of this announcement is that Team Explorer, the essential client-side piece of Team System that installs as a Visual Studio 2005 add-in, is now available for free download! That's insanely great news! It certainly makes hosting your project on CodePlex a no-brainer. If you already have a Team Edition installed, here's how to connect to CodePlex right now.

Now if only Microsoft would make Team Foundation Server available for free. Ok, ok, there's always the 180-day trial edition and the Cliff's Notes install guide.

Why doesn't check out also get latest?

Dave just asked me why Team System doesn't provide an option to get latest along with every checkout. As I mentioned in an earlier post, the problem is partly one of terminology-- "check out" doesn't really mean Check Out in Team System source control. It means "make editable".

There might be some expectations set here by Visual SourceSafe, too, which has a very different lock-modify-unlock model of checkout. Yet another unfortunate way that Visual SourceSafe poisons the mind of developers. ;)

Terminology aside, it's questionable whether you would really want to get the latest version of the files at the time of your edit, as Doug Neumann points out:

It turns out that [not getting latest] is by design, so let me explain the reasoning behind it. When you perform a get operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control. Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that are known to work together, and therefore is buildable and testable.

As a developer working in a workspace, you are isolated from the changes being made by other developers. You control when you want to accept changes from other developers by performing a get operation as appropriate. Ideally when you do this, you'll update the entire configuration of source, and not just one or two files. Why? Because changes in one file typically depend on corresponding changes to other files, and you need to ensure that you've still got a consistent snapshot of source that is buildable and testable.

This is why the checkout operation doesn't perform a get latest on the files being checked out. Updating that one file being checked out would violate the consistent snapshot philosophy and could result in a configuration of source that isn't buildable and testable. As an alternative, Team Foundation forces users to perform the get latest operation at some point before they checkin their changes. That's why if you attempt to checkin your changes, and you don't have the latest copy, you'll be prompted with the resolve conflicts dialog.

To make things even more confusing, the meaning of the term "checkout" differs quite a bit across source control systems. Martin Woodward has a nice post (with fancy illustrations!) explaining the differences:

Internally in Teamprise, we have been having a lot of discussions about check-in and check-out in Team System and how to explain this concept to our end users. The problem is that the terms are overloaded depending on the source control system that you come from. In Visual Source Safe (VSS) or PVCS, check-out means “give me the latest version of the file and lock it so that no-one else can edit it”. In CVS and subversion, checkout means “get the latest version”. If you are using the source control features in Team System then checkout means “Tell the server I want to edit this file and mark that file as writeable in my file system”, at the same time that you check-out the file you also get an option to lock the file using one of three lock types (none, check-out and check-in).

In general, it's a good idea to periodically do a Get Latest operation with Team System. But you control when the integration occurs, not the source control system.

Source Control: Not Just For Source Code Any More!

Mike Gunderloy, of Daily Grind fame, published an interesting article on alternative uses for source control. Sure, you could put source code in there, but why stop there? How about..

• tools
• documentation
• specs
• backups
• deployment maps

Mike also suggests that a part of your source control system could be public, depending on how transparent you want to be.

Interesting food for thought. Some people try to keep their entire lives under source control.

Comparing SourceSafe Labels to Team Foundation Server Labels

A colleague recently asked me how to find labels in Team System. I never used labels much, even in the bad old days of SourceSafe, so I did some exploring. What's a label?

A label is a marker that you can attach selectively to a set of otherwise unrelated files and folders in your source control server to facilitate their collective retrieval to a workspace for either development or build purposes.

To add a label, right click a file or folder in Team Explorer and choose the Apply Label command. That results in the following dialog:

Once you've applied the label, it's hard to find them again in the UI. Try File, Source Control, Label, Find Label:

If you're used to the Visual SourceSafe label model, you may be in for a shock-- Team System labels are very different animals. Brian Harry elaborates:

The difference with SourceSafe is that [labels] are not included in the history. There’s a good reason for this. Labels in SourceSafe were always “point in time” labels. You generally labeled some tree at some point in time and that implied a label of all of the contents of the tree at the same point in time. In this respect it is reasonable to display labels in time sequence with history. Everything before it in the list is in the label and everything after it is not. This works for a significant percentage of label uses (and is a convenient way to think of them) but not all.

In Team Foundation, labels are more powerful. Instead of being a single point in time, they are able to have versions of each file in the label from different points in time. The canonical scenario is that you label a build and then find some bugs and want to go back change the versions of a few of the files (either omitting changes that introduced bugs or adding changes that fixed bugs). Now the label does not represent a point in time, but rather a collection of points in time. This makes it very hard to display it in a list mixed with change sets because there is not “correct” ordering of the list. As a result, [in Team Foundation Server] we treat the list of changesets and the list of labels separately.

In other words, Team System labels represent a specific set of files at a specific version-- but nothing else.

Deleting Team Build Types and Team Builds

In the process of my Team System testing, I ended up with a bunch of unnecessary team build types (and corresponding builds for each type) in the Team Explorer for our Demo project. Unfortunately, there's no obvious way to delete these! I found this forum thread which describes how to remove both.

First, map the TeamBuildTypes folder into your workspace. You can access your workspace via the File, Source Control, Workspaces menu:

Once you've mapped the folder, bring up the source control explorer, expand the new folder, and start deleting the folders that correspond to each build type:

Commit your delete and you'll remove the build types. But what about the builds themselves? Unfortunately, you'll have to delete each individual build manually via the tfsbuild command line tool:

C:\>tfsbuild delete http://teamsystem:8080/ demo test3_20060127.1
Microsoft (R) TfsBuild Version 8.0.0.0
for Microsoft (R) Visual Studio 2005 Team System
(C) Copyright 2006 Microsoft Corporation. All rights reserved.

All data including test results and the build for test3_20060127.1 will be permanently
 deleted. Do you want to continue (Y/N)?y
Deleting test3_20060127.1... Done
TF42047: The build data was deleted. The drop location
\\wumpus\public\test3_20060127.1
does not exist or is inaccessible and could not be deleted.

(You can ignore the above error for the drop location, as that data was previously deleted long ago.)

The process is a little tedious, but now all traces of the demo builds are gone.