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.

Filename Collision - Another item with the same name exists on the server.

At one of our merges we encountered an error saying that there is a file collision and we could not complete the process. The error is raised when you are performing the check in after the merge. The merge itself passes with no error. It seem that it happens when 2 files/folders with the same name and location are added to both branches. While performing the merge the source branch treats the new item as a branch action to the destination branch which results in adding the file in the check in process. The merge process does not check if the file already exists and when you perform the check in you get the error and the only option to resolve it is to delete the local file (the file from the merge action). The problem is that we wanted the file from the merge source branch. To fix this we needed to delete the file in the destination branch (after performing undo pending changes for the merge) and than perform the merge again.