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.

Comments (11)

  1. Mark Brundieck says:

    Perhaps I’m also in the square peg – round hole group confused by "rename" being the equivalent of "move".

    In the example in your first paragraph, if the address is changed and the name (such as file1.cs) isn’t changed (such as to file2.cs) what is and isn’t affected by this? Would you see the file through windows explorer as "file2.cs", but when compiling it would be considered "file1.cs"?

    Also what would you use to rename the file name (and address) if you wouldn’t use "rename"?

    Thanks for the insight.

  2. Stuart says:

    To any unix person the equivalence of move and rename is decidedly old hat. Several decades old, in fact. As any unix user knows, the way you rename files is "mv"…

    Think of it this way: imagine you want to move a file and *also* change its name along the way. It’s perfectly natural, if you have a move command, to expect this to work:

    move folder1file1.cs folder2file2.cs

    (Perhaps some people actually would expect to have to use two separate steps to achieve this? I don’t know of any systems with commandline move tools that *do* require that, though)

    Now, if you can do that, what behavior would you expect if you do this:

    move folder1file1.cs folder1file2.cs

    That’s right, it "moves" the file to the same place it already was, with a new name.

    (I suppose you might expect that the move tool would complain that the source and destination folder are the same, but work with me here, okay? πŸ˜‰ )

    And if that works, why shouldn’t it work the same way if you leave off the folder name?

  3. AsbjornM says:

    In DOS (through int 21h, ah=17h, i used this in dos 3.2 with good sucess) you could rename an file to another location, which is the same as move.. :), well, if it was to the same drive..

    Anyway, in TF, will the history of the file record this rename/move?

  4. Its history is absolutely maintained along with any other pending changes that you check in to the repository at the same time. In fact, the "history" of a rename/move operation is maintained even before you commit it to the repository.

    Before you check in a rename operation (or any other pending change such as an edit, add, delete, or branch), you can see it in your workspace by using the tf status command. Any other user in the system with sufficient privileges (most users) can see that you have a pending change of type rename in your workspace from their client by using tf status /server:TeamFound1 /workspace:AsbjornM.

    It’s nice to hear from you again, Asbjorn. πŸ™‚ I hope you get a chance to pick up a copy of the November/December community drop of Visual Studio Team System and let us know what you think.

  5. AsbjornM says:

    Yepp, we have access to the drops at work, so I have tested the first Beta1, haven’t installed the refresh yet, but will soon.

    I found an page with some information about the new editions of vs.net, but it looked like the Team Foundation (IMHO the most interresting part) is an addon-product? and VSS is still the default?, hm, can’t quite find out if I liked that. πŸ™‚

    Anyhow, this time I’m back, also with an blog :), not much there yet, but someday…