"No history entries were found for the item and version combination specified"

July 2007 - My worst TFS fear almost happened today. I Right Clicked on a folder under Source Control and selected View History using Team Explorer. After spinning for a few seconds I got the error "No history entries were found for the item and version combination specified." "What the heck is that?" I said to myself. I was able to tree through the source and open a file, but couldn't do a Get Latest or perform any other function. "Am I loosing my mind? This just worked fine yesterday."

My first few hypothesis's were based on my previous experiences as a VSS administrator. "We have a corruption issue," I screamed out to my local contemporaries. The .NET guys had worry written all over their faces. The Java guys started to snicker.

I Googled the error and got back two unrelated hits. I Lived it, can ironically got the same two hits. Coincidence?

Anyway, after suffering a near break down, for some reason I decided to check the permissions of the project. When Right Clicking on the project, selecting Properties, then Security, the project had no one setup with permissions (or so I thought). That was odd? Since I'm part of the [Server]\Team Foundation Server Administrators group I thought I'd be able to add my account. Nope.

I then logged into the App Tier (don't tell our system administrators this) and checked the Security. Sure enough, I could see there was one group who had access to the project and it didn't include me. The Team Project administrator in London had adjusted permissions for the project. We centralized the Server administration, but decentralized some of the Team Project administration. I Logged onto the App Tier with an account in the local Administrator group and was able to add my account. Back on my machine then, I was able to do View History just fine. .NET guys were happy to see the error was so simple to resolve, the Java guys frowned and stuck their faces back in Eclipse.

So the moral of the story is, if you get the error "No history entries were found for the item and version combination specified" make sure you have correct permissions setup on the Source Control projects (a.k.a Folders).

Using Team Build for Java builds that use Ant

July 2007 - We're a Java development group using TFS. You're probably asking why a Java development group would buy TFS, which is a valid question. The answer is quite long and complicated (political), so I'll save the gory details for a future post. In short; though my group uses primarily Java, a group across the hall, which is equally sized, uses .NET. We're a fairly large software company who was looking for a cost effective solution that would satisfy both Java and .NET developers. After evaluating the array of offerings, TFS offered this for us.

To compile our Java code we use Ant exclusively and Anthill Open Source as a high-level driver to kick off the builds. If you're interested in using Anthill Open Source to talk to TFS, I hear there is a friendly open source developer ;) who has written an adaptor for you.....

Anyway, we really wanted our builds to list out the work items linked to changesets included in each build. Team Build gives us exactly what we want, but again we're a Java shop using Anthill. How can we use Team Build to run our Ant scripts?

We (actually my wonderful configuration management colleague who deserves all the credit for figuring this stuff out) had to override the "CoreCompile" target in our TFSBuild.proj file so we have control of what "compile" means for us. The full list of things "CoreCompile" does is located in the "microsoft.teamfoundation.build.targets" file. Since "compile" to use means call ant, we can override "most" of that stuff.

I say "most" because we do need to call MSBuild. If we don't, build results are not published to the data warehouse. This is a bit lame, but after we all got done cussing and swearing at Microsoft (remember we're a Java development group and take every good natured opportunity to bash Microsoft), we simply created a blank solution file, placed it next to our build.xml in source control and called it. The only two lines in the solution file are "Microsoft Visual Studio Solution File, Format Version 9.00" and "# Visual Studio 2005". It does nothing more than somehow signal Team Build to publish our results in the data warehouse.

After we get done calling the superfluous MSBuild task, we do the real work. We use the Exec task to call Ant with the needed parameters. Lastly we copied over the OnError task from the main "CoreCompile," which will execute the "OnBuildBreak" task in the master targets file (i.e. microsoft.teamfoundation.build.targets).

I don't consider this an optimal solution, but a step in the right direction. Our current Anthill solution has a nice feature where it will only build if there are changes. Team Build fires away every night, which ends up creating a number of needless builds. We also frown every time we setup a new project and have to put a blank Solution File next to the build.xml. Again, we get over it with a afternoon coffee and obligatory Microsoft bash session (all in good fun of course).

So if you're a Java group using TFS, give Team Build a try. It seems to be working fine for us, and once Orcus gets here Team Build should have a number of additional features (e.g. continues integration builds) that you'll want to take advantage of.

<Target Name="CoreCompile">
<TeamBuildMessage Tag="Configuration" Value="%(ConfigurationToBuild.FlavorToBuild)" />

<MSBuild Condition=" '@(SolutionToBuild)'!='' "Projects="@(SolutionToBuild)" Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);Platform=%(ConfigurationToBuild.PlatformToBuild);SkipInvalidConfigurations=true;VCBuildOverride=$(MSBuildProjectDirectory)\TFSBuild.vsprops;FxCopDir=$(FxCopDir);OutDir=$(OutDir);ReferencePath=$(ReferencePath);TeamBuildConstants=$(TeamBuildConstants);$(CodeAnalysisOption)" Targets="Build" />

<Exec Command='ant -f "$(SolutionRoot)\ant\build.xml" -Dappdeploy_nightly="true" -Dversion=0.0.0.0'>
<Output TaskParameter="ExitCode" ItemName="ExitCodes"/>
</Exec>

<OnError ExecuteTargets="OnBuildBreak;" />
</Target>

SQL 2005 SP2 and TFS RTM

July 2007 - We're running our Data Tier in a cluster and thus unable to upgrade to TFS SP1, as until lately TFS SP1's install was not supported on a clustered Data Tier. They have that fixed now, but since we're running fine in PROD, we've decided to wait for Orcus before we upgrade. With the amount of time we spent on getting TFS RTM running, we want to use the product and not continue to troubleshoot it.

We started off with SQL 2005 SP1 (plus a number of hot fixes that the DBAs take care of). For a reason unknown to me (probably just consistency in our data center) the DBAs wanted to upgrade to SQL 2005 SP2 (plus a number of hot fixes). We were a little nervous about this as according to Mr. Harry, they run MSSQL 2005 SP2, but also TFS SP1 (see link).

We got confirmation from our sales engineer that Microsoft was able to test the SQL 2005 SP2 and TFS RTM configuration and everything looks good. We've updated our DEV environment and can confirm that we've not run into any issues. We're planning on upgrading our PROD environment in two weeks.

If your DBAs are looking to get you to SQL 2005 SP2 and you're still running TFS RTM like us, feel free to upgrade SQL 2005 as it's worked fine so far.