I deleted a branch in TFS and just found out that I need the changes that were on it.
How do I recover the branch or the changes done on it?
Specifically in Visual Studio go to "Tools-Options" then Select "Source Control-visual Studio Team Founation Server" and check the "Show deleted items in the Source Control explorer".
Having done that - you can then right click a folder and say "Undelete"
As described in the TFS FAQ:
Are Deletes physical or logical? Can accidental deletes be recovered?
Deletes are fully recoverable with the “undelete” operation. You wouldn’t want to do a SQL restore because that would roll back every change to the TFS in the time since the file was deleted.
Related
My team is using redgate source control for our databases with Git. I noticed that as I was looking at the database, it wasn't obvious which source control path eg. which branch it was linked to in SSMS. Where can I see this setting?
You can see the branch name when you start a commit, but where can I see the full path - because there several different Git repos that we use.
[update]
ok, nevermind, it has been a while since i had to use it. An "update" message hiding the source control menu across the top of the window in ssms. Once I clicked on my update and installed it, the source control menu was visible again. I was able to see the folder where branch pointed to.
We are using Team Foundation Server as source code management tool.
I've checked a source file out and done some changes while other developers have checked in theirs.
Then I've got latest version of that file so TFS asked me to solve the conflict and I've wrongly chosen to "keep local changes". The right choice would have been to merge the differences.
Now for TFS the conflict is resolved and I can't rollback the choice I've done as a mistake.
If I choose the "Undo pending changes" then I'll lose all my local changes.
If I get latest version again TFS says that "All files are up to date".
How can I go back and make TFS ask me to resolve the conflict again?
Thanks.
UPDATE
I've just tried the second suggestion of Dylan Smith and did the following steps. 1) Looked at the workspace changeset number of the file2) Made a backup copy of the file 3) Made the "undo pending changes" 4) Deleted the file from its folder 5) Got the specific version by changeset previously noted 6) Overwrote the file with the backup copy (that was writable) 7) Got latest version of the file 8) Chose the "Checkout file and automerge" option. The final result was TFS triggering this error message : "Error The following exception was encountered. Program.cs cannot be merged. Please retry with another resolution option."
I see only one way because your local changes are not saved anywhere on its own:
Save your local files to a different directory and undo your pending changes. Run a diff, do your changes again, and check in.
Here's a similar question: When merging changes in the MSVS2013 IDE, is there a log of what occurred?
My 2 suggestions there were:
Use the Compare with latest and manually identify lost changes
Revert local workspace and reapply pending changes.
Is there a way to tell TFS that one or more files has been moved/renamed by another application (in our case, WebMethods 9) running in Eclipse? We have to move/rename the files using WebMethods and not TFS, because WebMethods does a whole lot of automatic reference updating. However, we haven't found a way to tell TFS "hey, trust me - I moved/renamed/deleted it outside of TFS". Instead, it refuses to commit any changes back to the repository until the old file reappears.
We're working around this at the moment by creating dummy files with the old name and then deleting them again via TFS, but you have to agree that kinda sucks. I'd be happy to treat a move/rename as a deletion of the old filename and creation of the new filename; I just don't want to have to fight TFS over it.
Eclipse: 3.6.1.M20100909-0800
TFS plugin: 11.0.0.201306181529
It depends on whether you use server workspaces or local workspaces.
In a server workspace, TFS requires that you inform the server for every change - to check out a file, rename, delete, etc. This allows TFS to avoid scanning your disk for changes, which is beneficial for large repositories. If you want to force a disk scan with Team Explorer Everywhere, because you may have made some changes outside of Eclipse, you can go to the Actions menu and select Detect Local Changes.
In a local workspace, TFS will examine your disk for changes every time you look at the pending change status. So all you have to do is run tf status or click refresh in the Pending Changes View to see changes made to files outside of Eclipse.
If your workflow involves files changed outside your IDE frequently, I would strongly recommend using local workspaces, however this requires TEE 11.0 and TFS 2012 or better.
I'm currently reorganising our TFS source control for a very large set of solutions, and I've done this successfully so far.
I have a problem at the moment where I need to delete a legacy "Release Branch" TFS project that was branched for the old structure, and is no-longer required since I now host a release branch within the new structure.
This is an example of how the source control now looks after moving everything:
$/Source Project
/Trunk
/[Projects]
/Release
/[Projects]
$/Release Branch Project
/[Projects]
/[Other legacy stuff]
So far I've found information that says:
tf delete /lock:checkout /recursive TestMain to delete a branch.
TfsDeleteProject to delete a project
tf delete seems to be only relevant when I need to delete a branch that is within the same project as the trunk, and TfsDeleteProject doesn't seem like it will delete the branch association from the source project (I hope I'm wrong, see below).
Can someone tell me if the above will work, and in what order I should perform them in, to successfully delete the TFS $/Release Branch Project while also deleting the branch association (from right-click $/Source Project -> Properties -> Branches)?
Let me put the facts like this:
Within the context of the TFS source control system, "Delete" is a purely logical operation. You can Undelete at any time. You can have multiple deleted items occupy the same path over time, or even simultaneously. Branch relationships are preserved.
TFS "Destroy" is physical removal. To maintain database integrity, that means all entity relationships are removed too: changeset history, pending change records, shelved versions, merge history, and yes -- branch hierarchy. This Destroy feature was introduced in TFS 2008.
Destroy is the only operation allowed to alter the merge history table (from which branch relationships are determined). All other operations are strictly append-only.
TfsDeleteProject does its best to completely remove all traces of a project, the primary goal being to allow creation of a brand new project with the same name. Some TFS subsystems support physical deletes; some, such as WIT field metadata, only support logical deletes, even in TFS 2008 & beyond. In the case of source control, TfsDeleteProject invokes "delete" in 2005 and "destroy" in 2008+.
In TFS you generally cannot permanently delete anything inside a team project (and TfsDeleteProject deletes a complete team project, but it is not clear if the source control content will actually be removed as a team project is just the top level of the source control tree).
A delete of a file, or whole set of files is just another tracked change, go back into history and it can still be seen.
You could use permissions to make it inaccessible to all. Or rename under an "Obsolete" team project.
EDIT (I finally remembered where this command was):
There is another option, from the command line: tf destroy:
Destroys, or permanently deletes, version-controlled files from Team Foundation version control.
I would expect this to remove the branch records to create the, now destroyed, files... but you might need to check.
Select the branch folder you want to unbranch. then
File > Source Control > Branching and Merging > Convert to Folder.
In VS2013 I couldn't find it under #Radhika answer
I did find it under Team Explorer > Source Control Explorer >right mouse on project > Branching and Merging > Convert to folder
Hope this saves you time.
Edit Copied from comment by #DdW: you need to do a Get Latest Version after converting, before the Delete option will be enabled
REMOVE A BRANCH USING ROLLBACK
Right click on the select branch.
Select rollback to specific changeset.
Enter 1
set.
Choose 1.
The branch will be marked for deletion.
Check in the changes and it will be removed from source control.
Both Team Foundation Server (TFS) 2005 and 2008 lose history (check-ins + comments) on files when they branched and merged back. So e.g. if changes in a branch are made then merged back to the root branch, none of the changes made in the branch are visible in the root branch. The only thing visible in the history states that a merge occurred.
Does anyone know if there is an option which can be set to retain the history, or a different way to do the merge which keeps the history?
You are correct that TFS does not track history by default when merging. There is a powertool, however, that allows you to do so (see History Command under TFS Power Tool Commands).
See this comment for more details:
“If TFS would only maintain the history of branched files, rather than starting them from scratch every time a branch is done, then a similar safe merge would be possible between branches”
You can install the Power Tools and then use the /followbranches flag to retrieve the history information: http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx
History Command
Use the history command to display the revision history for one or more files and folders. The /followbranches option returns the history of the file branch's ancestors.
There is also a codeplex project to enable the option in the GUI:
http://www.codeplex.com/TFSBranchHistory
TFS Branched History plugin for VS2010 is now available from Microsoft Gallery:
http://visualstudiogallery.msdn.microsoft.com/7d4f37b6-f9a4-44c6-b0a0-994956538a44
This plugin is just query history from different branches and make union of the records.
The TFS Branched History plugin from Microsoft Gallery only works with VS2010.
For those using Visual Studio 2008, here is a plugin that provides the same functionality.
After you install it, open up VS2008 and go to the TFS Source Control window.
Right-click on an item and you will see a new option in the context menu called "Branched History".
Click on this to get the history of the item in all previous TFS branches. Give it a few seconds if you're on a slow machine.
In the "Branched History" window you can also View or Compare file versions just as you can in the regular "History" window.