Timely Migration works by querying the StarTeam server for information about the items to be migrated. Older versions of StarTeam server do not provide access to information required for some features, so not all features are supported on all versions. The table below lists the limitations that are present with older StarTeam server versions:
Version | Changesets | Labels | Renames | Moves | Deletes |
StarTeam 6 | Yes | Yes | Yes | No | No |
StarTeam 2005 | Yes | Yes | Yes | Yes | No |
StarTeam 2006 | Yes | Yes | Yes | Yes | Yes |
StarTeam 2008 - StarTeam 14.0 | Yes | Yes | Yes | Yes | Yes |
Within StarTeam branches are accessed through the "Select View" dialog using a tree metaphor based on the parent-child relationship of the branches, and not the purpose of branch. Over time, the number of branches within your source tree will likely have grown, making the list of Views appear cluttered and tedious to navigate. With Timely Migration, you can group together branches into more meaningful relationships as part of the migration.
The example below shows six minor releases that were part of two major releases that were branched off the trunk for maintenance purposes. The example also shows three task branches that were created to develop features for large clients. The features for client A and client B were merged into the trunk after they were completed, while client C decided to stop development, resulting in a dead branch that never went anywhere and can be removed.
Using the Folder Mappings feature of Timely Migration, the branches can be reorganized to group the official releases together by major release, and the development task branches together while dropping out the task branch that was never finished as seen below:
History in StarTeam is typically reported on in a file by file basis which makes it hard to see how changes relate across modules. When Timely Migration brings over changes from StarTeam it will group individual file revisions into TFS changesets based on the user making the change, the comment and time of the change.
The example below shows how changes between two separate modules are grouped together during the migration process. The timestamp for the changeset is embedded in the comment and will typically correspond to the last timestamp for the files in the changeset.
With Git, tags refer to a single commit, which includes all the files in the tree and not just the files that were changed as part of the commit. Any labels in a view that do not refer to the entire view at the label time will be promoted to the latest commit that made of part of the original label.
StarTeam handles rename and move operations in a number of different ways. Depending on the operation being performed and whether or not it is an individual item being operated on or a parent folder, it can be difficult to determine when a rename or move was performed. When rename and move operations are brought over to TFS by Timely Migration they will both be represented as rename operations and their corresponding changesets will be shown for both folders and the individual files that they contain.
The example below shows the history for a rename operation on the folder Installation/WiXInstaller to Installation/TimelyMigration as it applies to a file within that folder:
The changeset details for the rename operation will include all files that were part of the rename as can be seen below:
Within StarTeam it can be difficult to find and access deleted files. Timely Migration brings over the history for these deleted files and they can be viewed by enabling the "Show deleted items in the Source Control Explorer" setting under Options -> Source Control -> Visual Studio Team Foundation Server.
As with rename and move operations, operations performed on a folder will also be visible to histories performed on files within that folder as can be seen below: