View History in TFS - tfs

We have created a New Team Project in TFS 2008. We want to merge 7 different team projects with this New Team Project and finally delete the old 7 projects.
A existing project is branched with a new team project. After this,we are not able to view the history of source project in the target (new) project view history. Please let us know, how to propagate the complete history from source project to target project.
I am new to this...I don't know whether I have stated the issue correctly or not...

I would recommend using the Rename feature to place the code under the same team project, rather than branching.
There is no UI for branch/merge history built into TFS 2005/2008. You have to use the command line (tf merges) or 3rd party tools (e.g. Attrice Sidekicks).

Related

TFS 2017 move TFS source code repository to new instance of TFS

We installed the free version of TFS 2017 and created a new project. We now have source code with history. The PM decided they wanted to switch from Agile to Scrum so a lot of commands were run to try to do this. These commands came from a blog found on the internet. The supervisor then decided that it should NOT have been switched to scrum and said we needed to switch back to Agile. So similar commands were run to try to do that. Now the Project Management portion of our project is broken. We can't run queries and the work items are corrupted. I want to try to just install a new instance of free TFS 2017 and copy/move the source code (TFS, NOT GIT) to the new instance and start over with the PM stuff. Can we do this or is it a lost cause.
Actually we do not suggest OPs to do the process template change in a single team project. Take a look at this MS documentation (here) ...
You can change the process a team project uses from a system process
or inherited process to an inherited process. You can only change team
projects to use another process that inherits from the same system
process. That is, you can change an Agile-based team project to any
process you created from the Agile system process as well as to the
Agile process. Whereas, you can't change a Scrum-based team project to
an Agile-derived inherited process.
There is no need to set up a totally new TFS instance, you could simply create a new team project based on Agile and then move your source code and workitems to that new team project.
Since you are not care about the history info about your original team project, it's more easier to achieve this, simply remove your old workspace mapping and map to the new team project.
To move workitems you can export them to Excel, create a new Excel connection to , that is connected to the new team project, and then copy the workitems and pushing them from the new Excel file into the new project.
If you insist on moving the code to new TFS server, you just need to back up your local code and directly check in them as pending changes in the newly created team project on new TFS server.
More details please refer the answer from Andrew Clear in this similar question: Visual Studio Team Services: How to migrate from Agile to Scrum process template
If you want to only move Source code from one Team Project Collection to another Team Project Collection, one of the crude workarounds is the following, when you are ONLY requiring SRC code moves.
Create a workspace and check out all SRC from the source Team Project in the source TPC.
Create a new Team Project in the new TFS instance.
Remove the binding files from the SRC dumped out in (1), or better yet just move it on the disk to a new directory and remove all SRC binding files.
Then add the source (from the above step 3) into the new Team Project you created in the target TPC you created in (2) above (or it could also be into an existing Team Project you already had in the target TPC).
Once again this is ONLY if you don’t care about the other things such as WITs and Reports from the older Team Project, and you only care about the Source Code.
In addition, you can use the following tool Timely Migration.

TFS Repository deleting status after upgrading major version

In the past, we seem to have created a TFS repository that was not part of a project. It seems that this is no longer supported by TFS in recent versions.
After updating TFS 2013 to 2015 and then 2017 we did not immediately notice the problem, but looking in the Collection Management screen on the web portal shows that the "Project" (which is not a project) is marked in a "Deleting" status.
The Microsoft page about this says that if you want to keep the code, no action needs to be taken. That "Deleting" status worries me however.
Is there any way to add an existing repo to a project? I can create a new project. I can add a new repo to a project. Can I add an existing repo to a project?
Alternatively, can I "Un-Deleting" that repo somehow?
That page have described this very clear:
Otherwise, no action is required. Placeholder team projects are
hidden in Web Access and Team Explorer in Visual Studio. Therefore,
they have no significant effect on day-to-day usage. As with any
other deleted item in Version Control, you can still access the
corresponding project in Source Control Explorer if the Show/Hide
Deleted Items button is enabled.
As you said, Placeholder team projects are not real team projects. When you delete a real team project, it will permanently removes data associated with that project from the database. You cannot recover it later.
They are just as deleted folders/items in TFS, you could undelete them in Visual Studio Source Control. Just select the deleted folders and right click it select undelete , and check in pending changes. Then you could get/download all files in the repo to local. Create a new team project, add files to the project, finally delete the particular placeholder project.
Since there is no way to import deleted files to either a existing project or a new project. Above is a safety workaround, the only disadvantage is it will lose the source control history of those folders. Otherwise, you could also take no action as the page suggested, the Placeholder team project will not be deleted. If you encounter any problem about this, you could contact the TFS support.

Adding solution to source control

I want to add solution to source control(tfs I am using vs 2015).I selected the option add solution to source control, then one dialog opened, in that dialog there is no option to create a new folder directly under collection, it is always adding to the existing project(folder).How can i create a new folder/project directly under the collection.
The structure TFVC uses for source control is as follows:
Team Project Collection (created by your TFS admin)
$/TeamProject1
$/TeamProject2
etc
You can't add source code directly under a Team Project Collection -- it has to be created in a Team Project. And you can't just create a "folder" that represents a new Team Project. You have to create a Team Project either via the web UI (if you're using TFS 2015 Update 2 or later) or via Visual Studio. The version of Visual Studio used to create a Team Project needs to match up with your version of TFS, as well.
Typically, guidance for Team Projects is to create a single team project for each portfolio of related applications, since each Team Project is isolated from other Team Projects in terms of things like source code, build, release, and work item management. You can use the concept of Teams within a Team Project to create separate backlogs and the like for individual applications.
Some further reading:
Why you should use one Team Project: http://geekswithblogs.net/Optikal/archive/2013/09/05/153944.aspx
Creating a team project: https://learn.microsoft.com/en-us/vsts/accounts/create-team-project

Create a branch in a project with its parent under a different project in TFS

I have the following structure:
$/ProjectA [Uses MS Agile Template]
--Branch1
$/ProjectB [Uses Custom Agile Template]
--[To Be Created Branch]
How can I create this new branch in ProjectB that has a parent relation with $/ProjectA/Branch1?
Our requirement says that we cannot be under the same Project because we must use different templates, but we still want to merge the code from new project back to the ProjectA. I checked the option in TFS when you create a new Project that lets you use an existing source control, but problem with that is:
1.There is NO option to bring in specific branches in a Project [Its all or none]
2.I cannot rename that new branch in the new project for some reason
I understand this can be achieved by using a Baseless merge between these 2 projects but I would like to know if there is still a way to have a smooth merge between these 2 branches in different projects.
P.S: we are using VS 2010 with TFS 2010
There's shouldn't be any problems in just branching from one team project into another. You should be able to do this just like you would any branch: just select $/ProjectA/Branch1, select Branch, and enter a branch target path of $/ProjectB/ToBeCreatedBranch.
This is because realistically, Team Projects are of fairly limited scope in TFS version control - it primarily treats the source control tree as a big hierarchy beginning at $/, and team projects are not particularly special, except for some very specialized operations. (Check-in policies are queried for by Team Project, as are settings for locklevels and labels are scoped to Team Projects.)
I'm a little unclear what version control options you specified when you created the new Team Project - you should have just created a new source tree node for it and then you can create your project branches beneath $/ProjectB.

Steps for changing process template for an existing project in TFS 2010

I have an TFS server installation that through time has gone through upgrades from TFS 2005 to TFS 2008 and then to TFS 2010.
During the lifetime of the installation a lot of projects have been created and different project templates have been used. MSF Agile 4.0, 4.1, 4.2 and 5.0. and a few MSF CMMI ones.
What I would like to do is "replace" the project template used for all these projects to use a new one common one: Microsoft Visual Studio Scrum 1.0.
I am aware that TFS project templates are used as templates for creating new projects and cannot modify the tfs projects definitions after creation.
Uptil now only the version control and build server part of TFS have been used and there are no existing work item types.
Additionally all projects and build scripts are depending on the source code paths stay the same.
As I see it I have the following options:
Create new TFS projects using the correct project template and then move/branch the source code to the new project.
All code is moved to a temporary team project.
The old project is deleted
New project with the original name and correct process template is created
Code is moved to the new team project
Temporary team project is deleted
All the build definitions needs to be to recreated which is not an option.
The source code move/branch will "mess up" the versioning history
By messing up the versioning history I mean that when you move source code it will behind the scenes do a delete + source rename on the original location and the history will still be located in the old project. This will make searching in the history difficult and if I actually delete the old project I will loose all the history before the source code move.
This is really not an option for me since there is years of code change history that is needed to for supporting the different applications being built.
Use the TFS migration tools to migrate to another TFS project
This has the same downsides as the first solution
Replace/import work item types, install new reports, create new SharePoint sites
For each tfs project
Delete existing work item definitions using "witadmin deletewitd"
Import each work item definition from the new process template using "witadmin importwitd"
Import work item categories using "witadmin importcategories"
Delete old reports in project folder in report server
Upload the report definitions from the new process template
Modify data sources used for the reports using the report manager to point to the correct shared data sources (TfsReportDS and TfsOlapReportsDS)
Modify the report parameter ExplicitProject default value to "" (empty string) and disable prompt user option.
Export the documents in the old SharePoint site using stsadm
Delete the old SharePoint site
Recreate the sharepoint site using the TFS2010 Agile Dashboard site template
Activate site feature "Team Foundation Server Scrum dashboard"
In TFS Project Settings -> Project Portal Settings: Enable "team project portal" and ensure the url is correct. Enable "reports and dashboards refer to data for this team project"
And finally..
Process the Warehouse
Process the Analysis Database
Even though that this involves a lot of small steps this looks more appealing because
this option will not force me to move the source code and my existing build definitions will be intact.
My question:
Are there other ways to achieve the replacement of work item types that I haven't mentioned?
And/or am I missing any steps in last solution?
Given that you aren't using any existing work item types, your final proposal looks like the best option.
After deleting the old reports and exporting the SharePoint documents (you could also use Windows Explorer instead of stsadm), there are actually two commands in 'tfpt' that will help you. This will reduce it from 14 steps down to 5 or 6 steps.
tfpt addprojectreports Add or overwrite reports for an existing team project
tfpt addprojectportal Add or move portal for an existing team project
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
Your first option is IMHO your best shot.
You can branch the sources from the old team project to the new team project. With TFS 2010 you can see the history also from the branched location. So you don't loose functionality in here.
The Build is just an msbuild file which is stored in source control. The only thing you have to do is actually copy the build definitions. You can do that either manually, or you can create a little app that does that for you.

Resources