I suggest you ...

rename project in TFS

Rename existing project in TFS

5,501 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Visual Studio ALM TeamVisual Studio ALM Team shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    152 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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?

      • Anonymous commented  ·   ·  Flag as inappropriate

        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

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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 4thSteve 4th commented  ·   ·  Flag as inappropriate

        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.

      • JemariJemari commented  ·   ·  Flag as inappropriate

        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.

      • EricTNEricTN commented  ·   ·  Flag as inappropriate

        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.

      • Alon.GretaAlon.Greta commented  ·   ·  Flag as inappropriate

        Nate - how do you clone the existing project and not lose all the work item meta-data (links, IDs, attachments), test asset meta-data(test suites/test plans), lab management meta-data (builds/build results), version control meta-data (annotations, history, labels), and security meta-data (groups, permissions)?

        If you have some solution that gives you all that meta data under a new name.....please share your workaround.

      • Michael CowanMichael Cowan commented  ·   ·  Flag as inappropriate

        I have a great idea to mitigate this.

        Add a new property called "DisaplyName" to the project. If its blank, use the original name, if its not blank use that name everywhere.

        Also create a GUID ID for each project that can be used instead of any name. So all scripting / API can be done against the project GUID.

        Keep the initial name plumbed everywhere as you have it. Let all API's continue to use the original name .. but allow us to use the GUID ID and friendly display name.

        thanks

      ← Previous 1 3 4 5 6 7 8

      Feedback and Knowledge Base