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.

<UpdateBuildNumberDropLocation and NFS File Systems

Our current Team Build drop location is a Common Internet File System (CIFS) mount to some network attached storage (NAS).  To a novice like me, the drop location looks just like a Windows server drive that is shared.  However, on the back end this CIFS mount has all the bells and whistles that the data center offers (e.g. backups, redundancy, etc.).

The issue we have with the CIFS mount is that while our Windows servers can pick code on their for deployment, our Linux boxes can’t see the CIFS mount.  Since a lot of our development is done in Java and runs on Linux, we have an issue.

Enter the fine storage and system admin teams who have tested the use of Network File System (NFS), as a replacement for the CIFS mount, which is accessible by both Windows and Linux servers.  We’ve tested the NFS mount and sure enough, both our Windows servers and Linux servers can mount to the same drop location and pick up the build output used for deployment.  Perfect right?  Unfortunately there is a small issue.

According to this post, Team Build’s <UpdateBuildNumberDropLocation Task has code in it which needs to update permissions on the drop location.  From what I understand, the code will change the permissions so the App Tier service account has access to the drop location (it needs access to delete builds and such).  To see this, Right Click on a file located on the drop location and notice how the App Tier service account has full access to the folder and any sub files or directories.  The <UpdateBuildNumberDropLocation is doing this.

The issue that I’m running into is, when the drop location is a NFS system, there are no permissions at the file or directory level.  For Windows, the permissions are at the share level.  I’m assuming Linux permissions are dependent on wether the mount is a write or read mount.  So when the <UpdateBuildNumberDropLocation Task runs, it gets a message back saying permissions can’t be set and thus throws this friendly message back to the user: “TF209025: The build process is unable to set the permissions on the drop directory <actual drop location>(Detail Message: Attempted to perform an unauthorized operation.). Make sure that the build service account has proper permissions on the build drop directory and try again.”

What’s interesting is, the share is wide open thus the NFS mount is wide open.  And Team Build actually writes files to the location.  So functionally everything should work fine if we could get past the feature in the <UpdateBuildNumberDropLocation Task where it tries to adjust permissions.

I’m not sure what a good solution is for this.  However, I think the current implementation needs adjusting.  In my Connect submission to Microsoft, I’ve asked them to provide a Property (e.g. UpdatePermissions=”false”) where you can turn off the permission change when you want to use a NFS mount for your drop location.

Team Explorer "did not load because of previous errors"

My colleague installed TFS 2008 SP1 on our app tier.  He then uninstalled it because we were having some issues, which we're tracking down. However, after uninstalling, we were unable to open Team Explorer due to the following error.

The Microsoft.TeamFoundation.Client.ServicesHostPackage, Microsoft.VisualStudio.TeamFoundation.TeamExplorer, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a ({8E01EC3E-2928-4AA5-B720-E28C163818E6}) did not load because of previous errors. For assistance, contact the package vendor. To attempt to load this package again, type 'devenv /resetskippkgs' at the command prompt.

I'm not sure what /resetskippkgs does, but I ran it and Team Explorer is now back to being functional.  If you run into a similar problem, I’d be interested to see if this /resetskippkgs works for you.

"Find in Source Control"

It's fall which means all the interns from MIT, University of Wisconsin and University of Minnesota (I'm an alumni) head back to school.  It's also time for us full time employees to pick up the messes they left.

For me, their messes usually include having thousands of files checked out in TFS (or VSS back when we used that).  In the past, I just deleted their workspace from a command line.  That works pretty well and to be honest, should be the way we do this.

However, my colleague showed me a really cool feature called "Find in Source Control" where you can search on a person's ID to see all their pending changes.  Then you can undo them from there from a nice gui.  Works great when you've got some lead engineer breathing down your neck because they can't update source code because some intern had an exclusive lock on the file.  Nice feature Microsoft.  Keep up the good work.