Is there any way to show linked files after a VSS to TFS migration? Additionally, how do you link files in Visual Studio 2013?
As Edward Thomson wrote, there is no such thing as linked files. Excerpt from How To: Migrate Source Code to Team Foundation Server from Visual Source Safe.
The main issues that you are likely to encounter are due to some differences in the way TFS handles version control in comparison to VSS. For example, because TFS does not support sharing of files, shared files are migrated by copying the version of the file at the time sharing began to a destination folder. Also, because branching in VSS uses sharing, the migration of a branched file results in the file being copied to the destination folder in TFS source control. As TFS does not support pinning, to help you locate items in TFS source control that were previously pinned in your VSS database, the VSSConverter tool labels any file that was pinned with the “PINNED” label.
Related
I'm new with source control but since we are more than one developer in our company I started introducing git with Visual Studio 2013 Express and the Team Foundation Server. Now when I create a new project and add it to source control it seems that sometimes one random cs source file in the project is excluded from version control. In the Solution Explorer there is no check-in icon infront of the file. Also there is no other icon infront of it and if i publish the repository to the server the file isn't there.
I have no idea why the file is excluded and how to include it.
Excuse me for the novice question :blush:
How do I detach a project from ClearCase in order to add it to a TFS source control system?
The easiest way is to do whats called a "tip" migration. This just means grab a copy of your source code from ClearCase to your harddrive. Then add all the files to TFS. This will bring over the latest version of your code, but will not bring over the history.
If you want to do a migration that brings over history you will need to use a tool such as the TFS Integration Platform. The ALM Rangers have produced a connector for ClearCase and a bunch of training and videos on how to perform a migration that can be found here: http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/07/27/getting-started-with-ibm-rational-to-team-foundation-server-tfs-migrations.aspx
I know it's silly but here's what I needed to do -
Open each of the csproj files
For each one, remove the xml nodes starting "Scc" (like SccProjectName, SccAuxPath, SccProvider etc) it seems they were the ones bothering the Visual Studio.
Reload the projects and add them to desired TFS workspace
Additional Steps that may need to be done:
Open the .sln with a texteditor and delete the entire section about source control.
In Visual Studio go to Extras -> Options... -> Sourcecontrol and change the plug in to TFS
I have included a folder with several sub folders in TFS, which is not a VS solution. Basically it is a bunch of XML files mainly, which are manipulated via some GUI. How can I exclude certain subfolders from check-in while check-in the 'solution'/folder?
You can manually include or exclude files from a check-in: the UI is a bit different if you are using the 2012 TFS client (Team Explorer) or an older version. It is described at this page.
On the Customize which files are ignored by version control section, you see a way to 'permanently' exclude folders or file types from a check-in.
I have some source code and other artifacts such as images that are not created in Visual Studio 2010. I want to put them into TFS 2010 version control, how can I do this?
TFS does not care what the format of your files is; you can use TFS to store any type of file - whether it was created in Visual Studio or any other program. This is true of all TFS versions.
The comments already somewhat address how to add a file to Source Control using Source Control Explorer; Once you have a workspace mapping, copy files or folders into a mapped folder in your workspace, right-cick on the folder you added the file to in Source Contol Explorer and select the option to Add Items to Folder; This will launch a wizard that you can use to let TFS know that you want to add the selected file(s) or folder(s) to source control - it can be any file on your computer.
After the files are added, check-in yor changes by right-clicking on the file in Source Control Explorer or by using the Pending Changes window (View menu -> Other Windows -> Pending Changes). Almost every source control operation in TFS is a 2-phase commit that involves first letting TFS know what you want to do (like add or delete a file) and then actually committing that change with a check-in.
You can also perform these steps using TF.exe from the command line or the Shell Integration Feature that is installed seperately with Team Foundation Server Power Tools (TFPT). Please note that whilst you can list and view the contents of files in TFS using the Web Access user interface, you cannot check-in or check-out files using that interface. Also, you will not be able to perform any source control changes without Visual Studio or at least a free version of it, named Team Explorer.
The only qualities of files that matter to the behavior of TFS are if the file is a mergable file type or not and what the encoding of the file is; however, in most cases the default setings in TFS will be fine for you. Mergeable file types are files that TFS will enable merging for; Examples of mergable file types are text files; Non-mergeable file types are file types that you would not want to merge, like pictures or Microsoft Excel files. You can read more about Managing File Types on the Microsoft site.
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.