Team Explorer Everywhere Options for Users Wanting a Standalone Client

We’ve had some users who have shied away from using Eclipse plug-ins and have become comfortable with Teamprise Explorer (aka Fat Client). When Team Explorer Everywhere (TEE) was launched, Microsoft discontinued delivering the Fat Client. Thus, those users have continued to use Teamprise. We’d like to get those users cut over so Brian has showed a pretty good work around that should work for these users. Here is what we sent to our teams:

If you’re used to using the Teamprise Explorer for development, here are some options you have when migrated to Team explorer Everywhere (TEE).

1) Switch to using the TEE plug-in in Eclipse.
2) Use the free Team Explorer plug-in to the free Visual Studio 2010 shell. (This only works for Windows users)
3) Per Brian Harry’s post, use the Eclipse Platform Runtime Binary standalone client.

If you decide to go with the last option, here are some general instructions for using the Eclipse Platform Runtime Binaries.

1) Download and install Eclipse Platform Runtime Binary- Install TEE
2) Window Show View Other Team Foundation Server Team Explorer
3) In the Team Explorer panal, select the Add Existing Team Project dialog button
4) Add your server and connection information
5) Select Team Projects you’re involved with
6) Double click on Source Control to get the friendly Source Control tree view
7) Get yourself a cup of hot coffee

"Updating Work Item Data has encountered a problem"

If you get an error in Teamprise like "Updating Work Item Data has encountered a problem. Java.sql.SQLException: File input/output error: Unexpected Token:", just clean your local cache. It's probably some kind of synchronization issue with the local cache and TFS server.

On XP the Teamprise local cache data are stored under C:\Documents and Settings\%USERNAME%\Local Settings\Application Data\Teamprise\2.0. For this error you just need to delete the ./db directory. You will have to close Eclipse or Teamprise before doing so.

"Mac, how do I compile Java with Team Build?"

In the past week, I've fielded a number of questions from people within my company regarding how to get started compiling Ant based Java projects within TFS. Here is what I tell them. And it would be what I'd tell you if you asked.

My Colleagues: "Mac, can you provide us some information on how to get started using Team Build to compile our Java projects?"

Mac: "There are a number of different ways to solve the problem, but I'd suggest looking at Teamprise's Team Build Extensions. This is an open source project, supported by Teamprise, to run Ant scripts via Team Build (which is nothing more than MSBuild behind the covers). They have a very good tutorial (as part of the distribution if I remember) and support forum.

I'd start by trying to get one of your simpler Java projects to build. Then once you build that, you can get a better understanding of how the tooling can best solve your problem. What we do is have one parent Ant script that calls all the other tier Ant scripts. So basically Team Build is just the high-level driver and we let Team Build Extensions and Ant take care of the rest. This seems to work pretty well for both [MY CURRENT BUSINESS UNIT] and [MY OLD BUSINESS UNIT]. Also, I think if you have JUnit tests that you run as part of the build, and follow some simple rules, Teamprise Build Extensions will publish the results back to TFS. Pretty cool!
"

So if you're looking for help getting started, consider this my response to you. Let me know how it goes.

Manually Adding Files to Pending changes in Teamprise's Plug-in

There have been a few times recently when users have added files in Eclipse, but the files were not picked up by Teamprise's Eclipse Plug-in as a Pending Change.  If this happens, the new file will have a "?" on it.  It's one of those incidents that we can't seem to reproduce, but happens ever so often.  It also seems to happen to a small subset of users.

If you run into this problem, a work around is to manually add the files.  I'm doing this from memory so the steps might be slightly off.  However, I think it's close.

1. Show the Team Explorer Panel in Eclipse.  Window > View > Teamprise > Team Explorer.
2. Make sure your Team Project is selected and expand it.  There you will see Source Control.
3. Double click on Source Control.
4. In Source Control, path yourself down to the correct directory where the files were indented to be added.
5. Right Click on the directory you're wanting to add the file to and say "Add Files to Source Control" (or something like that).
6. Now select the files that were not added by the plug-in.
7. Back in Eclipse's Package Explorer (or what ever view you're using), Right Click > Team > Synchronize.
8. The Synchronize command should now make the "?" files show up as "+" files and thus added to your Pending Changes.

Hope this helps anyone who runs into a similar situation.

"Waiting for version updates to finish..."

Last week we noticed a colleague's Teamprise hanging at the end of a Get Latest Version. The message was something along the line of "Waiting for version updates to finish...". Unfortunately on my local machine, everything worked as expected. Typical I guess.

Anyway, I was playing around with the VPC image developers (and the person having trouble) use and noticed that *.tfs.mycompany.com* was not listed in the Eclipse proxy exclusion list. It is my belief, if *.tfs.mycompany.com* is not added, you'll also get the strange "Waiting for version updates to finish..." behavior, and possibly other network related issues. In addition, Teamprise has a good article titled TKB00021 Diagnosing Common Connection Problems that also provides help with connection issues.

To properly set your proxy settings in Eclipse, you can go to Window > Preferences > General > Network Connections and add *.tfs.mycompany.com* to your "No Proxy for:" host list. There is also a short cut in Teamprise if you hit a wall during the initial Import.

Teamprise 3.0 is released!

If you didn't see, Teamprise 3.0 has just been released. As I've written a number of times, Teamprise is a great offering if you're looking for a cross platform solution for Team Foundation Server. NO I do not work for Teamprise or sell their product for a living. I'm simply a customer at a large software firm who uses Teamprise for our Java development groups.

We use every piece of their suite including the Ant scripts and Teamprise Build Extensions which allows you to call your Ant scripts from Team Build.

Teamprise has a great product, but even a better support group. If you have not checked them out, do it soon. You'll find it being one of the best products around.

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.

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.

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!

One way to rollback changes using Teamprise

I don't purport to say this is the best, or only way to rollback changes using Teamprise Explorer. It's just one way we came up with.

Before you do this, make sure you DON'T have "Automatically get the latest version before check out" selected under Tools > Preferences > Source Control. From my findings, this setting can cause some issues with the solution below. I'm working with Teamprise to see if there is a bug, or if I'm solving a problem with the wrong solution.

To rollback changes, or in other words, revert the latest version to a previous version:

• Right Click on the file you need to rollback and select View History. Right Click on the appropriate changeset and select Get this version.
  
  
• Right Click on the file in the Source Control window and say Check out for Edit. You should now have the old version of the file checked out.
  
  
• Right Click on the file and select Check In Pending Changes...
  
  
• The Resolve Conflict window will pop up. Select the file and click Resolve... Select Undo Server changes. This will tell the server that you mean to change the most current version of the file on the server.
  
  
• Lastly, Right Click on the file and select Check In Pending Changes... This will commit the changes to the database.