Oct 28, 2010

How To Stop Users Creating Work Items In TFS

I regularly get asked if there is any way to prevent users creating certain types of work item in TFS – the most common scenario being stopping people who are using the work item only view from creating anything other than bugs.

TFS still doesn’t let me hide blocked work item types from the users in the first place, but I can at least prevent users creating new work items of a certain type, which is a nice workaround.

Here’s how:

1. If you haven’t done so install the latest Team Foundation Power Tools for your appropriate TFS version.  If you are on TFS 2010 you’ll want the TFS 2010 September release.

2. Start Visual Studio and use the Process Editor to open the work item type you want to edit
image

3. Go to the workflow definition for the work item type and find the initial transition – it will be the one where the workflow moves from a blank state to an initial state:
image

4. Double click the transition and in the properties locate the Transition Detail tab and the “Not” field. This field is used to exclude users or groups from being able to use this transition, so set the value as appropriate.  In the example I am excluding a dummy user from a local VM I have.
image

5. Publish the work item type back to your TFS server and refresh team explorer to pick up the changes.

Done!

Let’s check it.  Connect as a blocked user and try and create a work item – in my example I excluded my dummy user from bugs.  Initially I see that I need to supply the Title, just as I had to before:

image

However, once I supply a title I now see the following:

image

Notice that now the State field is showing as required, but I am now unable to set the state to a valid value which effectively prevents me creating the work item type.

Hopefully that helps.

Oct 22, 2010

Why does Git Merge Work Better than TFS Merge

The question came up during a discussion on our internal mailing list as to why Git’s merge is seen as better than the TFS merge.  What better way to explain it than via a worked example:

TFS Example

Consider the following solution in TFS:

image

Now let’s branch it for two different teams.  Team A and Team B.

image

Now let’s go into TeamA’s code and refactor SomeClass to have a better name.  Here’s the changeset that gets created.  Note that we’ve changed the .csproj and Program.cs as well since they both had references to SomeClass.

image

Meanwhile TeamB adds an extra property for some functionality they are adding:

image

Team A then merges back to trunk.  When merging in Visual Studio you can only merge between branches that are directly related to each other.

image

Team B then wants to merge to trunk, but as Team A checked in first, they decide to follow good practices and pull down the latest changes from Trunk and merge them first.  Because the SomeClass file was renamed we now have a merge conflict as seen here:

image

And until we fix it our solution is broken.

image

Visual Studio asks us what we want to do with the file name and we need to figure out what the right option is.  Giving choice like this to the user is unnecessary and can easily result in a big mess.

Git Example

Let’s do the same thing using git.  We start by creating a new project and making the two team branches.  Note how the branches all point to the same commit instead of creating copies of all the files.

image

Now let’s refactor the TeamA code and add the property to TeamB as we did with the TFS example and commit the changes.  We see the branches now have some changes and are diverging from each other.

image

Now let’s merge the TeamA changes to TeamB.  For consistency with the TFS example we’ll do it by merging TeamA to master, and then master to TeamB

image

Note that the merge from TeamA to master is a fast-forward merge.  This happens because trunk hasn’t changed since TeamA branched so master can just be repositioned to the TeamA commit..

You can see that in the second merge from master to TeamB an auto-merge occurred, and git automatically detected that the changed SomeClass.cs file and the new SomeBetterName.cs file are actually the same file (with an 84% certainty), so it performed a rename for us automatically.

When we reload the solution in Visual Studio, everything looks fine, and we can get on with our development activities.  Here’s what it looks like in the repository viewer:

image

As a note, with git we don’t have to go via the master branch to merge TeamA changes to TeamB, we could have just done git merge TeamA as shown here:

image

For reference, you don’t have to merge from TeamA to TeamB via Trunk in TFS either.  TFS has a baseless merge option that you can run via the command line, though when you do the branch history can get a little messed up.

Here’s hoping that the next version of TFS will have a much better story around rename detection and version control in general.

Oct 16, 2010

Visual Studio and Deja Vu

This a post about fonts, not echoes of memories, just in case you’re wondering.  Now, let me say from the outset that I like Consolas and think it’s a great font, but almost everyone I know who uses Visual Studio does so using either it or one of the other fixed width fonts supplied with windows.

Given that the font is the thing I spend most time looking at, I wanted something a little different from the norm and that my eyes liked better so when I came across the Deja Vu font via Twitter I thought I’d give it a try.  And I must say, I’m very happy with it.  Here’s a screenie of it in action:

image

As you  can see it’s got dotted zero’s, good fixed width (mono spaced) characters, is sans serif and has quite a different look to Consolas, shown here for comparison

image

Oh, if you’re wondering, that colour scheme is the “Easy on the Eyes” theme from StudioStyles, but with a light coloured background instead.

As a note I’m also using DejaVu for my command prompt font as well:

image

Note that there’s a trick to getting other fonts in the command prompt these days, which I only ran across recently when looking at the Meslo font, which for reference looks like this in Visual Studio:

image

As you can see, Meslo is similar to DejaVu in overall style but the characters are a tad wider, punctuation characters are bolded and the line spacing is a little larger as well.  I’m happy to stick with DejaVu.

What about you? Are you still using the defaults or have you given your settings that personal touch? Feel free to post a comment with a link to your font of choice.