Odd Behavior for Workspace Mappings

Say you have the following Team Project Source Control structure. 1.0 under "releases" is the 1.0 branched version of the mainline.

$/TeamProject
  /mainline
    /src
    /lib
  /releases
    /1.0
      /src
      /lib

Then set your workspace mapping up like this.

$/TeamProject/mainline --> c:\Development
$/TeamProject/releases/1.0/src --> c:\Development

Then do a Get on $/TeamProject/mainline/src. You'll find that $/TeamProject/mainline/src will show "Not downloaded" under the column "Latest" while the "release" branch will show "Yes" under the column "Latest."

I can actually kind of understand why this behaves like it does. The deepest mapping is honored. However, it's kind of odd that you do a "Get" on mainline and the "release" branch is what is Got.

Phase 2: Tracking down the TFS license key.

Here's an update on trying to track down our TFS 2008 license key (a.k.a product key). For background see my post last week. If you're struggling with how to get your license key for TFS 2008, check out Martin's post or Brian's post. Both are very helpful.

From what I understand; Our company of 33,000 buys Microsoft software from a procurement vendor who in return buys it from Microsoft distributor who buys it from Microsoft (or something like that). Getting product keys always seems to be an issue.

Luckily we just got it figured out. There is a small body of people who can download "licensed" versions of software from Microsoft which have the license key embedded in the install. Unfortunately these people don't always know they have such powers, or they don't advertise themselves very well.

Anyway, we found a person who was able to download the standard edition of TFS 2008 for us, and then using Martin's post (above) we grabbed the "Product Key" and updated our trial edition of TFS 2008. Like Martin suggested; just to make sure, we used Brian's TFSVersionDetection and everything was kosher.

Now that was not that hard was it!

Firefox authentication issue resolved

The good folks at Microsoft reached out to use to see if they could get more information on the Firefox troubles we've been having. That request forced to look into the Firefox issues a bit, and as it turned out I think we have the primary problem resolved on both Windows and Linux.

Here is what we found out; we use a proxy server for the entire company. Because of the proxy we have a defined inclusion list in IE that tells IE and Visual Studio to not go through the proxy for internal sites. We use *.int.mycompany.com*. If you're wondering why the trailing "*" is there, check out this post. This list is company wide and managed by the support folks.

Since Firefox is not "company supported" they don't send out an inclusion list so people build their own. This is typically done by just copying what IE has. When the users copied IE, they got *.int.mycompany.com*. By the looks of it though, Firefox handles the list a bit different and was giving the consistent "Authentication Prompt" as the page rendered. To fix the issue, we needed just *.int.mycompany.com without the trailing "*".

So far this has worked with the small body of users we've had try it. Now that we have this fixed, we might have some more users go back to Firefox and test it out more.

New Blogger

My colleague Greg Collins is now blogging. While my blog is geared towards TFS and Teamprise, Greg's will be more on the software configuration management side of our business. For example in his first post, he wrote about how to grab certain values out of our major.minor.bug.build release number schema using Ant. We needed this solution so that our Teamprise Ant scripts know where to grab release code from during build time on our Linux/Linux64/Unix machines.

Being that we do most all of our CM work in TFS, I'm sure he'll have a number of postings related to specific solutions that we've found for TFS.

Greg is actually the person who figured out how to use Team Build for our Java builds. I was a bit sceptical, but Greg was persistent and as it turns out, we love using Team Build for our Java based builds.

I encourage you to check out his blog at softwareconfiguraton.blogspot.com

Statistics for TfsWitDisplayNames Issue

I was asked to collect some statistics on how often we run the TfsWitDisplayNames tool to fix our 'displayName' issue. Here are our results for the past two weeks.

1/14/08 - one time for 1 user. Changed business *units.
1/14/08 - one time for 1 user. Changed first name.
1/18/08 - one time for 1 user. Changed business units.
1/22/08 - one time for 119 users. Changed business unit name.
1/23/08 - one time for 3 users. Left company or changed business units.
1/25/08 - one time for 1 users. Left company.

As you can see, on average we do an update about every other day. The large change you see on the 22nd was due to our business unit name change. That is not normal, but does happen as you can see.

Overall the tool works very well. Other than the issue that I posted on here, we've had pretty good success using it. We have a modest number of work items (around 3000) so the tool runs very quickly.

The system administrators and DBAs don't like it very much as we have to run the tool with an account that has access to the data tier. Since this is against company policy, we've had a temporary account created until this is fixed. I threw out the idea that maybe we should have the DBA run the command for us, at which point they quickly gave us access ;).

Hopefully this provides some quantitative data of how much this Bug affects our group. While not overly difficult to fix, it's a pain to have to do this every few days.

* The Active Directory 'company' field is used for our business unit names. Thus when someone changes business units, the 'company' name is modified. 'company' is then used in our 'displayName' format. The overall 'displayName' format is Lastname, Firstname (Company). If you're wondering why don't we change this, it's because this is the format for 33,000 employees and the business doesn’t want to change it for everyone, just because TFS has an issue. I can't argue.

TFS and Teamprise slides are posted

Last week I gave a presentation to the Minnesota Visual Studio User Group on our adoption of TFS and Teamprise for a J2EE development group. If you're interested in getting the slides, you can find them here under "Mac Noland Teamprise-TFS presentation".

To be honest, I've never downloaded many presentations so by no means feel that I'm forcing these upon you. However, if you're thinking about implementing TFS in a Java shop, you may be interested in some of our information.

Phase 1: Tracking down the TFS license key.

Today I had intentions of trying to track down our TFS 2008 License key. This was a big problem for us last time so I started with a "Escalation Specialist" from the "NACS Response Management Team-MSDN".

After dialing the number they gave me, I ended up talking to City Gold and Smith Barney. Thinking that was wrong, I gave the MSDN number I have (800-759-5474) a call and after a transfer was able to talk to someone from the "Activation Team."

The Activation Team member said to get the License Key I just needed to look on the back of the CD. We don't actually receive any media as we installed the trial edition (per Brian Harry's suggestion). So then he directed me to have our procurement department talk to the reseller. We're a company of 33,000 people so you can imagine how hard it is to find the procurement department.

From what he said, if the reseller does not know the key (which they didn't with TFS 2005) then we need to have our procurement tell our reseller to contact their local distributor. At this point I lost interest in the conversation and offered my thanks for his time.

So I'm back trying to find our procurement department. Once the reseller's distributor tells the reseller that they don’t have the key, our procurement department will most likely direct me back to the vendor at which point I'll start over again with the "Escalation Specialist".

Port Issue Fixed in TFS 2008 Install

When we installed TFS 2005 we had a nasty issue getting it installed on a different port (i.e. 8888). The default (i.e. 8080) was consumed by a data center wide service (some raid copy service I'm told) and the fine data support folks were reluctant to change it just for us. Being I like standardization, I could not argue with them.

So after a few days and numerous calls to support, they told us installing TFS 2005 to a different port was impossible. See here for a work around, if you're ever so unfortunate.

Luckily they have this fixed in TFS 2008. Or at least their install documentation says it's fixed. See the section "How to Customize the Port Assignment for Team Foundation Server" for instructions.

FYI: If you're adamant in putting TFS on 8080 and need to figure out what is consuming 8080, try the command "netstat -ano". From here you should be able to find out what process is using 8080 (or any other port for that matter).

How we branch our code in TFS

There is always a lot of discussion about branching philosophies. From what I've found, there is no one right answer. That being said, there are better approaches than others.

We do things pretty consistent across our development groups so I thought we'd share it with you here. It is in my opinion, this approach is the best branching approach for developing and supporting multiple releases based off of one code base.

What we do is a variation of what they call the "Hybrid Branching Structure" in Microsoft's Live Meeting called "Application Platform: Branching and Merging: Which Approach Is Right for You (Level 200)"

First we have a mainline for each Application. Some people may call this "main" but we refer to it as mainline. Mainline is wide open for all developers working on that Application.

$/TeamProject
     /App
          /mainline

Then when we do code freeze, we branch the mainline to a folder under releases to it's appropriate major.minor release number. Release branches are read-only for everyone. If a change (either a Bug fix or Enhancement) is needed, permissions are opened for that one user after the Release Manager gives approval. Once the change is made, permissions are removed.

$/TeamProject
     /App
          /mainline
          /releases
               /releaseX.X (* branched from mainline)

For an application that has been around for a while and had a number of releases, the TFS structure looks something like this. In this example, we release every month and use year.month for our major.minor release numbers.

$/TeamProject
     /App
          /mainline
          /releases
               /release8.1 (* branched from mainline)
               /release8.2 (* branched from mainline)
               /release8.3 (* branched from mainline)
               /release8.4 (* branched from mainline)

This approach seems to be the best for us. It minimizes the need for merging and allows us to support multiple releases at once.

UPDATE: There have been some questions about how we merge using the branch philosophy stated above. When a change is made to a release branch, that change is merged back to the mainline. Depending on how many "live" branches you're supporting, you may (or may not) have to merge it into other branches as well. For example, if you made a change to release8.3, it should be merged into mainline AND release8.4.

VSTS Meeting on Wednesday, January 16th

If you're in the Minneapolis/St. Paul area you'll want to make sure you stop by the Visual Studio Team System Minnesota User Group on Wednesday night at 5:00PM. Details can be found on their website www.vstsmn.net.

I'll be the keynote speaker, which probably does little justice to the term "keynote." In all seriousness, I'll be speaking about our use of Team Foundation Server and Teamprise in a Java world. That is, we're using TFS even though almost our entire development area works in Java.

My discussion will cover our configuration management tool evaluation, why we choose TFS, how we use TFS, and some suggestions and things to look out for when implementing TFS for a Java development group.

Lastly, I hope you've enjoyed my blog so far. You may have noticed that my blog is a bit different than most TFS blogs. There are basically two reasons for this. First, we're using TFS in a Java world. I'd be willing to bet, most companies are using TFS for .NET developers. But I think that is starting to change. At least it is for us, as we've been very happy with TFS and Teamprise for our Java developers.

Second, I don't work for Microsoft, Teamprise or a consulting company implementing a Microsoft or Teamprise product. I work for a large software company and have simply been in charge of choosing and implementing a new configuration management tool. So I'm not here to sell anything, just state my observations in hope of helping others adopt TFS and to hopefully help make the product better.

I hope you've enjoyed so far!

Bug in the TfsWitDisplayNames tool

So HR contacts me yesterday afternoon and says we're going to have a 'displayName' change in Active Directory. Being the TFS Administrator, my heart sunk. I knew this was going to be an issue.

I've actually been through this many times before, yet not with 250+ users. Usually it's just a handful every week. I've been using a tool called TFSLocalize which I believe was a precursor to the new tool TfsWitDisplayNames.

To get the tool you need to call support. It can take a bit to get routed to the correct group. I'd recommend you tell the "router" to look up the KB article number (i.e. 932717) so they know what to do. Or at least ask someone in their group what to do. As usual my experience was a bit rough, but eventually I did get to the 2nd level support group. Once I got there, they were very helpful.

Anyway, like I said we've been through this a number of times in the past so I'm pretty familiar with the issue. The TfsWitDisplayNames tool works pretty well. The documentation is well put together, which helps calm your nerves after you get over the fact you have to map 250+ users.

Here is an observation we had when running the tool with the /d switch, which I think indicates you are accounting for deleted users. The error we get might happen without the /d switch as well, but I didn't test that.

Here is our first mapping file and output. You can see that we have three entries. The first two are for users who are no longer with the company. I mapped them both to me. The third user is an employee who changed business units and thus had his 'displayName' changed.

Mapping File #1
oldValue="Gates, Bill (MyCompany)" newValue="Noland, Mac (MyCompany)"
oldValue="Harry, Brian (MyCompany)" newValue="Noland, Mac (MyCompany)"
oldValue="Hodges, Buck (MyCompany)" newValue="Hodges, Buck (MyOherCompany)"
Output
Processing changes for ...[Field Count : 13; Value Count: 3]
Value: Gates, Bill (MyCompany) -> Noland, Mac (MyCompany)
Value: Harry, Brian (MyCompany)" -> Noland, Mac (MyCompany)
[WARNING]: Skipping update. Value 'Harry, Brian (MyCompany)' for field '' has already been changed.
Processing changes completed.

You can see that by having Noland, Mac (MyCompany) twice in a row, the tool stops after the first update with a warning. Now look at our second mapping. Here I've removed the duplicate and it produces correct results.

Mapping File #2
oldValue="Gates, Bill (MyCompany)" newValue="Noland, Mac (MyCompany)"
oldValue="Harry, Brian (MyCompany)" newValue="Noland, Brock (MyCompany)"
oldValue="Hodges, Buck (MyCompany)" newValue="Hodges, Buck (MyOherCompany)"
Output
Processing changes for ...[Field Count : 13; Value Count: 3]
Value: Gates, Bill (MyCompany) -> Noland, Mac (MyCompany)
Value: Harry, Brian (MyCompany) -> Noland, Brock (MyCompany)
Value: Hodges, Buck (MyCompany) -> Hodges, Buck (MyCompany)
Processing changes completed.

This produced the results we expected, but I think TfsWitDisplayNames has a bug. I sent this back to support so hopefully the duplicate issue will be fixed. In the mean time, you have to remove all duplicates and/or use multiple mapping files. Which unless you've accepted that this is a huge pain in the butt, like I have, may frustrate you even more.

Attention Microsoft: This is becoming a bigger, and bigger, and bigger problem as our TFS instances (currently four) continue to grow. I can safely speak for the 1000+ users we have (or soon will have).

Can't make Area Path and Iteration Path required

We're giving up on Area Path. Why? Because we can't make it required and management is sick and tired of having Work Items not filled out correctly.

They've slapped hands and threatened dismissal, but no go. So it was requested to me, as the TFS administrator, to replace Area Path with a new custom field called Service. Service is required on submit (a.k.a. Save).

This is a shame as I really like both Area Path and Iteration Path. They are easy to update and provide a nice tree hierarchy to break down subsystems (or Iterations) into sub-subsystems.

Iteration Path got ditched a long time ago for the same reason. Management said it's unacceptable for a Work Item to not have an Iteration Path selected. The best way to fix that? Make it required on Submit. Brute force I guess.

I'm sure there are technical reasons for it, but it would be really nice to have some way where you can make a tree hierarchy required. I can see there would be problems with how deep do you want to make it required? For example, is Iteration Path \TeamProject\1.0 good? Or do you require \TeamProject\1.0\1.0.1? Basically how deep in the tree makes Iteration Path valid?

Anyway, until we can make tree hierarchy required, important fields like Iterations (we call them Releases) and Areas (we call them Services) will be custom fields.

On a somewhat related note; here is the Excel formula we used to migrate all the Area Path values from Area Path to our new custom field. I only put this here for my future reference if I ever have to do it again. =MID(C3,SEARCH("\",C3)+1,20)

Unshelving files that have File Merging disabled

As Buck wrote about, unshelving files that have File Merging disabled can be troublesome. Disabling File Merging will exclusively lock files during check out. This works well for binary files as it's difficult to merge them.

However the exclusive "lock" will not allow users to shelve changes and have other users unshelve them. The user unshelving the change will get the error "The item is locked for check-out by in workspace ".

As Buck wrote about, Microsoft had this issue with Gauntlet. We have the issue as we use shelvesets to pass code between developers during code reviews. In the past we simply zipped up the files and used email. Developers feel shelving is a better way to share code for code reviews though. I agree.

So to allow Image files to be shelved/unshelved, we've decided to enable File Merging for Image files. This is a server wide setting under Team -> Team Foundation Server Settings -> Source Control File Types.

I'm sure there are some technical limitations that I'm not thinking of, but it would be nice to allow users to unshelve changes that have an exclusive lock. That way we can keep File Merging disabled, but still allow users to use shelving for sharing files.