Best way to migrate from Visual Souce Safe 2005

Aug 24, 2010 at 8:09 AM

We are in the process of migrating our Visual Source Safe 2005 Database to TFS 2010.

I'm wondering what's the best strategy for us, based on the actual use of VSS. Whe are a team of 10 developpers with some of them working on the whole project tree. The others are limited to severals sub projects.

The Basic Branch Plan seems perfectly fine because this is exactly what we do right now from the customer perspective (One major relase, hotfixes included in the next major realease). We're currently using VSS to share a lot of C++ code between native projects, mostly sharing, sometimes branching, .cpp and .h files. On the other end, we took another approach for managed projects source code (c#). Code is no longer shared for obvious reasons, we chose to share binaries with the assistance of disk folders. Labels are used in both cases to track versions of the final binaries (native and managed) in order to produce hotfixes for customers.

Our Source Safe database structure is basically the following :

$/Shared Tools/Domain Projects1...N with .h/.cpp source code only (no projects/solutions files). Domains are "registry" or "file" for instance, providing reusable C++ classes that encapsulates the corresponding operations...

$/Product 1...N" with Visual Studio solution files.

$/Product 1...N/Module 1...N with Project Files, Shared .h/.cpp files from $/shared tools sub projects and local files.

$/Shared Tools/Domain Projects1...N with c# source code and a project file to produce the binaries that are copied to shared folders on disk. We have an ASP.NET Profile provider assembly for instance.

$/ASP.NET Web Site 1...N with project file and c# source code.

The disk structure for shared libraries (managed/mixed) is like the following:

\\HOST\Libraries\Release\x86

\\HOST\Libraries\Release\x64

\\HOST\Libraries\Release\V1.0 

\\HOST\Libraries\Release\V1.1

\\HOST\Libraries\Release\V1.2DEV

The best practives for development is to always get the latest versions of all files for C++ projects. Managed projects have a file reference to the binaries on disk. Having up-to-date bits is ensured that way.

My main concern right now is to be able to provide easy C++ code sharing the way we do it in VSS (no manual complex operations/automated operations).

Any help appreciated.

TIA.

Olivier.

Coordinator
Aug 25, 2010 at 2:59 PM

Olivier,

The topic of “shared code” between Team Projects is a topic that this team is currently investigating and for which we are planning to add options and recommendations to the branching guidance. The shared code guidance update talks about three main techniques for sharing code, namely File Linking, Source Code Sharing and Binary (Assembly) Sharing. Whichever option you opt for, it is recommended that the common code is kept in a separate Team Project, which should maintained by a team committed to the common code. This introduces ownership and management of the common code and any revisions that may be received through reverse integration or independent submission, as well as a quality gate enforced by the common code team.

Once you have a common code project, for example $\Common Code\Enterprise Library, you can share the common code through the above mentioned strategies.

  1. Are your projects small?
    • If yes, File Linking, which shares a reference to a source file with multiple projects and is the closest thing to VSS file sharing, may be an option.
      • When using file linking, the dependent projects are not isolated from changes to the linked file.
      • This approach is generally not recommended for more than a small number of linked files and a small number of dependent projects.
    • Alternatively you can consider the following options:
      1. Option 1 – Binary (Assembly) Sharing
        • Teams managing the common code have full ownership and control, which in theory means that the control, versioning and quality of the product is probably better, and branching and merging complexities are avoided.
        • Teams re-using the common code have no access to the common source code and potentially have to wait for the team managing the common code to address features and bug resolutions.
        • Some of the questions that emerge :
          • Would the common code team check the binary files into version control?
          • How would the common code binaries be shared?
            • A well-known file share? 
            • A shared BIN directory within the common code team project version control?
            • Copied to dependent project directories?
            • Other…?
      2. Option 2 – Source Code Sharing (bi-directional)
        • Teams managing the common code share the source code by branching the code to the consuming project version control.
          • It is important to highlight that nested branches are not supported in TFS2010 and following the product group guidance you should:
          • Create a  folder within a dependent projects Team Project called share, for example $\Product1\Share
          • Branch the Main branch of the Common Library to the Share folder of the dependent Project, for example branch $\Common Code\Enterprise Library\Main to $\ProductX\Share\ Enterprise Library
          • Some of the questions that emerge:
            • How are changes made by the project teams using the common code reverse integrated (merged) back to the common code?
            • How are changes managed to avoid incompatibilities which make a reverse integration (merge) impossible, resulting in multiple copies of the shared code?
      3. Option 3 – Source Code Sharing (uni-directional)
        • Same as option 2, except that the branched source code is made read-only, which avoids the possible nightmare of merge complexities and conflict resolution mentioned with option 2.

So what is the recommended option? The question of scenarios and the recommended strategy is part of the branching guidance refresh and therefore we cannot give you a solid story at this point. But looking at your environment … as far as we understand in terms of managed and native (C++) code … option 3 may be the option to investigate.

Willy

Aug 26, 2010 at 2:13 PM

Willy,

Thanks for that.

While searching for the nested branches restriction in TFS2010, I found this very interesting thread :

http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/992e1d11-729d-40aa-bd07-943d3dc7ce1a

Today (thanks to the VSS "share" option), when a bug is found in the shared C++ classes, it is fixed by the person responsible for the shared code at the product level. All other products will benefit from the fix. Now assuming that TFS is in use with uni-directional code sharing, as suggested in option 3, we would make the change in the Common Team Project, then branch at the product level, right ?

To keep simplicty and to avoid breaking changes in existing code in other projects, when there is a need to add more features to the base classes, maybe it's time to add new functionnality solely in a new derived class. After reading the thread above, I'm pretty scared about bi-directional merging...

Olivier.

Developer
Aug 26, 2010 at 3:54 PM
Edited Aug 30, 2010 at 12:25 PM

Olivier,

To be clear to others, the VSS "share option" is most similar to the VS File Linking option. You correctly note that any developer in any of the dependent (Product) Team Projects have a *link reference* to the same source code file. Regardless of where a change is made, or by whom, this change will immediately propagate to all other dependent (Product) Team Projects as well as the *owning* Team Project.

As with any code sharing approach, I think it is appropriate to determine who the *owner* of the code is, and what *permissions* do users of this code have to make changes.

To clarify Option 3 Source Code Sharing, the source code is owned by a CommonLibrary owner (e.g $\Common Code\Enterprise Library). With uni-directional source code sharing (Option 3) the dependent (Product) teams would NOT have permission to change the shared code. Since we recommend branching the CommonLibrary from the Main branch to the dependent projects, any changes must first be in the $Common Code\Enterprise Library\Main branch and then merged (FI) to the dependent projects ($\Productx\Share\Enterprise Library).

The question then becomes where are changes to the source code made and checked in? I recommend not ever checking in changes to a Team Project's Main Branch. So, assuming we are talking about a new feature or enhancement, I would make the change in a development branch (e.g. $Common Code\Enterprise Library\Dev\DevTeam01) and once it is tested, integrate (Merge RI) the change into the main branch ($Common Code\Enterprise Library\Dev\DevTeam01) -> $Common Code\Enterprise Library\Main), and from there Merge (FI) into the dependent projects ($Common Code\Enterprise Library\Main -> $\Productx\Share\Enterprise Library)

 I agree that Option 3 is a more controlled mechanism for sharing code and is therefore less likely to cause breaking changes than File Linking or Option 2.

Again note that the branch hierarchy of the shared code is:

  • $Common Code\Enterprise Library\Main
    • $Common Code\Enterprise Library\Dev\DevTeam01
    • $\Productx\Share\Enterprise Library
    • $\Producty\Share\Enterprise Library

There is no merge releationship between the product branches and the shared code branch within the product team projects

  • $\Productx\Main
  • $\Productx\Share\Enterprise Library

Or you could add these features, as you suggest, in a derived class of a shared class that is in the Product's Team Project. This type of enhancemen would typically be scoped (restricted to) the Product where the derived class exists (not shared with other Products).

I would also note that Option 1, using binary references is a typical way that I reference shared code (such as Enterprise Library). I don't necessarily want to build all of the code in enterprise library everytime I build my dependent project(s). Option 1 would be faster build (or compile) than Options 2 or 3.

Regards,
Bill Heys
VS ALM Ranger

 

 

Developer
Aug 26, 2010 at 5:18 PM

Typically one would use Binary (Asssembly) references for third-party shared components. In this scenario, you might not have access to the third-party source code. Such third party components might need to be installed on all developer machines (as well as build machines). Typically you would reference the assemblies from wherever the install process deploys them (such as the GAC).

Further, one would prefer Binary (Assembly) references over Source (Project) references for very large solutions with many projects. When you use project references all of the projects are compiled on a full build. The is true even when none of the shared source code has changed. Compile and build times on these very large solutions will be noticably impacted by having to recompile all shared source projects.

When you use Assembly references you can store the assemblies locally in the solution (Team Project). This has the advantage that, once copied to a folder within the Team Project / Solution, it can be checked into source control. Automated builds can get the correct assemblies from source control (get latest).

Alternatively you can store the assemblies in a well-known location (such as a network file share). This network share needs to be accessible for developers when they build locally as well as automated builds.

Finally you can store the assemblies in the Global Assembly Cache (GAC). This is a good approach for signed assemblies.

A benefit of assembly references is that you have support for side-by-side versions. Each dependent project can reference a specific version of the shared code (or component). Other dependent projects can reference different versions of this same shared code (or component). Changing which version of shared code (or component) your solution references (or to pick up changes) is simply a matter of copying the appropriate assemblies (DLLs) into the shared binary folder within the solution.

When you use project references, you are typically using branching and merging (rather than file copying) to manage version control and updates.

Regards,
Bill Heys
VS ALM Rangers

 

Aug 30, 2010 at 12:14 PM
wheys wrote:

To be clear to others, the VSS "share option" is most similar to the TFS File Linking option. You correctly note that any developer in any of the dependent (Product) Team Projects have a *link reference* to the same source code file. Regardless of where a change is made, or by whom, this change will immediately propagate to all other dependent (Product) Team Projects as well as the *owning* Team Project.

Is the TFS Linking option provided by TFS or Visual Studio ? Could you point me to this feature's documentation ?

Developer
Aug 30, 2010 at 12:25 PM
Edited Aug 30, 2010 at 12:28 PM

I apologize for the type. It is a Visual Studio option, not a TFS option. I should have said VS File Linking (I corrected my post above). To use this feature, again for a small number of shared files, use the Add Existing Item menu. When you browse to the desired file you want to add to your project, you can choose from the *dropdown button* and select *Add* or *Add as Link*

Regards,

Bill Heys
VS ALM Ranger

Aug 30, 2010 at 1:36 PM

Finally, to take advdantage of all the features of Branching and Merging in TFS2010 after importing data from Visual Source Safe, is the 'Convert Folder to Branch' step the last thing to do after the initial import ? Is the baseless merge facility for C++ shared code usefull in my situation ? Any other suggestions ?

 

Kind Regards,

Olivier.

Developer
Aug 30, 2010 at 1:53 PM

Olivier,

At some point you will want to convert your *main* folder to a branch. I am not sure what your lists of steps are, so I am not sure it is the *last* step or not.

Perhaps you can explain why you feel you need a baseless merge, and what branches would be the source and target of this merge. I generally try to discourage doing baseless merges for a variety of reasons. A key reason is to avoid a confusing *matrix* of merge relationships where a branch has a merge relationship with many other branches (not simply its direct parent and children).

It is sometimes necessary to do a baseless merge. There are times when I have to do a baseless merge to fix a problem that I cannot fix through normal merge relationships or to invoke options that are not available through the UI.

Regards,
Bill Heys
VS ALM Ranger

 

Aug 30, 2010 at 2:24 PM

I was thinking that I would convert the main folder (ie : $/ ) to a branch right after the data import from Visual Source Safe.

About Baseless Merge, I was reffering about the reply marked as answer in this other thread : http://social.msdn.microsoft.com/forums/en-US/tfsgeneral/thread/3e4efc40-45c3-4242-a4cb-f38610961512/.

Kind Regards,

Olivier.

 

 

Developer
Aug 30, 2010 at 2:56 PM

Given your VSS source structure at the beginning of this thread, it would be helpful to understand more of what your target TeamProject/Branch/Folder structure will be.

You mention that you have Product 1...N. Are these each going to be in their own TeamProject?  Are all Products developed and released on the same schedule?

Knowing more about why your code is structured the way it is in VSS today will help me guide you in the right direction. In other words, I am not sure you will necessarily end up with a single Team Project and Main folder (branch)

While dated, I believe the thread you reference above is a valid approach, where for a single Team Project / Product, you have multiple VSS folders that are similar to the basic branch plan in TFS (e.g. Main folder, Dev folder, Release folder, etc)

Since you would not have a hierarchical relationship between the VSS folders (Main -> Dev) when you bring the folders over from VSS, you could use a baseless merge to allow you to create a merge relationship, and then even reparent the child folders to the parent folders in VS 2010.

Bill Heys

 

Aug 30, 2010 at 3:28 PM
Edited Aug 30, 2010 at 3:30 PM

I would strongly strongly advise against having multiple team projects. From what we've learned at Microsoft the "Big" divisions have enforced using 1, and only 1, team project for the entire division with many many branches under that 1 team project and using areas and iterations to seperate work items.

Think about that for a second 2500~3000 people on the Visual Studio Teams(including the .Net Framework team) use only 1 team project.

I want to warn you about a bug (a pretty severe bug IMHO) in having multiple team projects. http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/a71ac2f0-dc9c-4c03-a6a3-ab59877c55d8.

My recommendation would be when migrating from VSS to TFS to migrate your history to a folder (say $/Archive) and then create a new branching structure following the "standard" branching plan from the rangers guidance.

Aug 31, 2010 at 6:20 AM
Edited Aug 31, 2010 at 6:21 AM
wheys wrote:

Given your VSS source structure at the beginning of this thread, it would be helpful to understand more of what your target TeamProject/Branch/Folder structure will be.

You mention that you have Product 1...N. Are these each going to be in their own TeamProject?  Are all Products developed and released on the same schedule?

Knowing more about why your code is structured the way it is in VSS today will help me guide you in the right direction. In other words, I am not sure you will necessarily end up with a single Team Project and Main folder (branch)

My first guess is that I won't use several Team Projects.

1) All products developped are not released on the same schedule, we switch from/to developpement/release between them as needed, but we may temporaily switch back anytime a fix is needed. In my mind, this is where the benefits brought by the basic branch plan comes in with TFS (as opposed to the current use of labels in VSS to achieve the same goal and to avoid regression in shared code).

2) I would like to continue providing code sharing between projects for "system services" (like file and registry operations...), carefully dealing with FI and RI between projects and shared code.

wheys wrote:

While dated, I believe the thread you reference above is a valid approach, where for a single Team Project / Product, you have multiple VSS folders that are similar to the basic branch plan in TFS (e.g. Main folder, Dev folder, Release folder, etc)

Since you would not have a hierarchical relationship between the VSS folders (Main -> Dev) when you bring the folders over from VSS, you could use a baseless merge to allow you to create a merge relationship, and then even reparent the child folders to the parent folders in VS 2010.

Bill Heys

 Thanks for that, this not our folder structure in VSS at this time.

Kind Regards,

Olivier.