Module 3: Working with Jazz Source Control

Accelerating Product and Service Innovation
Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 9.0
Developing Software with IBM Rational Team
Concert
Module 3: Working with Jazz Source Control
© Copyright IBM Corporation 2008, 2014

Unit objectives
After completing this unit, you should be able to:
• Explain how source control is implemented
• Define these concepts:
 Repositories and workspaces
 Streams and components
 Change sets, change flow, and conflict resolution
• Create, use, and manage these items:
 Local sandboxes and repository workspaces
 Change sets
 Snapshots and baselines
• Use the Pending Changes view to share work with your
team

Overview of Jazz Source control
> Overview of Jazz source control
Working with change sets
Sharing changes with your team
Finding and resolving conflicts
Preserving and restoring component and
workspace configurations
Getting out of trouble
> = Current topic

Jazz source control
Jazz™ Team Server
 Uses a relational database in a central location for all artifacts that are based on Jazz
technology:
– Stores source code, documents, binary files, images, and more
– Stores all IBM® Rational Team Concert™ artifacts
– Supports geographically distributed teams
 Provides strong support for parallel development
 Supports process-centric automation, both agile and traditional processes
 Provides the infrastructure to link work items, plans, source-control artifacts, and builds
The Jazz source-control repository
 Is entirely change-set based
– Requires that all changes to artifacts are related to a change set
– Ensures that atomic changes to sets of files are together
 Provides secure mechanisms for creating, retrieving, updating, and deleting artifacts
 Maintains a complete audit trail of all changes, including these events:
– A record of past states of the item and past field values
– The user who saved the item
– The time of the change

Project area hierarchy

Components
 A component is the fundamental
organizational unit for artifacts
that are under source control.
 Components are collections of
related artifacts.
 For example, a component can be
Eclipse plug-in or a group of
documents.
 Any group of files and folders that
share a common root can be a
component.
 A baseline represents the
“version” of a component.

Streams
 A stream is a collection of one or more
components.
 Streams are typically used as follows:
 To provide a team integration area
– Controlled sharing of changes sets
between teams and team members
 To re-create important configurations
– Team integration builds
– Previous releases
– Stable versions of third-party or open
source software packages
 To provide a mechanism for a phased
promotion model
– Development stream or streams
– Integration stream
– Production stream

Repository workspaces
 A repository workspace is a
server-side storage area that a
developer uses for current
work.
 Flow target
– Specifies the initial
configuration of components
– Identifies the location where
change sets are shared
 Sandbox
– Provides access to files and
folders for desktop integrated
development environments
(IDEs), such as Eclipse and
Microsoft® Visual Studio®, and
other development tools
Repository
workspace
Flow
target
(Stream)
Sandbox
Jazz
server
Local
host

Change sets
A change set is a repository object that collects a related group of changes in
a component.
 The system tracks the changes that you make in the context of your current work
as a change set.
 Change sets are applied to a flow target in a single atomic operation.
The blue triangle icon ( ) indicates a change set.

Pending changes
 In the Pending Changes view,
manage the flow of change sets into
and out of your repository
workspace.
 Unresolved
Files in this section were
modified in the local sandbox, but
have not been checked in to the
repository workspace.
 Outgoing
Checked-in files are organized into
change sets.
Outgoing change sets have not been
delivered from the repository
workspace to the flow target.
 Incoming
Incoming change sets represent
changes that were applied to the
flow target, but that have not been
accepted into this repository
workspace.

Using workspaces in a team environment
Load
 Copies a specified configuration of
files from the stream to your
repository workspace and local
sandbox
Check-In
 Copies changed files from the local
sandbox to the repository workspace
Deliver
 Copies the change set or sets from
the repository workspace to the flow
target
Accept
 Copies a change set or sets in the
flow target into the repository
workspace and the local sandbox
•If the same file is modified in multiple
change sets, the Deliver and Accept
operations will identify potential
conflicts.
Load Check-in
Deliver
Accept
Accept
Load

Challenge
 Minimize the impact of emergency releases on new
development efforts
 Allow developers or teams to investigate solutions or new
feature work in isolation
 Allow large teams to stage the integration effort
 Allow teams to apply fixes to multiple code releases
How would you use streams and repository
workspaces to support these common
source-control management scenarios?

Working with change sets
 Overview of Jazz source control
> Working with change sets
 Sharing changes with your team
 Finding and resolving conflicts
 Preserving and restoring component and
 Getting out of trouble
> = Current topic

Creating and managing change sets
 Best practices:
 Set your current work item.
 Work on one task at a time.
 If you must multitask, follow these
guidelines:
 Use multiple repository workspaces.
 Suspend work on a change set to
postpone that work temporarily. You
can resume the work later.
 Worst case scenario:
 Before you deliver, adjust change set
contents in your repository
workspace.
Suspend
work

Sharing changes with your team
 Overview of Jazz Source Control
 Working with change sets
> Sharing changes with your team
> = Current topic

Sharing work between workspaces
Multiple developers who collaborate on a task must be
able to share their work:
1. Use the normal
deliver-accept model to
propagate a change set from
one workspace to the other
through a parent stream or
repository workspace.
2. Change your flow target
to point to the other workspace
and accept changes directly
from that workspace.
3. Create a patch file, which
other users can apply to their
workspaces.
(2) Accept
(3) Create
patch
(3) Apply
patch
(1) Deliver (1) Accept

Questions
In what situations would you suggest
delivering to an alternative target?
In what situations would you suggest using a
patch and sharing it with another user?
When would you insist on delivering to the
team stream, and then let the changes
propagate to the rest of the team with the
normal deliver-accept flow of events?

Finding and resolving conflicts
> Finding and resolving conflicts
> = Current topic

Finding conflicts
Conflicts are detected at the file
level, so any changes to the same
file by two different change sets
can potentially result in a conflict.
 Conflicts can be detected during
either the delivery or the accept
process
 Rational Team Concert will offer to
“auto-resolve” conflicts without user
intervention.
 If the changes cannot be resolved
automatically, Rational Team Concert
will prompt you to perform a manual
merge. This might happen if the same
line of code was modified in both
workspaces.
Conflict detected
during Accept
Load
Check-in
Deliver Accept
Accept

Resolving conflicts
Use the Compare editor to manually resolve conflicts.
The conflict is indicated in the
Change Explorer view.
Your editable
version of the file.
The other contributing
version of the file.
Conflict location indicators.

Avoiding conflicts
File locking
 You can lock a file on a "per-stream" basis.
 When you lock a file, only you can deliver changes to that file
in that stream.
 A file can be unlocked by the user who owns the lock or by a
member of the JazzAdmins group

Preserving and restoring component and workspace configurations
> Preserving and restoring component and
> = Current topic

Baselines
 A baseline is a version of a component.
 Component configurations can be saved at any time by
creating a baseline.
 Baselines are created in a repository workspace and are
delivered to a stream as a special type of change set.
 The Team Artifacts view indicates which component
baselines are in a repository workspace or stream.

Restoring configurations
Replace the
current
component
configuration in
a stream or
repository
workspace with
a different
baseline.
3. Choose which
baselines to restore. 2. Click Replace With to
change baselines.
1. To edit the stream
properties, open the stream
object under the project
folder.

Snapshots
A snapshot is a collection of baselines across all of the
components in a repository workspace or stream.
May 1
May 7
May 1
May 3
May 5
May 9
May 13
May 14May 14
SSMay 13
A stream contains
multiple components.
Each component has multiple
baselines over time.
A snapshot is a collection of
baselines at a single point in time.

Getting out of trouble
> Getting out of trouble
> = Current topic

Discarding changes
Before check-in
 To discard all of your local changes to a file, complete an
Undo action on the file in the Pending Changes view.
 To keep some of your local changes, use Eclipse local
history to search for a version of the file that will work.
Toggle the history display
between local Eclipse history
and source control version
history.

Discarding changes
After check-in
 To remove an entire change set, you can
Suspend, Discard, or Reverse the change set
from the Pending Changes view.
 To discard the changes to a file, Undo file-level
changes in the Pending Changes view. The rest of
the change set remains.

Discarding changes
After delivery
 Use the “brute force” method: Replace the
component in the stream or repository workspace
with a previous baseline.
 If you must systematically determine which change
to the stream is causing problems, use the process
on the next slide.

If the stream configuration fails to build, take these steps:
1. Accept the contents of the stream into a workspace.
2. Open the History view of the workspace.
3. Select the change sets to withdraw. Suspend each
selected change set.
4. Replace the content of the stream with the content
of your workspace.
5. One by one, Resume the suspended change sets in
the workspace. After each change set is resumed,
build it. When the build fails, you have found the
problem change set.

Module 3: Working with Jazz Source Control

More Related Content

What's hot (20)

Similar to Module 3: Working with Jazz Source Control (20)

More from IBM Rational software (20)

Recently uploaded (20)

Module 3: Working with Jazz Source Control

Editor's Notes