TFS 2010 does not display history for a renamed folder - by Code_Drone

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 538032 Comments
Status Closed Workarounds
Type Bug Repros 22
Opened 3/2/2010 2:16:40 AM
Access Restriction Public


When renaming a folder via the command line api, Source Control Explorer using "rename" or "move" or "branch" commands, the history does not display all the changesets that affected the renamed folder before the "move", "rename" or "branch" took place.

The history *is* displayed for individual *items* after a "move", "rename" or "branch" but not for folders.
Sign in to post a comment.
Posted by mjeson on 9/26/2014 at 11:50 AM
This "by design" answer is not acceptable. It is a bad design. Please modify it. You can certainly include softlink to track moved files / folders in workitem changesets, history, and labels.
Posted by jbtibor on 7/11/2014 at 10:35 AM
The issue is more serious than just displaying or not displaying changes before rename in history. The major problem is that changesets are not available in merge tool either, i.e. I can't specify to merge changes up to a changeset before the rename, even if I enter the changeset number manually I get error that changeset doesn't exist.
Posted by MichelZ on 1/9/2014 at 7:45 AM
You should vote for this issue on User Voice:
Posted by Fletcher James on 6/20/2013 at 9:51 AM
This just bit us yesterday. We decided to re-org our branching & folder structure to make it a bit more sensible. We waited until right after a major release, and then did our first rename. WHOA! All of our history disappeared on us, and we were in panic mode for about a half-hour until we discovered that even though we had lost access to all of the history, we could get it back by undoing the rename.

Reading the original blog by Matt just made my blood boil: "It was too hard for our programmers to make it work the way people needed, so we decided to change the functionality and call it 'slot mode'." Did it ever occur to the designers that maybe they needed a little help from one of the geniuses running around MS Corp? Like the people who designed VS & dotNET, which must be 2 orders of magnitude more complex than TFS. I can't remember any of my projects being stymied or compromised by design problems or bugs in VS, so why should I need to be avoiding a normal re-org of our storage structure because TFS will drop access to branch history? (Yes, I know that you can do command-line queries or use the VS extension to access the disconnected info, but it's not the same as just clicking History & being able to compare your changesets, etc..)

Posted by Shawnr69 on 4/29/2013 at 7:04 AM
I am really surprised this issue has been closed and we cannot vote on it to be fixed. It occurs in TFS 2012 as well. I agree with others that have commented on it being a poor design. There are a number of reasons why folders may be renamed/moved (e.g. wanting to put deprecated projects in a different location, misspelled folder, project name changed, etc.) and in each case I see no time when I would not want to see the whole history of the changes that occurred to the folder. This is an annoying enough bug to make us reconsider moving to TFS at this time. I hope this fix is considered for the next release or if possible a patch to the current release.
Posted by RyanGates on 4/15/2013 at 2:23 PM
This is only urgent if you don't want people migrating to git/mercurial, So I guess it's your call. Neither of those free open source products have this problem(I mean feature).
Posted by paulyphonic on 2/11/2013 at 9:18 AM
Works as designed doesn't mean much when it is a poor design. Fix it by redesigning it. It really doesn't matter what it looks like behind the scenes. Users want their actual use case to be supported. So if the data still exists, figure out how to show it, and show it!!
Posted by Jason D. Camp on 7/23/2012 at 11:32 AM
This makes me very sad that this doesn't work in the UI.
Posted by MS_NEVER_FIXES_ANYTHING_THEY_BREAK_THINGS on 1/26/2012 at 10:40 AM
This is another fail by the TFS team when they renamed vss to tfs

Posted by Doug Bennett on 2/24/2011 at 7:13 AM
Another spin on the same quirk, take a branch called "DEV" and *rename* it to "Old DEV". Next create a *brand new branch* called "DEV". "Old Dev" which has been around for years now has no history, where-as the shiny new DEV branch has the history of the "Old Dev" branch. The basic problem here is that the developers who "designed" this are thinking that renaming is creating a new folder (by implementation). Conceptually this is not the case. Rename is just giving a new name to the old branch, and it's history should correspond.
Posted by JBuzek on 2/14/2011 at 7:12 AM
It would be particularly useful when using Source Explorer to view the history of a branch that has been renamed to see the history of the branch all the way back to the changeset that established the branch. Perhaps the history of the branch under it's previous name could be indented (collapsed/expandable) under the changeset that contains the rename of the branch. Also, in the View Hierarchy visual view of the branch hierarchy, it would be useful to see that the branch had a previous name. If I look at a renamed branch in View Hierarchy, it looks like the current name was branched from the parent branch, but then when I do a view history on the renamed branch the history ends at the changeset that renamed the branch to its current name. It's certainly possible to figure out what's going on by looking at the rename changeset, and if you make deleted items visible as suggested, to then do a history of the previous name, but that's all pretty tedious, and it seems like there are existing conventions in View History and View Hierarchy which would do a nice job of giving one all that information in a single view.
Posted by Chris Lively on 1/10/2011 at 2:19 PM
Incidentally, subversion and other tools will retain history after a move command.

Instead of waiting until VS20xx, why not just release an update to fix this problem; and it is a problem. You could do it as a powertool or extension or whatever.
Posted by Microsoft on 7/2/2010 at 9:22 AM
Thanks for the feedback here. The previous comment about this being by design is correct, and there is an option on the command line. In the UI, history of folders is recursive - always. This is because most of the time, users care about the history of the contents of the folder. Files on the other hand dont have the concept of recursive history - you always see the history for the file itself. Now, from the command line, there is an option to show recursive history (/r) and if you run tf history on a folder without the recursive option, you'll see the changes to the folder itself. This would include changes such as a rename for the folder itself.

As for getting this in the UI, we've heard multiple requests for this, and we're tracking it as a possible feature for the next release.

Posted by B. Huard i on 3/11/2010 at 8:53 AM
I think this is by design with the new slotmode/Itemmode.

Is there a workaround (using the command prompt) to see the whole history underneath folders (after it was renamed) without going to each item?
Posted by Microsoft on 3/2/2010 at 7:07 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(