SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Example VSS Framework - Source Code Management - Part 1

By Chris Kempster,

This article provides a working framework for source code management in Microsoft Visual Source Safe.  The framework presented is not only designed purely for a system currently under support and maintenance, but will support other development initiatives (mini projects) that may be adding new functionality.   

For those working on multi-client software in which production source code is at different patch levels (and may include custom code), then you will need to rework VSS to adopt the strategy.

The article is scenario driven, starting with a very basic scenarios as we then move to more complex changes.



Change Control Manager.


Is similar to a folder in explorer, contain configuration items (files), VSS will automatically version projects and files with an internal value.


Is synonymous to a copy in explorer, but VSS maintain links between versions of branches to facilitate merging at some later stage. VSS via its internal version numbering will maintain the logical branch history in order to facilitate merging with any other branch. 


A shared file is a link to its master, or in other terms, a shortcut.  The shared file will be automatically pinned; to alter it you must unpin it.  If the shared file is altered its master will also be changed, along with any other shortcut (share).


Process of merging the changes from two branched files.  The VSS GUI will show the hierarchies of branches and associated links/paths, broken branches can not be merged too, or branches from incompatible parents (can merge the branches from two different trees!).

Build Phase - Moving to the new change control structure

The new structure of VSS is:

This structure maps to your equivalent development, test and server environments.  Source code for development and test environments is built from VSS production code project and the subsequent development/test project code applied over top (roll forward) to form the environment.  The developers need to manage themselves when there are multiple 'versions' of a DLL or other file source moving into test over time.  Either way, the VSS environment allows the full 'build' of development or test servers from a known image of production source code (which is critical):

The /production project folder includes the names of other applications currently under the change control process.  To start the process of change management using this structure, we will be introducing a new application called 'MYAPP'.  The CCM will:

  • Create a new project in /production call 'myapp; create sub-projects to hold myapp's source code
  • Label the MYAPP project as 'MYAPP Initial Release'
  • Arrange a time with the developer(s) and check-in source code into the projects created

Giving this structure:

The production folder is 'read only' for all but the CCM.

First Change Control

All application project changes in the /production project folder, follow a change control window path, as such, in the development project folder the CCM will:

  • Create a new project in the development folder representing the change control window (if none exist)
  • Notify developers of VSS development project status

Giving us this structure:

The MYAPP developer needs to alter his single ASP and COM files for this change control window, the developer will:

  • Create a MYAPP project under the CC001 project in development
  • Expand the production source code project, navigate to MYAPP and the COM Libraries project, then with a right click and drag the project to /development/cc001/myapp and from the menu displayed, select share and branch

  • Check the recursive check box if any sub-project folders are also required.

  • Do the same for Web Sites.  Important - If there are multiple websites and you only want selected projects, then manually create the same structure in dev then share off the projects from there. 
  • If you make a mistake, delete your project and start again.

We now have this:

To review where the original source came from in the production folder:

  • Select a file
  • Right click properties
  • Select the paths tab
  • Click links if the GUI is hard to read

Check in/out code as need be in the development project. The DEV server environment is then built (refreshed) from this source in VSS.

Moving Code to TEST

The CCM will:

  • Create a CC001 project in the /test project “folder”

The developer(s) will:

  • Remove any reference to Myapp in the /test/cc001 project (if applicable)
  • Expand the cc001/myapp project, select myapp then right click and drag to the /test/cc001 project, selecting the share and branch option

  • Select recursive check box (as all code for MYAPP is going up as a single unit of testing).

This will give us:

This scenario will assume all code will transition from DEV and TEST and into PROD. The TEST server environment is then built (refreshed) from this source in VSS.

Overwriting existing code in TEST from DEV

During testing we found a range of problems with our ASP page.  We fixed the problem in /development and now want to overwrite/replace the VSS /test copy for the CC001 change control.

The developer will:

  • Check-in code in the development folder for the change control
  • Navigate to the /test/cc001/myapp/Web Sites/ project
  • Delete from this point

IMPORTANT - You can do individual files if you need to, rather than a whole project !

  • Goto the /development/cc001/myapp project folder, right click and drag the websites project

Test now has the fixes made in dev.  Use the files to build/update the test server environment.

Taking a Change Control into Production

The developers will:

  • Ensure all code in the /test/cc001 folder is OK to go live
  • Remove any files that are not ready

The CCM will:

  • Create a new project in the production project folder to represent the change control going live
  • Share and branch the myapp application (entire structure) into the new project folder in production:

  • Navigate to the /test/cc001/myapp project, get a list of files to go live
  • Navigate back to /production/cc001/myapp project and locate these files, for each file:
    • Select the file, SourceSafe,  Merge Branches
    • Pick the appropriate branch to merge to

  • Press the merge button.
  • Check conflicts if need be.

The /production project structure is:

Once all files are merged into the new production project folder, the production server environment can be built from these altered files.

The branching in VSS provides an effective solution to managing versions and the inter-relationships between components (files) and physical projects.  The above scenario for example gave us this tree like structure to work from (versions in diagram are VSS internal versioning numbers - use labels to assist with source identification if you are having trouble with it):

Total article views: 5494 | Views in the last 30 days: 3
Related Articles

Development and Production Database

Insert Into Development and Production Database at the same time


how to migrate changes to production server

how to migrate changes to production server


MOVE SSIS PACKAGES from Development to Production server...

MOVE SSIS PACKAGES from Development to Production server...


Publishing a project with different folders within

Project - Properties


Migration to Production

SQL Server is an easy to use product in many ways, much better than the other major RDBMSs out there...