TFS Version Control and more .. : Scenarios

I cannot see my workspace

mrod — Wed, 09 Jan 2008 23:51:03 GMT

In the past we have had some customers report an issue where when they open Visual Studio the workspace owner is to 'Administrator' instead of their logon user name and hence they cannot get to their workspace and continue their work.

Since it has happened more than once I decided to make a quick post so it gets indexed and hopefully people are able to find the answer without going into our forums or support.

The Problem

You don't see any of your workspaces and whenever you create a new one it is assigned to Administrator instead of your log on user name.

The Solution

Windows has functionality to store UserName and Passwords for servers in a cache and use those credentials when communicating with those servers. This cache can be found under:

Control Panel -> User Accounts ->Manage Passwords (XP)

Control Panel -> User Accounts -> User Accounts -> Manage Your Network Passwords (Vista)

The majority of the time our customer has an entry in there for their TFS Server indicating to use the Administrator account or some other alternate account. The way to fix it is to remove that entry from the list.

Here is what that UI looks like in Vista:

Here is a forum post that also details the scenario:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2502323&SiteID=1

Merge your renames at the root

mrod — Fri, 07 Dec 2007 23:33:58 GMT

True Rename, not those delete/add solutions, is one of those things that is extremely tricky to get right and even more on merge scenarios. Unfortunately, I have seen some of our customers struggle with them resulting in confusion within the organization and at times build breaks. For this reason, I wanted to write a quick blog post to outline one of those things about our product that "does not make sense" but it happens, which can get you in an inconsistent state and hence mad at us.

We will be working to find out how to solve this issue, but in the mean time please have as a good practice to always merge at the root.

The Scenario

A user, Bob, has a branch named MAIN
Bob branches MAIN to a folder called FEATURE1 for new development
Inside the MAIN branch Bob renames one of the files from foo.cs to bar.cs (you can do this at the folder level as well and it will still reproduce)
Bob then makes further edits on that file as time passes by
For some reason Bob has to merge the file back into FEATURE1 so he selects is and goes through the merge wizard
The merge is calculated and the edits are brought over but NOT the rename

The file inside FEATURE1 is still called foo.cs

The Problem

Well, now you ask why if the range includes the rename this is not bringing it over. What happens if something else is dependant on this new name?

Now there are reasons but at a high level I think we need to rethink our reasoning and see if we can handle this scenario better.

The Solution

The solution is simple, merge at the root. If you execute a merge between MAIN and FEATURE1 everything will work as you expect, and you get a conflict because for us all renames are conflicts. Go and select Merge Changes for Me and select the name you would like (bar.cs) and you have completed the merge.

Regardless of our logic we will always recommend our customers to merge renames and for that fact a lot of the changes at the root instead of executing it from an individual file, so please keep that as good practice.

Hopefully this saved you some headaches and if you see other things like this one let us know.

tfs workspaces and reinstalling the OS or TeamExplorer

mrod — Thu, 06 Dec 2007 01:55:22 GMT

In some enterprises and even inside of Microsoft we often partition our drives in two sections. The OS and often used applications (this is often our C: drive) and the data and enlistment section (this is often the D:/ drive)

Recently, I received a question about what happens to the tf workspace cache when I reimage my OS drive and how I can get it repopulated again. Before we answer the question I think there is one core set of steps and then three scenarios on top of that which result in different actions from the user at the end.

Scenario1

the user has a need to re-image or reinstall the Operating System on this box
the OS is reinstalled by the user, the machine name is kept
the user then install Visual Studio and TFS once again
the user connects to the server

In this case, there is nothing you have to do as a user. The workspace cache file will be regenerated automatically

Scenario 2

As part of the new OS install I actually changed my computer name. I reinstalled Visual Studio and the Team Explorer.

Well in this case you do have to tell TFS version control that the machine name for this workspace has been changed. To do this you follow the documented syntax from msdn.

tf workspaces [/owner:ownername] [/computer:computername] [/server:servername] [/format:(brief|detailed)] [/updateUserName:oldUserName] [/updateComputerName:oldComputerName]

The command to execute is:

tf workspaces /server:servername /updateComputerName:oldcomputername

Scenario 3

I reinstalled the OS and only team explorer so Visual Studio is not installed and I use the command line so no UI please

This is different from the first scenario because there is no UI that is triggering an automatic regeneration of the client cache file. In this case you need to force that to happen. For this will we again use the workspaces command. The syntax is:

tf workspaces /server:servername

There you have it ! How to reuse your workspace after a reinstalled.