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.

Appreciations/Terminology

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. 

• REVISE WHAT YOU HAVE DONE - ONLY SHARE/BRANCH THE FILES REQUIRED FOR THE CHANGE CONTROL. IF YOU

  FORGET FILES OR REQUIRE OTHERS, THEN REPEAT THIS PROCESS FROM THE

  SAME PRODUCTION SOURCE PROJECT.  ALWAYS KEEP THE SAME

  PROJECT FOLDER STRUCTURE AS IN THE PRODUCTION PROJECT

• 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):