I use a server workspace for my Visual Studio / TFS setup because our project far exceeds the 100,000 file recommended limit for local workspaces.
One of the drawbacks of a server workspace is that Visual Studio cannot automatically detect changes to files in the workspace if these changes have been made outside of Visual Studio.
If I believe there may be undetected changes lurking in my workspace, how can I tell Visual Studio to actively/explicitly check the integrity of the workspace. I.E. I need a "get" operation that assumes that zero pending changes may actually be incorrect.
There is a PowerTools command tfpt online which looks for files which have had their read-only attribute removed (if you were messing with them on the train home for example) but I guess you might have new files and need something like detected changes in local workspaces.
If you go into Source Control explorer you can right click your folder, select compare and then play around with what you need to compare the server to your local copy (file types, new files, different files etc)
TFPT Online:
http://blogs.msdn.com/b/buckh/archive/2005/11/16/power-toy-tfpt-exe.aspx
If you are using TFS 2013+ and Visual Studio 2013+ then you can use the "tf reconcile" command to analyse the differences.
https://msdn.microsoft.com/en-us/library/bb385984.aspx
The power tools "tfpt online" command has been depricated for some time.
Related
I am new at using tfs online and create projects. When I am creating a project on TFS online platform, and connecting from visual studio. So I need to map project on my disc. And I see a workspace that has same named my computer name. Does visual studio creates a workspace on visual studio for every tfs project? What is the goal of workspaces?
A workspace represents a mapping between a location in source control ($/SomeTeamProject/SomeFolder and a location on your computer (C:\SourceCode\SomeTeamProject\SomeFolder).
That's all. It's a very straightforward concept.
You can maintain multiple workspaces for purposes of isolation, or just have one workspace mapped to the team project collection root ($/), which means that every team project in the collection will be mapped in the same workspace. It's entirely up to you. The advantage of multiple workspaces is that you can explicitly avoid doing things like modifying a bunch of stuff across branch or team project boundaries inadvertently. If you have a workspace for a development branch, you'll only be able to check in a set of files in that branch. If you want to check in files in another branch, you'll have to switch workspaces. It can be a nice sanity check, but it's by no means a necessity.
Workspaces can consist of multiple mappings (for example, $/Foo/Bar -> C:\Foo\Bar, $/Foo/Baz -> C:\Foo\Baz would map those two folders, but ignore any other folders under $/Foo).
Workspaces can also contain cloakings -- explicitly excluding a folder from being mapped. So you could map $/Foo/ and cloak /$Foo/Bar if you wanted everything under $/Foo except the Bar folder.
Workspaces come in two flavors: Server and Local.
Server workspaces were the default from TFS 2005 up until TFS 2012. In a server workspace, every activity you take in source control has to happen through Visual Studio (or an equivalent IDE) -- starting work on a file contacts the server and checks the file out. Files are stored in the file system as read-only unless they're checked out.
Server workspaces are, generally speaking, awful. I do not recommend using them except for in a few very specific cases.
Local workspaces were introduced in TFS 2012 and were first supported (not surprisingly) in Visual Studio 2012. Local workspaces are slightly more Git-like in that editing files does not require an explicit check-out on the server -- you can edit a file at any time in any IDE. This allows you to work offline in a very limited fashion.
I have a VERY large project which just went through an upgrade process. The upgrade is a process external to Visual Studio. As a result, files that are deleted by the upgrade process do not get properly detected by TFS so TFS pukes on checkin saying that it can't find the file.
The problem is that there are several hundred files that need to be excluded to resolve the issue. I could do this for days before I'm done. I'm pretty sure my boss would prefer it not take several days.
Is there a quick way to find and automate the exclusion of these files so I can just be done with it?
You have two options...
Use a Local Workspace - if you go into the settings of your Workspace you can change it from Server to Local. This will allow the changes to be detected automatically. You may need to copy everything out and then back in if you have already made the changes...
Reconcile the difference - You can use the TFS 2013 Power Tools and the "tfpt online /adds /deletes /diff /noprompt /recursive directory-name" command...How to have TFS 2010 detect changes done to files outside of Visual Studio?
We are experimenting to use Microsoft Team Foundation Server Source Code Control as a replacement for SVN.
Therefore, it would be great if the friction for this transition would be minimal.
For example, in SVN, whenever I create new files in the folder, and then use "Tortoise SVN Check for Modifications", I get a master list of Added Files, Deleted Files, and Edited Files.
I know that in TFS SCC in Visual Studio, the equivalent is the Pending Changes Panel. However, this panel only lists Edited Files. How can I get new files listed in that panel, too, just like SVN does?
The workflow really depends on whether you are using Local Workspaces or the traditional Server Workspaces. As you are coming from SVN, Local Workspaces would probably be a good fit.
Local Workspaces (New to TFS 2012)
Local Workspaces are TFS's attempt at DVCS and actually gives you a much more SVN-Like experience. The pending changes window with local workspaces is divided up into the following areas:
Included Changes - This is effectively files that are already in Source Control that have been changed.
Excluded Changes - These are all files within the workspace that are not in source control. This is like your Added files in SVN.
Server Workspaces
Server Workspaces are the traditional TFS workspace approach. An item is not in Source Control until it is explicitly added.
There is a much more detailed article on the differences here: http://msdn.microsoft.com/en-gb/library/bb892960.aspx
Drag and drop your new files into the right folders in the Source Control Explorer in Visual studio and then there will be asked if there are also files that need to be excluded from the source control. If that is done they are in the Pending changes window. The implementation like SVN is starting from Visual studio 2012 but then still it can give issues and not be in that panel.
I see this is an old question but I believe the answer is in Visual Studio's "Pending Changes Panel" itself. Notice the "Excluded Changes (nnn)" section. Just below that heading you should find "Detected: nnn add(s)". You can see your 'new files' listed there.
For what it's worth, I find the "Pending Changes" an unwieldy feature in that it seems it's never context aware. I find that I often have to "weed through" many, many files that are simply not relevant to the solution/project(s) at hand.
i have used TF.exe (Team Foundation Client) to checkout files from outside with the following command.
http://blogs.msdn.com/b/noahc/archive/2007/01/22/real-tfs-command-line-help.aspx
tf checkout $project/filename
but, i need to checkout from outside when TFS server is also not reachable. In visual studio, it prompts us to work offline and then later on, it sync automatically with the changes into server when it goes online. How do i acheive the same from tf.exe or any other way to do it.
PS: i do have real requirement of editing some files which is not belongs solution files which gets modified from outside of visual studio. as of now,i am using tf checkout method to checkout the file from outside. but, this require connection TFS server all the time.
You can't do this with the command-line tools, because the offline mode is a feature of Visual Studio, not of TFS.
The tools always work directly with the TFS, so it must be online and reachable at that time.
Amendment regarding your P.S.: What Visual Studio does in Offline mode is just setting the local files to writable and "remembering" with which files it did that. Then, on going online again, it checks for any changes in the meantime. If there were any, it starts a merge process, if there weren't, it checks out the file without getting it.
There's no reason why you couldn't do this same process by hand, it's just more comfortable through VS.
BTW: Why not have a Solution for this "dangling files"? Just create an emtpy solution and add them as Solution Items. This way you can use the VS offline mode.
It seems that when I use a tool (such as winmerge) to update my codebase... my Visual Studio Team System (VSTS) integration with Team Foundation Server (TFS) doesn't seem to pick it up.
How do I know which files to check out and check back in? Is there something I am missing? Is this a feature that isn't part of VSTS & TFS?
First, this is probably because the files have not yet been checked out. If you do that first before running your update, TFS will see those changes.
Second, you can use TFS Power Tools (available from MS) to review local repository for changes that are not recognized. If there are found differences, power toys resets the status of the file so Pending Changes window sees the change. this does not require you to check-out the files, it will do that for you if there are differences.
Pretty nifty.
Power Tools for 2008 is here: http://www.microsoft.com/en-us/download/details.aspx?id=15836
and you are looking for the "Online" command:
"Online Command - Use the online command to create pending edits on writable files that do not have pending edits."
I assume you are applying changes across an entire project, outside of VS.
You will have to check-out the complete project first, then apply the changes and check back in. Unmodified files will not be actually checked-in, AFAIK.
Your question sound like as if you have not installed the Team Foundation Server Client.
If you have installed the Visual Studio Team System edition you are able to connect with the Team Foundation Server. But to have the integration working you need to install the Team Foundation Server Client as well.
After having done this your Visual Studio should inform you in case of file changes and then automatically check out the files.