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:
- create /cc002 in /development
- The developer will branch the
DLL code from /production/cc001 into /development/cc002
- Select the file(s) to be merged
- 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
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
The scenario is this:
- We do weekly change
- 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
- Create /development/MYAPP Mini
- The developer branches in the
files to be altered into both /development/cc003 and /myapp mini
- 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
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
- CCM branches code used in MYAPP Mini Project from /production/cc004 (current production
- 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
- 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