Our TFS is not set up to be used in the traditional way since we moved it from Visual Source Safe which had a user\project hierarchy. Now I need to do a Move command to give another user a project that he is taking over from me and I want to use Move so it will preserve history. I understand that the parent of what you are moving must have mapping set up in order to get the option to Move activated and I've done that but it gives an error when attempting the move.
I hope the picture gives a better understanding. Help! Please!
Unfortunately, the 'Move' option will only move source files without their history information. TFS doesn't provide any feature to move items with history. You could use some other tools like TFS Integration tool.
Actually, when you use the 'Move' option to move, TFS first copy your files to your target place then delete the original files, so it looks like a migration.
That's why the history can't be seen after moving. The old history is still under the original place.
In addition, when you 'Move', the parent folder should be mapped and the target place folder should also be mapped.
Related
I have various solutions checked in to a VSTS online account.
Sometimes I have the need to create a new solution from a copy of the code of another, and then to check this back in to VSTS to work on as a separate project.
Is there an easy way to do this in Visual Studio?
In Source Control Explorer there is the Move option, but why not a Copy option?
(I am not talking about branching)
Move is a in effect a combined operation done atomically by TFS. Its essentially a delete and rename. It also retains history.
The following image shows moving a file and then moving it back. You can see the change to see what TFS did to the file.
If you are talking about taking code files from one location and copying to another, it's essentially a local file level operation. From a TFS point of view, it would be simply an "add" operation that you would need to do explicitly.
Copy does not make much sense when using a source control system.
As suggested by others you can make a branch, as this will give you the result you want. This could be seen as a copy, besides it not taking up space for the duplicated files.
I am cleaning up TFS which has multiple projects and multiple folders within. I want to move folder from one project to another. The 'Move' option in the right click menu is disabled until I get the source code. I want to know if there is a way to move it without getting latest. I want to avoid the 'getting latest' activity since that is time consuming.
No, you have to pull the files local first.
I have two VS2013 sessions opened, each with a solution that is version controlled by the same visualstudio.com TFS repository.
In one project I wanted to check in some files, but Check In will always want to check in changed files from all my other VS projects.
Is there a way to make Check In work only on the current project?
It's very confusing when checking in project A also checks in project B when I am not ready or certain about the state of project B.
Check ins are based on your workspace, not the solution or project you are working on, which means a check in will always detect changes made in any of the folders that have been mapped from source control, regardless of which instance of Visual Studio they were made in (since it looks at the physical disk to determine what changed).
You can be more specific about your workspace mappings and/or use multiple workspaces if you wish to have a smaller scope for your check ins, though this brings with it usability complexity as you now need to ensure source control explorer and pending changes are referring to the correct workspace.
If instead of checking in with no scope (defaults to workspace wide) you can right click on the scope you want.
If you right click on the solution and select check in, Visual Studio will filter the checkin for you. It will be scoped to only files in that solution.
Whenever this happens to me, if I have made changes in the VS instance i do not want to check in, then navigate back to the one i want to check in, I am presented with an alert box that says something like "the files have changed, would you like to update them?" If this is true for you, you could just say no.
Alternatively, if the each VS instance is touching code in different branches, then you may choose to "exclude" (in team explorer) these other-branchly files.
In order to clean up my project structure, I moved a folder into another (new) folder through the TFS Power Tools Shell-Extension (Rename/Move).
After checking the history at the new place, the move is the only entry. (I tried one folder up, down, even on single files in the moved folder.. same result.)
I had also put on some labels on versions of the folder before the move, since there were some important states of the code I wanted to get back to.
So.. what went wrong, and how can I either get the history or at least find out the label names again and check out those versions?
Turns out it is pretty easy.
In Visual Studio 2010, go to Tools->Options. There you can find the option to show "deleted" items (roughly in the middle of the dialog box). The old folder got deleted during the move - it will be displayed again after activating that option. (They will be kind of grayed with a red cross.)
Labels seem to have disappeared, though, so I had to go by version.
In the Source Explorer you have the normal operations again - like View History or Get.
DISCLAIMER: For reference of everyone that gets here, this answer is not fixing #Andreas problem, just giving some context on why this happens and offering a couple of workarounds.
Seems that losing history when moving folders in TFS 2010 is not a bug, is a "feature". (still happening in TFS2012. From this MSDN link you can read official Microsoft answer:
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.
Workaround to get history once lost: As you can see there, you have a workaround using tf history.
Workaround to avoid losing history: If you want to avoid losing history in folders instead of using move feature, you can use TFS Integration tool to migrate code from one folder to other preserving history, migrating from $/TFSCode/FolderA to $/TFSCode/FolderB. It is a little bit overkill but if the history is pretty important for you is much better than looking for it in deleted folders
It is true that the folder history is lost, but the individual file history is actually not lost. It is hidden under the little "expand me" arrow at the far left on a file history line. Expand it on the oldest history entry for a file, or anywhere you see it, and you will see history of that individual file also from an old location that no longer exists.
At the top of History window you can edit Source location, put the old name and get the full history before it has been moved.
Also, is good to mention that you can get the full history back by moving/rename the branch back to the old location/name.
I have a workspace where I want the repository root mapped to a particular folder (e.g., $/ mapped to D:\Home). This then picks up the default "natural" folder structure in the repository without having to map stuff manually.
There's a pair of subprojects that I had under the default TFS structure and were recently moved around under another folder. TFS helpfully remembers that those were pointed to a particular location on my hard drive, but what I need is for them to lose the (now) custom mapping and simply go back to picking up the default mapping location based on where their parent folder points to.
I can see an option to remap the folders, but no option to simply drop the custom mapping. IIRC Visual Source Safe had a way to do this -- to just stop mapping a folder in a custom way and return it to being mapped by default based on its parent folder. But I can't figure out if TFS can do that as well...
If it makes any difference, this is TFS2005 being used from VS2010.
EDIT
Here's an example to make this clearer. Say $/ was mapped originally to D:\Home. So $/Foo would map 'naturally' to D:\Home\Foo. $/Foo/Widget was also mapped naturally to D:\Home\Foo\Widget. Then Widget was moved from under $/Foo to $/Bar, but TFS is still telling me that the mapping is to D:\Home\Foo\Widget, when I want it to be D:\Home\Bar\Widget. I want to remove the custom mapping and let Widget be mapped to the 'natural' location under its parent folder, not point to the older location.
I think I understand what you are trying to do.
How did you move that widget? Did you use TeamExplore -> Source Control Explorer to move it? If not...
Open Source Control Explorer -> Go to your widget and right-click -> Move (Option is directly under Brancing and Merging)
You will see a dialog with a From and To box. Browse to the new location on your HDD and move the widget.
In this way, TFS will pickup the new location correctly and it will be naturally mapped again. Anytime you want to move Widget (where widget = project or folder etc) from $/something to another $/something use the Move tool. Checkin in the change and you should be good to go.
When you create a Working Folder within Team Foundation Server, you specify the server path you want to map, the local path on your computer, and the recursion level. For folders beneath those paths, the server determines the local paths based on those mappings (and recursion level) but it does not actually create any new mappings or any long-term state, the local paths will be recalculated. (In other words, there's nothing to clean up after a rename.)
If a folder rename is checked in on the server, to update this on your local workspace, you simply need to do a get on the parent folder. For example, if $/Foo is renamed to $/Bar, you should do a get on $/ in order to get that rename locally.
Nice and easy. Everytime you associate a file by checking it into TFS, TFS remembers the source path by creating a reference to it in the list folders mapped to your workspaces.
To clean this up, open Visual Studio, Connect to TFS. Go to File menu, chose Workspaces. You will see all the mappings that visual studio has managed to create for you. Feel free to clock or delete the ones you are not interested in. http://msdn.microsoft.com/en-us/library/ms181386.aspx
HTH.
Cheers, Tarun