Version Control API changes in TFS 2010 - part I
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 (https://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 :)