|
|
-
Last Tuesday I was going through all tasks that we have open related to TFS Msscci provider, tfpt bind and bindings in general. One of the gems ;) I found was automating the process to bind existing solution to source control. 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: - 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.
- 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.
- 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!
|
-
Recently user has reported problem when using SQL Server Management Studio and TFS. When he branched folder and opened a newly created solution, he kept pending changes on the original projects instead of the branched one. Veterans of source control integration in Visual Studio (2003, 6.0 and others) will probably recognize this problem immediately – solution file has embedded server path, which is not updated during branch operation. 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
|
-
As you probably know, one of the biggest changes in the version control part of TFS 2010 was moving from item mode (files and folders are uniquely tracked by itemId) to slot mode (itemId is attached to a slot and renaming file or folder changes its itemId). Matt wrote more about it here. 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!
|
-
As Brian mentioned a few weeks ago (http://blogs.msdn.com/bharry/archive/2009/12/01/tfs-2010-power-tools-are-available.aspx) we have updated our powertools, to work with TFS 2010 beta2. As usual, I was working on the Msscci provider and now I want to finally describe changes made - it can be useful when updating other tools for TFS 2010. It's also worth reporting new features. The first change was of course to support custom URLs. Now you can write any url in the connect dialog, in the similar fashion to VS 2008 SP1. Then we had to react to all changes related to itemIds and pendingChangeIds(http://blogs.msdn.com/michalma/archive/2009/06/15/version-control-api-changes-in-tfs-2010-part-i.aspx), To fix this, we decided to start using ui controls that we are shipping with Visual Studio. This way TFS Msscci msi file dropped about 2 MB and users are getting latest and greatest UI - new history and resolve dialogs: 
The last but not least was to support gated checkin. As a quick reminder for people who are not familiar with this feature - now, when you checkin, it is possible to have those changes built, tested and checked in by the Team Build. From the api perspective, VersionControlServer.Checkin is throwing the exception when a gated checkin starts, but of course showing plain message box is not the best user experience. Instead, TFS Msscci is showing the same dialog as Visual Studio and tf.exe I have not tested actual Team Build workflow for for example VB6 but I would love to hear about actual user experience with it!
|
-
I was asked recently to investigate problem when using VB6 and TFS Msscci Provider. We found out a limitation, that is not really surprising, but is still worth documenting.
The code base looks like this:
Source
SharedCode
Class1.cls
Project 1
Project1.vpb
Form1.frm
There are a few problems with TFS integration in this environment:
- If Source directory is not mapped, we will ask you to map only Source\Project1 (this is root of the project and we know only that, we are not aware of Class1).
- If SharedCode is not mapped we will fail to add any file except of Project1.vpb to source control
- Creating workspace mappings outside of VB (with Team Explorer or tf.exe) that would map whole Source directory will solve above problems.
- "Create project from Team Foundation" will never work seamlessly in this situation. Even if you do #3 and successfully add whole project to scc, and you have correct mappings in the workspace where you are doing "Create project ..." we will not download Class1. You need to download it later with tf.exe/Team Explorer. After that it should work fine.
Hope this will help you when dealing with more complex code base and a vb6+tfs mix!
|
-
Today I had to test behavior of our less commonly used feature, get latest on checkout, in a mixed VSTS 2008 + TFS 2008 environment. Hopefully this blog post will save the time next person who wonders if this should work (It took me 3 hours to update my VS2005 hyperv image before I could actually try it).
First of all, a little about the feature. We resisted a long time before we gave up and implemented it in TFS 2008. We thought that it doesn't go well with TFS philosophy by we were convinced that we are wrong :) It causes client to download latest version of the file before pending edit in single web server call. It's both client side and server side setting.
Ok, now the actual finding. You need both VSTS2008 RTM and TFS 2008 RTM at the minimum to use gloc. If server is TFS 2008 and has this option turned on, but client is 2005, it will not take advantage of it.
Hope this helps!
|
-
Yesterday I was talking about changes we did to itemId and pendingChangeId in TFS 2010. Today I want to list other changes, related to various part of VC api:
- You should be careful when using DiffItemVersionedFile class, especially if you use constructor that requires itemId. Much safer thing to do is to call Difference. CreateTargetDiffItem. It will use QueryHistory under the covers to find correct item, but it has optimizations for most common cases that will avoid it.
- VersionControlServer. GetBranchHistory returns objects that are result of both branching and renaming items. BranchRelative.BranchToChangeType contains information about the operation that created given branch, however this is not recommended to try mimicking Orcas behavior by pruning results of GetBranchHistory. In some cases, like cycles in renames, it’s not possible. Instead new method VersionControlServer. QueryMergeRelationships should be used, which returns all items that have merge relationship to the specified item (i.e. not only branch relationship, but also merge relationship).
- Labels in TFS 2010 include deleted items, in oppose to labels in TFS 2005 and TFS 2008
- VersionControlServer.GetItems and Workspace.GetExtendedItems do not returns items that were deleted as part of rename, unless GetItemsOptions. IncludeSourceRenames was specified
Enjoy!
|
-
As Matt writes in his post, the way version control behaves in TFS 2010 has changed in a few significant ways. Our team was responsible for making the client code updates in response to those server changes and I tried to write down lessons we have learned.
First of all - itemId. Before, it was a unique identification of an item. It was the same across all renames, deletes and undeletes. Now, it's not:
- it changes during rename
- there can be two items with the same itemId, when you have rename A->B and add A in the same workspace
When we are dealing with PendingChange objects, the helpful fact is that PendingChangeId still remains unique, so it can be used for indexing instead of itemId, when we are dealing with just pending changes. Please keep in mind however that Chandru wants to get rid of PendingChangeId as well :) Other property we can use to identify pending changes is target server path (ServerPath) which is unique in the given point of time. SourceServerPath is not unique.
PendingChangeId has, however, also changed a little. It's no longer indexed on the server, so calling VersionControlServer.GetPendingChange[s] is very discouraged (and can throw exception). Instead client needs to use QueryPendingSets/QueryShelvedChanges or Workspace.GetPendingChanges.
If your tool needs to track item across renames, VersionControlServer.QueryHistory is your best friend. Please keep in mind that it can't be recursive (it will be always slot mode then). Remember that you can specify versionFrom, versionTo and max number of records to return. The call should be quick if you are requesting only single changeset, just before item was renamed - version does not need to be between versionFrom and versionTo (http://msdn.microsoft.com/en-us/library/bb138961.aspx)
Those are the biggest changes, in the next blog post I will talk about other changes, less used but still interesting :)
|
-
Recently a few folks from our and other team tried working with TFS inside PowerShell ISE (http://blogs.microsoft.co.il/blogs/scriptfanatic/archive/2008/12/30/windows-powershell-integrated-scripting-environment-ise.aspx).
What they discovered is that tf.exe thinks that its output is redirected and switches to noprompt mode. Which means that running
tf.exe checkin
will check in the code instead of bringing up UI. Ouch.
The problem is that ISE is really redirecting the output of tf.exe in order to display it. tf.exe is trying to be smart and suppress UI if it detects it. Fortunately there is easy workaround since TFS 2008.
If you set environment variable:
TFS_IGNORESTDOUTREDIRECT=1
We will stop detecting output redirection. You need to add /noprompt to force no ui mode.
Hope this helps :)
|
-
As you could notice in CTP1 or CTP2, new Resolve Dialog displays detailed information about selected conflict. This information is partially calculated on the background and can involve some time consuming operation. Right now they are:
- attempt to merge the content - we say if there are content change in both source and target, if they can be automatically automerged etc.
- query the history to display edits on the server/target branch. Right now we display list of last 2 changes. This includes their numbers as links (clicking one of them brings up changeset dialog) and tooltip with changeset number , owner and comment
If you can think of any other analysis that would be useful and that can be calculated for the conflict - let us know!
|
-
|
TFS always creates conflict when rename is involved, even if it's only on server/source branch. We expanded Automerge All, so it can automatically resolve those conflicts. We exclude from this, conflicts on folders, as those are rare and user should review them.
If you can think of other ways of expanding "Automerge All", please let us know - sometimes a few hours of work invested in the tool can save days of work spent duirng big merges :)
|
-
We heard that some users are afraid of performing "Automerge All" operation. The thinking here is that TFS (or any) merge engine is not 100% bulletproof. If method foo was added at the beginning of the file in the source branch and at the end of the file at the end of the file, automerge will succeed but build will be broken soon after.
As a way to mitigate this, we allow user to specify what kind of content change should be resolved:
1. Only conflicts that have content change in the local workspace or in the target branch
2. Conflicts that have content change in the local workspace/target branch OR on the server/source branch
3. All conflicts that TFS engine can merge content of (original behavior)
The type of the content change is also included in the conflict description.
Personally I always perform AutoMerge All (2) to rule out all simple conflicts and then resolve other conflicts one by one.
This change is available in CTP2.
|
-
As Brian said long time ago in his blog (http://blogs.msdn.com/bharry/archive/2008/02/01/a-new-spec-on-conflict-resolution-is-available.aspx), and Mario described in the spec (http://download.microsoft.com/download/e/0/e/e0ed04ec-bf14-4dd6-b5ad-22094b128498/Resolve-Improvements.xps) we are actively working on improving resolving version control conflicts in new version of TFS. The biggest highlights are already described in those posts/blogs (like non modal experience). What I'd like to do is to list a few small, cool features which I hope can save a lot of frustration, especially when working with big merges. First of all, we finally provide a history both for Source and Target when dealing with conflicts caused by merging between 2 branches. We also provide Annotate, when inside Visual Studio, adn when it's merge conflict you get Annotate both for Source and Target. I must say that when dealing with a large number of conflicts, it's great to work inside VS, with maximized Conflicts window, with History and Annotate as tabbed documents (nothing is modal).
The other small but useful feature I'm playing with is ability to resolve multiple conflicts with external merge tool in a bulk. You select a list of conflicts and click "Merge changes with Merge Tool". We stat merge tool for the first conflict and queue the rest of them. As soon as you resolve one conflict, we start a tool for the next one. If you use the default diffmerge, you don't need to click any prompts or select conflicts -just pick the right content changes ;)
If after reading the spec you can think of any such little (or not so little) neat feature, please share them and we'll be happy to discuss them inside our feature crew.
|
-
I have played a little with MS Access 2007, verifying that it's working with TFS Msscci 2008. In order to get SCC integration, you need to install Access Developer Extension - a add-in that allows Access to use any Msscci provider (and a few other goodies).
Access does not allow you to change SCC provider, so if you have installed a few of them on your machine, you may check my other blog post: http://blogs.msdn.com/michalma/archive/2006/03/01/541255.aspx
Everything seems to be working just fine - you can add tables, forms and queries to TFS, display History, Properties etc. The Source Control toolbar looks really cool.
The unfortunate problem, which we plan to fix in the next release of TFS Msscci is the fact that Access (the same way as VB6) verifies if item is checked out by somebody else, before allowing user to perform checkout. The problem is that we tell that file is checked out even if the pending change exists only in the shelveset, not in the actual workspace. This makes using Access and shelvesets in the same time very hard.
|
-
Yet another tool that should be working with TFS Msscci Provider is RoboHelp. The reported problem is "Server Busy" error message display over Msscci dialog.
The solution for this (until release of the new provider) is to create registry file (robofix.reg) with the following content:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Team Foundation Server MSSCCI Provider\Settings\RoboHelp]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Team Foundation Server MSSCCI Provider\Settings\RoboHelp\ROBOHTML.EXE]
"issues"=dword:000000D1
Then run it.
Of course this script is provided "as is". If it does not help, please remove this entry from your registry.
|
|
|
|
