Building Blocks

When merging conflicts between branches in TFS, there is a dialog for mering multiple conflicts. When you select more conflicts and wish to take either the target branches version or the source version. The Dialog uses the terms Server and Local changes instead. The end result I keep refeering to the following blogpost to make sure I select the correct option.

http://blogs.msdn.com/richardb/archive/2007/06/04/ui-bug-resolving-multiple-merge-conflicts.aspx

I hope they’ve fixed this in 2010, but I have yet to try it in the Beta.

I ran into this issue at work today. Another team depends on my teams code to create customer specific solutions. Now they have an issue where they have to keep track of which versions are currently in use, and produce software for the different solutions. Now I have issues with keeping more than one version of working software in production. The administrative cost for this is enormous and it keeps the organization from scaling.

This is one of the problems that could arise from keeping more than one version of the same software in production. The team that creates customer adaptions have to keep references to the different versions of code.

This means that they might have to compile the same code but with two different versions of the software. Either they keep two versions of their software checked in under source-control at two different locations, or they keep two versions of the references checked in, or both.

Using source-control in this way defeats the purpose of using source-control. You do not use the time dimension of the source control system, instead your just using it as a shared folder.

Instead the way to use source-control is to check-in the references for each version they have to support, in order. Keeping them at the same place, this enables them to get the specific version of the reference and compile a custom delivery for that specific version. That way you are working with the time dimension instead of working in parallel to it. Dependency management can become a pain in the rear if you don’t use the tools for what they are worth.

I keep forgetting this option in the team system powertools. The rollback command undoes all change sets to a specific point, this is done by reverting the changes. That is it checks out the files and changes them to specified version, deletes new files etc. As such it doesn’t actually Undo, but it helps you create a rollback for a specified change set.

Just needed it, so its nice to have as a option.

Simply do:

tftp rollback

And you are presented with a ui to select which change sets to rollback.

A while back I posted a post about a concept I call the Independent trunk.
The core concept is that everything required to build a distributable version of a software product is checked in under one branch in the source-control system. A build system should get everything it requires to build the system from the branch and shouldn’t need any more sources.

Ideally I would thus like to have custom buildtasks checked in under the branch so that the custom build processes for the product follow the evolution and version history of the product.

Now buildtasks for MSBuild doesn’t change very often, so we had a theory that we could have a compiled version of the checked in as a reference for the build system. Having the buildtask set up to be checked out and checked in as its recompiled.

Anyway we looked into this, this week. It turn out that such a setup is not valid for MSBuild. The reason is due to the order in which MSBuild does things.

See first MSBuild compiles and checks the project files and their structures. Then it goes to fetch the sources needed for the build.

This means that in order to have custom buildtasks they have to be avaliable from the same location that the TFSProj file is located or be avaliable before the sources are fetched from the server.

All in all, we cannot have the buildtargets checked in with the product under source-control.

If anyone have an idea on how to get around this constraint I’m all ears.

We’ve changed most of our projects to import other .target files. This means that we get allot of warnings about unsafe imports.

To eliminate these we can add a registry setting with the file name of the .targets file in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\9.0\MSBuild\SafeImports.

However this needs to be the full path of the file, which makes it problematic for branching and for teams without common rules of where to put their work spaces.

Our initial idea was to create an .inf file that adds our project targets to the registry, but the full-path requirement spoils it for us as we use allot of branches.

For more information I found this how-to.

Along with this Forum entry in 2005, describing that this has been reported as a bug.

Ever experienced having multiple entries of the same menu item in Visual Studio 2008?
Well, I have.

See what happens is that all of a sudden, usually related to an installation of a plug in or third party tool; my Visual Studio displays each item in my menus and toolbars several times, this also includes the sub menus and context menus. The record so far is 12 times for each item.

I forgot to screenshot, but lets just say that the environment gets hard to work in.

I’ve solved it once by reinstalling (repair) Visual Studio 2008, but after SP1 of .Net 3.5 this did not work.

Instead I found the following forum entry on MSDN forums.

This resolved the issue for me.
In fact all I had to delete was the devenv.CTM

The path for me on Vista was:
C:\ProgramData\Microsoft\VisualStudio\9.0\1033

Hope this helps someone else.

The independent trunk

Manging source control is a fundamental task in any software development environment. I do not claim to be anything of an expert in the area, but I have a theory for setting up the environment that Id like to share with others.

Lacking a name for it I’m going to call it The independent trunk. The idea is to have all the requirements for building the system checked in under source-control in the trunk. This includes binaries and third party components, build scripts and build tasks. While it might not sound as much of a revolutionary idea, I believe it is one take a closer look on.

All you need to build the system, and all you need to set it up.

A few years ago we had a release process that took hours, if not days. We had to find all the documents specifying how to install, configure and update the system we were working on at the time. We had to place all the documents in a specific release structure, together with the different parts of the system. Clients, web-pages, database scripts, all these had to manually be placed in a structure and verified for a release.

Needless to say, a release process like this costs money and if you want to release every other week it costs too much. So when starting of our current project we said that the release process had to be automated. Inspired by Mary Poppendick’s book “Implementing Lean Software Development” I created a build that we called the package build. The idea is that it takes all the parts of the system and combines them in a releasable package. This means among other things that we started to check our configuration documents into the source-control system, so that they are available for the build system to be included in the build structure.

The package build has of course evolved since then, which is another story all together, but its fundamental purpose remains the same. Important to note, however; is that all our builds can be run on a developer machine. This includes the package build.

Your system is not only your source code.

The system were building is not only the source-code and documents, its much more than that. It is also a product of our development and the tools and third party components that we combine our code with. This means that our system is tightly coupled with the versions of the tools and the components we build it with.

We started by adding third party components in a folder under the trunk called References. By placing third-party components in the source-control they don’t have to be installed on each individual developer machine, and you guarantee that each developer will use the same version of the third party component. Doing this was not straight forward to us as a team and as usual we had allot of discussions around the subject. However it turned out to be a good idea. Naturally this means that there might be some big files checked into source-control, but the benefits of having them checked in far outweighs the drawback of paying a few bits of extra storage.

Our development environment is based on Microsoft Team Foundation Server 2008. One of the new features in TFS2008 is that the build definitions can be placed in any part of the source-control, opposed to placed in the special BuildTargets directory in TFS2005. While converting to TFS2008 we placed the build definitions a part of the solution its supposed to build.

These two changes in how we use our source-control system means that; no matter what version of the system a developer wants to build, he or she can fetch it from the source-control. This results in a structure that is a ready to build using the versions of the third-party components and build scripts and setup instructions used for that specific version of the system.

This is extra use-full for someone who just received new hardware as all the have to do is make sure Visual Studio is installed, get latest and run a local Package build. Then they are up and running with the latest version of the source-code compiled and ready.

I ran across a problem earlier today, our reports in TFS2008 hadn’t updated for 4 days.
Turns out that the scheduling process for TFS had stoped without warning.

If you run across this problem make sure that the “Visual Studio Team Foundation Server Task Scheduler” is running.

This blog post details of how to force an update of the TFSWarehouse.