Monday, April 30, 2007

Do charity work through Live Messenger

After a strugle with a broken computer the past weeks I found myself reinstalling windows once again and when I was getting a version of live messenger I saw that microsoft has launch a new charity program.

They will donate a portion of their advertisement revenue generated through there Live services when ever you send a instant message using live Messenger, you can even choose the cause you want to support (mainly american organisations) read more about it here.

Test Mangement in Visual Studio 2005 Pro and above...

Microsoft recently announce their intentions to release there unit test framework that is included in all Team System versions of Visual Studio 2005 for the professional version of VS2005 as well. This was great news and whats even better is that the after getting feedback on the subject they have decided to include the testmanagement tools in the package as well, read about it here.

Sunday, April 22, 2007

TFS Migration Toolkit now available on CodePlex

Yesterday Microsoft announce a pre-release an upcomming power tool called TFS Migration and Synchronization Toolkit, you can download it here.

The toolkit aims to help people with the migration towards TFS and offers a set of apis to make life easier for people with heterogenous systems by helping with bi-directional syncronization. Be sure to check it out and remember to be share your solutions (CodePlex is a great place for this) my guess is we'll be seeing some nice integration tools soon.

And a quote to rember when playing with this comes from Matthew Mitrik:

Please note that this is a prerelease version of the Migration and Synchronization Toolkit. Several features are not complete and as testing has not completed, the code has the potential to contain bugs and overwrite data stored in TFS. Please be careful to use this only in a testing environment and not on live production data.

Another one from Robert Horvick:

Oh - and this is still under active development (and has known issues) so if you have any feedback it's still early enough for it to be considered for inclusion in the final drop.

Thursday, April 19, 2007

Recreating your WIT database (part 3/3)

So to round of this subject there are some alternative approaches that you can use.

Moving source control contents, this approach consists of creating a temporary project where you can host a copy of your source controlled contents during the recreation of the project the steps to do this are:

1, Create a new team project.

2, Move all your folders directly under the root of your team project to the new team projects root and checkin the changes.

3, Delete the project using TfsDeleteProject.exe.

4, Recreate the project with the desired process template.

5, Move back all your folders from your temporary team projects to the newly created project and checkin the changes.


The major drawback with this is that you will get a alot of activity in your merge process due to the fact that all files in all branches will get marked as changed and if you like us have a branch intensive environment this simply is not possible.

Finally you should look at the upcomming power tool TFS migration toolkit the team that is responsible for this tool has a blog where you can keep yourself updated on the progress. The migration toolkit is looking promising in alot of areas (one being the possiblity to perform a move of the source control database between projects with out affecting the contents in it).

Recreating your WIT database (part 2/3)

Ok, so we want to recreate the team project so we can apply a different process template on it (you really only have to do this in case you need to delete/rename work item types) but we don't want to loose all our history in source control.

Here are the steps you need to do:

1, Back up all your databases acording to the documentation mentioned in part 1 of this post.

2, Copy all your drops of your team builds to a backup location.

3, Delete the Team Project using TfsDeleteProject.exe.

4, Recreate the TeamProject using the correct template and the same name as before.

5, Restore the TfsVersionControl database to it's original state.

6, Restore the team build drops to theri original location.


There reason this works is due to the fact that the only thing that links source control to the rest of the Team System functions is the logical path name based on the team project name. Thus if you have a project called "DEMO" the link to version control will always be "$/DEMO". This will most likely change when the Orcas release of TFS hits the streets since then we will get all kinds of goodies to deal with problems like this.

I've tried this on many projects and most have been a success, I have not lost any project doing this but our main project (the reason for even thinking about this) failed misserably when doing this since it was to big and generated a timeout exception during the delete process leaving it in an inconsistent state (we had to restore it and resort to a different method, which I'll probably post a blog about as well).

In the last part of this post I'll point you to a couple of different approaches that you can take if you like.

Recreating your WIT database (part 1/3)

Been awhile since I posted something now, I'll blame the weather :). Spring has come to Sweden and it's really lovely so it has mainly been gardening and not so much messing about with blogging and Team System.

Anyway today is a cloudy day so what could be better then posting something about our adventures concerning work items and customized process templates. When we first decided to adopt Team System as our source control and collaboration system we decided to move ahead quickly and just implement the source control parts and deal with the rest at a later date.

Boy was this a misstake, if you intend to not use the default process templates based upon MSF you must spend some time thinking through what you want to change since in version 1 of TFS there is no easy way of reversing your choices once you've created your team project.

I'll describe a way to recreate the WIT database for your team project without loosing your source control data, but remember that this solution is not for the faint of heart :) and as someone told me:

You should be clear that any messing around with TFS at that level is inherently complex and error prone (and not recommended :))


Well with that out of the way here are the documentation you need to have read through and made certain it works on your installation of Team System before proceeding:

How to: Back Up a Team Foundation Server

How to: Restore Team Foundation Server Data

Also I recommend that you read about and perform a move of your TFS so you got experience in disaster recovery in case anything goes awry:

How to: Move Your Team Foundation Server from One Environment to Another

Well that should be enough with the saftey stuff in the next post I'll explain how to actually perform the magic...

Friday, April 6, 2007

Some usefull links when dealing with notifications in TFS

I've been working with TFS Notification Services lately and figured I'd post the links I've found usefull when trying to get this to work the way I want. The first place to look should be "Filtering Team Foundation Server Events" in the MSDN documentation

Here comes a collection of good to have links on the subject, enjoy:

Naren Datha (Microsoft)
FAQ on VSTS subscriptions and common problems

Jeff Atwood (Vertigo)
Subscribing to Team Foundation Server Events

Howard van Rooijen (Conchango)
Team Foundation Server Notification Web Services: Visual Studio 2005 Project Template

Mathias Olausson (Callista Knowledgebase)
Using BisSubscribe.exe for Team Foundation Server notifications

Subodh Sohoni as SEED InfoTech
Articles on Visual Studio Team System (VSTS)

The order in your files, matters when merging...

This post is just some basics on how to behave well when dealing with merging changes from different branches.

A rather common scenario is to have a main trunk and then branch of a maintenance version and a production release and a ongoing project branch. When dealing with a structure like this there tend to be alot of different people involved and all that goes along with that.

So why does the order in your files matter then? Say for instance you have the following class:

    public class MyClass
    {
        public MyClass()
        {
        }

        public void DoWork()
        {
        }
    }


Then you find a bug in you production code which you have to correct asap and in the process needs to refactor the code for some reason ending up adding a new method to the class. Now our class looks like this in the production branch:

    public class MyClass
    {
        public MyClass()
        {
        }

        public void DoWork()
        {
        }

        public void OurNeatNewBugfixMethod()
        {
        }
    }


Then your people working in maintenance (maybe the same person that fixed the bug in the first place) have no patience to wait for the regular forward / reverse integration cycle between the branches and makes the correction in the maintenance branch as well. So far there is no problems, but what if someone else has added functions in the maintenance branch. No problems well just add the function last right? And the result would look like this:

    public class MyClass
    {
        public MyClass()
        {
        }

        public void DoWork()
        {
        }

        public void DoMoreWork()
        {
        }

        public void OurNeatNewBugfixMethod()
        {
        }
    }


So what's the deal? Why is this a problem? Well now the day comes when we do our normal forward / reverse integration cycle and the merge detects changes in the file in both you branches. If you as lucky the file in question is a small one like this example and you'll get a merge conflict so you can catch it right away. However real life tends to be less compliant and you'll most likely have a large file and the problem code will not lie within the same block and thus slip through with out any conflict. The resulting file would look like this:

    public class MyClass
    {
        public MyClass()
        {
        }

        public void DoWork()
        {
        }

        public void OurNeatNewBugfixMethod()
        {
        }

        public void DoMoreWork()
        {
        }

        public void OurNeatNewBugfixMethod()
        {
        }
    }


So the moral of the story is that if you need to take shortcuts in your forward / reverse integration cycles make sure that you place the code in the exact same place in both branches and you'll save your self some problems with failing builds.

If you are curious on what the heck I'm talking about when I mention forward and reverse integration check out my post on branching guidelines for TFS.

Thursday, April 5, 2007

BisSubscribe and none evaluating filter expressions

After pulling my hair and screaming in agony over the darn filter property of TFS notifications I finally managed to figure it out :)

These examples works:

bissubscribe.exe /eventType CheckinEvent /address some@somewhere.com /deliveryType EmailHtml /server mytfsserver


bissubscribe.exe /eventType CheckinEvent /address some@somewhere.com /deliveryType EmailHtml /server http://mytfsserver:8080

bissubscribe.exe /eventType CheckinEvent /address some@somewhere.com /deliveryType EmailHtml /server http://mytfsserver:8080 /filter "TeamProject = MyProject"

This one however does not work:

bissubscribe.exe /eventType CheckinEvent /address some@somewhere.com /deliveryType EmailHtml /server mytfsserver /filter "TeamProject = MyProject"

Since all commands will execute with no errors resulting in a subscription in the TfsIntegration.tbl_subscription one easily gets fooled into thinking it should work but in the case of the fourth command nothing will happen.

The reason for this is that the /server switch of bissubscribe requires a fully qualified url address to your TFS server to function properly but only if you specify a filter with the /filter switch.

Hopefully Microsoft will add some validation on this switch in the future since it's one of thoose things that are hard to spot when no errors are generated (when glancing over it you mostlikely will only register the server name as its correctness).

Tuesday, April 3, 2007

The old new thing a good dose of windows nostalgia and more


The Old New Thing: Practical Development Throughout the Evolution of Windows by Raymond Chen

I recently finished reading the above book and I found it to be a very entertaining read, it contains everything you wanted to know about windows and it inner quirks. Much of the information is explanatory information on why windows is behaving in as it does in regards to backwards compatibility, but you will also find many good tips on how to write better applications for windows in general.



The middle part of the book reminded me of the good old days reading Charles Petzold's book Programming Windows ... which in turn leads to another book (by none other that Charles Petzold) for people who like to read about historical stuff and computers.

Code: The Hidden Language of Computer Hardware and Software by Charles Petzold