Team Foundation Server - moving a source with a story

Question

I was wondering what the best approach might be when moving source code with history from one Team Project to another Team Project. I'm not interested in work items, reports, or SharePoint sites because the system we are about to restore did not use these features. The reason for the desire to move to another Team project is also due to the fact that the initial implementation (being restored from a backup that was supported by a third party) used a third-party process template, which we do not want to use to go forward. We want to start using work item tracking and reporting after the migration is complete.

The TFS Integration Platform seems to be one of the likely scenarios. It can be used to modify the process template in accordance with the documentation. However, I was curious if the tf.exe move syntax could work? Something like:

tf.exe move $ / ProjectA $ / ProjectB

As far as I understand, this command works the same as the rename operation, while moving using the "Move" context menu in the "Source Control" is more like a delete and add operation. Also, will the tf.exe move path actually associate the code under the folders with the corresponding Team Project, assuming that $ / ProjectA is the root source control folder for one project and $ / ProjectB is the root source control folder for another? The key should be able to keep a story, if possible.

We will be grateful for any advice or advice!

Change Can branching to another project handle this scenario - as Microsoft discusses branching the manual in the documentation? I think this may be the answer, as the story is likely to persist with the branch. However, at the moment I do not have access to an instance of Team Foundation Server 2008 to verify it.

Answer 1

Moving and renaming are aliases. In any version of TFS, there is no difference from the command line or user interface.

Both keep a story. At least in 2005/2008, you keep the same physical element in the VersionedItem table no matter how often or how much the name and / or parent path changes. There is really no way to get a “fake” rename (delete + add) without a lot of manual work on your part.

However, although this version model is very pure in a theoretical sense, it has some practical errors. Since different elements can occupy the same name at different points in time, TFS requires a full name + version to uniquely identify any inputs that you send. Usually you did not notice this restriction, but as soon as you rename elements in the system, if you say tf [doSomething] $ / newname -version: oldversion , then it will be confused and either throw an error or work with an item that you may not planned. You must be careful to pass valid combinations (newname + newversion or oldname + oldversion) to ensure that the commands behave the way you want.

TFS 2010 changes the story a bit: this is the + delete branch under the covers, as a result of which the ID element will change. However, daily commands, such as Get and History, are "faked" very well; old customers are approximately 95% compatible. The advantage is that when you have several renames in the system, and the search based on the path starts to become ambiguous, as indicated above, the server will simply accept the name that you specify and run with it. This improves overall system performance and eliminates several pitfalls often encountered by unfamiliar users, at the cost of not being so flexible and not preserving history with 100% accuracy (for example, when names collide when merging two branches).

Returning to the problem ...

It is not as simple as telling tf to rename $ / projectA $ / projectB . Top-level folders in the version control tree are reserved for the Team Project creation wizard; you cannot run standard tf commands against them. You need a script like:

Get-TfsChildItem $/ProjectA | select -Skip 1 | # skip the root dir foreach { tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB") } 

[of course, you can do it manually if there aren’t many children in $ / ProjectA]

As I already mentioned, I’ll talk about this right now, as looking for an old story seems very important to you. When you check the rename, tf history $ / ProjectA / somefile.cs will NOT work. By default, tf commands assume version = "latest". Any of these alternatives will have the full story you want:

• tf history $ / ProjectA / somefile.cs; 1234 where changeet 1234 was before moving
• tf history $ / ProjectB / somefile.cs; 5678 , where changeet 5678 was after the move. Or you can just omit the version.

The ultimate alternative for completeness and debugging:

• tf history $ / ProjectA / somefile.cs -slotmode . You will only see changes that occurred before the move; however, you will also see a history of any other elements that might have lived in the slot $ / ProjectA / somefile.cs "before or after the element that you moved under B.

(In TFS 2010, slot mode is the default behavior, there is the -ItemMode option to request tracking of your search in history, as it was in 2008, and not based on paths.)

EDIT - No, forking is not a great alternative. While the fork leaves enough metadata in the system to keep track of the complete history in ProjectB and from ProjectB, this is not very convenient for users in 2008. Plan to spend a lot of time learning the tf merges command (there is no equivalent user interface). 2010 greatly improves your ability to visualize changes across multiple branches, but this is not a clean, unified experience that you will get from renaming.

Answer 2

Richard's answer above is well written and well explains the situation. However, I had a couple more practical questions to add.

In TFS2010, the default behavior makes it seem like moving a file, causing you to lose the whole story before moving. The command that my users can use (and the one that is apparently used by the VS2010 GUI):

 tf history $/ProjectB/somefile.cs 

My users intend to get the whole history of somefile.cs, both before and after the move. They want a "history of code that is currently stored in $ / ProjectB / somefile.cs", regardless of the file name at any given time. Perhaps other people see it differently.

The first way is that the GUI that appears for me in VS2010 using TFS2010 starts with the history only from the moment of transition. The least recent item in the list is the rename operation. It can be expanded using the thin arrow of the drop-down list. Below is a story from a previous place. If you do not know how to look for it, it may seem that your story is gone.

The second problem is that if you later delete ProjectA (because you completed the transition to ProjectB, say), the story really disappeared. Extending the drop-down list in history for $ / ProjectB / somefile.cs does not create an older history.

Answer 3

Another option (and, I think, easier) is to import into Git and then export back to TFS using the Git-TF command of linear tools.

• Install Git-TF from binary, Choclatey, or source code.

• Clone TFS folder:

git tf clone https://myAcc.visualstudio.com/mycollection $/TeamProjectA/Main --deep

• Disconnect Git Repo from the TFS server by deleting the .Git/tf and .Git/git-tf .

• Configure the new Git Repo to connect to an empty TFS folder.

git tf configure https://myAcc.visualstudio.com/mycollection $/TeamProjectB/Main --deep

• Don't forget --deep

git tf pull

At this point, you should get the message "git-tf: this is a newly configured repository. There is nothing to extract from tfs."

git commit -a -m "merge commit"

git tf checkin --deep

Answer 4

Regarding the original command above: -

 Get-TfsChildItem $/ProjectA | select -Skip 1 | # skip the root dir foreach { tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB") } 

Both source and destination names must be surrounded by quotation marks if there are spaces in the full pathfilename. It was hard for me to do this on $ _. ServerItem , like surrounding it with an escaped ", returns the entire child, not just the string .serverItem. Or, if I managed to get the string, I got unwanted carriage returns, such as

"
$ Projected / folders / files
"

In the end, I got a team to work with the following, but I found that the story is still not being transmitted, which was the whole! Therefore, I believe that this command is the direct equivalent of a simple right-click in the source explorer and select rename (or move).

 $tfsServerString = "http://machine:8080/tfs/DefaultCollection" $tfs = Get-TfsServer $tfsServerString Get-TfsChildItem -server $tfs "$/Dest Project/MyTestProject" | select -Skip 1 | foreach { $sourceName = $_.serveritem; $targetName = $_.serveritem.replace("$/Dest Project/MyTestProject/", "$/Dest Project/Source/StoreControllers/dSprint/dSprint2/") ; ./tf rename `"$sourceName`" `"$targetName`" /login:myUser } 

Also note that this requires the use of the escape escape