tf.exe Rename==tf.exe Move in Visual Studio Team Foundation
When you use the Team Foundation tf rename command to rename a source-controlled file in your local workspace, you change its address, not its name. If you rename file1.cs to file2.cs, you implicitly change its address from c:\folder\file1.cs to c:\folder\file2.cs.
So what happens if you rename the folder part of an address to an existing repository folder rather than renaming the file? Example:
tf rename c:\queue\file1.cs c:\projects\file1.cs*
Note This example uses local, workspace paths but repository paths such as $/queue/file1.cs are also accepted.
This example uses the tf rename command to move file1.cs from the queue folder to project folder in your workspace and when you check in the change from your workspace, the move will be committed to the repository as well. That, my friends, is why there is no move command in Visual Studio Team Foundation: the move command isn't needed because the rename command does it all.
For folks like me who just don’t get it (square peg (rename)...round hole (move)...pound), the Hatteras team was kind enough to provide a move alias for the rename command. Thus, tf rename c:\folder\file1.cs c:\projects\file1.cs can also be written as tf move c:\folder\file1.cs c:\project\file1.cs.
The rename command has one option, /Lock, which locks both the source namespace ($/folder/file1.cs) and the destination namespace ($/project/file1.cs) and thereby prevents other users from modifying the item until you check in the pending rename and unlock it. For more about locks, see Team Foundation vs. SourceSafe | Locking vs Exclusive Checkouts.
++++++++++++++++++++
*In the second Community Technology Preview, which is due out in November and is MUCH better than the first, tf.exe does not exist. Instead, use h.exe. The 'h' stands for Hatteras.
