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.

View deleted files the Source Control Explorer

The Vertigo blog describes very useful feature I was looking for for ages.

If you want to Undelete deleted files in GUI, you may set Source Control Explorer to display deleted files.

The option may be set using menu Tools->Options->Source Control->Visual Studio Team Foundation, by checking magical "Show deleted items in the Source Control Explorer" checkbox.

Every TFS practioner must-know-how-to!

Undo add of solution/project

If you have performed addition of unbound solution/project to TFS source control, and want to undo the operation, there are several gotchas.

First, you perform "Undo pending changes" to undo pending Add change. All is kool, the operation is undone and it is possible to work without source control as before.

But let's say that you finally decided to add the solution/project. Several findings here:

* "Add to SC" functionality is not available! Ok, I have undone the operation but now I do want to add my solution!
Workaround: must go to File->Source control->Change source control, and there one will discover that there still exists binding of the solution to TFS. Unbind the solution/project, and then "Add to SC" functionality becomes available

* Now when performing the Add, TFS does not ask you for mappings. It adds your files to the path you specified before Undo operation!
Workaround: must go to your workspace, and there one will discover that there is mapping for your solution. Remove that mapping - then on Add TFS will ask you to specify the path.

Overall, I would say those are the facts to be aware of (as Microsoft says here there are aware of those somewhat unobvious workarounds, so any TFS user also should)

Conflict resolution window

It has been stated in Chris Rathjen blog that conflict resolution window may be displayed in three different cases.

Must check that thoroughly! Have seen those empty windows now and then, never quite knowing why...

How lock set on file is affected by check out

When check out operation is performed on file, the lock set will be that of the check out option specified. It may lead to some not entirely obvious consequences.

Obvious example
1) No lock on file prior to check out
2) After check out is performed with lock option other than "None"("Check-out" or "Check-in" lock), the file is editable and has changes "Lock,Edit" associated with it (in "View Pending Changes" window)

Not so obvious example
1) Lock on file prior to check out ("Check-out" or "Check-in" lock)
2) After check out is performed with "None" lock option, the file is editable and has change "Edit" (in "View Pending Changes" window)
That is, previously set lock level was essentially removed (demoted) by using check-out option.

So lock level may be either promoted or demoted by check out operation (the situation occurs only in case lock is owned by user performing check out or user has admin permissions for locks). Personally I think that is the thing to watch for or at least to be aware of.

As Microsoft explained in their answer, locks are affected only by explicit check outs; implicit check outs (for example, when auto check out on edit is enabled) are not affected.