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).

Get latest version on check out

The question whether "Get latest version" of file should be performed on file check out by TFS rather than by user manually was discussed multiple times in the past and is being raised almost on weekly basis in forums.

While it appears that Microsoft will provide at least configuration option in the future versions, it will not be in SP1 (see Richard Berg post).

As Microsoft has been promising to release SP for qute a while, and it is still in the works and will not contain the feature mentioned, it appears that the community will have to learn to get by without that option. I hate conspiracy theories, but it surely appears that the users are being educated against their will. We all shall witness what would be the result.

In my opinion though, at least survey on the issue would be a great idea. Hopefully, someone at Microsoft is listening...

Source control path length limitation

When defining folders in source code control repository (or adding local paths hierarchies) it may be useful to keep in mind that maximum path length (of concatenated path) may not exceed 260 characters both for server and local path.

I thought that the days of MAX_PATH (for those who are in the know) are long gone, but it appears that TFS has the maximum length limit in its database (see post about the issue).

To make a personal confession, having upper limit imposed is not any problem for me. Sensible folder hierarchies and file names should not take more anyway.

Generally, the most probable case for the issue to occur is to use long local paths (the worst ones of the form C:\Documents and Settings\dumb_user\My Documents\Visual Studio 8\Projects\...) - but in those cases the user education will solve the issue. It may be even for the better that such users will receive maximum length error - source code has no place in My Documents.

Pending rename folder change

When renaming folder in Solution Explorer tool window in Visual Studio (vs. performing the operation in Source Code Explorer), I have discovered one tricky point.

The following sequence of operations is performed:

* Initiate operation by using "Rename" pop-up menu on selected folder in Solution Explorer

* Change the folder name

* The "Check Out Files" dialog will appear to check out project file; set the desired lock type and click "OK"; renamed folder will appear in the project. If the "Check Out automatically" on edit option is set, the user will not be prompted and required files will be checked out automatically

* Check in the project files, using either "Pending Changes" window or "Check In …" pop-up menu in Solution Explorer or "File->Source Control->Check In …" menu, and clicking "Check In..." in the appearing dialog


Now, the walkthrough appears to be pretty obvious. But there is a catch - if the "Filter by solution" toolbutton is toggled in check in window to display only solution's changes, the "rename" change is not there! And it will dangle there for ages pending, unless you toggle off the filter or look into Source Code Explorer.

All in all, there is nothing complex here, but in my opinion the point is definitely one to be aware of.

UPDATE It was confirmed by MS that the behavior is a bug and is going to be fixed. There is also another minor bug mentioned in the MS post, so read and be enlightened.

"Resolve conflict hangs Visual Studio" issue

UPDATE Microsoft devs say that
* The issue occurs only rarely
* The problem usually may be localized to single file, so workaround suggested is sufficient
* Fix was already implemented to be distributed in first patch

So overall that downgrades the issue from "panic mode" to "something to be aware of".

See the full discussion on the issue.


ORIGINAL POST
Some of TFS users complained, that following scenario can get the application to hang:

1. Perform Merge between two branches
2. If there are conflicts, they are identified Conflicts dialog is displayed
3. Clicking Resolve brings up Resolving Conflicts dialog, saying that summary is built.
At this point application never comes back. And whats more, it happens for some files at some conditions (not exactly identified).

How to determine source controlled solution workspace in Visual Studio

When you have several solutions in different workspaces, it is not always easy to remember what workspace you work with (say, you load the solution into Visual Studio from file system), but right workspace you need to specify when performing operations such as branch, that are not supported from the Visual Studio Solution Explorer, but rather from the TFS Source Control Explorer.

The answer is short - when you load the solution and open the Pending Changes window, the workspace selected by default is the one the solution is associated with.

When you change the workspace though, your selection will be remembered until solution is reloaded.

Thanks to Richard Berg for the answer.

Opening local solution of other user

The following scenario may occur on shared computer:

1. Bob logs in using his account to computer A
2. Bob performs get latest to folder for the solution in his workspace
3. Bob performs required activities with the files in his workspace, finishes up his activities and logs off
4. Alice logs in using her account to computer A
5. Alice opens solution in folder using "Open..." Visual Studio menu
6. Error that "bingings are improper..." is displayed

The scenario is supported by Visual SourceSafe and is not possible with TFS (see error in bullet 6).
What user (Alice) should do in TFS is to perform "Open from Source Control" for solution in her workspace2 to folder2.

Additional point you should be aware of that message saying bindings are incorrect may be caused by the scenario above.

See issue discussion here.