tf get /remap

This switch was added to "tf get" to improve performance when a user is switching an existing workspace from one branch to another. The performance benefit is best explained with an example.

Let's say that in our Team Project Collection we have one Team Project ($/Proj), and two branches -- $/Proj/Main and $/Proj/Dev. And let's also say that we have a workspace which maps $/Proj/Main to C:\MyWorkspace. Our source tree is pretty small -- we only have 5 files, named a.cs through e.cs. I've done a get, and so when I look in C:\MyWorkspace, this is what I see:

C:\MyWorkspace>dir
Volume in drive C is Physical Disk 1
Volume Serial Number is BA8F-FF44

Directory of C:\MyWorkspace

05/18/2012 01:41 PM <DIR> .
05/18/2012 01:41 PM <DIR> ..
05/18/2012 01:41 PM 14 a.cs
05/18/2012 01:41 PM 54 b.cs
05/18/2012 01:41 PM 5 c.cs
05/18/2012 01:41 PM 115 d.cs
05/18/2012 01:41 PM 17 e.cs
5 File(s) 205 bytes
2 Dir(s) 60,134,879,232 bytes free

Let's also say that my co-worker, John, has made a change in the Dev branch to c.cs. He's really added a big chunk of code in the Dev branch, and so the c.cs file there is much bigger. But he hasn't changed any of the other four files. The other four files are exactly the same in Dev and Main.

Furthermore, for some reason (maybe John and I need to work more closely together now) I need to switch my workspace from mapping the Main branch to having the Dev branch. The way I would do this is through the "tf workspace" dialog.

Change the server path mapping only, from $/Proj/Main to $/Proj/Dev. Leave the local path part (C:\MyWorkspace) the same.

When you click OK, you'll be prompted to do a get.

If I say yes, a regular get will be performed, and everything will work fine -- but the get will be inefficient. Let's watch what happens when I click yes.

C:\:
Getting MyWorkspace
Deleting C:\MyWorkspace\a.cs

C:\MyWorkspace:
Getting a.cs
Deleting C:\MyWorkspace\b.cs
Getting b.cs
Deleting C:\MyWorkspace\c.cs
Getting c.cs
Deleting C:\MyWorkspace\d.cs
Getting d.cs
Deleting C:\MyWorkspace\e.cs
Getting e.cs

Each item is deleted and re-downloaded as part of the switch from $/Proj/Main to $/Proj/Dev. Even the four items that are identical in the two branches are redownloaded, which is not a good use of time.

Let's look at what would have happened if I had said "no" to the dialog, and then run a "tf get /remap".

C:\MyWorkspace>tf get /remap
Deleting C:\MyWorkspace\c.cs
C:\MyWorkspace:
Getting c.cs

You can see that no action was taken for the four items which are identical. As a result no time was expended downloading these four items unnecessarily.

Why not run “tf get /remap” all the time? Nothing bad would happen if you were to do so. However, adding the /remap switch does increase the amount of work done by the server to process your request. As a result, it is not on by default.

Comments

• Anonymous
  September 03, 2013
  Phil, why not make "/remap" the default when you hit yes on this dialog? By definition, you've changed the workspace. It would still be off by default for 99% of gets, when you have not changed the workspace.