TFS Integration Platform – I have just moved my VC content, now I want to sync from a specific snapshot … now what?


2011-03-24: Also refer to Can I use snapshots and catch-up for both VC and WIT? QA-51 


As shown above we have a hypothetical situation or scenario of a Team Foundation Server (TFS) 2008 on the left. By using the Visual Studio 2010 TFS Upgrade Guide or any other manual migration process we move a project from the TFS 2008 server to a TFS 2010 instance on the right. At this point we have two copies of the same project with the latest valid copy (snapshot) associated with changeset 2000 on the left and changeset 1000 on the right, for arguments sake.

If we would switch off the left server we could end this post right here and go for the next coffee break. However, for some strange reason such as teams still working on the project in the left environment and teams working on the project on the right we have to keep the version control in sync.

We install and run the TFS Integration Platform TFS-TFS Connector … only to be faced with a tsunami wave of conflicts as the code already exists in both the source and the target, resulting in content conflicts.

Now what?

Using Snapshots

The latest tooling (dated 2010/3/16 or later) has a new feature that will assist you in this regards. Notice lines 14 and 15, which allow us to specify a SnapshotStartPoint that tied the left to the right and visa versa. In recent builds we could do this one way, but with this feature we can configure a sync that honours the snapshot points and side steps the tsunami wave of conflicts as above.


Note that the SnapshotStartPoint defines the last changeset. The session will process 2000 + 1 next on the left and 1000 + 1 on the right.

   1: <Session SessionUniqueId="..." FriendlyName="Version Control session" LeftMigrationSourceUniqueId="..." RightMigrationSourceUniqueId="..." SessionType="VersionControl">
   2:   <EventSinks /> 
   3:   <CustomSettings>
   4:     <SettingXml>
   5:       <VCSessionCustomSetting>
   6:       <Settings>
   7:       </Settings>
   8:       </VCSessionCustomSetting>
   9:     </SettingXml>
  10:     <SettingXmlSchema /> 
  11:   </CustomSettings>
  12:   <Filters>
  13:     <FilterPair Neglect="false">
  14:       <FilterItem MigrationSourceUniqueId="..." FilterString="$/serverpath1" SnapshotStartPoint="1000" PeerSnapshotStartPoint="2000" /> 
  15:       <FilterItem MigrationSourceUniqueId="..." FilterString="$/serverpath2" SnapshotStartPoint="2000" PeerSnapshotStartPoint="1000" /> 
  16:     </FilterPair>
  17:   </Filters>
  18: </Session>

A final nugget to highlight …

My lucky number 13 … line 13 has the last nugget I would like to highlight for today, namely “Neglect”.

The attribute neglect defines cloaking. Neglect = “true” means the filter string is cloaked. For instance, you could map $/path1 -> $/path2 and Cloak $/path1/cloakedpath ->$/path2/cloakedpath.

This only works for a new configuration!

As correctly highlighted by Hyung, the above only works for new configurations. In other words, you have manually copied the snapshot from source to target and the TFS Integration Platform has not run yet and teams are not making changes while all of the above is going on.

If you wish to use this feature on an existing configuration, the following steps are recommended by Hyung:

  1. Deliver changes manually to make both ends in sync under a new server path
  2. Lock the server path (Don’t allow users to check-in under the new path)
    • This step is important to avoid the VC session from skipping changes to the high water mark that the VC session maintains.
  3. Stop sync service
  4. Add a new filter pair with sync point pair
  5. Start sync service
  6. Now it’s okay for users to deliver changes to the new server path

Finally a word of warning …

Orange Person Seeing Stars And Lying On Their Back After Slipping In Front Of A Caution Sign Clipart Illustration Image

As appealing as the above synchronization may appear, please note that as outlined in our guidance the synchronisation scenario is last on the list of options and should be avoided where possible. While it is technically possible, the challenges and especially cost are associated with the monitoring and maintenance of a synchronization environment. Also it is importantly to remember that complexity and cost of migrations increase as history increases … avoid trying to move history when possible.

See you next time for more magic that bubbles up from the platform 🙂

Comments (4)
  1. Manish Jain says:

    This is great Willy. Thanks. How do I sync work items? What is the xml syntax is that's supported.

  2. I recommend that you review the product documentation, especially the configuration guide and the sample configuration templates. You can sync WIT similarly to VC, including linked items. The supprted XML syntax  is documented in the configuration document, however, the recommendation is to use the TFS Integration UI where possible and not to edit the configuration file by hand.

    The forum…/tfsintegration is a great source of information and channel to raise questions or problems.

  3. Manish Jain says:

    I'm already using TFS 2008/2010 to TFS 2010 migration and it's working fine. Thanks for building such a great tool. How can I achieve syncing work items for e.g. WI # 2000 onwards OR WI# 2000 to WI # 4000 – on similar lines syncing change sets explained above. Can you point me to specific link? Thanks.

  4. You can create and WIQL queries in your configuration. I recommend that you create a WIQL query and test it within Team Explorer and then re-use the query as part of the TFS Integration Platform configuration. If you are experiencing problems, please raise a thread on…/threads and share your configfuration file for analysis.

Comments are closed.

Skip to main content