Scenarios

This section will cover various sitiations and how to handle them with HCM. Each scenario is assuming the repository structure shown below:

• The repository represent a product line
• The components directory is at the base of the repository
  • This is where components between products will be shared
• There are two projects under the trunk directory
• Under each project is a components directory
  • This is where components will be developed

Scenario 1: Share component between projects in same repo

Setup

In this scenario there are two projects: Project A (PA) and Project B (PB). PA has been in development for several months and has a stable code base. The code has been through several Quality Control Tools (QCTs), verification and has been tested on hardware.

PB has started up and wants to re-use the rook component PA has developed.

Goals

1. Show how a single component can be transferred between PA and PB
2. Show how updates from PB can be fed back to PA
3. Show how this can be accomplished without merging

Workflow

The following diagram shows the steps in this scenario:

1. Project A publishes the rook component version 1.0.0 to the component directory.
2. Project B installs version 1.0.0 of the rook component to it’s project working copy.
3. Project B finds a bug and commits local changes until the bug is fixed.
4. Project B publishes version 1.1.0 of the updated rook component to the component directory.
5. Project A sees there is an update and decides to install version 1.1.0 of the rook component.

These are the commands

Task	Project A	Project B
PA Publishes rook	hcm publish rook 1.0.0 –url $REPO_URL/components -f release_notes.txt
PB installs rook		hcm install rook svn ci rook -m “Installing rook version 1.0.0”
PB fixes bug		vim rook/rtl/rook.vhd svn ci rook -m “Fixed bug.”
PB publishes rook		hcm publish rook 1.1.0 -f release_notes.txt
PA looks for updates	hcm list hcm show rook –upgrades
PA installs rook	hcm install rook svn ci rook -m “Installing rook version 1.1.0”

Scenario 2: Project needs to make an update but does not want to use a newer version

Setup

In this scenario Project A (PA) is getting ready to release code to production. PA is at version 1.0.0 of the rook component. PA has to make some minor changes to the rook component. PA checks for any updates to the rook component and finds a version 1.1.0. Due to the phase of the program, PA does not want to bring in the changes for version 1.1.0.

Goals

1. Show how Project A can still make local changes
2. Show how Project A can publish without affecting 1.1.0

Workflow

The following diagram shows the steps in this scenario:

1. Project A checks for updates to the rook component
2. Project A makes and commits changes locally
3. Project A publishes version 1.0.1 of the updated rook component to the component directory.

These are the commands

Task	Project A
PA looks for updates	hcm list hcm show rook –upgrades
PA makes changes	vim rook/rtl/rook.vhd svn ci rook -m “Added header.”
PA Publishes rook	hcm publish rook 1.0.1 -f release_notes.txt

Scenario 3: Project needs to make an update but sees an upgraded version

Setup

In this scenario Project A (PA) wants to make a change to a component. PA is at version 1.0.0 of the rook component. PA has to make some changes to the rook component. PA checks for any updates to the rook component and finds a version 1.0.1. PA wants to include changes from 1.0.1.

Goals

1. Show how Project A can make changes to an upgraded version of a component
2. Show how Project A can make changes available to other projects

Workflow

The following diagram shows the steps in this scenario:

1. Project A checks for updates to the rook component
2. Project A installs version 1.0.1
3. Project A makes and commits changes locally
4. Project A publishes version 1.1.0 of the updated rook component to the component directory.
5. Project A installs published version

These are the commands

Task	Project A
PA looks for updates	hcm list hcm show rook –upgrades
PA installs rook	hcm install rook svn ci rook -m “Installing rook version 1.0.1”
PA makes changes	vim rook/rtl/rook.vhd svn ci rook -m “Fixing bug with movement.”
PA Publishes rook	hcm publish rook 1.1.0 -f release_notes.txt

Scenario 4: Bringing in a component from a long lived branch

Setup

In this scenario Project A (PA) has a component it has modified on it’s own branch.

• The component is not under HCM control.
• There is a similar component that is under HCM control.
• The published version of the component is 1.1.0
• PA wants to merge their changes with what is published.

Goals

1. Show how Project A can merge their changes with the published version.
2. Show how Project A can make changes available to other projects
3. Show how Project A can start to use HCM to control the component

Workflow

The following diagram shows the steps in this scenario:

1. Project A checks the repository for the component
2. Project A copies the existing component directory to a backup
3. Project A installs the latest version of the component
4. Project A compares the contents of the backup and installed version
5. Project A merges the changes from the backup to the installed version manually
6. Project A commits changes locally
7. Project A publishes version 1.2.0 of the updated component to the component directory.

These are the commands

Task	Project A
PA checks repository	Use a repo browser or a web browser to check what version of the component is installed.
PA makes backup component	cp -r rook rook_backup
PA installs component	hcm install rook svn ci rook -m “Installing version 1.1.0 of rook”
PA compares backup to installed component	Using a tool specifically made for comparing directories will help.
PA merges backup and installed component	Move, add, modify, and/or delete files as necessary to change the installed version to the version you want to publish.
PA commits merged component	svn ci rook -m “Merged rook with version 1.1.0 of “rook”
PA publishes merged component	hcm publish rook 1.2.0 -f release_notes.txt