I've been using Git now for a few months almost exclusively. When I last blogged on it I'd been using it for but a few weeks. Since then I've come to the conclusion that it should be the de-facto choice for source control. This might be obvious to those of you that use Git on … Continue reading Update on experiences of using Git
git seems to be everywhere these days doesn’t it. Everyone is using it, and looking for any excuse to blog today, I wanted to share both my early experiences with it, and the new Microsoft git plugin for VS2012. Initial thoughts on git Pretty much like everyone else, I imagine. Branching is much easier to … Continue reading Better git integration for VS 2012
A new version of the Unity Automapper (1.3) is now available on NuGet. It now supports a fluent-style, provider API in addition to the attribute-based model for overriding default settings etc. I’ve also decided to open-source the Unity Automapper at this time and push it onto GitHub. There are several reasons for this. Primarly, I’ve … Continue reading Unity Automapper 1.3 released
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.
I recently installed TFS 2010 on my local machine for testing, but after playing around with it, decided that I wanted to try the new Labs feature of TFS plus some of the other stuff. Plus I didn’t want to keep running TFS all the time (and SQL) just in case I decided to do some development. So I downloaded Windows Virtual PC (WVPC) for Windows 7 and installed a version of Windows 7 on it. I then installed TFS 2010 along with SQL Express 2008 and hey presto, working TFS in its own environment. WVPC is pretty good; the only criticism I have with it is that it only emulates a 32 bit CPU (even though I have a 64 bit one). This is a little annoying as I can’t run Windows 2008 R2 through a virtual pc (as it is 64 bit only). However, aside from that, the whole process did not take that long:- Downloading the ISO for Windows 7 off MSDN: 15-20 minutes. Installing on the VPC: about the same. Installing and configuring TFS: 10 minutes The only thing that did take a while was installing SQL Express 2008 Management Studio and then exposing the SQL service to my host machine via Windows Firewall. But it’s all up and running now. I want to try TFS Labs but we’ll see how that goes…
I’m planning on using a “proper” Scrum TFS template on the next project we do. My understanding is that there are two main TFS templates available for Scrum: - Scrum for Team System (Conchango) VSTS Scrum Process Template (CodePlex) There’s also what looks like a handy dashboard TFS add-in which works with both templates. I’d really like to use one of these, but I’d like to know people’s thoughts on either of the templates – what did they like about them? What did they not like? What are the reports like that come with the template (if any)? Was it a pain to install the template? etc. etc. Any thoughts / comments greatly appreciated! Once I choose one and we start to use it, I’ll blog on how we’re finding it ourselves.
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...