Getting associated work items for changeset

Lately we have been working at next version of our Team Foundation Sidekicks application (more specifically at labels-related Sidekick), and as part of the development it was required to retrieve all work items associated with changeset.
Initially, the following simple code was used:

Changeset changeset = server.GetChangeset(changesetId);

Once Changeset object is instantiated, its WorkItems property readily makes all associated work items available.

The problem was the method performance; so after some search I found Naren Datha's post solving the same task. The code there uses WorkItemStore and ILinking objects and looks much more complex (as compared to one liner we used before). Heck, it must work quicker (or so I thought)!

But after some benchmarks, it turned out that those two approaches have very similar performance. I did not perform exhaustive research, but the execution time was essentially the same (within 10% delta).

So my guess would be that both methods use same core queries; and as far as complexity goes we shall stay with our previous one liner. Wouldn't you?

Removing iteration hidden goodies

I have just found a new feature in TFS! That still amazes me how after a whole year I am involved with TFS, there are still hidden and unexplored places to go.

In short, I was going to remove iteration path I have created by mistake, and there TFS goes displaying the window shown below:



Frankly, I was not thinking about work items at the time as I knew the iteration path was without any items assigned, but TFS thinking about that on my part - that is all goodness. Sure, if I had some work items I would like to migrate them, and the thoughtful dialog displayed is not a bad way of doing it.

I guess the possible usage of the feature (besides deleting iterations created by mistake :) would be for moving work items in iterative development. For example, in one setup we frequently assign all strange low priority tasks to iteration "Backlog" in milestone; so it would be convenient to delete that backlog and move all leftover backlog work items to next milestone.

It would be interesting to see if someone out there is in fact using that feature.

Renaming Team Project

When you create new Team project, give some serious consideration to its name. The Team project cannot be renamed in TFS v1 (No comment about it - you may find some opinions in MSDN usergroups).

The rename operation seems so obvious to the folks that I thought it is worth to post about it. You may well imagine with what incredulity the absense of the feature is met when need to rename project arises (there you have some really colorful language :).

If you already named your project and looking at ways to rename it, you may use the following workaround (sort of workaround, because you won't really end up with renamed project with identical contents):
1) Create new project with desired name
2) Copy work items from old project to a new one (one-by-one, as there is no bulk copy option).
3) Move all source control folders from under old project folder to a new project folder
4) Sharepoint portal documents cannot be moved in bulk (as far as I know), so you do that manually
Move of source code will retain the files history, and work items will also have partial history, but overall I would say the workaround does not worth the labour (and Sharepoint docs will not have their history). At any rate, selecting right name in the beginning beats any workaround by far.

So be circumspect when you name your Team project!

Update: I stand corrected, as there exist freeware utility for moving work items between Team Projects (written by Eric Lee); see posts here and here.

Cached TeamFoundationServer

Yesterday I have read Buck Hodges blog post on how to get instance of TeamFoundationServer. Getting TeamFoundationServer is the first thing one does when writing code that utilizes TFS Version Control object model, so naturally it is worth to know. Frankly, I did not think I will discover something new, but you live and you learn...

Two choices available are TeamFoundationServer class constructor or TeamFoundationServerFactory GetServer method. Buck covers the usage quite nicely in his post. The point of interest for me was that TeamFoundationServerFactory method will actually return same object in two different calls if given same URL as GetServer parameter.

That means if you use GetService method of returned TeamFoundationServer instance, it will essentially be the same service! So for example, if you retrieve VersionControlServer and hook up onto some event, you will need to do it only once; the second instance of TeamFoundationServer returned by factory will be the same and will return the same VersionControlServer with event handler set (below is pseudo code just to visualize the idea; no chance it will compile):

// first place
tfs1 = TeamFoundationServerFactory.GetServer(url);
vc1 = tfs1.GetService();
vc1.NewPendingChange += event1;
...
// second place
tfs2 = TeamFoundationServerFactory.GetServer(url);
vc2 = tfs2.GetService();
vc2.NewPendingChange += event1; // not required! already set

So that is something you'd want to keep in mind while writing your applications.

P.S. And some additional piece of wizdom from commentaries to the post:
"I recommend obtaining services from TFS OM for all services except the WorkItemStore. It is not thread safe, where as all other services you obtain from TFS OM are. To work around this issue, create a new WorkItemStore object and pass the credentials that you get from the TFS OM."
It is not official and I did not check that, but I love to assemble those bits of information. You never know when it may come in handy ...

Merging Visual Studio solutions

Recently, I have read a post in MSDN, and that reminded me of important issue I meant to raise for quite some time.
The scenario is rather simple - let us say that you branch folder that contain Visual Studio solution (or project); then you perform development in both branches. At some stage you merge one branch onto another.

While it is obvious how code files (C#, C++ etc.) are merged, for Visual Studio project and solution files it is less so. Even if you do not peform advanced changes in those files (for example, specifying different custom pre-/post- build steps), Visual Studio itself may change the file (see the problem is described in the post). And when you merge, usually there is no conflict and changes are merged automatically and thus you can end up with invalid solution or project file!

It appears there is no magic bullet solution for the issue in current version of TFS. What I do is essentially manual procedure: the idea is to check whether any solution/project files were merged. In most cases there are no conflicts to resolve, so I manually review the merged solution/project files before checking them in, to make sure that automatic merge changes make sense. It may be paranoid but is way better than broken solution.

More than that, after some thought on the subject, I do not see how it may be handled (aside from customized merge wizard specifically for Visual Studio solutions and projects). Any thoughts on the subject would be appreciated (I believe Microsoft guys will thank you as well).

Copying work items - hidden gotchas

Today I came across Eric Lee's post about copying work items. I also discovered this function quite accidentaly and have been happily using it for several months already.

So you right-click on selected Work Item in Query Results or on open Work Item, and click "Create Copy of Work Item..." - and voila! New item with identical data is displayed for you, so you can modify and save it. It allows one to avoid hassle of copying common fields or easily copy item to another project.

All goodness, but there are some not so obvious features within...

First, the newly created work item will be linked to the source work item (work item you copied a new work item from). If that is not your intention, and you do not glance on "Links" tab contents - you are in for surprise. And if you do that for some time then you have a whole lot of links. For example, if you have Item 1, then created Item 2 (by copying from Item 1) and then created Item 3 (by copying from Item 2) - now, how many linked items you will have in Item 3? You will have two - Item 1 and Item 2. That is surely a feature to be aware of (especially if you do not want to link those items)! I have discovered it only after I created the whole bunch of interlinked items...

Additionally, there is something very interesting in the history of the newly created work item. If you are creating items one after another (as in example above), all that information will be saved in history!

Here you can see copied work item history:


And here the first history entry expanded (and that is only a part of it):


Not that I care much about that information currently. It may be useful if you are trying to propagate bug through several Team projects (say bug found in "Project 1" will be copied to "Project 1.1" and then to "Project 1.2" - the data will be visible in history); but with current implementation of Team projects I doubt it is of much use. On the other hand, if you are copying items only for convenience, I do not see how that information is useful to anyone.

Those two I have discovered in a course of some two months of usage; but I will not be surprised if there are additional goodies in that function. And I wonder - what was the idea of the original author?

Circular references in Active Directory

Recently in user feedback on Team Foundation Sidekicks application we have dealt with issue that may be of importance to people with complex Active Directory dependencies between user groups.

To put it simple - if you have circular relationships between user groups in AD and those groups are used in TFS, IGroupSecurityService ReadIdentity method will fail. I did not see it but on one occasion and do not know how that API is used in TFS core, but my experience with Active Directory tells me that circular relationship is not something very rare to come by.

So if you feel that way also, have a look on the following post.

Shared workspace mappings

For everyone that has used TFS source control it is well known fact that it is impossible to create more than one workspace mapping to same directory (in single or different workspace on same workstation). When you try to do that, TFS error message pops up informing you that the path is already mapped somewhere.

For non-shared computer there is no probem in the situation; you just use the workspace with mapping or create a new path.

Now, on workstations used by several people (for example, integration stations) there may be lot of value in the "shared" workspace, namely so that each user after logging in has mapping in his workspace to the same path. Until today, I did not think that possible, but came across very interesting post in MSDN newsgroup that suggests a solution.

The solution is simple and elegant! You just map disk drive to the directory, and while users Alice and Bob have mappings in their workspaces to G:\ProjectA and F:\ProjectA, they in fact will be working with same project in c:\src\ProjectA. One might note that it is not single shared workspace but instead workspace per user with the same mapping, but heck - that's the best solution we have! Surely beats having separate directory for each user just for mapping.

Kudos to Nate for suggesting the solution.

Maximum number of Team projects

Today while reading MSDN newsgroup I came across interesting piece of information that I was not aware of before. It turns out that Team Foundation Server supports maximum of 500 (five hundred) Team projects (as stated in official documenation); though in the newsgroup thread it is stated that the limit is not a hard one, it is still an official number.

While 500 is quite sensible number, I do find it rather disturbing; while not many organizations will have more than 10 millions of versioned items per project (10 millions as limitations go is not a very restrictive one), I can visualize organization having 500 logically separate software products or modules.

As Microsoft prefers working with a few projects (separating modules by using source control structure and area paths) it appears that having great many projects is rather gray area as of now. I would definitely say that the limit is one to be aware of in planning, though hardly a critical limitation.

Apply Label adventure

When one performs "Apply Label" on file or folder in TFS source control, the operation may lead to not entirely expected results.

Let us say that Bob has selected file $/Northwind/foo.cs, right-clicked it and chosen "Apply Label" menu. File is selected by default, thus Bob proceeds from "Choose Item Version" dialog to "Apply Label for foo.cs" dialog. There Bob specifies label name Test Label and hit OK. As was expected, new label is created with foo.cs contained.

But when Bob performs the same sequence for file $/Northwind/foo1.cs and specifies same label name, the file is added to existing label! User is not notified in any way that label already exists, and after operation is completed, Test Label contains two files, foo.cs and foo1.cs. More than that, if one would specify label name as tEST lABEL, TFS will still consider that to be same as Test Label.

While operation is called "Apply Label" and one may argue from the point of wording it does exactly that - applies label to the item versions selected (creating it only if needed), I believe that is the behavior to be aware of as inadvertently user may easily add items to existing label while believing that new label is being created (to say naught of case sensitivity in label names).