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

Scenario

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 …

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