VSS Sourcesafe Migration Tool - queries

We have a number of VS6 databases containing a large amount of source code. We rely heavily upon pinning and branching to maintain a core development project and a set of branched release points (which are pinned and potentially repinned later to accept fixes from the main core).

When looking at the currently released version of the Source Control Migration tool, there were some issues which made us unable to move forward. It's unclear from the documentation whether all of these issues are bugs or whether they are features. So, the resultant questions are :

- In VSTS Source Control, changes can be merged, but only between branches. VSS branches which were migrated forwards into VSTS did not have their branch status maintained so merging was no longer possible. Is it intentional that migrated source loses its branch information or will this be fixed ?

- Migrated source which was Pinned is migrated at the final version point with a Label added to indicate the location of the old Pin. We have tens of thousands of source files which have been pinned and branched - what's the intended migration path for such files ? There's no way that we can roll-back these pins by hand to their correct location in the history & right now I shudder at the thought of trying to test the results if I try to automate this.

- Is there a way to associate two source trees together as branches, or must they be created as branches in the 1st place? Without this linkage there appears to be no way to perform merges, which removes the workaround option for the migration tool failing to maintain this linkage.

Thoughts on any of these points would be appreciated,

Cheers,

Martin

[2107 byte] By [MartinCrimes] at [2007-12-16]
# 1
In VSTS Source Control, changes can be merged, but only between branches. VSS branches which were migrated forwards into VSTS did not have their branch status maintained so merging was no longer possible. Is it intentional that migrated source loses its branch information or will this be fixed ?

In VSS, share is precondition of branch. Share is not supported by TFS Source Control. Hence converter creates a copy of shared file as described in documentation. Once the copy is created it is not possible to treat copies as branch after the migration of branch event
.

Migrated source which was Pinned is migrated at the final version point with a Label added to indicate the location of the old Pin. We have tens of thousands of source files which have been pinned and branched - what's the intended migration path for such files ? There's no way that we can roll-back these pins by hand to their correct location in the history & right now I shudder at the thought of trying to test the results if I try to automate this.

In above case the version of file is first pinned, shared and then branched in VSS. During migration,
1. The converter will apply "PINNED" label to the corresponding version in team system,
2. While migrating share event it will create a new file in destination folder with content same as present version of file in source folder
3. Since the file is branched the changes(newer versions) in source and destination files are not propogated.

Is there a way to associate two source trees together as branches, or must they be created as branches in the 1st place? Without this linkage there appears to be no way to perform merges, which removes the workaround option for the migration tool failing to maintain this linkage.

No it is not possible to associate two source trees as branches in the 1st place they should be created as branches. The workaround for user is to perform baseless merge between two sources. Infact if converter was migrating VSS branch as branch, the user will be able merge only branched files, as folders are anyway not branched in VSS.

AkashMaheshwariMSFT at 2007-9-8 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...

Visual Studio Team System

Site Classified