There was a problem importing the global list: TF26204: The account you entered is not recognized.

If you got the error "There was a problem importing the global list: TF26204: The account
you entered is not recognized." while trying to import a global list file then probably one of the items in the lists contain backslash and TFS considers this value as a user name... I got this while entering the value 800\40. Funny!

Deleting work item in TFS 2010

After the release of TFS 2010 power tools I have noticed that the command destroywi that is used for deleting work items was removed. Searching the Visual Studio installation directory I found a new command line utility called witadmin.exe. This new tool hosts all the known work item management commands like import, export... To delete work items you use the same command as in the power tools with the work items id as a parameter:
Example: witadmin destroywi 10

TFS 2010 Beta 2 - Back in business

Just installed TFS 2010 beta 2. Good to be back.

Convert a Physical Machine to a Virtual Machine

You probably know Norton Ghost as a great tool to backup your machine state so you could restore it if needed from a backup. Norton actually saves an exact image of your HDD and enables you to restore it even to another physical machine.
What if you want to backup your machine and open it using VMWare without having to restore it to another physical machine?
VMWare support opening a Norton Ghost image so you could use this to restore a machine. VMWare also supports converting a physical machine to a virtual machine and enables you to backup and duplicate a machine in few simple steps.

What do you need?

VMWare vCenter Converter Standalone - A free tool that will convert your physical machine.
VMWare Workstation/VMWare Player - to open the machine. VMWare Player is a free tool.

How to do it?

Install VMWare vCenter Converter Standalone. Select "Local installation" in the "Setup Type" form.

Run the tool.

Press the "Convert Machine" button. A wizard will be opened. In the "Specify Source" tab select "This local machine" in the "Specify the powered-on machine" radio group.
Press the "Next" button.


In the "Specify Destination" select "VMWare Workstation or other VMWare virtual machine" in the "Select destination type" combo box. After that specify the VMWare product, give the machine a name and choose a location to save it.
Press the "Next" button.

In the "View/Edit Options" tab you can review and fix warnings regarding the conversion, edit the machine settings and define which HDD to convert.
Press the "Next Button".

In the "Ready to Complete" tab review you settings. When completed press the "Finish" button.

The wizard will be closed. In the main window a task will be added to the list and the conversion will start. You can track the status in this window.
After the conversion is finished you can open the machine using VMWare Workstation or Player. Please notice that to actually continue working with the machine you will probably have to re-activate it.

Shelveset as a Backup

Long time since I posted. Been busy (implementing TFS), long vacation and a new work place.
In the last implementation I did I have noticed that in some cases users work in a network drive that is always backed up by IT. This is a good solution for backing up your workspace without checking in your pending changes (like we used to do when we worked with SourceSafe...) or performing a shelve for backup purpose. I thought it would be nice to share the idea of automatic backup shelves with those of you that work locally without any automatic backup. When you shelve your pending changes the shelve is saved in PendingChange table. The pending changes will be removed from the table when you delete or replace the shelveset. So to perform an automatic backup of your workspace that does not overload your TFS database you can add a schedule task that will run the following command:
tf shelve {workspace name} /replace /noprompt
Remeber to set the current folder to the workspace local path before executing the command.
Enjoy.

VersionControlPath - Class to Manipulate Version Control Items Path

I was navigating through TFS assemblies and I found out a static class that I wasn't aware of: Microsoft.TeamFoundation.VersionControl.Common.VersionControlPath. This class contains functions that help manipulating version control items path. It is like the System.IO.Path class. Here are some of the methods in the class:

• GetFileName
• GetExtension
• GetFolderDepth
• Combine
• GetFolderName
• ValidatePath

Very useful.

No matching items found in {0} at the specified version

I recently got this error while trying to create a branch from that its parent was renamed.

Here's an example of what happened:

1. A branch was created at: $/Project/Folder1/Branch1.
   
2. Some work has been done on Branch1 so its history contained several change sets.
   
3. Folder1 was renamed to Folder2 ($/Project/Folder2/Branch1).
   
4. A branch operation failed while trying to create one from a change set before the rename operation with the error: "No matching items found in $/Project/Folder2/Branch1" (A branch operation on a change set created later than the rename operation will succeed).
   

I thought that the rename operation has broken the branch history. Looking at the branch dialog I saw that the source branch text box is read only and I thought to myself what would have happen if I had changed the source from $/Project/Folder2/Branch1 to $/Project/Folder1/Branch1. It was time for some coding…

private void PerformBranch(string server, string workspaceName, string userName, string changesetId, string sourceBranch, string targetBranch)

{
TeamFoundationServer tfs = new TeamFoundationServer(server);
VersionControlServer vcs = tfs.GetService(typeof(VersionControlServer)) as VersionControlServer;
Workspace workspace = vcs.GetWorkspace(server, userName);
VersionSpec versionSpec = VersionSpec.ParseSingleSpec(changesetId, userName);
workspace.PendBranch(sourceBranch, targetBranch, versionSpec);
}

This method has fixed the problem and after running it with the old branch path (source = $/Project/Folder1/Branch1), pending changes were waiting for check in.