Installing TFS Power Tools with PowerShell 1.0

This is not really related to TFS, but I need a place to write it down and my TFS blog felt like the best place. So we could install TFS Power Tools on our application tier we had to install Power Shell 1.0. Unfortunately when we tried to install PowerShell but got the error listed below.

0.313: 2007/12/27 10:42:01.209 (local)
0.328: d:\4dd898e4a95d73bd5cfec8a50379\update\update.exe (version 6.2.29.0)
0.344: Failed To Enable SE_BACKUP_PRIVILEGE
0.344: Setup encountered an error: You do not have permission to update Windows Server 2003.
Please contact your system administrator.
0.359: You do not have permission to update Windows Server 2003.
Please contact your system administrator.
68.000: Message displayed to the user: You do not have permission to update Windows Server 2003.
Please contact your system administrator.
68.000: User Input: OK
68.000: Update.exe extended error code = 0xf004
68.000: Update.exe return code was masked to 0x643 for MSI custom action compliance.

I found this article from Microsoft. It looks like the machine's group policies were a bit out of whack. We fixed them by going to Start > Run > gpedit.msc and following the steps listed out in the article above I was able to add machine-name\Administrators to the "Back up files and directories" policy, "Restore Files and Directories" policy.

After a reboot we were able to install PowerShell 1.0 and TFS Power Tools.

Teamprise 3.0 Preview Release #1

If you use Teamprise, which you should if you want a great cross platform tool, you'll want to check out the Teamprise 3.0 Preview Release that just came out. 3.0 has a number of nice features like check in policies, Team Build integration and recursive compare that you'll want to take advantage of. Contact support for details.

I've played around mostly with the recursive compare and sent them the following feedback.

• When you "Compare" source tree (e.g. $/TeamProject) to local workspace (e.g. c:\my_development) the Compare tool you setup under Tools > Preferences > Compare Tools is not used when you double click on a file. Should it be? I noticed that when I compare file to file, the compare tool I selected is used.
  
  
• Maybe just a personal preference, but I notice that other tree structure diff tools (e.g. TreeDiff for Team Explorer or Beyond Compare, or even Source Gear's DiffMerge) they use a common format where location #1 is on the Left Hand Side and location #2 is on the Right Hand Side. I think something like that would be more familiar than the single Structure Compare window like 3.0 preview #1 has now.
  
  
• It might be nice to add some of the Source Control functions in the compare window. For example if you see a file has changed, but is not checked out, the user can Right Click and say Check out for Edit. I think VSS had this and the TFS Power Tools Tree Difference has this as well.
  
  
• Along with the bullet right above is might be nice to have some Source Control meta-data with the files. Like maybe show if they are checked out or not.

Team Explorer and Teamprise Date format difference

So I'm writing this extension for Anthill Open Source so that Anthill can talk to TFS from a Unix/Linux machine. We still have a need for Anthill and it was requested of me by our testers. I did the same for Windows months ago and it has worked remarkably well. See my previous posting on where to get the code. I only mention "remarkably well" as there is probably a good reason why I don't develop much software; I was never very good at it.

The Window's adapter uses tf.exe which is provided by Microsoft. The Unix/Linux version uses Teamprise. Both command lines work well for what Anthill needs to do.

In Anthill there is logic where it will check to see when the last code change was and compare it with the last successful build Anthill has recorded. If there is a change AFTER Anthill's last successful build, a build will fire off. If there is NOT a change, the build will not run. Very nice feature that I think Team Build will have in TFS 2008. If not, my colleague wrote a program that does this for us in Team Build 2005 and we can just apply the concept to Team Build 2008.

Back to Anthill. What we do is run a history command to get back the "Date" of the most current changeset on a particular folder. Tf.exe gives us back the format "Wednesday, May 23, 2007 4:25:41 PM" which translates into a SimpleDateFormat of "EEEE, MMMM d, yyyy h:mm:ss aa". Teamprise on the other hand, returns "May 23, 2007 5:24:39 AM" which translates into a SimpleDateFormat of "MMM d, yyyy h:mm:ss aa". This causes a cross platform issue as the SimpleDateFormat is used for the compare with Anthill's last successful build.

I've modified our code to account for the difference and will be posting it back up to Anthill OS as soon as we have it fully tested. I doubt many people will have an issue like this, but if you are depended on the "Date" format coming from Team Explorer and Teamprise, note they are slightly different.

Permissions for Labeling

A colleague of mine ran across an interesting scenario today. They have a large Team Project with multiple code bases in it. They control permissions in Source Control so only certain groups can work on certain code lines. An example is something like this:

$/TeamProject/CodeLine1
$/TeamProject/CodeLine2

They wanted to ensure that only "CodeLine1 Contributors" could label CodeLine1. And vice versa. To do this, they gave "CodeLine1 Contributors" LABEL permission to $/TeamProject/CodeLine1. And vice versa. But when a member of "CodeLine1 Contributors" tried to label "CodeLine1" they got the error TF14098: Access Denied: User %USER% needs Label permission(s) for $/TeamProject.

My assumption is that when you label a folder in the structure, the label is actually applied to the folder's parents as well. I'm pretty sure there is good reason for that. I'm guessing it has something to do with the fact that when you label something you want to take a point-in-time baseline of the artifacts. Since the parents are part of the artifact structure, it applies the label to the parent as well. This is just a hypothesis, but I think it makes sense.

Anyway, to fix this "CodeLine1 Contributors" and "CodeLine2 Contributors" need label access to $/TeamProject. At that point then I think you can DENY "CodeLine1 Contributors" on CodeLine2 and DENY "CodeLine2 Contributors" on CodeLine1. Obviously if you have a ton of code lines in one Team Project this can take a few minutes to get setup. The good thing is, I think you only have to do it once.

Please feel free to refute my assumptions if you find them incorrect.

Initial Results of TeampriseBuild for TFS 2005

I've spent a few hours working with TeampriseBuild and to be honest, I love it! With Martin's instructions a novice could get up and running within an hour or so (I seem to take longer due to excesive note taking and pondering). That is assuming their Ant scripts work autonomously from the initiation mechanism. In our case they are, so I was able to simply use his instructions to call an Ant file just like we'd use Anthill our CruiseControl to call an Ant script.

I did have to edit the WorkspaceMapping.xml to make sure you're not bringing down too much code. This has nothing to do with TeampriseBuild, just an observation of Team Build that is not always apparent.

I also like Martin's idea of not having to create the bogus solution file. "In a future release of Teamprise we hope to remove this restriction". While it's easy to crate the bogus solution file, it would be nice to avoid this. It just confuses people more than anything.

We did need one deviation from Martin's write-up. To get the logging correct we had to change the TFSBuild.rsp file to use /v:d, which is detailed logging for MSBuild, instead of /v:n. /v:n did not give us the Ant's standard output. However /v:d did. So while you have to dig through a bunch of MSBuild junk, you do get to see the output returned by Ant.

Some of our Ant scripts take care of their own logging so it's not a big deal. But it would be nice to not see all the "detail" information in the log file and just get back Ant's standard output.

Overall, I give this effort an "A". Keep up the good work Teamprise.

Teamprise Offers Team Build Solution

A few months back a colleague of mine found a way to use Team Build to call our Ant build scripts. It works quite well to be honest. You can see my original post on how we do it.

I just saw that the good folks at Teamprise are offering what I would guess, is a better solution. I've got that same colleague of mine checking it out, but if it's anything like other Teamprise offerings, it should be a nice addition for those of us using TFS in J2EE development groups.

Check TeampriseBuild out and give Martin some feedback on what you think. We plan on doing the same.

A scare when changing workspace mappings

Here is a good way to scare even the most seasoned developer.

• Set your workspace U000001-XPA mapping so $/TeamProject/MySource is pulled down to c:\MySource
  
• Check out $/TeamProject/MySource/MyFile.cs to c:\MySource\MyFile.cs
  
• Make a change to MyFile.cs, but do not check in.
  
• Now let's say for some reason you want to get the code $/TeamProject/MySource to c:\MyTempSource. To do so you decide to change workspace U000001-XPA mapping so $/TeamProject/MySource is pulled down to c:\MyTempSource.
  
• Do a Get Latest.
  
• Open up My Computer and you should see code under c:\MyTempSource. And you should notice that all code, including the code that was checked out and changed!, is deleted from MySource.
  
• Start freaking out.
  

This just happened to one of our tech leads. Luckily he checked in the code before running through these steps. So he felt alright, but did have me over to his desk to take a look and see if it's correct behavior. I didn't think it was and did some testing.

Well good news. Team Explorer and Teamprise are smart enough to move the changes under the new mapping location. In our case. c:\MyTempSource. In addition, Team Explorer and Teamprise are smart enough to not delete any files that were in the original location (i.e. c:\MySource), but NOT added to the list of pending changes.

I think this is correct behavior, but it does scare us a bit.

Long source file names don’t work well in TSWA 2005

We have not run into an issue with long file paths in TSWA, but another TFS administrator in this monster of a company has. Apparently it's caused when you have a file path more than 260 characters. We're probably not running into the error for one of these two reasons.

First, our localCache path is set to D:\cachedir from the default of C:\Program Files\Microsoft Visual Studio 2005 Team System Web Access\cache\. Thus saving us 64 characters.

Second, who interacts with source code from TSWA? While I nice feature to put in the marketing material, our users don’t use it often.

Here is a good posting explaining some more of the gory details. Sounds like the issue is fixed in TSWA 2008.

Setting up DiffMerge in Teamprise

To be honest, I don't like the compare tool that defaults in Teamprise. And if you've noticed - or if I've missed it somehow - Teamprise does not ship with a merge utility. Teamprise does however, provide documentation on how to setup new compare and merge tools. See their user guide for how to setup kdiff3.

Anyway, I seem to like DiffMerge better. So here is how we setup DiffMerge on our machines. NOTE: Some developers use other compare/merge tools as well, but I recommend DiffMerge if they don't have a preference.

I'll assume you know how to get DiffMerge installed and find your way to Teamprise Preferences. If not, then read the user guide as it will lead you there.

For compare our Arguments are %2 %1 -t1 %7 -t2 %6. If you read through DiffMerge's documentation, this syntax will put the server file (i.e. %2) on the left hand side, your local file (i.e. %1) on the right hand side and title the panels with (Latest Version) on the left and (Local Version) on the right.

For merge our Arguments are %2 %3 %1 -result %4 -t1 %7 -t2 %8 -t3 %6. If you read through DiffMerge's documentation, this syntax will put the local file (i.e. %2) on the left hand side, original baseline file (i.e. %3) in the middle, server file on the right hand side (i.e. %1), resulting file (i.e. %4), and then title the panels with Yours on the left, Original the middle and Theirs on the right.

Hope this helps!