This article continues on from Part 1, expanding on other source

control scenarios and how our defined project structure and VSS

branching functionality accommodates it.    

I want to move files to next weeks change control

In the previous example, we only processed the single ASP file,

for some reason, the developers wanted to delay the DLL for the

next round of change controls.  Therefore we need to get the

COM file in /development/cc001 into the new project

/development/cc002 for it to be included in that change window.

The CCM will:

1. create /cc002 in /development

   folder

2. The developer will branch the

   DLL code from /production/cc001 into /development/cc002

3. Select the file(s) to be merged

   in /development/cc002.

4. Resolve the differences (we

   know what they are and are fine with all of them)

After the merge, double check

your code before moving on with development.

What does VSS look like after 2 iterations of change?

After two complete iterations of changes, we end up with this

structure in VSS:

We have a snapshot of production for all iterations:

• Initial snapshot
• change control 1
• change control 2

We can also rebuild the test server from a production build and

roll forward through change controls.  In the development

project, we have a well managed source environment for each change

and its progression through the environments.

I forgot to take a file into production for a schedule

change

The CCM needs to:

• Check files are in the

  equivalent /test project folder

• If not, the developer should

  update this project folder by branching the missing files from the

  equivalent development folder.

• As the /production/ccxxx folder

  already exists (had to for other code to go into prod), the CCM

  simply merges this missing file into the project and takes the

  files from here to the production server environment.

I have a special project that will span many weeks, now

what?

The scenario is this:

• We do weekly change

  controls

• A new special project will take

  2 standard chance control iterations to move into production

• The standard change controls

  will be altering files the special project will be using

• We need to ensure that the

  standard change controls are not affected and visa versa for the

  special project until the special project is ready to do live.

To manage this we need to ensure these rules apply:

• Strict branching from a single

  point in time from the /production project folder

• The special project files will

  merge with some future change control and go live with this change

  control window to ensure VSS consistency.

At CC003, we start a new special MYAPP project that affects the

single ASP file we have.   The CCM will:

• Create /development/CC003

  project

• Create /development/MYAPP Mini

  Project

• The developer branches in the

  files to be altered into both /development/cc003 and /myapp mini

  project 

• Now both project folders in dev

  are branched from the single tree root (for one of a better

  word).  Developers continue to work in DEV and branch to test

  as need be to facilitate standard app testing.

Merging MYAPP Mini Project back into the standard change

control.

Here we assume CC003 and CC004 changes over the last 2 weeks are

in production, we need to get MYAPP Mini Project live, this will be

done in CC005.  The VSS structure is:

• CCM creates

  /development/CC005

• CCM branches code used in MYAPP Mini Project from /production/cc004 (current production

  source)

• CCM then, working with the

  developers, merges into /development/MYAPP Mini Project with the

  /development/CC005 project files.

• Merging is a right pain in VSS,

  take care and where possible, attempt offline from the

  product.

• On completion of the merge,

  remove MYAPP Mini Project or renamed to 'CC005 - MYAPP Mini Project'

• Go through standard

  development, test, production VSS practices as outlined through

  this document.