rename project in TFS
Rename existing project in TFS
We’re taking another look based on all the feedback here! As Doug pointed out, this is rather hard problem though.
- Siddharth (PM on TFS)
Paul Kemper commented
Please add the possibility to rename a team project.
Tobias Larsson commented
This is really important when TFS projects with teams often are reflecting organization. Only way to handle that currently is to have one TFS project to rule them all...but that is a nightmare if you got +100 teams in a collection... its impossible.
So please add this... this should be prio.
Bitte, bitte, kommt in die Puschen!
This has just bitten me for the second time this month! Not being able to rename a project is VERY BAD, not to mention embarassing and costly. Can someone in the TFS team put together a utility that will do this. Or at the very least put together instructions on how to do this manually so that we get everything into a new project. With an issue like this I can't recommend TFS to anyone.
Adrian Allonso commented
I saw the September 23rd release notes here : http://www.visualstudio.com/en-us/news/2014-sep-23-vso and I wanted to see if renaming team projects is possible. Apparently it's not available.
Is there any update about when it will be available and the version of TFS that it will work on?
Randy Syester commented
Make it happen
We have consolidated 2 TFS servers into 1 TFS Server with 2 TPCs and have upgraded to 2013 and update 3.
We have so many projects with the wrong names and we want to / need to figure out how to rename and archive old team projects with like a .old appended to the name and find a way to move all of the contents of a team project from the old team projects into the new team projects....we can branch source control folders....but how do we move builds, workitems, and lab environments across team projects?
There was a third party codeplex tool previously....is that still available?
Commercial software products like TFS should follow the now, next or within strategy of release scoping.
Now - features, bugs, changes in the currently in development version (usually to be released in 6 months or less)
Next - features, bugs, changes in the next planned version (usually to be released in 1.5 years or less)
Within - Features, bugs, changes in the plan for 2 versions from the current production one (to be released within 2 to 2.5 years or less).
Any request, bug, feature, change that is not implemented in a production release within 2 years of being opened is to be closed as 'never to be implemented', This is important to keep the product backlog cleaned up and not growing with an ever increasing list of blue-sky wish list items that cannot have a business case made for their implementation.
MS came back 3 years ago on Aug 25, 2011 with a 'We're taking another look' on renaming TFS project. Either implement it or publicly remove it as 'never to be implemented'.
Cloud based TFS is not a good solution for the thousands of financial companies, utility companies, nuclear power plants, airplane manufacturers, medical device companies which cannot host their source code and bug lists in a third party off-site storage location
Jeff Post commented
Pretty please do this!
Now I am suffering this scenario: created a project with TFVC, people ask switching to Git. Now I have to create a new project, move all data, delete the old, ... but cannot rename the new project to replace the old one.
Looks like this is "on the way" (read comments):
We need to be able to do this. This functionality can and should be implemented.
Stunning that this cannot be done!
It looks like this is coming soon! http://blog.thoughtstuff.co.uk/2014/05/tfs-project-rename-is-coming/
We are actively moving off of similarly limited legacy technologies. The business value is outweighed by the increasing support costs. This fits given we use the basics features of version control, bug and issue tracking, builds and simple agile planning. The largest cost in our 50+ person software project dev, QA, UX, management team is people time; and that people time cost is very minimally changed by using anything beyond the basic version control, bug issue tracking, build and agile planning tools. An added benefit of this simplistic approach is that each group needs to build a significant business case for adding any custom scripts or code to any of the code in the check-in, build and package pipeline.
Steve 4th commented
In my case our product name has been changed after we created the initial TFS project. The TFS project now refers to the old Product name. This is quite confusing for a bunch of reasons. We don't want the whole copy and start again approach as we have a large backlog defined and really do want to keep the history.
We are using TFS on-line i.e. at VisualStudio.com.
I don't mind if the underlying project name never changes so long as I can have the project name displayed as the new name and the URL to read the new project name. What I'm trying to say is that a display alias would work for me.
Paul Katz commented
Yes, renaming capability would be highly, highly valuable
YES for Michael Cowan's feature as described in his March 12th, 2014 post!
I need to rename a project. Our client who has view access to TFS wants to change the name. The name is also easily confused with another project, and sometimes work items are entered under the wrong project. We need a fix. As a workaround, I have a number or queries and activities I do to ensure all the items are in the right place. This takes hours every sprint.
We have a little joke to make light of the occasional lacking TFS feature (can't query tags, cannot easily remove weekends from the burndown chart, new work items default to current sprint). We say "WTFS!"
It is to know another team pushes some doozies to production, not just mine! Overall, we love TFS.
As you look at how to solve this I'd recommend going back historically and seeing if anyone has notes from when the problem of how to move from the DOS 8.3 file name standard to Windows long file names was successfully tackled, since that's somewhat similar, in that the impact of getting it wrong would've been huge, but they found a way through it by having every filename have a unique 8.3 equivalent being managed (as I understand it). I also think the idea mentioned by Michael Cowan below is on point. That is, you take the existing infrastructure and add one or more properties to it (DisplayName). The existing identifier goes through the arc that 8.3 filenames went through, that is, right now it's overt, but eventually it could fade more in the background as an internal property.