I assumed this would be easy, but I'm not finding anything on it...
I have a project in TFS 2010, which needs to be moved to a new TFS 2015 server. Apparently the project cannot simply be moved normally because it's using a different project template which is not compatible and causes errors when trying to migrate (so I'm told - I don't have any more details on this).
I'm looking for a way to bring over the changesets, keeping history, to the new server. I assumed there was some kind of "dump" where you could export the TFS changesets, then import them into the new server into an empty project - but I'm not finding that option.
TFS Integration is deprecated and apparently doesn't work for TFS2015, with no alternative listed.
I'm open to other creative options like temporarily exporting to a different version control system - for example, I've looked at SVNBridge, but I can't even get that working, let alone figure out if it would help here.
Is there a way to migrate all changesets for a given project and keep history, without migrating the entire project?
There is no default way to migrate changesets in TFS, you would need 3rd party tool, like OpsHub (some features are not free), to migrate the most commonly requested data. Check: http://www.opshub.com/products/opshub-visual-studio-migration-utility/
Or you may consider doing a upgrade from TFS 2010 to TFS 2015, which is a full data transfer. To understand factors that affect your upgrade's compexity, check the requirements and review the upgrade process.
Learn if a dry run makes sense for you, and weigh the benefits and the costs to perform a pre-production upgrade.
When you're ready to upgrade, minimize downtime with the TfsPreUpgrade tool - especially for very large TFS collection databases (> 1 TB). Follow these steps for how to upgrade TFS.
We have a situation where at a point in our project's life, we needed to split off work item tracking and source control into 2 separate TFS projects, with the work items being in a VS Team Services project, and the source on-prem in TFS 2013.
The reason at the time being, we needed to grant access for our stakeholders to the product backlog, without them being on the corporate network where TFS is hosted. At the time there was concerns about security of the source code, hence the whole project was not lifted and shifted, just the backlog.
Now we're realizing some of the security concerns were not warranted, and we are missing out on the integration of ALM provided by a single project having both responsibilities, and would like to merge our source control out into the cloud-based VSTS project.
The problem is, the migration tools are overwriting the Work Items in VSTS. Is there some way we could merge, preserving that data, or any alternative to merge these two things together somehow?
I think you're looking at the Team Foundation Server Integration Tools here if you want to migrate source code history. Bear in mind that it's not going to be perfect (data time stamps will not be the same etc.).
If you can get away with it then just stick the latest code in VSTS and consider the on-prem server your archive should you need to go back. That doesn't tend to be too popular so you'll be wrestling with the integration tools. It's not the most friendly thing to use but mostly it will get the job done.
When you configure your session, you will want to choose Team Foundation Server\VersionControl.xml for your configuration. Then select a One-way-migration between your on-prem and VSTS.
You'll need to install VS 2012 or at least the Team Explorer.
Edit Coincidentally I had to do this myself so I blogged about the process here
I'd like to know if it's possible (and how, if anyone has ever done it before) to have Mantis Bug Tracker "tickets" automatically imported/transformed into TFS work items.
We use mantis to keep track of development and TFS as a Repo. Every check-in made to TFS must be associated with one work item. Right now, these two systems are not integrated which causes, for example, that the ticket 100 is relative to the work item 497 without no way of knowing that one is relative to the other.
I've looked at TFS Integration Tools but was unable to install it for some reason at this time.
So, how can I have an automation process that "imports" Mantis tickets into TFS work items automatically? Is this even possible?
There is a plugin for source integration which supports Git, SVN and Mercurial (experimental).
https://github.com/mantisbt-plugins/source-integration
I am not aware that there is something similar avalaible for TFS, but it should be no big problem to implement TFS integration based on the framework which is offered by the plugin.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
we are on the research level of choosing a full ALM system for our company.
we consider both TFS 2012 and JIRA for use in product, project managment, QA, support and developemnt teams departments.
the things to support are bug tracking, workflows, project graphs (such as bugs count, burn down and so on).
any recommendations? pricing?
as far as i can see TFS is better for R&D teams using visual studio and less for eclipse.
Here are TFS advantages:
TFS is an application life-cycle management (ALM) solution, but Jira is simply an issue tracker. Many features of TFS, e.g. source control and automatic builds are not supported in jira and you should use other solutions, e.g. Subversion or Bamboo to this aim.
All TFS components, i.e. source control, issue tracker, build automation are fully integrated. Such level of integration cannot be attained on other solutions.
It is fully integrated with Visual Studio.
Here are Jira (and other Atlasian Solutions) advantages:
It has been used in MANY open source projects, e.g. JBoss, Spring, etc.
For launching TFS, you need a high end server, MS SQL, etc. But Jira could be installed on an ordinary PC on open DBMSes, e.g. my SQL.
If you are using Java technologies, many Java IDEs, e.g. IntelliJ, Eclipse and Netbeans fully support Jira. I have not seen such a nice support for TFS.
There are lots of plug-ins available for Jira. You can take a look at them here.
If your team is small, Jira costs only $10. It is really cheap.
Atlasian solutions have better support for java technologies (Ant, Maven, junit, etc.)
I have worked with JIRA / Subversion and now with TFS 2010, and I think JIRA / Subversion are much better tools.
I like the idea of having source control, workitem control, build control, test control in one integrated package, but somehow TFS is just a below average implementation of everything (Except Gated Checkin because that is cool).
TFS version control uses binding just like VSS, so doing multiple checkouts of the same requires extra effort. The ability to Suspend/Resume work using TFS shelveset, is the official workaround for being able to do concurrent work.
TFS sometimes goes haywire with its SQL table locks, so it has be restarted. Also the SQL indexes randomly gets broken, so suddenly showing folder history takes minutes. TFS in VS2010 needs to be online all the time to do any source editing, though this has been fixed in VS2012. But the VS2012/VS2013 GUI is so tightly integrated with TFS, so if the TFS-server has issues, then everything becomes sluggish in VS. This is really visible with the new VS2015 CodeLens, where all TFS WorkItem Lookup should be disabled, or else VS2015 will get stuck more often than usual.
Visual Studio will one or two times during a work week fail to get latest source (sometimes silently). If you attempt to get latest again, then it will say you already have latest. When you perform a build, then it will ofcourse fail. The workaround is to perform a get specific version with forced overwrite.
To create a wiki for documentation, then one have SharePoint, and version 2010 is a really crappy wiki tool.
For some really strange reason Microsoft System Center (really expensive) is completely detached from the TFS solution, and lingers around like an old lady. Making it super difficult to synchronize incidents with TFS-workitems, and get TFS-builds deployed using System Center. VS2013 Update 4 now includes the almost free InCycles Release Management, that should make the continuous integration work better (IIS applications can use Web Deploy).
If you work with advanced stuff like release-branching, then you will be surprised how difficult it is to generate a release notes document (read requires unsupported 3rd party tools). There is no automatic association of Work Items when merging to release-branch. And if you suddenly want to release a new build, then no help around for creating a release-report that lists the changes/workitems that has been included since last released build.
The integration of JIRA/Subversion in Visual Studio (VisualSVN) is so much better (ankhsvn is an alternative opensource version of VisualSVN). Still don't understand why Tfs-annotate cannot jump to next previous version like Svn-blame can.
I have no idea about the difficulty of setting up TFS 2010/2012, but JIRA / Subversion / CruiseControl.NET was very easy and cheap (Guess one would now use Git and Jenkins that also supports Gated Checkin).
VS2012 also includes a redesign of the entire user interface, which includes a new "improved" TFS Team Explorer that is really a pain to work with as a developer (Compared to VS2010). Microsoft has declared that Team Explorer has been fixed in VS2013, but it is not true. It is mouse-click hell to perform checkin and associate tfs-workitems.
Visual Studio 2012 now includes a virtual kanban board, but I would be surprised that this feature is not added to JIRA.
Became very suprised when the Visual Studio Team announced that they will implement GIT support in Visual Studio 2012. Guess it is easier than trying to rewrite TFS into a distributed version control system. Hope the new GIT integration will come up to the standards of VisaulSVN.
We use JIRA and GreenHopper for all our development tasking, bug tracking, and product management needs. We have a team of 46 developers, testers, and management. It integrates fully with Eclipse. I highly recommend it.
The tasks and workflows are fully customizable, you can add fields, add automation (like assigning tasks to team members when the task changes state), support drag-and-drop attachments, and more.
The pricing on JIRA just dropped to a significantly for managed hosting.
Well this is basically about the tend in the market, IF you people working on open source technologies specially java , mostly professionals of java are familiar with JIRA, JIRA has almost all type of plugin for project management, SDLC, Code Review and Bug tracking. But if your people working on the .net or microsoft technologies than they are comfortable with TFS.
In general, if your project is built in Java (Or other Open Source), go with JIRA. If it's built on .NET technologies, go with TFS.
Theoretically you could use either one with Java or .NET, but the integration won't be as tight and you will have to use plugins to get everything working.
JIRA / Subversion / Bamboo are much more configurable and integrate with other open source tool with hooks and triggers. TFS does not allow integration with anything. It's not extendable. You can't improve it with modules or plug-ins or extensions. In my opinion, TSF is quite unexciting and dull, that is if you think of source control and change management as a necessary evil then TFS is for you but if you are in Configuration Management or a Build / Release Engineer, JIRA is the way to go.
at our company we are using a TFS 2008 server. We need some capabilities offered by TFS 2010 (like Lab Management) but currently we cannot change the server (we're a small part of a big company and doing that would make others to update their tools so it's not an option).
What I'm looking for is a way to install a TFS 2010 server that links somehow to the repository of the actual TFS server so when the 2010 MSBuild tries to build he takes sources from TFS2008.
Is this possible or do you think that could be another way of getting that to work?
Thanks for your assistance.
You can use the Integration platform to sync the sources and work items of TFS2008 with TFS2010.
See http://tfsintegration.codeplex.com/ for more information
You can also customize a build template so that it pulls in source code from anywhere.