Of course in order to do it, we need to to translate path we get from IVsSelectionEvents into server path. The path we get is a URL, whenever you select a http website in solution explorer. This is where IVsSccEnlistmentPathTranslation comes in. It is Visual Studio service, which allows translation of project path to enlistment path and vice versa. The enlistment path is the physical path, used by the scc provider. The project path is the path (possibly virtual) that is stored in the solution file. So for example http://localhost/foo is a project path, and c:\wwwroot\foo is a enlistment path. So far so good? You can try it, it works great.

The problem is after you open solution from source control. If solution contains http website and there already exists website with this name. Website will ask you if you want to overwrite existing website or not. If you say no, it will create http://localhost/foo_1. However sln file stays unchanged and project path is still http://localhost/foo. The 10$ question is what kind of path you get from IVsSelectionEvents… Yes, it’s foo_1 :) The translation service does not have method that will handle it (it cares only about http://localhost/foo and c:\\wwwroot\foo).

The solution: just use something else. In our case I’m using __VSHPROPID.VSHPROPID_ProjectDir from the IVsHierarchy object that is provided by IVsSelectionEvents as well.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

Visual Studio 2010 was significant for TFS version control for many reasons (biggest being probably schema change), but one that every one in the division was paying attention was that we became the default scc provider. So whatever perf tests were run (and we were running a lot of them) it was hitting tfs scc provider. In different points in time different project system groups were realizing that calling GetSccGlyph is not optimized for not source controlled projects and takes some significant amount of time (I think 15% when loading C# project). They also realized that in those cases, GetSccGlyph is a no-op. You may see where it is going :) Of course project system knows the bindings that are stored in it, because it's passing them to the RegisterSccProject call. So as you can imagine, obvious solution was to bypass calling GetSccGlyphs if there are no bindings.

Surprisingly tfs is not a victim in this story. We add bindings as soon as project is added to source control and we keep them forever (or until you remove them). However some scc providers don't use bindings at all (one of the providers for Source Depot) or save them lazily (e.g. on checkin - VSS). In that case, they won't be called and no glyphs will be displayed. In some cases the provider may depend even more on GetSccGlyph calls and other functionality will be broken as well.

Solution: rollback changes to the project systems and make GetSccGlyph in tfsprovider very, very fast. Please don't cut public calls just because it works with one scc provider!

"tf diff foo.txt;W~T"

If there was a pending rename involved, it would fail and we will need to specify both paths separately:

tf diff foo.txt;W~T
Item $/michal1/foo.txt was not found in the current workspace.

In TFS 2010 we hide all those "ifs" and "unless":

tf diff foo.txt
Comparing local to latest: e:\ws\foo.txt

So what we do? Whenever user specifies single path which doesn't have pending change, we are comparing local file to latest version on the server. We gracefully handle pending changes and different encodings.

When we don't do it? Whenever user specified /r (recursive) or wildcard (*) - we don't want to start diffing unknown number of files. Please just use folderdiff for that.

http://visualstudiogallery.msdn.microsoft.com/en-us/bce06506-be38-47a1-9f29-d3937d3d88d6

As Mario describes on the download page, we made a few nice improvements in this release. The biggest one was adding support for Sybase extension to the msscci interface- SccQueryInfoEx function. It decreases number of server calls PowerBuilder is doing, when loading project and allows it to avoid hitting some problems around white spaces and new lines added when generating files. You should also start seeing changeset numbers inside the IDE.

We also try to report situations when IDE is creating multiple workspace mappings. It's not necessarily always a bad thing but in a few situations it causes super hard to troubleshoot problems. The warning is displayed only during "Open from source control" so I hope it won't be too annoying. It just asks the user to validate workspace mappings in Team Explorer.

The problem:

How to version control only specific folders inside a website. Please keep in mind, we are ordinary user, not a project creator. We don't want to reimplement GetSccFiles :) We have c:\workspace\nuke website full of folders, but we want to version control only App_code and DesktopModules folders.

Solution:

workspace mappings. The website will be still reporting some errors, but cloaking root of the website and mapping only specific folder allows us to get exactly what we wanted:

$/tp/nuke/DesktopModules - c:\workspace\nuke\DesktopModules

Enjoy! 

 The first solution, which I favor, is two implement IVsSccProject2.GetSccFiles in a way that it returns success (S_OK) and empty list for the interesting files. Returning success is a key here, because otherwise caller should fall back to GetMKDocument() call. Returning empty list indicates that this node in the hierarchy has no source controlled files associated with it.

The second solution is to use DTE.SourceControl.ExcludeItem. This solution is much simpler than the first one - we don't need to complicate implementation of the GetSccFiles after all. However It comes with a price:

- calling ExcludeItem will cause scc provider to be loaded. This maybe a noticeable delay when you create first project in a Visual Studio session

- format in which excluded items are stored is not standardized. If you create project with one scc provider being active and you change provider, the file will not be excluded any more. This is not true between VSS and TFS, just because they both use vspscc file format.

- ExcludeItem does not work for websites. In case of both VSS and TFS we store excluded items in a hint file. Websites don't have project files, so keeping hint files would be much more complicated.

I hope that this description will let you make the right design decision in the future!

The problem I want to describe today was actually not fixed in VS 2010 (it's high on my todo list though) and can shave off some time off the solution load. Its symptoms are progress dialog popping up during solution load and "All files are up to date" text in the Output Window.

So what is happening? Basically whenever the project is open, we are collecting list of files it is referencing and we check if they all exist on the disk. If any of those files are gone, we are performing get. The usual cause of this problem is referencing binary files that are created during build or long time forgotten resources files that are not used in the source code. To fix the problem you can manually inspect solution structure, you may also turn on soap tracing to see what files/directories we are requesting. Then remove invalid references. You may also try using registry key described by Tim here. Be aware that the functionality I describe below will not be working when this key is turned on!

Why we are doing this get at all? It is required to handle situation when user does "get" on the project file and its new version is referencing new files. The get invoked by the user will download only project file and trigger its reload. During reload, the code I described above will download new files.

Hope this helps!

The story goes as follows: user is migrating source code to tfs. He can use VSSConverter or he can just copy sources to a workspace, run “tf add” and then “tf checkin”. The problem he still has, is that when he opens migrated solution in VS, it is not recognized as source controlled. The things it’s still lacking are “bindings” – pieces of information in sln and proj files, that indicate that this solution is in fact source controlled.

If the solution was bound to VSS before, then the problem may be fixed already for him, because latest VssConverter will fix bindings for you. If not, you can run “tfpt bind” which will definitely do it.

If solution was not bound at all (e.g. you were using CVS or SVN), then the solution is not that trivial. Although we don’t have a tool that would fix this situation yet, I will provide you information that can simplify the process a lot.

The possible solutions (afaik) are as follow:

1. The most obvious one ( and the slowest). After opening the solution, go to File->Source Control->Change Source Control. Select each project and click Bind.
2. Right click solution and choose “Add Solution to Source Control” or run DTE command File.TfsAddSolutionToSourceControl. If the solution has not been checked in yet (you still have pending adds) than you are good and the task is done. If the files are already on the server, then you will be prompted whether you want to select different location, cancel or ignore. Click Ignore.
3. You can attempt to manually add bindings to the solution and project files (they are all text files after all). It may be very simple for a known projects but in general is less trivial – each project can have them in different format (e.g. websites, setup projects) and projects located outside of solution root add extra complexity. Please backup before, don’t checkin without proper testing etc. Do it on your own risk!

I feel that approach #2 is the simplest and safest one. You can automate it a little by running “devenv solution.sln /command file.tfsAddSolutionToSourceControl” which will open the solution and execute the command. I feel that opening the solutions after the migration is a good idea anyway, just to do a quick sanity testing.

Good luck!

This problem, however, was solved already in VS 2003, by introduction of mssccprj.scc files, which store bindings and are local only. So why SSMS does not use them? Well, it’s a partially our fault, partially weakness of Msscci standard. Creation of mssccprj files is optional and we didn’t enable it for SSMS. The second problem is that we need to know what files should contain bindings, and embed necessary information in mssccprj.scc for them. The knowledge of those files is not standardized and both VSS and TFS msscci providers have necessary file extensions stored in the registry. As you can guess, we didn’t include ssms extensions in that list.

The good news is that you can fix this problem with a simple registry script. Of course be careful – the script is provided without any warranty:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider]
"BindingExtensions"="vbp, mak, dsp, sln, vbproj, csproj, vcproj, mdp, vfpproj, vdp, vdproj, dbp, vsmproj, vsmacros, hwproj, etp, etpproxy, actproj, atp, dmp, mdmp, dsw, vjsproj, csdproj, vbdproj, ssmssln, ssmssqlproj, ssmsasproj, ssmsmobileproj"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider\Settings\VssProvider\SQLWB.EXE]
"issues"=dword:00000510

Of course when we made this change, we had to ask ourselves how much we want to try to pretend on the client level, that everything is the same way as in TFS 2008. Soon we understood that we can’t completely hide we should provide tools that allow user to find all information he needs about given file, the same way as in the previous versions. Most often the tool we are talking about is History, that allow us to track file changes across merges, branches and renames.

One situation when history does not provide all information user (or at least user, who is new to slot mode) expects is when he start tracking history, by specifying file name before the rename. For example:

7    rename    michal    12/31/2009 1:30:18 PM    $/michal1/1/MyAddin1/MyAddin12/Connect2.cs   
6    rename    michal    12/31/2009 1:30:02 PM    $/michal1/1/MyAddin1/MyAddin1/Connect2.cs   
5    add    michal    12/31/2009 9:13:46 AM    $/michal1/1/MyAddin1/MyAddin1/Connect.cs

user specifies:

tf history $/michal1/1/MyAddin1/MyAddin1/Connect2.cs

and sees the following dialog:

Now he doesn’t know what happened after file was renamed in the changeset 6. The only information we have is that it wasn’t deleted, it was renamed - “source rename” tells us that.

So what we can do? We have 2 choices:

• We can open changeset 6 and see what item has a rename change. This is very easily done from the history dialog, but may not be conclusive if there were more than one rename in the changeset:
  
• We can open history in the item mode: “tf history $/michal1/1/MyAddin1/MyAddin1/Connect2.cs /itemmode”. This way we will see history of this item, the same we would see it with VS 2008. Unfortunately we can do it only from the command line.

Happy New Year!