TFS

The project I’m working on currently has two branches; a main trunk for hot-fixes and a branch for a new module which will be released at some stage in the future. We’re getting a few issues with check-in policies and builds as a result of branching, however. For example: - Continuous integration. We’ve had to turn off the CI build in TFS as whenever anyone checks in anything to the “new module” branch, the main trunk CI build kicks off. Is there a way to change this so that it only happens when a check in occurs for that branch of code? Our unit testing check-in policy is playing up now. It complains that certain unit tests haven’t been run as a result on check-in. I can only assume that this is because the policy points to the main trunk’s VSMDI file, whereas when you run unit tests on the branch, that runs that version of the VSMDI file. As we’ve removed some unit tests from the branch version of the application (due to them no longer being appropriate), I suspect that TFS thinks that we’ve not run all the units tests, when in fact we have. I can’t figure out a way around this, though…. any ideas welcome.

At my office we we discussing the differences between these two ways of getting source code from TFS are, and I wanted to find out once and for all. I have found some people generally use Get Specific because Get Latest “doesn’t work” / is buggy / is unreliable / doesn’t actually get latest code (?) or something similar. What are the real differences between them? When should we use one and not the other? How do Workspaces fit in with these two features? Workspaces OK. To start with, I went through Workspaces and how they work – and, importantly, how do they make TFS by default act differently from SourceSafe (VSS)? This is how I understand it: - Workspaces are a local cache of the code in TFS. When you pull code out of TFS – whether it’s by GetLatest or GetSpecific - the code is stored locally in some folder that you never know the name of (or care about, really). The files in this workspace can be thought of offline-version of TFS against which all your changesets are managed. Checking out a file When you edit a file for the first time after getting code, the TFS plug-in does the following: - If you are using single check-outs, the plug-in checks with TFS to see if the file is locked. If multiple check-outs are permitted, this is ignored. If the file is unlocked, the plug-in removes the read-only lock on your local file and marks the file as checked out in TFS. Assuming (2) was successful, if you are using single check-outs, it also places a lock on the file to prevent anyone else checking it out at the same time. At no point in this process does TFS check whether the version of code in your workspace is the same as what is centrally stored in TFS. Checking in a file Imagine the following scenario (assume that we are using single checkouts for simplicity): - On Monday Jim does a Get Latest (or Get Specific) of all files in a TFS project. This code is copied onto his local machine’s workspace, and also to wherever he has mapped the workspace to e.g. C:\Dev\MySolution etc. On Tuesday Sally start to work on File A and checks it out exclusively. At this point, TFS knows that she has a check-out on the file, but that’s all. It does not know what the changes she is making to that file are. On Wednesday she checks in her changes of File A. TFS now has the latest version of code. Jim’s workspace version of the file is unchanged. On Thursday Jim decides to modify File A. The plug-in checks out the file exclusively to him and places a lock on the file in TFS as already described. The version of the file he modifies is the original version he got on Monday. He does NOT get the version which was checked into TFS yesterday by Sally. On Friday Jim is finished with his work and checks it in. The TFS plug-in pops up with a message asking him to merge his changes in with TFS’s version of the file. This is to resolve the changes he has made and the ones that Sally made earlier in the week. This shows that you can get the merge dialog even in a single check-out environment, not just with multiple check-outs. The old VSS way that this process would have worked would be on editing the file ((4) above) that the plug-in automatically pulls down the latest version of File A. The reason why TFS does not do this is to prevent you accidentally breaking your local build i.e. you get the latest version of File A which references File B which was checked in at the same time by myself on Wednesday. You don’t have File B, so your build will break, forcing you to do a full Get Latest of code. You can do it get the TFS plug-in for VS to behave in this way: - Open up Team Explorer. Go to the root node of your project. Right click and select Team Project Settings –> Source Control… (you will need Project Admin rights to get this option) Select “Enable get latest on check-out”. That’s it - you’re back to the original VSS behaviour. Get Latest vs Get Specific version I’ve searched everywhere for a definitive answer to this one. I’ve been using Get Latest since we started using TFS and don’t get any problems with it, ever! What I have read is this: - Get Latest will synchronise your local workspace (and the mapped development folder) with all the files checked into TFS. This means it will: - Update files already in your workspace that differ from TFS (bringing up the Merge dialog if necessary) Add any new files into your workspace Remove any deleted files from your workspace Get Specific (provided that tick a few of the boxes in the dialog) will get EVERY file from TFS under the node you’ve requested, even if they match the copy of the file in your workspace exactly. When is Get Specific “better” than Get Latest? Under what circumstances would Get Latest not be enough for you? I can’t think of any for day-to-day development. I’ve found a few blogs on this issue – the overriding situations where Get Latest will not get your the same set of files on your machine is if you have :- Removed files outside of Visual Studio, in which case the TFS plug-in will not know that you have removed the file and will not get it from TFS when you do a Get Latest because it still exists in your workspace. The solution is to either delete it through Solution Explorer in VS or through Team Explorer. Conversely, if you delete a file in e.g. Windows Explorer, when you check-in your changes, I don’t believe that TFS will know that the file has been deleted (for the same reason), so won’t delete it from TFS. If someone can confirm this that would be nice 🙂 Removed the lock on a file manually i.e. right click to get properties and remove the Read-Only flag. In this case, when you Get Latest on the file, it will not do any change tracking because again the workspace does not know that you’ve editing the file, because you never had to remove the lock in the first place. When is Get Latest “better” than Get Specific There’s nothing “better” in terms of the accuracy of files that you will get using Get Latest. However: - It’s much quicker, as it only pulls down files that are different between your workspace and TFS. In a slow network environment this might be very important! You don’t get VS going bananas about reloading projects. Designer-generated files There is one unique scenario where things can go belly-up when resolving your check-ins – designer files e.g. Forms, Entity models, DataSets etc. which have designer.cs / .dbml / xsd / xss files that are generated by Visual Studio when you made changes in a designer surface. When you check in your e.g. Form, if someone else has made changes to the same form (the visual part, not the “code behind”) in the meantime, VS will fail to resolve the differences automatically and ask you to resolve the changes manually. If you fancy going through a designer generated file, this is of course not a problem 🙂 But I’d sooner undo my checkout on that file, get latest, and make my changes again. In a single-check out environment, the only way to guard against this is to force the “Get Latest on Check Out” feature on developers. However, in a multiple check out scenario, even using both Get Specific Version and the Get Latest on Check Out feature of Visual Studio will not save you from this situation! As far as I can tell, there is simply no way to prevent it happening. So, if you are using multiple checkouts, be careful when working on designer-generated files – maintain short check-outs on them so that the risk of someone else working on them in the meantime is reduced. Comments welcome… See also: - TFS Top Tip #11 - Removing source control files from your local file system Why "Get Latest" sometimes doesn't...

I've recently started looking at using Team Build to perform scheduled builds for our development projects. We're currently using TFS 2005 (although we'll be upgrading to 2008 shortly). However, I've come up with an issue on the build machine. TF Server -> Build Server -> Deployment Server The Team Build service is installed on the Build Server. When a team build is performed, the service contacts TFS, pulls down the latest source code, performs a build, and dumps the output onto the Deployment machine. I installed Team Build onto my local machine - it worked fine. However, I then installed it on another machine, and the build process refused to work. The error I get is "TF42056 - The build service could not connect to the Team Foundation Server: Unable to connect to the remote server". I'm not entirely sure what the problem is though. I know that TFS is able to communicate to the Build Server, because if I disable the Team Build service it comes up with a different error (something like can't communicate to Team Build service). Despite the error message, I also think that the Build Server can communicate back to TFS, because this TF42056 error ends up getting logged in the Event Log of the TF Server (unless the Build Server is timing out when trying to contact TFS, I suppose). So where is this problem occurring? I can't figure it out! I've Googled for this, but the TF42056 error seems to be a generic connection problem with more specific details - no-one else has this "remote server" one. Any ideas?