TFS strategy to move a large number of projects from Source Safe

Question

The company I work for has more than 1000 applications that we support. Many of them relate to old technologies such as VB6 or to weak technologies (Access).

We are committed to moving away from Source Safe. We have TFS and we are moving our dot.net projects to TFS. Other projects do not integrate with TFS and do not need a portal or other TFS functions (except for the control source).

I am worried about leaving other projects in Source Safe due to product unreliability.

As far as I can see, there are two options:

1) Create an empty project in TFS called "VB6" (for example). Separate it for each VB6 application that resides in VSS. This will put all VB6 applications in this subfolder. Thus, all applications can be in TFS.

2) Put clean point projects in TFS. Create a CVSNT repository and host all other VSS projects there.

3) Put clean point projects in TFS. Leave all other projects in VSS. Run weekly compact and restore all VSS databases.

Which option do people consider the best? Has anyone else been in a similar situation?

Answer 1

None of the three options make sense to me. If you want to leave SourceSafe and have already decided to move to TFS (at least for your .NET projects), then, in fact, you ask, is there a good way to transfer the source for 1000 older technology applications for TFS?

My recommendation is to simply use Source Control Explorer as your SCC client for TFS. It works similarly to the SourceSafe GUI. Any reason that won't work?

Answer 2

The IMHO problem is your definition of "Project". Team Project is a high-level container used to define processes and isolation. There is no reason not to have a VB6 Team Project with a complex source tree. There is no need to create actual “branches” (in the “Merge” and “Merge” sections) for each VB6 application. Just the same folder structure as in SCC.

So, essentially, I see no reason not to do my first option - just don't worry about branching overhead (unless you have a real need)

Answer 3

Option 3 looks like the most economical bet in this situation, assuming that VSS storages remain less than 1-2 GB in size (I understand that they are much more prone to corruption when they become larger - this goes out of memory, though, so that I can make mistakes). Keep a backup of VSS in a physically separate place for insurance, and if not, keep going as is. The relatively small return on investment for the movement, as you described in the general case.

Answer 4

Git> TFS, use this instead.