michal.Log : Rosario

Version Control API changes in TFS 2010 - part II

michalma — Tue, 16 Jun 2009 23:46:00 GMT

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!

Version Control API changes in TFS 2010 - part I

michalma — Tue, 16 Jun 2009 02:44:00 GMT

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

Resolve improvements in Dev10 – Server and Target edits

michalma — Sun, 11 Jan 2009 03:34:00 GMT

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!

Resolve improvements in Dev10 – Automerge All part2

michalma — Sun, 11 Jan 2009 03:31:00 GMT

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

Resolve improvements in Dev10 – Automerge All

michalma — Mon, 05 Jan 2009 22:07:00 GMT

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.

Resolve improvements in next version of TFS

michalma — Mon, 05 May 2008 04:50:00 GMT

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.

New features in next release of TF

michalma — Sun, 20 Jan 2008 22:34:00 GMT

Brian published a few screen shots of tools that we are working on right now for the next major release of TFS (not SP1). The Branch Visualization (Scenario 2 and 3) are amazing but right now my personal favorite is improved history (Scenario 1). While working on my feature I was doing some forward merges and resolving conflicts (fun, fun, fun ;)). Being able to display history and track the changes in time to understand why a line of code changed in the way it did would be invaluable. Unfortunately it's utilizing new server calls so chances for powertool including this functional are smaaaaal.

Early Rosario feedback

michalma — Sun, 06 Jan 2008 04:10:00 GMT

I just read Brian's post (over month after the fact :() about Rosario specs - http://blogs.msdn.com/bharry/archive/2007/11/30/vsts-codename-rosario-specifications-begin-to-arrive.aspx

It's a great way to influence product that is being written right now (literally :) ). If you are interested in changes we do to:

History dialog
Add to source control
Labeling

please read the specs (http://msdn2.microsoft.com/en-us/teamsystem/bb936702.aspx) and comment on the forum!