Migrating from SourceSafe to Team Foundation Server

We plan to provide migration tools for users switching to TFS.  A VSS user asked in the newsgroup about migrating VSS labels, revision history, sharing, and pinning.

The goal is migration of all data, consisting of projects, files, and folders, with associated metadata reliably with minimal information loss while preserving user information and appropriate permissions.  There are some features in VSS that do not translate to TFS.  The following is quick overview of the preliminary plan.

  • Users and groups in TFS are Windows accounts (it uses standard NTLM authentication).  SourceSafe identities will be migrated to Windows accounts. 
  • Labels and revision history will be preserved.  With regard to revision history, TFS supports add, delete, rename/move, etc.  It does not support destroy/purge in V1.
  • TFS does not have the equivalent of sharing, so the current plan
    is that the migration tool will handle that by copying.  Each copy will have its own history of the common changes made after the file was shared.  VSS branching is migrated in a similar fashion.
  • Pinning and unpinning are also not available in TFS.  The current plan is that for any item currently pinned, the user will be given the option to either ignore the pinning or to assign a label to the versions that are pinned and lock them.
  • TFS does not support the VSS archive and restore features.

That is a very quick summary of the plan, which may change.  We welcome your feedback.

Comments (35)

  1. David Campeau says:

    No pinning… this disapoint me a little bit, but i can do without.

    No sharing? No here is a show stopper for me. I was soo exited about the features in in TFS. Guess i will have to wait for v2 in 3-4 years :-(

  2. Buck Hodges says:

    Yes, there is no sharing support in V1. How do you use sharing? What problems does it solve for you?

  3. Brendan says:

    No sharing is also a showstopper for my organization as we use it quite heavily.

    Pinning as well is often used instead of forking in my organization and will be sadly missed.

    Looks like we’ll only be upgrading to VSS 2005 (provided it still supports both when released).

  4. David Campeau says:

    This is what sharring does for us:

    1) in VB6 to avoid DLL hell. We share some classes between project. When a project updates a class. All the application using it gets the upgrade. this way we only have en executable to push.

    2) All our utility module are shared between all projects

    3) When going from V1 to V2 of our projects. we share/pin to be able to backtrack fixed bugs in the previous version.

    As much as i would love to always be in the .NET world, we still have 80% of our project still in the VB6 world (maintenance and all). I can see how in the .NET world the deployment of software (read DLL, components etc.) is much easier. but for me no sharring = no VB6 support for our project.

  5. Buck Hodges says:

    That’s interesting. I think the same thing can be accomplished, but the process is different. In TFS and the source control MS uses internally, these scenarios are accomplished with branching and merging.

    TFS uses a SQL server for the repository and fully supports branching and merging, including renaming and deletions. Source shared among projects would be branched into each project, if that is the mode of reuse. When it needs to be changed, the changes would be checked into the "trunk" (master) and then they would be merged into each branch. Since these are branched, the new sources would be merged into each branch, built, changed as necessary to build and run, and then everything would be checked in as one change set so that what is available in the repository always builds and runs.

    Normally, binaries aren’t versioned, but there are exceptions such as common build tools (compilers, build scripts, etc.). These are handled with the same process as for source.

    Having the binaries copied in different branches only occupies more space in the repository if they are different. Having the same exact file content in multiple locations does not take more space in the repository.

    For maintaining releases, a branch would be created. In fact, TFS has workspaces and branches can be created by saying "branch the versions that I have in my workspace" so that you can branch exactly what you built for the release. Then if you need to make a change later, the change can be made in the branch and merged into the trunk. Also, particular changes from the trunk could be merged into the branch, if needed. This provides a more robust method of maintaining the releases.

  6. David Campeau says:

    Guess I will wait and see…

    Just to make things clear, I was talking about vb class file (.cls) and VB Module file (.mod)

    and any "code" file for that matter.

    I know we will probably still use it for our .NET dev, just not for the hole shop.

    Just one feature i would like if possible:

    Add the VSS/TFS context menu that is available from SourceSafe/VisualStudio in explorer.

    We have many external tool that use files that are in VSS. And going in VSS to CheckOut/CheckIN/GetLatestVersion/etc. is a real pain.

    Having something like the "Send To" or "WinZip" in the WindowExplorer/FileOpen/FileSaveAS dialog box would make all our lives simpler.

  7. Buck Hodges says:

    There’s no special .NET support with respect to version control. The TFS client and mid-tier are written in .NET, but that’s it.

    I’ve mentioned your comments to Doug, our PM, and I’ll make sure he sees your feature request.

    Thanks for the feedback and the discussion!

  8. With our current projects we’re heavy users of sharing. In our case we’re doing most of our work with VB6. We have something like 400 individual executables each one of which shares code with the others, each executable is in a seperate subdirectory along with .VBP so each executable can be built seperately. It stops the problems you get with COM components and versioning under VB6. Basically it’s far to easy to screwup the users registry with COM under VB6 so shared DLLs are basically out (More details of the pain on request).

    This isn’t a big problem for our next generation of stuff being written in whidbey, however I like the ability to use sharing to share individual lumps of code across projects so when we fix something in one place we don’t have to copy it to another project. One place we’ve used it would for the tiny XYModem module I wrote for use on barcode scanners, each one needs that code in it’s project, putting it into a library isn’t sensible as often the processors are different (or at least the C compiler used)

    It means I don’t need symbolic links on my local hard disc.

    Often dealing with code like this is just plain easier than dealing with libraries. With VSS I just get the version associated with a label and away I go OR I can get the latest version and see if it compiles, if I use a library then I may need to store both the source and the library away to be sure of getting the same version we shipped to a customer.

  9. Steve says:

    Sharing is also a deal breaker for us. Our projects often reference third party binaries – we put each version of our dependant dlls in the repository seperately, and then share the file into the destination directory of each project that needs it. Its the only way we’ve found to manage versioning across lots of small projects.

  10. secretGeek says:

    on a teams i’ve worked on, we banned ‘sharing’ (VSS sharing that is, not the concept of sharing in general) a while ago, because we found it too broken in VSS at the time, and its not nice when you hurt your source code.

    no pinning, but there is locking and labelling – well that sounds good.

    as long as MS internally use TFS there is a chance that it won’t suck as much as Vss.

    a feature i’d like is RSS from TFS.



  11. swingbozo at yahoo dot com says:

    Can you expand on the ‘sharing’ vs ‘branch and merge’ approach? I can’t conceptually wrap my scrawny brain around it.

    I have project that is simply a base class in C++ terms. Let’s say for the sake of arguement it’s a socket class that implements stupid boring winsock calls. I have lots of other projects that need to talk using sockets that all use a shared copy out of this base project.

    Now I find out every time I do a socket close I have to do it a new way, instead of the incorrectly documented way in MSDN. How, using ‘branch merge’ do I automatically propogate those changes to every other project that uses this file?

  12. Rich Knox says:

    Regarding Brendan’s question: Visual SourceSafe 2005 continues to support sharing and pinning.

    – Rich Knox [MS]

    This posting is provided "AS IS" with no warranties, and confers no rights.

  13. swingbozo at yahoo dot com says:

    But does VSS 2K5 work reasonably over the internet? Visual Studio .net would have been a perfect time to address this obvious failing of VSS.

    This is yet another case where Microsoft over-promises and pre-announces then under-delivers LATE simply to fill these high profit vertical markets with FUD.

    This type of nonsense keeps me along with a rather large pack of other programmers back at Visual Studio 6, with our ear to the rail for other technologies.

  14. The more I read, the more I’m convinced you need to support BOTH the new Hatteras branch/merge model AND the VSS model of sharing and pinning if you want to make the transition to Hatteras practical for many users.

    Whilst branch/merge may be the ideal, there are situations where it just doesn’t fit (the shared common header file scenario is a simple example) and Hatteras needs to support such scenarios in ways which aren’t going to cause people to curse it the same way they do VSS at times…

    As a database administrator as well as a developer, I have another concern – the fact that databases imported into Hatteras will not retain the same structure they had before importing them. This – and the lack of support for VSS archive/restore – have the potential to kill it as a solution for my team as we have several large databases to migrate, and we’ll need to merge changes from pinned products back into the development branch even after migrating them.

    *Please* try to address these shortfalls. A lot of people will be very, very grateful if you do. If you don’t, the reverse could well be true – and it would be a shame to see a potentially great product fall short at the first hurdle.

  15. Will it be possible to map vss users to windows users?

  16. Buck Hodges says:


    Yes, you’ll be able to specify how the VSS users are mapped to Windows users for TFS. The current plan is that there is an XML config file for the conversion tool which will contain that information and more.

  17. Jon Robertson says:

    > as long as MS internally use TFS there is a

    > chance that it won’t suck as much as Vss.

    Microsoft uses an internal change management tool that is much more sophisticated than VSS, and probably TFS.

    I suspect Microsoft is finally caving to the fact that VSS is lousy for anything but the smallest of projects and has needed to be retired for a while. Even the smallest and most irritating of quirks have gone unfixed for years (and several "updates"). Why in the world would Get Current overwrite files that I have checked out without prompting me first?

    I suspect TFS is strictly for Microsoft customers, not Microsoft internal usage. You know, like Visual Basic. :)

  18. Buck Hodges says:

    Microsoft won’t be using TFS source control when it ships in large part due to the infrastructure built up around the current source control system (scripts, web pages, you name it). But TFS was designed with that goal in mind.

  19. Moving from one software application to another often results in various "surprises" where the new application…

  20. emmym says:

    in my organization we use the TFS 2005 but we apply it on the Delphi projects only and i ant to apply it for .net also how can i make this

  21. Raj says:

    How can I check in new files to previous label?

  22. buckh says:

    Raj, you’ll need to use the /child:replace option on the tf label command to updated the files in a label.



  23. Andrzej Martyna says:

    Lack of sharing also stops our company from moving to TFS for some projects.

    It relatively easy to move to TFS for new projects but what for old, 10 and more year-old projects?

    Proposing branch/merge to people that have built some solutions using sharing for many years is… let say, funny…

    These companies would have to do huge effort to move to TFS: change processes, totally reengineering source code… (and all this effort, all this risk just for nothing, just to follow Microsoft’s rules – hello, we are here to earn real money and we certainly need Microsoft to help us earn money not otherwise).

  24. Andrzej Martyna says:

    Just to be honest: don’t get me wrong – TFS is a really great product, and for sure it was huge effort to make it.

    The only thing I complain of is that you’ve forgotten about some important needs of some customers. That’s all.

  25. buckh says:

    Andrzej, I won’t disagree with you with regard to old projects that depend on SourceSafe features.  To minimize both disruption and cost, it makes sense to leave them in SourceSafe for now and start all new projects with TFS.

    We’ve talked about adding sharing in a future version of TFS, so it’s on our list to consider.  It will not be a feature in TFS 2010, though.


  26. Kenneth says:

    Can I check-in a previous label to the latest (tip)?

  27. buckh says:

    Kenneth, I’m not sure that I quite understand the question.  What are you trying to accomplish?


  28. We are in the process of Migrating all our applications in VSS to TFS. I belive we can use VSSConverter available with visual studio. Is this the tool you are providing or is there any other tools provided by Microsoft ?

  29. buckh says:

    Shobin, VSSConverter is the right tool to use if you want to migrate history, labels, etc. If you were comfortable migrating without history, you could check in the latest version of files.

Skip to main content