Integrity

M KS Source
2007
User Guide

MKS Source 2007

User Guide
Copyright 20012007 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved.
MKS makes no warranty of any kind with regard to this material, including, but not limited to the implied warranties of merchant ability,
performance, or fitness for a particular purpose. MKS shall not be liable for errors contained herein, or for any direct, indirect, incidental,
or consequential damages resulting from the use of this material.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in
any form by any means, without written permission from MKS.
MKS, MKS Source Integrity, MKS Integrity Manager, Implementer, MKS Toolkit, Sandbox, NuTCRACKER, MKS Integrity Solution,
AlertCentre, MKS Integrity Suite, and MKS Federated Server are trademarks or registered trademarks of MKS Inc. All other trademarks
or registered trademarks are the property of their respective holders.

Co r p o r at e He ad q u ar t ers

W o r ld w id e O f fi ce s:

410 Albert Street

Waterloo, ON N2L 3V3
Canada

1815 South Meyers Rd.

Suite 220
Oakbrook Terrace, IL USA
60181
tel: 630 827 4900
fax: 630 629 9167
sales (toll free): 800 633 1235

tel: 519 884 2251

fax: 519 884 8861
sales (toll free): 800 265 2797
www.mks.com

12701 Fair Lakes Circle

Suite 350
Fairfax, VA USA
22033
tel: 1 703 803 3343
fax: 1 703 803 3344
sales (toll free): 1 800 637 8034
Martinstrae 42-44
73728 Esslingen
Germany
tel: +49 711 351775 0
fax: +49 711 351775 7555

This document is uncontrolled when printed or copied.

Third Floor, Dukes Court

Duke Street, Woking
Surrey
GU21 5BH
United Kingdom
tel: +44 (0)1483 733900
fax: +44 (0)1483 733901
sales: +44 (0)1483 733919
3 Killiney Road
#07-05 Winsland House 1
Singapore 239519
tel: +65-6732-8768
fax: +65-6732-0768
Ebisu Garden Place Tower 18F
Ebisu 4-20-3
Shibuya-ku, Tokyo, Japan
150-6018
tel: 03-5789-5862
fax: 03-5789-5757

Table of Contents
Chapters

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Where To Go From Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Basic Project Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Creating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Importing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Dropping a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Adding a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Opening a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Working With Subprojects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Creating a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Adding a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Adding a Shared Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuring a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Moving a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Dropping a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Project Histories and Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Checkpointing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Project History View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Restoring a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Adding Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Deleting Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Viewing Project Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Project Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Branching Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Release Based Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Project Based Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Creating a Development Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Removing a Development Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Locating Where an MKS Source Object Is Used . . . . . . . . . . . . . . . . . 30
Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Changes Grouped by Author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Changes Grouped by Author (Summary) . . . . . . . . . . . . . . . . . . 33
Revisions Newer Than Member Revision . . . . . . . . . . . . . . . . . . 33
Changes From Member Revision to Label . . . . . . . . . . . . . . . . . . 34

Table of Contents

Changes From Member Revision to Revision . . . . . . . . . . . . . . .

List Locked Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List Revisions Associated With Labels . . . . . . . . . . . . . . . . . . . . .
List Revisions Associated With States . . . . . . . . . . . . . . . . . . . . .
Project Member History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Promoting and Demoting Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sandboxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Types of Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Variant Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Build Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Importing a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sharing Sandboxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Sandbox as Shared . . . . . . . . . . . . . . . . . . . . . . . . .
Importing a Shared Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removing Sharing From a Sandbox . . . . . . . . . . . . . . . . . . . . . . .
Dropping a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opening a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Retargeting a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taking Sandbox Snapshots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Sandbox Snapshots in a Development Environment . . .
Using Sandbox Snapshots in a Build Environment . . . . . . . . . .

38
38
38
40
40
41
42
43
43
43
44
45
45
47
47

Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Managing Project Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifying Members to Add to Projects . . . . . . . . . . . . . . . . . . .
Adding Members to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Members From Archive to a Project. . . . . . . . . . . . . . . .
Importing Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dropping Members From a Project. . . . . . . . . . . . . . . . . . . . . . . .
Member Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking Out a Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing and Editing Member Content . . . . . . . . . . . . . . . . . . . .
Checking In a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Renaming a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discarding Changes to a Member . . . . . . . . . . . . . . . . . . . . . . . . .
Resyncing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Locking a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removing or Downgrading Locks . . . . . . . . . . . . . . . . . . . . . . . .
Making the Working File Writable . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Member Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

34
34
35
35
35
35

50
50
51
53
55
57
60
62
62
63
65
66
69
70
71
72
73
73
74
75

Table of Contents

Adding Labels to Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Deleting Member Labels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Freezing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Thawing Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Deferring Member Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Submitting Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Canceling Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Resyncing Members With Deferred Operations . . . . . . . . . . . . . 84
Working with Member Histories and Revisions. . . . . . . . . . . . . . . . . 85
Viewing a Member History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Updating a Member Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Setting a Member Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Deleting a Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Viewing an Annotated Revision . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Working With Pending Revisions . . . . . . . . . . . . . . . . . . . . . . . . . 94
Comparing Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Branching and Merging Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Branching and Merging Members Overview . . . . . . . . . . . . . . . 98
Merging Modified Working Files . . . . . . . . . . . . . . . . . . . . . . . . 100
Merging Two Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Working With MKS Visual Difference . . . . . . . . . . . . . . . . . . . . 102
Working With MKS Visual Merge . . . . . . . . . . . . . . . . . . . . . . . 105
Resolving Merges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Locating Where a Member Is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Generating Member Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Promoting and Demoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Promoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Demoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Change Package Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrating With MKS Integrity. . . . . . . . . . . . . . . . . . . . . . . . . .
Why Use Change Packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Change Packages to Control Development . . . . . . . . . .
Creating a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working With Change Package Entries . . . . . . . . . . . . . . . . . . . . . . .
Specifying a Change Package for an Operation . . . . . . . . . . . .
Change Package Entry Types. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving CP Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discarding CP Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing CP Entry Member Differences . . . . . . . . . . . . . . . . . .
Working With Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Finding Change Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Change Package Details and Entries. . . . . . . . . . . . . .
Editing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

114
115
116
116
117
117
118
118
119
120
121
122
122
124
125

iii

Table of Contents

Submitting Change Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discarding Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reopening a CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Package Reviews Overview. . . . . . . . . . . . . . . . . . . . . . . . . .
How CP Review Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP Review Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP Review Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP Entry Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pending Operations in CPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reviewing Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accepting a CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rejecting a CP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apply CP and Resync CP Overview. . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Apply CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Apply CP in Your Development Environment . . . . . . .
Working With Subprojects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applying a Change Package With No Dependencies . . . . . . .
Using the Apply CP Backfill List. . . . . . . . . . . . . . . . . . . . . . . . .
Using a Propagation Change Package with Apply CP . . . . . .
Resolving Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apply CP Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Resync CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Resync CP in Your Development Environment . . . . . .
Using the Resync CP Backfill List . . . . . . . . . . . . . . . . . . . . . . . .
Applying Changes From a Variant . . . . . . . . . . . . . . . . . . . . . . .
Applying Change Packages From Two Variants . . . . . . . . . . .
Using a Propagation Change Package with Resync CP. . . . . .
Resolving Binary Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resync CP Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Resync By CP Command . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix

125
126
127
128
128
129
130
130
133
134
134
135
136
136
138
138
139
141
142
145
146
146
151
151
152
155
157
157
160
160
164

MKS Source Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Product Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

iv

CHAPTER ONE

Introduction

Understanding and Using This Guide

MKS Source provides comprehensive, cross-platform software configuration management
(SCM). It is the ideal SCM solution for large, distributed development organizations with
complex development environments.
There are two main roles when using MKS Source: the administrator and the user.
The administrator installs MKS Source; defines and customizes projects and policies; and
creates and manages user accounts, allowing users to access the program.
A user is anyone who needs to work with MKS Source projects.
This chapter contains the following:

About This Guide on page 2

Assumptions on page 3

Where To Go From Here on page 3

Chapter 1: Introduction

About This Guide

For content that is essential and applicable to all guides, MKS provides a single location for
you to access the information. See the MKS Integrity Client 2007 Getting Started Guide for
information on the following topics:

a complete list of related documentation

descriptions of the typographical conventions used in this guide

getting help from MKS Customer Care

consulting MKS Professional Services

how to provide feedback on this documentation

detailed descriptions for base concepts used in MKS Integrity and MKS Source

installing and configuring the MKS Integrity Client

an overview of the interfaces available for the MKS Integrity Client

Most procedures in this guide are documented using menu-based commands; however,
toolbar buttons, shortcut menus, and shortcut keys exist for most procedures. For more
information, refer to descriptive tooltips and menu items in the interface.
For detailed information on wizards, views, and dialog box options, see the online help.
This chapter introduces you to the MKS Source 2007 User Guide and its contents. The
following is a list of the guides other chapters, with a brief description of the topics covered
by each chapter:

Chapter 2: Projects on page 5

Describes how to create and work with MKS Source projects and subprojects. This
chapter also includes information on checkpointing projects, working with project
histories, and branching projects.

Chapter 3: Sandboxes on page 37

Describes how to create and work with Sandboxes, including sharing Sandboxes and
retargeting Sandboxes to a different project configuration.

Chapter 4: Members on page 49

Describes how to manage members in projects, and work with members and member
histories. This chapter also includes information on working with pending member
revisions, comparing differences between member revisions, and branching and
merging member revisions.

Assumptions

Chapter 5: Change Packages on page 113

Describes how to use change packages to track and review changes, including the Apply
CP and Resync CP commands used to move specific changes between different project
configurations.

MKS Source Terms on page 167

Provides a glossary of common terms and definitions for MKS Source.

Assumptions
Before using MKS Source, MKS assumes the following about your knowledge and
experience:

You fully understand the hardware platforms and operating systems you are installing
MKS Source on, that is, Windows, Solaris, Linux, IBM AIX, and HP-UX.

You fully understand your chosen Integrated Development Environment (IDE), for
example, Sybase PowerBuilder (if you are using the integrations with MKS Source).

Where To Go From Here

To Do This

See

Learn basic MKS Source concepts

MKS Integrity Client 2007 Getting Started Guide

Install the MKS Integrity Client.

MKS Integrity Client 2007 Getting Started Guide

Log in to MKS Source.

MKS Integrity Client 2007 Getting Started Guide

Set MKS Source preferences.

MKS Integrity Client 2007 Getting Started Guide

Create a project.

Creating a Project on page 6

Create a sandbox.

Creating a Sandbox on page 40

Add members to an MKS Source

project.

Adding Members to a Project on page 51

Check out a member.

Checking Out a Member on page 63

Check in a member.

Checking In a Member on page 66

Create a change package.

Creating a Change Package on page 117

View a project history.

Project History View on page 19

View a member history.

Viewing a Member History on page 85

Learn MKS Source terms.

MKS Source Terms on page 167

Chapter 1: Introduction

C H A P T E R TW O

Projects

Managing Projects
An MKS Source project is any group of files under version control that, taken together,
forms a single body of work.
For example, in a development environment, a project might include source code files
required to build a program element.
MKS Source allows you to create large projects composed of smaller component projects
known as subprojects. Subprojects behave in the same way as projects. Once you create a
subproject, it is considered a member of the project.
This chapter describes the following MKS Source project related operations:

Basic Project Operations on page 6

Working With Subprojects on page 10

Project Histories and Checkpoints on page 17

Project Metrics on page 26

Branching Projects on page 27

Locating Where an MKS Source Object Is Used on page 30

Generating Reports on page 32

Promoting and Demoting Projects on page 35

Chapter 2: Projects

Basic Project Operations

When you are ready to place a group of development files under version control using
MKS Source, the first step is to create a project on the MKS Integrity Server. Projects can also
be imported from older versions of MKS Source, or added back after being dropped.
This section provides the procedures for:

Creating a Project on page 6

Importing a Project on page 7

Dropping a Project on page 8

Adding a Project on page 8

Opening a Project on page 9

Creating a Project
When creating a project, you only create the project container. To add files, or members, to the
project, you must create a Sandbox on your client machine that points to the project and then
add the project members through that Sandbox. For more information on creating
Sandboxes, see Creating a Sandbox on page 40. For more information on adding project
members, see Adding Members to a Project on page 51.
To create a project, select Project > Create.
Keep the following points in mind when creating a project:

When you specify the name of the new project, MKS Source automatically assigns the
.pj file extension. If you specify a .pj file extension in uppercase or mixed case,
MKS Source replaces that file extension with the correct lowercase .pj file extension. If
you specify a file extension other than .pj, MKS Source appends the .pj file extension
to the file name. For backwards compatibility, you can import projects and subprojects
that do not have the .pj file extension.

A single project name can be used only once in the same location.

For case-insensitive repositories, MKS Source does not distinguish between project
names differing only in case. For example, if project.pj already exists in C:/
Aurora_Program, you cannot create PROJECT.pj in C:/Aurora_Program. This results
in an error and MKS Source asks you to specify a different path and file name, or a
different project name.

For suggested best practices on creating projects, see the MKS Integrity Server 2007
Administration Guide.

Basic Project Operations

Importing a Project
You import projects if you need to do the following:

restore projects that were dropped in earlier versions of MKS Source (Source Integrity)

migrate projects from Source Integrity Standard (an earlier version of MKS Source)

Importing a project registers it with the MKS Integrity Server. Once a project is imported,
MKS Source commands can be performed upon it.
To import a project, click Project > Import.
NOTE The Import Project command is not supported for database repositories. For
information on how to import projects for database repositories, see the Database
Repository Migrator document.

When importing projects, the import process automatically creates histories for any nonarchived members and checkpoints any non-archived projects. Before you import a project,
the project files must already reside in the server repository.
CAUTION MKS Source does not support encrypted archives. If your existing project
has encrypted archives, you must first decrypt the archives before importing and
registering the project with the MKS Integrity Server.

Importing From Earlier Versions

If you are importing a project from an earlier version of MKS Source, once a project has been
imported you may not perform commands on it using an older version of MKS Source. If for
some reason you need to use an earlier version of MKS Source on a project, first drop the
project using the Drop Project command. The project must be re-imported before it can be
used again with this version of MKS Source.
If you are importing an existing Source Integrity Standard project that includes out-of-tree
members or subprojects, MKS Source automatically detects these and imports them into the
newly registered project. A project member or subproject is considered out of tree when it
does not reside in the project directory.
If you are importing a dropped project to its former repository location, the project must first
be reclaimed by your administrator. For more information on reclaiming a project, see the
MKS Integrity Server 2007 Administration Guide.

Key Considerations

If your connection to the MKS Integrity Server is disconnected while you are browsing for
a file, the file browser does not show any files or directories.

You cannot import a project that is already registered.

Chapter 2: Projects

For case insensitive repositories, MKS Source does not distinguish between project
names that differ only in case. For example, if project.pj is already registered in C:/
Aurora_Program, you cannot import PROJECT.pj into C:/Aurora_Program. This
results in an error and MKS Source does not import the project.

The processing of this command may take some time, since it traverses all subprojects in
the imported project and may perform various operations on them, such as
checkpointing.

The administrator may restrict the path names of projects being imported on the server.
This is done through the si.serverRoot property in the si.properties file on the
MKS Integrity Server. If this is set, then any project location given must be under that
directory. For details, see the MKS Integrity Server 2007 Installation Guide.

Dropping a Project
When a project has outlived its usefulness or just does not belong on the MKS Integrity
Server anymore, you can remove it.
To drop a project means that the projectis no longer registered with the MKS Integrity Server.
Dropped projects can still be accessed as read only from the Change Package and Locks
views until the project is purged or reclaimed by your administrator.
To drop a project, select a project in the Projects view, and click Project > Drop.
CAUTION If a project is dropped and any Sandboxes or variants are associated with
it, those Sandboxes or variants no longer function.

Dropping a project unregisters it from the MKS Integrity Server, but it does not delete the
project. Dropped projects can be added back into MKS Source.

Adding a Project
You can add the following:

a dropped project that still resides on the server (in the repository)

an existing subproject as a top-level project

To add a project, click Project > Add.

If you need to restore a project from a backup or a dropped project from an older version of
MKS Source, use the Import Project command. For more information, see Importing a
Project on page 7.

Basic Project Operations

Opening a Project
Opening a project in the GUI allows you to view the project and perform certain commands
with its members.
Operation

Procedure

To open a project in the GUI

Select Project > Open Project.

To open a project in the Web interface

Select File > Open Project

or
Select File > Open Variant Project
or
Select File > Open Build Project

To open a recently used project

Select Project > Recent, then select a project

from the list.

Specifying the Project to Open

You can type in or select the project to open. For detailed information about entering project
paths, see the MKS Integrity Client 2007 Getting Started Guide. For detailed information about
selecting projects, see the MKS Integrity Client 2007 Getting Started Guide.
If you are opening a variant or build subproject, initially only enter the path and name of the
root project. You specify the subproject later in the procedure. When specifying the
subproject, there are rules that control what project configuration you can jump to. For more
information, see the MKS Integrity Client 2007 Getting Started Guide. If your selection breaks
any of the rules, you cannot open the project.

Selecting a Project Type

When opening a project you can open the following types:

Normal opens the working project based on the mainline.

Variant opens a project based on a specific development path.

NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

Build opens a static project based on a specific checkpoint of the master project that is
used for building or testing the project, but not for further development. You can specify
the checkpoint through its checkpoint number or label.

Chapter 2: Projects

Alternate Methods of Opening a Project

In the Web interface, if you know the location of a project, you can open it by typing the
following URL in a browser:
http://<server>:<port>/si/viewproject?projectName=<(sub)projectname>

for example
http://xyzBusiness:7001/si/viewproject?projectName=
c:/master_projects/SourceCode/project.pj.

In the Web interface, you can also open a variant project from a Project view by selecting
Project > Open Variant Project.

In the GUI, you can open a project from the Projects view by selecting the project and
clicking Project > View Project. You can open a build project from the Project History
view by selecting a checkpoint and clicking Project > View Project.
NOTE In the Web interface, you can use the active links in the title bar to navigate
within a project. To navigate to a subproject, click the applicable portion of the link.

Working With Subprojects

This section discusses the procedures for:

Creating a Subproject on page 10

Adding a Subproject on page 11

Adding a Shared Subproject on page 12

Configuring a Subproject on page 13

Moving a Subproject on page 15

Dropping a Subproject on page 17

Creating a Subproject
You create a new subproject, then add members and configure the subproject as necessary.
For example, if you had a financial toolkit application that you wanted to add a new
calculator application to, you would create a new subproject in the toolkit project to contain
the calculator application source code.
To create a subproject in the GUI, select the project or Sandbox to create a subproject in, and
select Project > Subproject > Create.

10

Working With Subprojects

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on page 117.
For detailed information on the Create Subproject options, see the online help.

Adding a Subproject
When a subproject is dropped from a project, the subprojects historical information remains.
You can add the subproject back.
To add a dropped subproject to a project in the GUI, select Project > Subproject > Add.

Selecting a Subproject Type

When adding a subproject you can specify one of the following types:

Normal adds a working subproject based on the mainline

Variant adds a subproject based on a specific development path.

NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

Build adds a static subroject based on a specific checkpoint of the master project that is
used for building or testing the project, but not for further development. You can specify
the checkpoint through its checkpoint number or label.

Default adds a subproject as the same type as the parent project.

NOTE If you do not select a subproject type, the subproject is added as the same type
as the parent project.

Specifying the Subproject to Add

You can type in or select the subproject to add. For detailed information about entering
project paths, see the MKS Integrity Client 2007 Getting Started Guide. For detailed information
about selecting projects, see the MKS Integrity Client 2007 Getting Started Guide.

Using Change Packages

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on page 117.

11

Chapter 2: Projects

Adding a Shared Subproject

A shared subproject is a subproject that is a member of more than one project. MKS Source
allows you to share a subproject between two or more projects by referencing the original
subproject. A shared subproject allows you to access common members across many projects.
Shared subprojects are not required to be located within the same directory structure or
project hierarchy.
To add a shared subproject, select the project or Sandbox you want to add the shared
subproject to, and select Project > Subproject > Add Shared.

Example
Ryan maintains the North American and German Web sites for ABC Financial. Both Web
sites are under version control and use the same images, but they contain different content.
To avoid duplication and ensure both Web sites contain the same images, Ryan adds the
images to a subproject and shares it between the two projects.

Shared Project Behavior

A shared subproject functions the same as an unshared subproject and is accessible by the
same commands. The shared subproject continues to reside within its original master project,
but is referenced by the other project and shown as a shared subproject.
When working with shared subprojects, MKS Source uses the actual name of the subproject
in the repository rather than its relative name in the project hierarchy for the purposes of
resolving ACLs, policy statements, event triggers, and change package entries. This enhances
the portability of change packages across different projects.
You cannot import members into a shared subproject from its shared location.

Shared Projects From Source Integrity Standard

Shared subprojects (out-of-tree subprojects) that were created in Source Integrity Standard
(an earlier version of MKS Source) are detected as they are accessed by MKS Source without
disrupting the operation. The format of these subprojects is retained until you change or
update it to the new format by reconfiguring it.

Selecting a Subproject Type

When adding a subproject you can specify one of the following types:

Normal adds a subproject based on the working subproject on the mainline

Variant adds a subproject based on a specific development path of the master project.
NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

12

Working With Subprojects

Build adds a static subroject based on a specific checkpoint of the master project that is
used for building or testing the project, but not for further development. You can specify
the checkpoint through its checkpoint number or label.

Default adds a subproject as the same type as the parent project.

NOTE If you do not select a subproject type, the subproject is added as the same type
as the parent project.

Specifying the Shared Subproject

You can type in or select the subproject for sharing. For detailed information about entering
project paths, see the MKS Integrity Client 2007 Getting Started Guide. For detailed information
about selecting projects, see the MKS Integrity Client 2007 Getting Started Guide.

Specifying a Destination Directory

When you type the subdirectory for the shared subproject, the subproject name must reside
in the project directory.

Using Change Packages

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on page 117.

Configuring a Subproject
Once you create or add a subproject, you can modify the type to suit your needs. For
example, you can change a normal subproject to a build subproject to suspend development,
or you can change a variant subproject to a normal subproject to continue development on
the main trunk.
Interface

Procedure

GUI

Select Project > Subproject > Configure.

Web

Select Project > Configure Subproject.

Example
Jen wants the ABC Tools development team to work with revision 1.2 of amortization/
project.pj, the last known stable version of the code. Jen does not want the general
development team to do any further development on this release, so she configures the
amortization/project.pj subproject to be a build subproject.

13

Chapter 2: Projects

Changes Between Configurations

Any changes you make when configuring a subproject affects the project as a whole and any
shared subprojects within it. Deltas reflecting these changes appear in the Project or Sandbox
view. Some differences you may see include:

Members existing in the original version and configured version of the subproject
display a delta if the working revision in the Sandbox is different from the new member
revision.

Members that did not exist in the original version of the subproject, but do exist in the
configured subproject, display a delta to indicate that the Sandbox does not have a
working file for the new member.

Members that existed in the original version of the subproject, but do not exist in the
configured subproject, display as former members.

Subprojects that existed as members in the original version of the subproject, but do not
exist in the configured subproject, display as former subprojects.

To resolve the differences, resynchronize the subSandbox.

Configuring Shared Subprojects

When configuring shared subprojects, remember that each shared subproject is configured
independently. This means that when you configure a shared subproject, the reconfiguration
does not change all instances of that subproject. For example, if the subproject tools/
project.pj is shared in the two projects, Aurora/project.pj and Libra/project.pj, a
change to the configuration of Aurora/tools/project.pj does not affect the configuration
of Libra/tools/project.pj.

Source Integrity Standard Subprojects

Configured subprojects or frozen subprojects created in Source Integrity Standard (an earlier
version of MKS Source) are detected as they are accessed by MKS Source without disrupting
the operation. The format of these subprojects is retained until you change or update it to the
new format by reconfiguring it.

Selecting a Subproject Configuration Type

When configuring a subproject you can specify one of the following types:

Normal configures a subproject to the working subproject on the mainline.

Variant configures a subproject to a specific development path.

NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

14

Working With Subprojects

Build configures a static subproject to a specific checkpoint of the project that is used for
building or testing the project, but not for further development. You can specify the
checkpoint through its checkpoint number or label.

Using Change Packages

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on page 117.

Moving a Subproject
To meet the needs of changing project configurations, you can move one or more subprojects
and all of its members and sub-subprojects between projects, and/or directories in a single
project, or variants of the same project on the same MKS Integrity Server.
When a subproject is moved, it behaves like a shared subproject. The subproject in the new
location continues to be backed by the underlying subproject in the old location, and the path
and name of the subproject file in the repository remains the same. Any external references
(ACL names, event triggers, policy statements) to the moved subproject continue to work
because they are based on the subprojects original name; however, a subproject that is
moved into a new project hierarchy continues to inherit ACLs from its original hierarchy and
not from the new parent project. The moved subproject also retains its configuration type
(normal, variant, build). If you are moving multiple subprojects, any common directory
prefix shared by the subprojects is automatically removed during the move.
You can move a subproject through a Project or Sandbox view using the Project > Subproject
> Move command.
You can also moved a subproject by dragging it onto a project, Sandbox, subproject, sub
Sandbox, or directory node in the active Project or Sandbox view, or onto an adjacent open
Project or Sandbox view. The drag and drop action initiates the Move Subproject Wizard,
summarizing the details of the move. For more information on the Move Subproject Wizard,
see the online help .

Example of Moving a Subproject

The size of the documentation set for the ABC Financial toolkit has increased significantly
since the last release. To reduce the size of the toolkit installer, product management wants
the documentation available from the CD browser only. Michelle moves the
documentation.pj subproject from the toolkit.pj project to the cd_browser.pj project.

Key Considerations

Moving subprojects between projects on different servers is not supported.

15

Chapter 2: Projects

The moved subproject inherits the project or directory ACLs from its original location.
You cannot apply the ACLs from the new location to the subproject.

The path and name of the subproject file in the repository is permanently reserved. If
you attempt to create a new subproject using the moved subprojects original path and
name in the repository, you are prompted to add the existing subproject. If you answer
no, the create subproject operation exits without providing you with the option of
creating a subproject with a different path and name.

Deferred subproject moves are not supported.

The AddSubproject permission is required on the target project, and the

DropSubproject permission is required on the source project. The
ConfigureSubproject permission is required for moving heterogeneous subprojects.

You can move one or more subprojects across directories within a single project.

Move subprojects do not display as shared in a Sandbox or Project view unless the
subproject was shared before the move.

When you move one or more subprojects, you cannot co-locate subprojects in the same
directory. If you want to co-locate an existing subproject with another subproject,
perform an Add Shared Subproject operation (for more information, see Adding a
Shared Subproject on page 12) on the subproject you want to move, followed by a Drop
Subproject operation (Dropping a Subproject on page 17).

If you move a subproject that is associated with any MKS Integrity items, the items no
longer display on the Associated Items tab for the project. You must open the
MKS Integrity items and associate them with the subprojects in their new locations.

Selecting a Destination Project/Sandbox

If you are selecting a destination project or sandbox instead of using the default, you can type
in or select your destination project or sandbox. For detailed information about entering
project paths, see the MKS Integrity Client 2007 Getting Started Guide. For detailed information
about selecting projects, see the MKS Integrity Client 2007 Getting Started Guide.
If you are moving the subproject to a variant or build subproject, initially only enter the path
and name of the root project. You specify the subproject later in the procedure. When
specifying the subproject, there are rules that control what project configuration you can
jump to. For more information, see the MKS Integrity Client 2007 Getting Started Guide. If your
selection breaks any of the rules, you cannot move the subproject.

Selecting a Project Type

You can move the subproject(s) to a normal project based on the working project on the
mainline or a variant project based on a specific development path (as long as there are
available development paths).

16

Project Histories and Checkpoints

Selecting a Destination Directory

When specifying a destination directory for the subproject(s), you cannot specify the
destination projects directory or the destination Sandboxs directory if this would result in a
co-located project scenario.

Dropping a Subproject
If a subproject has outlived its usefulness or just does not belong in a project anymore, you
can remove it at any time.
To drop a subproject, select one or more subprojects to remove and select Project >
Subproject > Drop.

After you remove a subproject from a project, it is no longer listed as part of the Sandbox or
master project, but the subprojects history remains in the project record, in case you need to
recreate an earlier version of the project.
IMPORTANT When you remove a subproject, you also remove all members within
that subproject.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on page 117.

Project Histories and Checkpoints

You can track the changes made to a project throughout its evolution by preserving the
project information as of a particular point in time. When you checkpoint a project in
MKS Source, it creates a revision of a project in the project history. You can view the history
of a project, restore a project to an earlier checkpoint, and compare differences between
checkpoints.
This section provides procedures for:

Checkpointing a Project on page 18

Project History View on page 19

Restoring a Project on page 22

Adding Project Labels on page 24

Deleting Project Labels on page 25

Viewing Project Differences on page 25

17

Chapter 2: Projects

Checkpointing a Project
Checkpointing a project creates a new revision of the project and adds it to the project history.
When you checkpoint a project, you save all the information needed to recreate the project
completely as it existed when you checkpointed it. The saved information includes the
project structure and the list of members with their revision numbers.
If you want to create a variant or build Sandbox, you must first checkpoint the project. For
more information on variant or build Sandbox, see Using Variant Sandboxes on page 38
and Using Build Sandboxes on page 38.
Interface

Procedure

GUI

Select a project or Sandbox and select Project > Checkpoint

Web interface

Select a project and select Project > Checkpoint Project

Example of Checkpointing a Project

Release 3.0 of the ABC Financial Toolkit is approaching and work on the amortization project
has been completed and passed to Quality Assurance. To preserve the project structure, Steve
checkpoints the amortization project.

Checkpointing With a Database Repository

If you are using a database type repository, all checkpoints are transactional. This means that a
checkpoint records the structure and contents of the project at the time the checkpoint starts.
It does not include anything added to the project or its subprojects after the checkpoint starts,
such as checkins or submitted change packages.
NOTE To ensure that only complete change packages are included in your project
checkpoints, your administrator must enable change package reviews. For more
information on change package reviews, see Change Package Reviews Overview
on page 128.

While the checkpoint is in progress, you can perform member and subproject operations on
the project, but you cannot perform any operations that affect project checkpoints,
development paths, or labels. You cannot perform the following operations:

Checkpoint the project on another development path

Restore the project to a previous checkpoint

Delete the project from the database

Add or delete project labels

Create or remove development paths

For more information on deleting projects, see the MKS Integrity Server 2007 Administration
Guide.

18

Project Histories and Checkpoints

Using Project Labels

You can use the projects revision number to keep track of your projects, but to simplify postrelease maintenance, use a label to identify significant project development milestones when
you checkpoint a project. For example, if you checkpoint a project and label it with a release
identifier (for example, Release 6.2), you can find and recreate that particular
development state more easily.

Key Considerations

Checkpointing a project affects the project only; it does not check in every member of the
project.

If you are working in a regular Sandbox, issuing a checkpoint command checkpoints the
Sandboxs master project.

Checkpointing a project checkpoints all its subprojects. If you do not want to checkpoint
subprojects, configure them as build subprojects first. For more information on
configuring subprojects, see Configuring a Subproject on page 13.

A checkpoint label is a unique text string assigned by you to identify a new project
checkpoint, for example, Beta. Labels cannot contain colons (:), square brackets ([ ]), or
leading spaces. Additionally they cannot have the same format as a valid revision
number.
NOTE If you specify a label that is the same as one used for another checkpoint in
the history and have the MoveProjectLabel permission, the label from the earlier
checkpoint is moved to the new checkpoint. For more information on permissions,
contact your administrator.

Using the Apply Label to All Members or Apply State to All Members options when
checkpointing a project slows down the checkpoint operation considerably. Do not select
these options unless there is a definite need to label or set the state of all members
individually.

Project History View

The Project History view is a window that displays the history of a project, including the
checkpoint number and description, author, date, labels, and promotion state of the project.
Interface

Procedure

GUI

Select Project > Views > View History

Web

Select Project > View Project History

19

Chapter 2: Projects

Working With the Project History View

By default, the project history view displays two panels: a panel showing the path of
development, and a panel showing details for a selected checkpoint. In order for information
to display in the details panel, you must select a checkpoint in the GUI or click a revision
number in the Revision column in the Web interface.
In the GUI, you can toggle between a graphical view and a list view by clicking View > List or
View > Graphical.

Graphical Project History view

The information in the graphical view shows the path of development from checkpoint to
checkpoint, including branches and merge lines. You can change the information that
displays for each checkpoint by selecting View > Show beside each node. If summary
information is not displayed in the view, it displays in a tooltip when you place your mouse
pointer on a specific checkpoint.

20

Project Histories and Checkpoints

List Project History view

The information in the list view is displayed in columns. If the Associated Items column is
displayed, and there are multiple MKS Integrity item associated with the checkpoint, clicking
on a cell in this column changes it to a drop down list.
The details panel in the graphical or list view displays additional details for a selected
checkpoint. You can turn the display of this panel on or off using the View > Show Details
option. The following information can display in the project history details.
Field

Description

Checkpoint

Checkpoint number of the project

Author

User who checkpointed the project

Date

Date the checkpoint was was created

Labels

Label for checkpoint.

State

State of the project

Checkpoint Description

Description for checkpoint

Development Path

Development path of checkpoint

Development Path(s) Branched From Here

Any development paths that branch directly from

the checkpoint.

If you have configured the Project History view to be dynamic, it is automatically updated to
reflect changes in the Projects view and the Project view. For more information on
configuring dynamic views, see the MKS Integrity Client 2007 Getting Started Guide . If you are
using MKS Deploy, this view is also automatically updated to reflect changes in the Staging
System view, Stage view, and the Staging Systems view. For more information on MKS
Deploy, see the MKS Deploy 2007 Administration Guide.

21

Chapter 2: Projects

Filtering a Project History in the GUI

You can use the project history filter in the GUI to display any checkpoints of the current
project that meet specified selection criteria. You can change the filter by selecting View >
Change Filter. This allows you to display a specific group of checkpoints for a project that
might have hundreds or thousands of checkpoints. Checkpoints selected with this command
can be manipulated as a group by other MKS Source commands. You can apply filters to a
project history in either the graphical history view or the list view.
Even with filtering, the number of checkpoints displayed can be too large to work with. By
default, a maximum of 200 checkpoints display. You can change the maximum by selecting
View > Maximum trunk revisions. The number of checkpoints displayed is calculated based on
the number of visible mainline checkpoints; branched checkpoints are not included in the
count.
If the graphical history view is filtered, the linked nodes may not represent consecutive
checkpoints. The nodes are connected by solid lines if they represent consecutive checkpoints
and dotted lines for non consecutive revisions.

Key Considerations

To invert a filter, click the filter a second time and the ! symbol displays. You would
invert a filter if, for example, you wanted to exclude checkpoints created by a particular
author.

If you choose more than one selection criteria, select whether the criteria should be
combined using a Logical AND or a Logical OR.

If you limit the number of checkpoints to display in the Project History view and the
maximum has been reached, a banner displays at the top of the view indicating the
number of checkpoints displayed.

Restoring a Project
The Restore Project command allows you to restore a project to a previously checkpointed
revision. Restoring a project is useful when development must revert back to an earlier
version and there are no plans to proceed from the current version of the project. Any further
development then proceeds from the restored project revision. The Restore Project command
can be applied to both normal and variant projects.
NOTE The Restore Project command can potentially restore and checkpoint dropped
subprojects that existed at the target revision, even if they are not currently a
member of the project.

22

Project Histories and Checkpoints

To restore a project through the GUI, select the project that you want to restore in either a
Project or Sandbox view, and select Project > Restore.
NOTE When you work through a Sandbox or sub Sandbox, the corresponding
master project is referenced.

IMPORTANT Do not use the Restore Project command to create a new development
branch from a previously checkpointed project. For new development paths, you
should instead create a development path (see Creating a Development Path on
page 28).

How Restore Project Command Works

MKS Source performs the Restore Project command as follows:

A checkpoint is performed on the current project revision.

The project is restored to the target revision.

A final checkpoint of the restored revision is made.

Therefore, for each project you restore, two revisions are generated. For example, if the head
revision of the project is 1.4 and you decide to restore it to revision 1.2, the following project
revisions are generated:
1.6final checkpoint
1.5pre-checkpoint
You would then continue your project development work from revision 1.6.

Selecting Checkpoint to Restore

You can select the checkpoint to restore by selecting a Pre-Defined Revision or a Specific
Revision.
If you want to restore a pre-defined revision, select one of the following:

Head revision, which represents the latest checkpoint on the default branch of
development (or on the mainline, if no default is specified)

Trunk Tip, which represents the latest checkpoint on the mainline independent of the

default branch settings.

If you want to restore a specific revision, you can select the revision based on a checkpoint
number or label by clicking the appropriate tab. The default revision is the most recent
checkpoint.

Key Considerations

When a project is restored, all restored members return to the initial state.

23

Chapter 2: Projects

The Project > Restore command can be applied to both normal and variant projects.

You can effectively undo the Project > Restore command by restoring the project to the
pre-checkpointed revision.

You cannot restore a build project using the Project > Restore command.

You cannot restore a project that is associated with a deploy stage. For more information
on deploy stages, see the MKS Deploy 2007 Administration Guide.

You cannot retore a project if a checkpoint is in progress on that project.

To restore a variant project to a specific project revision, the development path must
exist in all subprojects referenced by the project revision.
For more information on creating a development path, see Branching Projects on
page 27.

Adding Project Labels

You can add labels to project checkpoints. Labels are unique text that describe the product
stage or release, or the content of the project. Project labels can be based on any information
that would be useful in identifying that particular checkpoint of the project, for example, a
code freeeze. If there is more than one label on a project, the labels display in alphabetical
order.
Project labels can also be added as part of the checkpoint process. For more information, see
Checkpointing a Project on page 18.
Labels cannot contain colons (:), square brackets ([ ]), leading spaces, numbers in the same
format as a valid revision number (1.23), or numbers without any spaces (14325). Numbers
that contain spaces are acceptable, for example, 2432 1234.
Operation

Procedure

To add a project label in the GUI

Select a checkpoint in the Project History view

and select Project > Properties > Add Label

To add a project label in the Web interface

Select a checkpoint in the Project History view

and click History > Properties > Add Label
or
Select a project in the Project view and select
Project > Add Label

NOTE You cannot add a label to a project if a checkpoint is in progress on that

project.

In the GUI, to move an existing label to another checkpoint, click Options, then select the
Move Existing Label option.

24

Project Histories and Checkpoints

Deleting Project Labels

You can delete project labels. Deleting project labels may be appropriate in situations where a
label is no longer relevant or where an incorrect label is applied.
Operation

Procedure

To delete a project label in the GUI

Select a project or Sandbox and select Project >

Properties > Delete Label. In the Delete Label
dialog box, select a label to delete from the Label
list.

To delete a project label in the Web interface

Select a project and select Project > Delete Label

or History > Delete Label. In the Delete Label
dialog box, select a label to delete from the Label
list.

NOTE You cannot delete a label from a project if a checkpoint is in progress on that
project.

Viewing Project Differences

As you work with the project and its members, the content of the project file changes:

The revision number of the project is updated each time you checkpoint that project.

As you check in individual project members, their revision numbers change.

Project members may be added or deleted.

Project attributes may be added or deleted.

The View Project Differences command can compare the following:

two specified checkpoints of the project

working project with a specified checkpoint

working project with the last checkpoint

For more information on checkpointing, see Checkpointing a Project on page 18.

Information is provided on any change packages that have been applied between two
checkpoints of the project. This information is extremely useful for confirming the specific
content of a project.
For more information on the Project Differences view, see the online help

25

Chapter 2: Projects

Viewing Differences Between Two Specified Checkpoints of the Project

Interface

Procedure

GUI

From the Project History View, select the two checkpoints of the project
you want to compare, then click Project > Views > View Differences

Web

From the Project History view, click the check boxes of the checkpoints
you want to compare, then select History > View Project Difference

Viewing Differences Between the Working Project and a Specified Checkpoint

To compare the contents of the working project (or the last checkpoint of a build projects
branch) with a specified checkpoint, from the Project History view select a checkpoint, then
select Project > Views > View Differences.

Viewing Differences Between the Working Project and the Last Checkpoint
When no specific checkpoint of the project is selected, MKS Source compares the contents of
the working project (for normal or variant projects) with the last checkpoint. For normal
projects, this is the last checkpoint on the trunk; for variant projects, this is the last checkpoint
on the variants branch. This comparison shows all of the changes to the project since it was
created or since the last time it was checkpointed. For build projects, MKS Source compares
the contents of the build project checkpoint with the last checkpoint on the build projects
branch.
Using a Project view in the Web interface, you can perform the same type of comparison by
selecting Project > Views > View Differences.

Project Metrics
If metrics are being tracked for MKS Source projects, you can view the calculated metrics for
a specific project checkpoint. For information on setting up metrics for MKS Source projects,
see the MKS Integrity Server 2007 Administration Guide.

26

Operation

Procedure

To view project metrics for a build project in the

GUI

View Metrics

To view project metrics for a normal or variant

project in the GUI

Select a revision in the Project History view and

click Views > View Metrics

To view project metrics for a build project in the

Web interface

Project Metrics

To view project metrics for a normal or variant

project in the Web interface

Select a revision in the Project History view and

click History > View Project Metrics

Open a build project and click Project > View >

Open a build project and click Project > View

Branching Projects

The Metrics view displays the calculated value for each metric, the number of files used in the
metric calculation, and the average value of the metric across all files used in the metric
calculation.

NOTE Metrics are calculated automatically by event triggers. You can calculate
metrics manually in the Project History view of the GUI by selecting a project
checkpoint and clicking Project > Calculate Project Metrics.

Branching Projects
Branching projects is useful for:

extracting and building from previous versions of a project

building customized versions of a product

performing branch development work

performing post-release maintenance

fixing defects in previous versions of the product

testing new features outside of the main development path

experimenting with research that does not affect regular development

You create a project branch by creating a new development path. For more information, see
Creating a Development Path on page 28.
There are main models to follow when branching projects:

release based branching

project based branching

27

Chapter 2: Projects

Release Based Branching

In a release based branching model, the content of the project (features, enhancements, and
defects) tends to be static and well defined. Typically, the complete project goes through the
stages of development, testing, and release.
All development activity is performed on the main trunk of the project. Release candidates
are identified as checkpoints and finalized on a project branch. Bug fixes and stabilization
development work continues on the main trunk of the project and are migrated to the release
candidate branch using Apply Change Package. For more information on Apply Change
Package, see Using the Apply CP Command on page 138.
This type of branching model is suited for development environments where full versions are
released into production. When using this model, it is recommended to limit the number of
branches to avoid the need for mass merges at a later point.

Project Based Branching

In a project based branching model, the content of the project (features, enhancements, and
defects) tends to be dynamic, with constant additions and removals of subprojects
(comprised of features, enhancements, and defects) until the last minute. The project is
released in increments into production. Usually, this type of development does not release
the entire project after the initial rollout, and tends to have updates to production as
frequently as every week.
All development is performed on project branches created from the latest production
checkpoint. Changes made on project branches are merged into an integration branch using
the resynchronize change package command and tested on that branch before being merged
into the main trunk. For more information on resynchronizing change packages, see Using
the Resync CP Command on page 151. After newly introduced integration code has been
released on the main trunk, all active project branches are dropped and re-created from the
latest main trunk (production) checkpoint. This forces all active project branches to
synchronize with the latest production release.
In a project based branching model, it is recommended that you only create branches for
concurrent or parallel development projects. Creating branches at the feature, enhancement,
defect or task level is not recommended.

Creating a Development Path

A development path is an identifier given to a new branch of software development. Changes
made through the new development path are kept separate from the main development
trunk unless you choose to merge them later.
Once you have created a development path, you can open and work in a variant project by
opening a variant Sandbox. For more information, see Opening a Sandbox on page 44.

28

Branching Projects

MKS Source allows multiple developers to point to the same development path, each using
their own variant Sandbox. In the variant Sandbox, you can see the current state of the project
along the development path and the changes made by other developers using it.
When a development path is created for a project, it is also created for all subprojects,
reserving the assigned name as a unique identifier and ensuring no two paths can share the
same name.
Interface

Procedure

GUI

Select a project or Sandbox and select Project > Development Path >
Create.

Web

Select a project and select Project > Create Development Path or

History > Create Development Path.

NOTE You cannot create a development path for a project if a checkpoint is in

progress on that project.

Example
A user group at ABC Financial requests a version of the Stock Calculator that has the
commission fields removed and a special commissions legal message added. The task is
assigned to Chad. He must use version 1.0 of the stock project that did not contain the
commission fields and then add the new legal message to that version. To do this, he creates
a development path and a variant Sandbox off of the checkpointed 1.0 version.

Selecting the Checkpoint to Create a Development Path From

You can select the checkpoint to create a development path from by selecting a Pre-Defined
Revision or a Specific Revision.

If you want to create a development path from a pre-defined checkpoint, you can select one
of the following:

the Head revision, which represents the latest checkpoint on the default branch of
development (or on the mainline, if no default is specified)

the Trunk Tip, which represents the latest checkpoint on the mainline independent of
the default branch settings.

If you want to create a development path from a specific checkpoint, you can select the
checkpoint based on a checkpoint number or label by clicking the appropriate tab. The
default checkpoint is the most recent checkpoint.
You can view the development path of a checkpoint, plus any development paths branched
from a checkpoint, by selecting the checkpoint in the Project History view and viewing the
details panel.

29

Chapter 2: Projects

Removing a Development Path

Once a development path is no longer needed or useful, you can remove it at any time.
Deleting a development path is permanent; however, any changes you checked in through
the development path remain in your repository.
CAUTION If you remove a development path that is referenced by a variant Sandbox,
you cannot open that variant Sandbox.
Interface

Procedure

GUI

Select a project or Sandbox and select Project > Development Path >
Remove. In the Remove Development Path dialog box, select a
development path to remove from the Development Path list.

Web

Select a project and select Project > Remove Development Path or

History > Remove Development Path In the Remove Development Path
dialog box, select a development path to remove from the Development
Path list.

NOTE You cannot remove a development path from a project if a checkpoint is in

progress on that project.

Locating Where an MKS Source Object Is Used

As projects grow in complexity, it can be difficult to determine the relationships that
MKS Source objectsprojects, subprojects, and membershave with one another. Using the
Locate command, you can locate where a specific MKS Source object is used in your source
code repository. The search results appear in a Locate view, that allows you to refine and sort
the results, view each located object in greater detail, and perform basic operations on them,
such as viewing members.
When working with multiple development paths and shared subprojects or shared member
archives, it becomes important to understand what areas of a project might be affected by
parallel development. For example, you might need to:

30

determine what active projects a selected member, subproject, or registered top-level

project is shared with. Active projects are projects that are currently under development.

determine what development paths a selected member or subproject belongs to

determine if a selected member revision is part of a checkpoint

confirm all existing checkpoints for a selected revision before you delete it

display the development path that a corresponding member revision belongs to

Locating Where an MKS Source Object Is Used

display which master projects a selected subproject belongs to

Operation

Procedure

To locate where a project is used

Select a project, then select Project > Locate

To locate where a subproject is used

Select a project, then select Project > Subproject > Locate

To locate where a member is used

Select a member, then select Member > Locate

To locate where a revision is used

Select a revision, then select Member > Revision > Locate

To locate where a subproject is used

by searching by subproject name

Select a project, then select Project > Subproject > Locate

To locate where a member is used by

searching by member name

Select a member, then select Member > Locate By Name

By Name

Details Displayed
On the Advanced tab, you can specify the level of detail displayed in the Locate view:

Distinct mode provides a high-level view of the information. It displays only the projects
and development paths containing the object you are searching. You can select whether
to display only project names, only development path names, or only registered toplevel project names.
If a subproject is shared by two or more projects, only the original project is displayed.
Any projects where the subproject was added as shared are not displayed.

List mode displays detailed information about all occurrences of the object in the
projects and development paths containing the object.

Projects to Search
On the Advanced tab, checking he Limit Search to Active Paths option only searches projects
referenced by top level projects currently registered on the server.

Maximum Results Displayed

If you are searching for a member or subproject by name, You can specify the maximum
number of results to display. The number of results displayed is also controlled by the server
limit, which is set at 5000 by default. Administrators can change the default limit. If the
number of objects that match the search criteria exceeds the set limit, MKS Source displays
the following message at the bottom of the Locate view: Showing <set limit> of
<total number of objects>.

Key Considerations

The Locate command can only be used in the database repository. Running the
command from the file system repository returns an error message.

31

Chapter 2: Projects

You require the OpenProject permission for the project you are running the Locate
command from. When the Locate view displays, MKS Source informs you if there are
additional projects that you do not have permission to view.

Archive locations do not display in the Locate view.

Objects in development paths that have been removed do not display in the Locate view.

Generating Reports
In the GUI, MKS Source Reporter analyzes projects, their members, or individual archives,
and allows you to generate a variety of reports and graphs based on its findings. For
example, you could create a report to show the changes that have been made to a source file,
and which team members made them.
To generate a report, select a project or Sandbox, then select Project > Run Report. Select a
report type from the list of reports.
Reporter calculates a summary of the changes to a project or archive, then displays or prints
the summary as text or, for some reports, optionally as a graph. If you display a report as a
graph, you can define how you want it to look to suit your preferences or for quick, projectspecific identification. You can save Reporters data files (containing the results of its project
or archive analysis) as text files that most database applications can read.
To use Reporter, you must have a default printer installed, and you must have selected
Microsoft Access as your reporting application when you installed the MKS Integrity
Client. You can also create customized reports using MS Access.
If you installed MS Access after installing the MKS Integrity Client, contact your system
administrator to enable MKS Source reporting.
NOTE If you are integrated with MKS Integrity and your administrator has set up
MKS Integrity items to collect MKS Source project information, you can use the
expanded reporting capabilities provided by MKS Integrity. For more information,
see the MKS Integrity 2007 User Guide.

Types of Reports
Reporter generates the following summaries:

32

changes introduced by individual authors

changes between the member revision and a revision with a particular label

changes between the member revision and any other revision

a list of locked members and the names of users who locked them

a list of revisions with a particular label or state

Generating Reports

project member history (including revision descriptions) by file

Changes Grouped by Author

This type of report lists changes to members or revisions grouped by the person who made
them. For example, if both John and Sue made changes to several members, the report would
include two sections, one for John and one for Sue. Each section of the report shows:

name of the member

revision number of changed revisions

date the change was made

number of lines (or bytes for binary files) that were added or deleted

This type of report offers two additional options:

The report can be on a single, specified author, or all authors.

It can be restricted to changes made before or after a specified date.

Changes Grouped by Author (Summary)

This type of report shows a brief summary of changes made by each user. Each type of
project member (Text, Binary, Auto-Detect) displays in a separate section of the report,
subdivided according to the person who made the changes.
The information summarized includes:

name of the member

total number of revisions changed by each person

total number of lines (or bytes for binary files) that were added or deleted by each person

This report type offers two additional options:

The report can be on a single, specified author, or all authors.

It can be restricted to changes made before or after a specified date.

Revisions Newer Than Member Revision

This report tells you which members have more recent revisions available. For example, if a
member revision is revision number 1.3, but the archive contains revisions numbered 1.4, 1.5,
and 1.6, this report lists the newer available revisions and information about each, including:

name of the member

revision numbers of newer revisions in the archive

33

Chapter 2: Projects

date of the newer revisions

revision description for each newer revision

Changes From Member Revision to Label

This report lists all revisions in a members archive between the member revision and
another revision with a specified label. This report can be generated for a single member or
for all project members.
For each member, the report shows:

name of the member

revision numbers of all the revisions between the member and the labeled revision

author of each revision

date of each revision

revision description for each revision

Changes From Member Revision to Revision

This report lists all revisions in the member archive between the member revision and
another revision with a specified revision number. This report can be generated for a single
member or for all project members.
For each member, the report shows:

name of the member

revision numbers of all the revisions between the member revision and the selected
revision number

author of each revision

date of each revision

revision description for each revision

List Locked Revisions

This report lists all locked revisions in a project or archive. For each locked revision, the
report lists:

34

name of the member

revision number

person who has it locked

Promoting and Demoting Projects

List Revisions Associated With Labels

This report scans the archives of all project members and extracts any labels they contain. For
each label it finds, the report lists:

name of the label

name of the member archive

revision number the label is associated with

List Revisions Associated With States

This report scans the archives of all project members and extracts any state settings they
contain. For each state setting it finds, the report lists:

state setting

name of the member archive

most recent revision the state is associated with

Project Member History

This report displays all the revisions of a specified project member. For each revision, it
shows:

revision number

revision date

revision description

When you choose the member to report on, you can specify that the information should be
sorted according to revision number or revision date in either ascending or descending order.

Promoting and Demoting Projects

Administrators can define promotion states that control how development objects move
through a structured development cycle. For example, a project could go through states such
as: development, testing, production, and release. You promote a project to move it to the
next state in the cycle, or demote it to return it to the previous state.
NOTE Promoting and demoting projects is for historical purposes only. To control
project workflow more effectively, MKS recommends using MKS Integrity.

35

Chapter 2: Projects

Promoting a Project
Typically, you promote a project (or set its state) when you checkpoint it, but you can do so at
any time. To promote a member, your administrator must have defined promotion states.
NOTE When you promote a project, only the project (.pj) file is affected. Individual
members of the project are not changed.
Interface

Procedure

GUI

Select a checkpoint from the Project History view and select Project >
Properties > Promote. In the Promote Project dialog box, select a new
state from the Promote to State list.

Web

Select a checkpoint from the Project History view and click History >
Promote. In the Promote Project dialog box, select a new state from the
Promote to State list.

TIP In the MKS Source Web interface, you can also promote a project from the
Project view by selecting Project > Promote.

Demoting a Project
Typically, you demote a project (or set its state) when you checkpoint it, but you can do so at
any time. To demote a member, your administrator must have defined promotion states.
When you demote a project, only the project file (.pj) is affected. Individual members of the
project are not changed.
NOTE Demoting projects is for historical purposes only. To more effectively control
project workflow, MKS recommends using MKS Integrity.
Interface

Procedure

To demote a project in the

GUI

Select a checkpoint from the Project History view and select Project >
Properties > Demote. In the Demote Project dialog box, select a new
state from the Demote to State list.

To demote a project in the

Web interface

Select a checkpoint from the Project History view and select History >
Demote. In the Demote Project dialog box, select a new state from the
Demote to State list.

TIP In the MKS Source Web interface, you can also demote a project from the
Project view by selecting Project > Demote.

36

CHAPTER THREE

Sandboxes

Managing Your Personal Workspace

A Sandbox is a private workspace that resides on the client machine and mirrors the
content of a project on the server. Although it looks and acts like the project it mirrors, a
Sandbox is actually a collection of pointers to its real-life counterparts in the master
project. Sandboxes allow you to work locally in your own workspace, without
interfering with the work of others.
This chapter provides details on the following:

Types of Sandboxes on page 38

Creating a Sandbox on page 40

Importing a Sandbox on page 40

Sharing Sandboxes on page 41

Dropping a Sandbox on page 43

Opening a Sandbox on page 44

Retargeting a Sandbox on page 45

Taking Sandbox Snapshots on page 45

37

Chapter 3: Sandboxes

Types of Sandboxes
Different types of Sandboxes are available for different types of development.

Normal Sandboxes are useful for the sequential development of a project over the long or
short term.

Variant Sandboxes are useful for branching off the main development path.

Build Sandboxes are useful for testing a specific revision of the project.

Using Variant Sandboxes

A variant Sandbox is based on a specific development path of a project. When you create a
variant Sandbox, you choose the development path to use. In the variant Sandbox, you can
see the current state of the project along that development path and the changes made by
other developers using it.
When a variant Sandbox is created for the first time, it is also created for all subprojects,
reserving the assigned name as a unique identifier and ensuring no two paths can share the
same name.
For information on creating development paths, see Creating a Development Path on
page 28. For information on viewing a variant project, see Opening a Project on page 9. For
information on creating variant Sandboxes, see Creating a Sandbox on page 40.
Conflicts can occur when developers working on different paths need to work on the same
revision of a file. For example, one developer could be working in a regular Sandbox that
includes utility.dll, version 1.4 and another developer could be working in a variant
Sandbox that contains utility.dll, version 1.3. Both versions are stored in the same
member history.
To prevent potential conflicts, the first time you check in a member from a variant Sandbox,
you are prompted to branch the member history. Branching the member history gives each
development path its own copy of the revision. For more information on branching members,
see Branching and Merging Members on page 98.

Using Build Sandboxes

After major milestones, such as product releases, you might want to recreate a static version
of an entire project as it existed at some point in the past. You create a build Sandbox to build
or test the project, but not to begin further work along a new development path. Build
Sandboxes could be used for quality assurance or production to distribute files in a fixed
configuration.

38

Types of Sandboxes

A build Sandbox is a Sandbox associated with a particular project checkpoint and has no
development path (since it is static and not meant for further development). No further
development can be carried out in a build Sandbox.
For information on viewing a build project, see Opening a Project on page 9. For
information on creating a build Sandbox, see Creating a Sandbox on page 40.
Within a build Sandbox, you can:

change labels and states

resynchronize your Sandbox

compare a member revision in the build Sandbox to another revision

merge a member revision in the build Sandbox with another revision (of course, you
cannot check a merged file back into the build Sandbox)

check for differences between checkpoints, such as changes to a project since it was last
checkpointed

When you create a build Sandbox, you choose the project checkpoint to base the build
Sandbox on.
However, with a build Sandbox, you cannot:

check out, lock, or check in members

add or remove members

set the development path

freeze or thaw members

checkpoint the master project

modify project or member attributes

revert members

set the member revision

Each of these represents further development, which requires a normal or variant Sandbox.

Example
Steve, the build manager, needs to burn a CD of a special build of the savings calculator for
an ABC Financial executive who does not like the bottom part of the calculator. It does not
suit his corporate audience.
Steve uses an earlier checkpoint of the savings calculator that did not include the bottom part,
and creates a build Sandbox on the CD burning system.

39

Chapter 3: Sandboxes

Creating a Sandbox
Once a Sandbox is created, you can add files or members to that Sandbox. The project is then
updated to reflect the addition of new project members.
To create a Sandbox in the GUI, select Sandbox > Create and follow the instructions in the
Create Sandbox Wizard.
NOTE While it is possible to create more than one Sandbox in a single directory, it is
not recommended.

Specifying the Project to Base the Sandbox On

You can type in or select the project to base the Sandbox on. For detailed information about
entering project paths, see the MKS Integrity Client 2007 Getting Started Guide. For detailed
information about selecting projects, see the MKS Integrity Client 2007 Getting Started Guide.
If you are creating a variant or build Sandbox in the GUI, initially only enter the path and
name of the root project. You specify the subproject later in the procedure. When specifying
the subproject, there are rules that control what project configuration you can jump to. For
more information, see the MKS Integrity Client 2007 Getting Started Guide. If your selection
breaks any of the rules, you cannot create the Sandbox.

Selecting a Sandbox Type

When creating a sandbox you can create the following types:

Normal creates a Sandbox based on the working project on the mainline.

Variant creates a Sandbox based on a project on a specific development path. For more

information on variant Sandboxes, see Using Variant Sandboxes on page 38.

NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Removing a Development Path on page 30.

Build creates a Sandbox based on a specific checkpoint of the master project. You can
specify the checkpoint through its checkpoint number or label. For more information on
build Sandboxes, see Using Build Sandboxes on page 38.

Importing a Sandbox
Use the Import Sandbox command when:

40

you need to use a dropped Sandbox again

Sharing Sandboxes

you are sharing a Sandbox with another user

your client registry was lost (for example, during a client machine upgrade)

you need to change the project or server used by your Sandbox

NOTE The master project of the Sandbox must also be registered with the
MKS Integrity Server before the Sandbox is imported.

To import a Sandbox in the GUI, select Sandbox > Import and browse to the Sandbox file on
your local drive.

Sharing Sandboxes
MKS Source provides a way to create a common build location using shared Sandboxes.
Shared Sandboxes provide developers and buildmasters with a window into a single shared
work location.
Sandbox sharing is intended when:

There is a common build location that contains files that developers need to access to
build their source before checking it into the build

Users share the Sandbox by importing it through the network or a mapped drive. The
imported Sandbox is by reference, so no working files are stored on the users machines.

Users who imported the shared Sandbox now have access to the working files in the
shared Sandbox and use those files to create test builds on their machines without
requiring those files to be stored locally.
NOTE To share Sandboxes, all clients connecting to the shared Sandbox must be
MKS Source 8.6 or later. MKS recommends that all clients connecting to the shared
Sandbox be the same version of MKS Source.

41

Chapter 3: Sandboxes

Shared Sandbox
Common location with
working files

Imported Sandbox 1

Imported Sandbox 2

Imported Sandbox 3

References Working Files

References Working Files

References Working Files

Sandbox shared with multiple users

CAUTION MKS does not support using shared Sandboxes for collaborative
development with multiple developers. Shared Sandboxes may become unstable in
this scenario.

Users sharing Sandboxes:

must select View > Refresh for the project to update their Sandbox view to see the true
state of the Sandbox (top level project updates recursively)

should all be in same time zone

must have read and write permission for the shared location where the shared Sandbox
resides, as well as for the files in that location

cannot submit deferred operations in the Sandbox made by other users using the Submit
Change Package command (their deferred and lock entries do not appear in your
Change Package view)

only top level Sandboxes can be shared (Shared, Sparse, and Line Terminator options in
the Sandbox Information view are disabled for sub Sandboxes)

Configuring a Sandbox as Shared

For users to share a Sandbox, only the creator of the Sandbox can configure the Sandbox as
shared. When a top-level Sandbox is configured to be shared, all sub Sandboxes are shared as
well. Sub Sandboxes cannot be individually configured to be shared or not shared.

42

Dropping a Sandbox

To share a Sandbox in the GUI, open the Sandbox Information view for a top-level Sandbox
created by you (Sandbox > Views > View Information), and check the Shared option on the
General panel.
IMPORTANT If clients on different platforms are sharing a Sandbox, you may need to
modify the line terminator setting to ensure compatibility with file editors.

Importing a Shared Sandbox

You access another users shared Sandbox using the Import command, and browsing through
the network to the users shared Sandbox directory. For more information on importing
Sandboxes, see Importing a Sandbox on page 40. When you share another users Sandbox,
no working files are stored on your local machine.
Only import another users Sandbox through the network if that Sandbox has sharing
enabled. For more information, see Configuring a Sandbox as Shared on page 42.
Only top-level Sandboxes can be imported as shared.

Removing Sharing From a Sandbox

When there is no longer a need for a common location, the creator of the Sandbox can remove
the sharing from the Sandbox. When Sandbox sharing is removed, users sharing that
Sandbox no longer have access to it.
Only the creator of the shared Sandbox can remove sharing (or edit Sandbox information).
To remove sharing from a Sandbox in the GUI, open the Sandbox Information view and clear
the Shared option on the General panel.
Users sharing the Sandbox each receive an error message stating the change in sharing
configuration the next time they attempt to access the Sandbox or perform an operation on its
contents.

Dropping a Sandbox
When a Sandbox has outlived its usefulness or just does not belong anymore, you can
remove it at any time.
To drop a Sandbox means that the Sandbox is no longer registered with the MKS Integrity
Client. Once a Sandbox is dropped, it cannot be accessed with MKS Source. However, if you
do not delete the Sandbox, you can import it again if you want it to be accessible in
MKS Source.

43

Chapter 3: Sandboxes

You can select what files you want to delete when you drop your Sandbox:

Select Nothing to not delete any files from the Sandbox directory on your local drive.

Select Sandbox Members Only to delete the Sandbox members on your local drive but
leave any other files.

Select Entire Sandbox Directory to delete the Sandbox directory on your local drive
and all of its contents.
CAUTION If you select the Entire Sandbox Directory option, MKS Source
deletes all files in the Sandbox directory and all files in subdirectories, if any exist.
This includes files not created by MKS Source.

Opening a Sandbox
Opening a Sandbox in the GUI allows you to view and work with the Sandbox and its
members. The Sandbox view displays the members and sub Sandboxes of a single Sandbox.
NOTE To see a list of recently used Sandboxes, select Sandbox > Recent. To open a
Sandbox, select one from the list.

TIP You can view which Sandbox locked a member from the Member History view,
Locks view, Project view, and Sandbox view by setting the view preferences to
display the information. For more information on setting view preferences, see the
MKS Integrity Client 2007 Getting Started Guide.

To open a Sandbox in the GUI, select Sandbox > Open Sandbox and select the type of
Sandbox to open:

Normal opens a Sandbox based on the working project on the mainline.

Variant opens a Sandbox based on a project on a specific development path. For more

information on variant Sandboxes, see Using Variant Sandboxes on page 38.

NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

44

Build opens a Sandbox based on a specific checkpoint of the master project. You can
specify the checkpoint through its checkpoint number or label. For more information on
build Sandboxes, see Using Build Sandboxes on page 38.

Retargeting a Sandbox

Retargeting a Sandbox
If you need to change the project configuration that a Sandbox points to, you can retarget the
Sandbox. For example, a developer can change a variant Sandbox to point to a different
variant project, or a buildmaster can change a build Sandbox to point to a different build. You
can also change the type of project that the Sandbox points to; for example, you can change a
normal Sandbox to point to a variant project.
You do not use the Retarget Sandbox command to change the project or server for a Sandbox
or the location of a Sandbox on the client. To perform these operations, you must drop the
Sandbox and then import it.
To retarget a Sandbox, select a top-level Sandbox and click Sandbox > Retarget, then select
the project configuration that you want to point the Sandbox to.

Key Considerations

You cannot retarget a Sandbox containing deferred member operations or locks.

You cannot retarget a shared Sandbox.

You can only retarget top level Sandboxes.

You can only retarget to another type of the same project that the Sandbox is currently
pointing to.

Taking Sandbox Snapshots

A snapshot captures the current state of a Sandbox, where each element in the Sandbox can be
identified with a pre-existing entity in the repository on the MKS Integrity Server. The
Sandbox snapshot creates a project checkpoint that you can create a build Sandbox or
development path from. The revision number of a checkpoint created by a snapshot includes
the revision number of the last checkpoint. For example, if the last checkpoint of the project
has a revision number of 1.1, then the revision number of the checkpoint created by the
snapshot is 1.1.1.1.
To take a sandbox snapshot, select a Sandbox, and then select Sandbox > Snapshot.
When you take a sandbox snapshot, you can specify a state or a label for the snapshot, and
apply it to all Sandbox members. A label is a unique text string assigned by you to identify
the project checkpoint created by the snapshot. Labels cannot contain colons (:), square
brackets ([ ]), or leading spaces. Additionally, they cannot have the same format as a valid
checkpoint number.

45

Chapter 3: Sandboxes

The Sandbox snapshot displays as a branched project checkpoint in the Project History view.
NOTE If working files are missing from the Sandbox, a warning displays listing the
missing working files that will not appear in the snapshot. If you want to include
those working files in the snapshot, cancel the operation, provide the working files
(by resynchronizing the corresponding members), and then perform the snapshot.

Contents of a Sandbox Snapshot

The set of Sandbox elements captured in a snapshot includes the following:

Sandbox members identified with an archive and working revisions the archive was
created from

former members that were dropped but are still present in your Sandbox

sub Sandboxes identified by project name and type

former sub Sandboxes that were dropped but are still present in your Sandbox

Example
Steve has been assigned to create a build of the savings calculator. He uses a build Sandbox to
perform the build. He discovers a readme file is missing from the checkpoint his build
Sandbox is based on. Jen has added the readme file in a change package. Steve adds the
readme file to his Sandbox using the change package and then takes a snapshot of his
Sandbox to save the configuration.

Key Considerations

46

To be included in the snapshot, you cannot have working file changes in the Sandbox.

If the working file revision differs from the member revision, it is the working file
revision that is included in the snapshot.

Members without working files are not included in the snapshot.

Former members that still have working files in the Sandbox directory appear as
members in the snapshot.

Former subprojects that are still in the Sandbox view appear as subprojects in the
snapshot.

MKS Source always uses the actual name of the member working file for the snapshot.

You cannot take a snapshot of a sparse Sandbox.

The Snapshot Sandbox command is performed on the entire Sandbox independently of

the filter used to display the contents of a Sandbox.

Taking Sandbox Snapshots

You can compare differences between a project checkpoint created by a snapshot and
another project checkpoint (including checkpoints created by a snapshot) in the project
history, but you cannot compare differences with the Sandbox contents.

To specify an existing development path when taking a Sandbox snapshot, you must use
the CLI. For more information, see the MKS Source 2007 CLI Reference Guide.

Members of a Sandbox need to be associated with a corresponding archive on the

MKS Integrity Server.

When recursing into sub Sandboxes, the snapshot represents exactly the same directory
structure and files of your Sandbox. All subproject elements become the same type and
shared subprojects of different types become shared subprojects of the same type.
When you take a snapshot of a Sandbox recursively that contains sub Sandboxes, the
snapshot creates a checkpoint for the sub Sandboxes based on the last checkpoint of the
master project (if one exists), not on the current subproject in your Sandbox. Member
revisions are unaffected.

Using Sandbox Snapshots in a Development Environment

The recommended scenario for when to take a Sandbox snapshot in a development
environment is as follows:
1 You are in a situation where you are working in a regular Sandbox, but should be

working in a variant Sandbox.

2 Instead of checking in your changes to the main development path, check in (or merge

in) your changes on a branch.

3 Take a snapshot of the Sandbox.
4 Create a development path from the project checkpoint that corresponds to the snapshot

(see Creating a Development Path on page 28).

5 Create a variant Sandbox from the development path you created, and then continue

work on that development path.

TIP From the CLI, you can specify an existing development path at the time you
take the snapshot. For more information, see the MKS Source 2007 CLI Reference
Guide.

Using Sandbox Snapshots in a Build Environment

The recommended scenario for when to take a Sandbox snapshot in a build environment is as
follows:
1 Checkpoint the project.

47

Chapter 3: Sandboxes

2 Create a build Sandbox for the build.

3 The build fails, but since development has continued, some of the required members are

at later revisions than the last checkpoint.

4 Resynchronize the required revisions to fix the build (you can use Resync CP).
5 Take a snapshot of the Sandbox, and use the project checkpoint created by the snapshot

to recreate the build in the future using a build Sandbox, instead of using the original
project checkpoint.

48

CHAPTER FOUR

Members

Managing Source Files and Objects

The files under version control in a project are known as members.
A members content is stored in an archive. MKS Source creates a history file for each
project member where its history of changes is stored. Each submitted update is
recorded in a members history as a revision and given a sequential number for reference.
This chapter describes the activities that can be performed on MKS Source members.
This chapter provides details on the following:

Managing Project Members on page 50

Member Operations on page 62

Deferring Member Operations on page 82

Working with Member Histories and Revisions on page 85

Comparing Differences on page 95

Branching and Merging Members on page 98

Locating Where a Member Is Used on page 109

Generating Member Reports on page 110

Promoting and Demoting Members on page 111

49

Chapter 4: Members

Managing Project Members

A project is any group of files under version control that, taken together, forms a single body
of work. For example, in a development environment, a project might include source code
files required to build a program element. When you are ready to place a group of files under
version control, the first step is to create a project. For more information on how to create a
project, see Creating a Project on page 6. Once the project is created, you can add members
to it. This section describes how to add members to projects and manage them within the
context of projects. For information on how to perform operations on members after they
have been added to a project, see Member Operations on page 62.
This section provides information on the following procedures:

Identifying Members to Add to Projects on page 50

Adding Members to a Project on page 51

Adding Members From Archive to a Project on page 53

Importing Members on page 55

Moving Members on page 57

Dropping Members From a Project on page 60

Identifying Members to Add to Projects

From MKS Source, you can view non-member files (files that have not been placed under
version control) residing in your Sandbox directory. The Non-Members view is useful when
used recursively to identify all of the files that may need to be placed under source control.
To view non-members, from a Sandbox view, select Sandbox > Views > View Non-Members.
NOTE

If a member is selected when you display the Non-Members view, the nonmembers for the nearest project or subproject are displayed. The project or
subproject name used by the Non-Members view displays in the title bar.

You cannot display multiple Non-Members views for the same Sandbox.

The Non-Members view does not display files that are:

50

deferred imported members

deferred add members from archive

pending members (add, add from archive, import)

working files from members that are renamed but not resynchronized

Managing Project Members

By default, former members (members that were dropped from your Sandbox) are not
displayed in the Non-Members view. For information on how to modify the default view
settings, see the MKS Integrity Client 2007 Getting Started Guide.
For detailed information on the Non-Members view columns, see the online help.
You can add a non-member to a project, or delete or edit a non-member by selecting one or
more files and selecting the appropriate option on the View menu. You can also filter the
contents of the Non-Members view.

Filtering Non-Members
You can filter the content of the Non-Members view by specifying files, file types, or
directories to include or exclude.
To filter the view, do one of the following:

Select one or more files and select View > Exclude with Name or View > Exclude with
Extension.
NOTE Files excluded by name are not excluded once the Non-Members view is
closed.

Select View > Filters and specify any combination of files or directories to include or
exclude. By specifying file types to include, all file types not specified are excluded.
NOTE If filters are specified in the Non-Members view preferences, those filter
settings appear in the Non-Members Filter dialog box. For information on setting
view preferences, see the MKS Integrity Client 2007 Getting Started Guide.

TIP To specify all files with a specific file extension, use the wildcard (*), for
example, *.java.

Adding Members to a Project

Once you create a project, you can add files to it, making them members of that project. Once
you add members to your project, you can check them out for editing, and then check them in
to preserve your changes.
To add server-side files to a project, use the Import Member command (see Importing
Members on page 55).

51

Chapter 4: Members

In the GUI, you can add members through the Sandbox. In the Web interface, because
Sandboxes do not exist, you can add members through the project only.
Interface

Procedure

GUI

Select Member > Add. Follow the instructions on the Add Member
Wizard.

Web

Select Project > Add Member and enter the name of the new member,
including the file extension. For example, features.gif.

TIP To add selected non-member files to a project or subproject by dragging and

dropping, with a Sandbox view open drag the files from the Non-Members view to
the Sandbox or sub Sandbox that corresponds to that project or subproject you want
to add the project to. Subdirectories that do not correspond to subprojects are not
maintained.

NOTE If you are using a file system repository, the maximum size for members is
2 GB; if you are using a database repository, the maximum size is 2 GB for Oracle or
SQL Server, and 1 GB for DB2. To find out the type of repository used on your
server, see your administrator.

Adding Multiple Members

If you select multiple files to add in the GUI, they will be added to the project that they are
closest to (top-level project or subproject).
Adding a large number of members or a directory with a large number of members to a
MKS Source Sandbox may cause the client to stall if the MKS Integrity Server does not have
the recommended system configuration. Consult your administrator for more information.

Archives and Subprojects

Project members may be one of following types of files: archived (files under MKS Source
revision control) or subproject (another MKS Source project).
When adding members in the GUI, you have the option of adding members recursively to
the project or creating subprojects.

Using Change Packages

You can record the add member or create subproject operation in a change package. For
information on the Change Package field, see Specifying a Change Package for an
Operation on page 118. For information on creating a change package, see Creating a
Change Package on page 117.
NOTE If you choose to create subprojects, the specified change package is used to
record the Create Subproject operation.

52

Managing Project Members

Deferring Adding Members

You can add a member to the project on a deferred basis. Deferring the addition of a member
allows you to work with the member in your Sandbox without causing any changes in the
project. For more information on deferred operations, see Deferring Member Operations
on page 82.
NOTE If there is a deferred add operation associated with a member, you cannot
view the member history for that member because it has not yet been added to the
actual project.

Adding Members to Deploy Projects

If the member is being added to a deploy project, you can specify the deploy type for the
member when entering the archive description in the Create Archive dialog box. The Deploy
Type field only displays if you are licensed to use MKS Deploy. For more information, see the
MKS Deploy 2007 Administration Guide.

Re-adding a Dropped Member

If you are re-adding a dropped member, an archive already exists for the member, and you
must specify whether you want MKS Source to associate the member with the existing
archive or generate a new one.

Adding Members From Archive to a Project

Use the Add From Archive command to add a dropped member from an archive located on
the server. You can also use this command to share the history of another member, where the
source member can be located in another project from the added member.
The Add From Archive command:

can be deferred when performed from a Sandbox.

may be part of change package review (displayed as pending members in the project).
For more information on change package reviews, see Change Package Reviews
Overview on page 128.

supports multiple selection of archives using the wizard.

To add members from archive in the GUI

1 Select the project, subproject, Sandbox or sub Sandbox you want to add members to.
2 Select Member > Add From Archive. The Add Members From Archive Wizard displays.

53

Chapter 4: Members

3 Members are added by specifying a member name with an archive location; together

they define an entry that represents the destined member.

Do one of the following:

Click Select Archives to browse the repository for an archive. The Locate the
Member Archive(s) dialog box displays.
Select the archives corresponding to the members you want to add to the project.
Archives are identified by the
icon. If you are using a file system repository, by
default the files are located in the subdirectory named rcs. To add the selection as
an entry in the list, click OK.

In the first field, type the name that represents the member being added. Then type
the archive location in the subsequent field (requires a valid location to an existing
archive). The default archive location is the project selected in step 1. To add the
entry to the list, click Add.

Repeat to add additional entries. Added entries appear as follows:

Member Name displays the name of the member (may differ from the archive file

name).

Archive Location displays the absolute path of the archive and the archive file name.

To remove an entry from the list, click Remove. Repeat to remove additional entries.

54

Managing Project Members

4 To add the operation to a change package, from the Change Package list select a change
package. To create a change package, click Create.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
NOTE If you choose to create subprojects, the specified change package is used to
record the Create Subproject operation.

5 To modify the Add Members From Archive Wizard options, click Options. For detailed

information on the Add Member From Archive options, see the online help.
6 When you are finished specifying entries to add, click Finish. The Add Member From
Archive dialog box displays.
7 The archive location displays in the Archive Location field. To change the location, type a
new location in the field, or click Locate Archive to select it.
8 To modify the Add Member From Archive options, click Options. For detailed

information on the Add Member From Archive options, see the online help.
9 When you are finished, click OK to add the member to the project. To add all subsequent
members specified in the Add Members From Archive Wizard, click OK to All. The

member is added to the project.

Importing Members
When you add a member, it is automatically registered with the MKS Integrity Server;
however, members added with Source Integrity Standard (an earlier version of MKS Source)
or server resident files must be imported to register them with the MKS Integrity Server.
Do not use the Import Member command to add members that are dropped from a project.
Instead, use the Add From Archive command (see Adding Members From Archive to a
Project on page 53).
NOTE The Import Member command is not supported for database repositories.

Key Considerations

The project must be registered with the MKS Integrity Server before the member is
imported.

Before you begin the import operation, the files to be imported must first reside on the
MKS Integrity Server.

55

Chapter 4: Members

Archives cannot be imported. When selecting a file to import, select the working file in
the project directory. If the working file does not exist, select the project directory and
enter the file name.

You cannot import members into a shared subproject. For more information on shared
subprojects, see Adding a Shared Subproject on page 12.

To import a member in the GUI

1 From a Project or Sandbox view, select Member > Import. The Import Members Wizard

displays.
2 To import a list of files to the project, click Add File. To import a directory and its
contents, click Add Directory. The Select One or More Members to Import to the Project

dialog box displays.

3 Select one or more files from the displayed list, navigating to the desired directory if

necessary.
NOTE If your connection to the MKS Integrity Server is disconnected while you are
browsing for a file, the file browser does not show any files or directories.

4 To add the operation to a change package, from the Change Package list select a change
package. To create a change package, click Create.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
NOTE If you choose to create subprojects, the specified change package is used to
record the Create/Add Subproject operation.

5 Click OK. The files are added to the members list. To remove files, select the files, then
click Remove.
6 To modify the Import Member options, click Options. For detailed information on the

Import Members Wizard options, see the online help.

7 Click Finish to import files without specifying options. The Import Member dialog box

displays.
8 If the member is being imported to a deploy project, specify the deploy type for the
member in the Deploy Type field. This field only displays if you are licensed to use

MKS Deploy. For more information, see the MKS Deploy 2007 Administration Guide.
9 To modify the Import Member options, click Options. For detailed information on the

Import Member options, see the online help.

56

Managing Project Members

10 To complete the operation, click OK. The members appear in the Project or Sandbox

view.

Moving Members
As software designs and project structures change, it may become necessary to move one or
more members between projects, variants of the same project, or directories in a project.
For example, if you are re-designing and expanding your company web site, you can
organize the site more efficiently by moving some of the files to new and existing directories
and subprojects.
Moving a member performs a drop in the source project and an add in the target project,
creating a new revision in the existing archive. The members archive remains in its original
location in the repository so that change packages, member histories, and project histories
continue to work. If the move is performed with a change package, the member is added as a
single Move entry in the change package. If you are moving multiple members, any common
directory prefix shared by the members is automatically removed by default during the
move.
You can move one or more members between projects or directories in a Project or Sandbox
view using the menu command or by dragging and dropping.

Key Considerations

Moving members between projects on different servers is not supported.

To move a member, you require the DropMember permission on the project you are
moving the member from and the AddMember permission on the project you are moving
the member to.

You can perform deferred member moves only if both the source and target locations are
Sandboxes.

The move members command does not work recursively on subprojects. To move one or
more subprojects, use the Project > Subproject > Move command. For more information,
see Moving a Subproject on page 15.

MKS Source detects whether any ACLs exist in the tree defined by the source project, the
target project, and the common root between them (or the global ACL, if there is no
common root). If any ACLs are found, MKS Source warns you so you can manually
make any required adjustments to the ACLs after the move is complete. For more
information on ACLs, see the MKS Integrity Server 2007 Administration Guide.

To move a member in the GUI

1 Select one or more members to move.

57

Chapter 4: Members

2 Select Member > Move. The Move Members Wizard displays.

NOTE Depending on the view you performed the move from, the Project or
Sandbox option is selected and the name of the project or Sandbox displays.

3 Specify the destination project or Sandbox for the member(s):

To move the member(s) to a specific project, proceed to step 4.

To move the member(s) to a specific Sandbox, click Sandbox, then click Select to
choose a Sandbox from the list. Proceed to step 8.
NOTE If you specify a Sandbox, the move occurs in the corresponding master
project.

4 Click Project, then click Select. If you are performing the move operation from a Project
view, proceed to step 7. If you are performing the move operation from a Sandbox view,
the first panel of the Specify the target project for the move wizard displays.
5 Enter the path and name of the project and proceed to step 10, or click Select to choose a

project from the list.

For detailed information about entering project paths, see the MKS Integrity Client 2007
Getting Started Guide.
NOTE If you are moving the member(s) to a variant or build subproject, only enter
the path and name of the root project in this field. You specify the subproject later in
the procedure.

For detailed information about selecting projects, see the MKS Integrity Client 2007
Getting Started Guide.
6 Click OK. The second panel of the Specify the target project for the move wizard displays.
7 Select the type of project you want to move the member(s) to by clicking a project type

option. The available types are:

Normal moves the member (s) to a project based upon the current state of the
project. Click Finish and proceed to step 10.

Variant moves the member(s) to a project based upon a specific development path.

From the Development Path Name list, select a development path name, for
example, Aurora_Beta_Variant.
NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

58

Managing Project Members

8 If you are moving the member(s) to a variant or build project, click Next to select a
subproject. The third panel of the Specify the target project for the move wizard displays.
9 Expand the project to select the specific subproject that you want to move the member(s)
to. Click Finish.
NOTE There are rules that control what project configuration you can jump to. For
more information, see the MKS Integrity Client 2007 Getting Started Guide. If your
selection breaks any of the rules, you cannot move the member.

10 Under Change Package, select a change package, if applicable, or create a change

package to link to.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
NOTE If you choose to create subprojects, the specified change package is used to
record the Create Subproject operation.

11 To modify the Move Members options, click Options. For detailed information on the

Move Members options, see the online help.

12 Click Next. The second panel of the Move Members Wizard displays.
NOTE The options that appear depend on whether you selected a destination project
or destination Sandbox.

13 Specify the destination directory for the member(s):

To move the member(s) to the destination projects directory, click Destination

Project Directory.

To move the member(s) to the destination Sandboxs directory, click Destination

Sandbox Directory.

To move the member(s) to a subdirectory in the destination projects directory, click

Subdirectory of Destination Project Directory, then type the subdirectory, for
example, bin/etc.

To move the member(s) to a subdirectory in the destination Sandboxs directory,

click Subdirectory of Destination Sandbox Directory, then type the subdirectory, for
example, bin/etc.

14 Click Next. The third panel of the Move Members Wizard displays, summarizing the

details of the move.

15 Review the settings you selected and make changes if necessary.

59

Chapter 4: Members

16 To move the selected member, click Finish. If you enabled the Confirm Move option,

MKS Source prompts you to confirm the move.

17 To confirm moving the member, click OK. (for multiple members, click OK to All). The

member(s) appear in the new location.

To move a member by dragging in the GUI
You can move one or more members by left-clicking and dragging one of the following:

One or more member nodes.

A directory node. This automatically moves all members in the directory and
subdirectories. If any subprojects or sub Sandboxes are encountered, this initiates the
Move Subproject Wizard, prompting you to confirm the move. For more information on
the Move Subproject Wizard, see Moving a Subproject on page 15.

A subproject or sub Sandbox node. This initiates the Move Subproject Wizard, prompting
you to confirm the move. For more information on the Move Subproject Wizard, see
Moving a Subproject on page 15.

You can drag a member onto a project, subproject, Sandbox, sub Sandbox, or directory node
in the active Project or Sandbox view, or an adjacent open Project or Sandbox view. The
drag-and-drop action initiates the Move Member wizard, prompting you to confirm the
operation. For more information, see Moving Members on page 57.

Dropping Members From a Project

If a member has outlived its usefulness or does not belong in a project anymore, you can
remove it at any time.
In the GUI, you can remove a member through a Sandbox view or through a Project view.
In the Web interface, because Sandboxes do not exist, you can remove members through the
Project view only.

After you remove a member from a project, the member is no longer listed as part of the
Sandbox or master project, but the members history remains in the project record, in case
you need to recreate an earlier version of the project.
A former member is one that is dropped from the project, but still has a working file in the
Sandbox. MKS Source retains the member history for former members as part of the project.
Depending on the options you select when dropping the member, MKS Source can also
delete the members working file and close any associated change package.
NOTE You cannot check in a member that is associated with a deferred drop
operation.

60

Managing Project Members

To drop a member in the GUI

1 Select one or more members to remove.
2 Select Member > Drop. The Drop Member dialog box displays.
3 Under Change Package, select a change package, if applicable, or create a change

package to link to.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
4 To modify the Drop Member options, click Options. For detailed information on the

Drop Member options, see the online help.

Once a member is dropped from a project, the change is not immediately reflected in
other Sandboxes. Other users must resynchronize their Sandboxes. For more
information on resynchronizing, see Resyncing Members on page 71.
5 To drop the selected member, click OK. To drop multiple members, click OK to All. If you
selected the Confirm Drop option, the Confirm Drop dialog box displays.
6 To drop the selected member(s), click Yes. The project or Sandbox is updated to reflect

the removed member, and the member is removed from the project.
IMPORTANT If change packages are enabled, the Associate Change Package with
dropped member dialog box displays.

To drop a member in the Web interface

1 From a Project view, select the member(s) you want to drop from the project by clicking

the corresponding check box(es).

2 Select Project > Drop Members. The Drop Member dialog box displays.
3 Modify the Drop Member options as necessary. For detailed information on the Drop
Member options, see the online help.
4 To drop the selected member, click OK. To drop multiple members, click OK to All. If you
selected the Confirm Drop option in step 3, the Confirm Drop dialog box displays.
5 To drop the selected member(s), click Yes. The member is dropped from the project. The

project is updated to reflect the dropped member.

IMPORTANT If change packages are enabled, the Associate Change Package with
dropped member dialog box displays. For information on the Change Package field,
see Specifying a Change Package for an Operation on page 118.

61

Chapter 4: Members

Member Operations
Once members have been added to a project, you can check them out to make changes, and
check them in to preserve those changes as a new revision in the members history. You can
also perform actions such as resynchronizing members in your Sandbox with the latest
checked in member revision, renaming members, or adding labels to members. This section
describes the basic operations you perform on members. during development. For
information on working with revisions in a member history, see Working with Member
Histories and Revisions on page 85
This section contains the procedures for:

Selecting Members on page 62

Checking Out a Member on page 63

Viewing and Editing Member Content on page 65

Checking In a Member on page 66

Renaming a Member on page 69

Discarding Changes to a Member on page 70

Resyncing Members on page 71

Locking a Member on page 72

Removing or Downgrading Locks on page 73

Making the Working File Writable on page 73

Viewing Member Locks on page 74

Using Keywords on page 75

Adding Labels to Members on page 78

Deleting Member Labels on page 79

Freezing Members on page 80

Thawing Members on page 81

Selecting Members
The Select command allows you to highlight any members of the current Sandbox or project
that meet specified selection criteria. Members selected with this command can be
manipulated as a group by other MKS Source commands. This command allows you to
instantly select a specific group of members in a project that might contain hundreds or
thousands of members.

62

Member Operations

To select specific members, from a Project or Sandbox view, select View > Select.
You choose selection criteria by selecting a check box. To invert a filter, click the filter a
second time and the ! symbol displays. For example, select members that are not frozen.
If two or more criteria are selected, they can be joined using the Logical AND or Logical OR
option.
For detailed information on the Select Members options, see the online help.

Checking Out a Member

Before you can make changes to a member, you must first check it out. When you check out a
revision, it is copied to a working file where you can view or modify its contents.
Checking out a member extracts the contents of a revision in a member history and copies it to
the working file. You can check out any revision by specifying either its revision number or
label.
If you already have a member checked out, and you have not made any changes to the
member, MKS Source does not perform the checkout a second time. While the checkout
dialog box does appear, the original checkout stands.
In the MKS Source Web interface, when you check out a revision, it is downloaded to a
working file for editing. This occurs because Sandboxes do not exist in the Web interface.
To check out a member in the GUI
1 From a Sandbox view, select one or more members to check out.
2 Select Member > Check Out. The Check Out dialog box displays.
3 Click the desired tab, then modify the checkout options. For additional checkout options,
click Options.

For detailed information on the checkout options, see the online help.
4 Under Change Package, select a change package, if applicable, or create a change

package to link to.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
5 To check out a single selected member, click OK. To check out all selected members, click
OK to All.

If you have made changes to your working file, and then attempt to check out the
member, the Confirm Overwrite Working File dialog box displays. If you want to retain
your changes in the working file, click No (No to All for multiple members). If you want

63

Chapter 4: Members

to compare your working file with the revision you are checking out, click Differences.
To proceed with the check out operation for a member, click Yes (for multiple members,
click Yes to All).
If your working file is based on a different revision, you can merge it with the revision
you are checking out. For more information, see Merging Modified Working Files on
page 100.
The member is checked out for editing, indicated by a padlock icon, the lockers name,
and the date and time of the lock.
The padlock icon indicates the type of lock and any potential conflicts with other lockers.
For a description of the padlock icons, see the MKS Integrity Client 2007 Getting Started
Guide .
To check out a member in the Web interface
1 From a Project or Member History view, select a member to check out by clicking the

corresponding check box.

NOTE In the Web interface, you can check out only one member per operation.
Multiple member selections for checkout cause an error.

2 From the Project view, select Member > Check Out. From the Member History view, select
History > Check Out. The Check Out dialog box displays.
NOTE The Change Package options appear only if change packages are enabled.

3 Click the desired tab, then modify the Check Out options. For detailed information on

the CheckOut options, see the online help.

4 To check out the member, click OK. The File Download dialog box displays.
NOTE Once you reach the file download stage of the checkout operation, if you
cancel the file download the member appears locked in the project. This occurs
because the member is checked out and saved to a temporary location pending your
download options.
To unlock the member, if you cancelled the file download, select the member by
clicking the corresponding check box and then select Member > Unlock.

5 To download the member, select one of the following options:

To open the member in its associated program immediately, select Open this file
from its current location and click OK. The file is automatically sent to a temporary
directory on your system. If the member you are checking out is a program or
application (executable format) the File Download dialog box reappears with the
following options:

64

Member Operations

To run the program immediately, select Run this program from its current
location and click OK.

To save the program to a specified location on your local drive, select Save this
Program to disk and click OK. The Save As dialog box displays. Specify a
location for the program and click Save.

To save the member to a specified location on your local drive, select Save this file to
disk and click OK. The Save As dialog box displays. Specify a location for the
member and click Save.

The member is checked out for editing, indicated by a padlock icon, the lockers name,
and the date and time of the lock.
The padlock icon indicates the type of lock and any potential conflicts with other lockers.
For a description of the padlock icons, see the MKS Integrity Client 2007 Getting Started
Guide .

Viewing and Editing Member Content

You can open a member in your default editor or in the editor associated with the files
extension. To configure your default editor, see the MKS Integrity Client 2007 Getting Started
Guide. In the Web interface, the working file member is opened in a second browser window.
You can view the contents of a member , or you can edit the working file for the member.
To view the contents of a member, in the GUI, select Member > Revision > View Contents or in
the Web, select History > View Revision. When you view the contents of a member,
MKS Source copies it to a read-only temporary file and opens it for you. The temporary file is
not the revision. If you make changes to the file and want to save it, the actual revision is not
modified.
To edit the contents of a members working file, in the GUI, select Member > Edit Working File
or in the Web, select Member > View Member.
When you edit a working file, whether you can edit or just view the contents of the member
depends upon whether you have read-only or read-write access to the member. You must
have a member locked in your name to be able to check it in.
TIP If you know the location of a revision, you can view it by typing the following URL in
a browser:
http://<server>:<port>/si/viewrevision?projectName=
<(sub)projectname>&revision=<revisionnumber>&selection=
<membername>
for example
http://xyzBusiness:7001/si/viewproject?projectName=
c:/master_projects/SourceCode/frameworkproject.pj&revision=
1.4&selection=setup.ksh

65

Chapter 4: Members

Scanning for Changes

Changes to member information are automatically displayed in the GUI in the Sandbox
view. You can also use the Scan for Changes feature to display changes if the client is offline
from the MKS Integrity Server or if you need to see changes to working file information on
your local drive.
To scan a Sandbox for changes in the GUI, from a Sandbox view, select View > Refresh. The
Sandbox view displays members whose working file has changed (indicated by working file
deltas), or a message informing you there are newer revisions available in the member
history (indicated by member deltas).

Checking In a Member
When you are satisfied with the changes you made to a member, you should check in the
member to preserve those changes as a new revision in the members history. Members
should be checked in on a regular basis.
Checking in a member creates a new revision of a member and adds it to the member history.
When a member is checked in to a revision other than the head revision or a branch tip
revision, a new branch is created.
Interface

Procedure

GUI

From a Sandbox view, select one or more members to check in, and
then select Member > Check In.

Web

From a Project or Member History view, select a member to check in

by clicking the corresponding check box. From the Project view, select
Member > Check In. From the Member History view, select History >
Check In.
Note: In the Web interface, you can check in only one member per
operation. Multiple member selections for check in cause an error.

NOTE If you are using a file system repository, the maximum size for members is
2 GB; if you are using a database repository, the maximum size is 2 GB for Oracle or
SQL Server, and 1 GB for DB2. To find out the type of repository used on your
server, see your administrator.

In the GUI, you can click the Differences button on the Check In dialog box to view the
differences between your working file and the revision you checked out.
For detailed information on the Check In options, see the online help.

66

Member Operations

Resychronizing Before Checking In

If you use a non-exclusive locking policy, other users besides yourself may have the same
revision checked out. If another user checks in their changes first, they get the next sequential
revision on the current branch (if the revision is the tip of the current branch). When you try
to check in your changes, you are prompted to resync and merge the previously committed
changes into your working file before you can complete the check in. For more information
on your locks policy, contact your administrator.

Assigning Revision Descriptions

A revision description is text that becomes a permanent part of the archives metadata. It allows
you to provide a record of the changes you made and why you made them. This can be of
great value to you or other team members if it ever becomes necessary to revise or update the
member.
Once a new revision is checked in, its revision description cannot be changed. You can,
however, append new information to a revision description.
If your administrator has set the feature for enforced revision descriptions, you must enter a
revision description.

Using Change Packages

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118. For information on creating a change package, see Creating a
Change Package on page 117. If change package reviews are mandatory, a pending revision
is created when the change package is submitted. For more information, see Working With
Pending Revisions on page 94.

Updating the Member Revision

You can use the Update Member Revision option when you are checking in a member to
ensure the most recent revision of each member is added to the list of members in the project.
If the option is not enabled, the project list might not reflect the most current revision of each
members history. For example, if the current project member is revision 2.7 of an archived
file, but a newer revision 2.8 has been added to the members history, you can update the
member to the new revision.

Assigning Revision Numbers

By default, when you check in a member, MKS Source automatically assigns a unique
revision number to the new revision. It does this by incrementing the current revision
number by one. For example, if the previous revision is 1.3, the new revision is assigned
number 1.4. For best practices, MKS recommends letting MKS Source generate revision
numbers for youdo not use revision numbers to record milestones (use labels or
checkpoints). The ability to specify a specific revision number is supported for legacy
purposes, but is not recommended.

67

Chapter 4: Members

You can choose the revision number of the changes you are checking in, so long as your
revision number:

is greater than the last revision number (you cannot use previously skipped revision
numbers)

has no leading zeros (zeros as complete revision numbers are acceptable)

starts a new branch based on an existing revision (optional)

If you check in a revision using an already existing revision number, MKS Source attempts to
add one to the revision number and check it in as that revision. If that revision already exists,
MKS Source then chooses the next available branch number and creates a new branch.
For example, if you are checking in a new revision to an archive where the head revision is
1.7, the following numbers are valid:

1.8 (greater than head revision)if you check in a revision as 1.7, which already exists,
MKS Source assigns it 1.8

1.10 (greater than head revision)

1.72 (none of the numbers between 7 and 72 may be used afterwards)

2.0

1.7.1.1 (if it starts a new branch)

1.7.0.1 (leading zero as the branch number)

The following numbers are invalid:

1.3 even if there was no revision 1.3 previously (MKS Source branches the archive and
assigns 1.3.x.1, where x is the first available branch number)

1.08 (leading 0 in last portion)

02.1 is considered the same as 2.1 (leading zero in branch number)

Starting a Branch When Checking In a Member

MKS Source usually places a new revision at the top of the main trunk. There are times,
however, when you do not want your work to be checked into the trunk. You may be
pursuing a line of development that will not be included in the finished product, or you may
be doing post-release maintenance while development for the next release continues on the
trunk. Divergent lines of development in the same archive are managed through the use of
branches. For information on branching, see Branching and Merging Members on page 98.

Deferring a Check In
In some situations, you cannot check in a member. For example, you cannot check in a
member if:

68

there are revision conflicts on the member that you dont yet want to resynchronize

Member Operations

there is an exclusive lock held by another user on the member revision and you dont
want to force the creation of a new branch

the member revision is frozen

When you cannot check in a member, but still want to record information about the check in
(for example, the revision description), you can defer the check in.
When a revision conflict occurs on a check in, a deferred check in is created automatically. In
other situations, you can select the Defer Check In option.

Specifying a Source File in the Web Interface

In the MKS Source Web interface, because Sandboxes do not exist, you specify a source file
(working file) for the member, which is checked in as the new revision.
If the name of the source file you specify is different than the member name, depending on
how you have the Different Member/Source File Name option set, one of the following occurs:

MKS Source confirms if you want to proceed. Click Yes if you want to check in a source
file different from the member.

MKS Source cancels the checkin operation because the file names do not match.

The member is checked in.

Renaming a Member
When you need to change the name of a file in your project, for example, the title of a user
guide, you can rename the member while working from a Project or Sandbox view.
Renaming a member performs a drop of the old member name, and an add of the new
member name and creates a new revision in the archive, then copies the attributes from the
old member name to the new member name.
The members archive remains the same and points to the old member name so that change
packages, member histories, and project histories continue to work.
To rename a member in the GUI, select the member you want to rename, and then select
Member > Rename.
NOTE

Because renaming a member affects other users on the same development path,
the member you want to rename must not be locked by any other user.

The new name must be in the same directory as the existing old name. To move a
member into a new directory, use the Move Members command. For more
information, see Moving Members on page 57.

69

Chapter 4: Members

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118. For information on creating a change package, see Creating a
Change Package on page 117.
For detailed information on the Rename Member options, see the online help.

Renaming a Member That Is the Tip Revision

The tip revision is the most recent revision on a branch in a history.
When you rename an unlocked member, MKS Source places a lock on that member and
creates a new, unlocked revision at the tip. For example, if you rename an unlocked member
(1.3), MKS Source locks revision 1.3 and checks in a duplicate file for revision 1.4 with the
new member name, leaving 1.4 unlocked.
If you rename a locked member, MKS Source performs the rename operation and retains
your lock. For example, if you rename a locked revision (1.3), MKS Source performs the
rename by checking in a duplicate file for 1.4 and then moves your lock to revision 1.4.
If you rename a member in a variant project while you also have the member locked in the
master project, MKS Source performs the rename operation but moves your lock to the
variant member.

Renaming Members on a Branch

If you rename a member that is not the tip revision, that is, a revision along the branch,
MKS Source creates a duplicate of that revision along a new branch and updates the member
revision to that branch.

Discarding Changes to a Member

If you are sure you do not want to check in a members modified working file, you can revert
it to its state before it was checked out. This is useful if youaccidentally or purposefully
save changes that you do not want to keep.
Reverting a member discards any changes made to the working file since it was checked out,
and then unlocks the revision.
NOTE If the revision you have locked is not the revision the working file is based on,
then the lock is retained.

When you revert a deferred add operation, MKS Source retains the working file in your
Sandbox. After the revert operation, the file becomes a non-member, rather than a former
member, because it was never added to the project.

70

Member Operations

To discard changes to a members working file in the GUI

1 From a Sandbox view, select one or more members that are checked out in your name or

are modified.
2 Select Member > Revert.

If you have made changes to your working file, the Confirm Overwrite Working File
dialog box displays. If you want to retain your changes in the working file, click No (No
to All for multiple members). If you want to compare your working file with the revision
you are reverting it to, click Differences. To proceed with the revert operation for a
member, click Yes (for multiple members, click Yes to All).
The member is reverted to its original state prior to checkout.

Resyncing Members
When many users are working from Sandboxes based on the same master project, it is
common for the members in an individual Sandbox to become out of sync with the member
revisions in the project. For example, the member revision of a particular file may be at 1.5,
while you still have revision 1.2 in your Sandbox.
When this happens, a member delta symbol ( ) displays next to the member in the Sandbox
view, signaling its status.
To update out of sync working files to the most current member revisions, you resynchronize
the members.
For information on resyncing members with deferred operations, see Resyncing Members
With Deferred Operations on page 84.
CAUTION Resynchronizing members can overwrite files, even ones that you have
locked and that have changed since you last checked them out. Be certain of your
response to any prompts indicating that the files will be overwrittenonce
replaced, you cannot get back your changes. If files have been dropped from a
project, resynchronizing deletes them.

If the revision that your working file is based on is locked by you, your lock is automatically
moved to the member revision before the resync proceeds. If you had an exclusive lock on
the working revision, and another user already has an exclusive lock on the member revision,
you are prompted to downgrade your lock to non-exclusive.
If you are working in a sparse Sandbox, resynching deletes your working file, unless the
revision that it is based on is locked by you.
When working in your Sandbox, you can also use the Resynchronize By Change Package
command. When you select a member and use Resynchronize By Change Package,
MKS Source automatically searches the change package associated with the member you are

71

Chapter 4: Members

resynchronizing and then brings all of the changes recorded in the change package from the
project to your Sandbox. For more information on resynchronizing by change package, see
Using the Resync By CP Command on page 164.
To resynchronize a member in the GUI
1 From a Sandbox view, select one or more members that contain member deltas( ).
2 Select Member > Resynchronize.

If you have made changes to your working file (without a lock), and then attempt to
resynchronize the member, the Confirm Overwrite Working File dialog box displays. If
you want to retain your changes in the working file, click No (No to All for multiple
members). If you want to compare your working file with the revision you are
resynchronizing it with, click Differences. To resynchronize the member by overwriting
the working file, click Yes (for multiple members, click Yes to All).
You can also merge your working file with the revision you are resynchronizing it with.
For more information, see Merging Modified Working Files on page 100.
The selected member is updated.

Locking a Member
A lock is a feature of MKS Source that controls how changes are made to revisions. When a
change is checked in, it requires the revision being updated to be locked, in order to prevent
more than one user from simultaneously checking in changes to the same revision.
Normally you lock a member during a checkout. Sometimes, however, you may have made
changes to a working file that was not checked out in your name first. In this case, you can set
a lock without overriding your changes.
To lock a member, select the member or revision in the GUI, then select Member > Locks >
Lock.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118. For information on creating a change package, see Creating a
Change Package on page 117.
For detailed information on the Lock Revision options, see the online help.
The person who has a revision locked is referred to as the locker.
To upgrade your lock from a non-exclusive lock to an exclusive lock, see Viewing Member
Locks on page 74. For information on your locks policy, contact your administrator.

72

Member Operations

Removing or Downgrading Locks

When you no longer need the exclusive ability to change a member, you can unlock it. The
main reason to unlock a member is to abandon work on the member, in which case you can
use the Revert command (see Discarding Changes to a Member on page 70). In views
where there is no Sandbox context for the member you are unlocking, you can use the
Remove My Lock command.
You can downgrade your exclusive lock to a non-exclusive lock, in order to enable another
user to get the exclusive lock. Depending on the permissions your administrator has defined,
you may also be able to downgrade another users exclusive lock to a non-exclusive lock, in
order to be able to give yourself an exclusive lock. To remove locks for another user, see
Viewing Member Locks on page 74. For information on permissions and on your locks
policy, contact your administrator.
Operation

Procedure

To unlock a member in a Sandbox in the GUI

Select Member > Revert

To unlock a member in the GUI interface when

there is no Sandbox context

Select Member > Locks > Remove My Lock

To unlock a member in the Web interface

Select Member > Remove My Lock

To downgrade an exclusive lock on a member

in the GUI

Select Member > Downgrade Lock

To downgrade an exclusive lock on a member

in the GUI when there is no Sandbox context

Select Member > Locks > Downgrade

To downgrade an exclusive lock on a member

in the Web interface

Select Member > Downgrade Exclusive Lock

Making the Working File Writable

If you want to edit a file locked by someone else, and you have no intention of checking the
files back in, you can make the working file writable.
In the GUI, you can make your working file writable during the checkout process or from a
Sandbox view.
Select a member or revision in the Sandbox view and select Member > Make Working File
Writable.
In the Web interface, you can make your working file writable during the checkout process.

73

Chapter 4: Members

Viewing Member Locks

You can view a list of all of the members you have locked across all projects, even projects
that you no longer have permissions to access. You can then remove unused locks,
downgrade exclusive locks to non-exclusive locks, or upgrade non-exclusive lock to
exclusive locks.
You can also view a list of all the members that another user has locked, as long as they are in
projects that you have permission to view. This is useful if you want to know what files a
specific user is working on. Depending on the permissions defined by your administrator,
you may be able to downgrade or remove locks for another user.
Operation

Procedure

To view member locks in the GUI

Select Member > Locks > View. The Locks view

displays.

To view member locks in the Web interface

Select Tools > Manage My Locks. The Locks

view displays.

To upgrade a non-exclusive lock to an exclusive

lock in the GUI

Select an item in the Locks view, and then select

To upgrade a non-exclusive lock to an exclusive

lock in the Web

Select an item in the Locks view, and then select

To remove another users lock in the GUI

Select an item in the Locks view, and then select

Member > Locks > Upgrade My Lock.

Locks > Upgrade My Lock.
Member > Locks > Remove Lock.

To remove another users lock in the Web

interface

Select an item in the Locks view, and then select

To change the user whose locks are displayed in

the Locks view (GUI only)

From the Locks view, select View > Change

User. For details on how to select users, see the
MKS Integrity Client 2007 Getting Started
Guide.

To find another users locks (GUI only)

Select Member > Find > Locks. For details on

how to select users, see the MKS Integrity Client
2007 Getting Started Guide.

Locks > Remove Lock.

NOTE
You may only view other users locks that are in projects you have permission to
view. You can always view your locks for any project regardless of project
permissions.
You cannot remove another users lock on a member that was locked from a shared
subproject.

For detailed information on the Locks view columns, see the online help.

74

Member Operations

Using Keywords
A keyword is a placeholder that can be inserted into text-based working files. This placeholder
is a special variable (for example, $Date$, $Author$, $State$) used to represent textual
information in a working file. Keywords can be expanded (that is, replaced with their literal
values) when a revision is checked out.
To use a keyword, simply include it in a working file, surrounded by dollar signs (for
example, $Date$) and check the file back into its archive.
NOTE Your administrator may define custom keywords for your use. For
information about these keywords, see your administrator or the MKS Integrity
Server 2007 Administration Guide.

The next time you check out the revision, MKS Source scans it for keywords and replaces
them with the appropriate information, if keyword expansion is turned on.
Keyword expansion is the process of automatically adding or updating information to a
keyword reference when a revision is checked out or viewed.
For example, if the $Date$ keyword is encountered, the date and time of the revision
(assigned at check in) is added to the working file as part of the keyword. When expanded,
the entry would look something like
$Date: 2005/06/12 10:25:32$

This method of adding or updating information in a keyword is called keyword expansion.

For example, if the member main.c has the keywords $Author$ and $State$ embedded
within it, checking out main.c and issuing the command:
ident main.c

returns
main.c:
$author: paula_t $
$state: Exp $

The following MKS Source commands contain keyword expansion options:

Add Members

Check Out

Check In

Resynchronize

Revert Member

75

Chapter 4: Members

Keyword expansion is configured using the Preferences dialog box in the GUI. The dialog
boxes in the GUI can override the default settings. For information on setting command
preferences, seethe MKS Integrity Client 2007 Getting Started Guide.
NOTE Keyword expansion applies to text files only. It is disabled for binary files.

Text before and after the keyword is preserved, making it suitable for use within expressions,
as above, and within comments.
If keyword expansion is enabled and you are checking out a text file that contains the string
$Revision$

MKS Source, when it encounters this string, automatically adds the value of the keyword
$Revision$ in the format
$Revision: value $

where
value is the appropriate value of the keyword (in this case, the revision number).
For example, including the statement
char revnum[] = "$Revision$";

in a C source file creates a character string named revnum containing the files revision
number. The program can then be configured to display this string when it starts up,
automatically presenting the current revision of the programs source file.
Using the $Revision$ keyword to obtain the revision number of a file is one of the common
applications of keywords. Other common applications include:

The $Header$ keyword provides a one-line summary of useful information associated

with a revision. Including this information in a comment makes the information
available to anyone looking at the member.

The $Log$ keyword supplies the same sort of information as $Header$ plus the revision
description. The $Log$ keyword provides a complete list of changes that are made to the
member over time.
NOTE The keyword format of $<keyword>$ causes MKS Source to replace between
the first $ and the next $. If you use a keyword in the format $<keyword>,
MKS Source continues to replace until it encounters another $. It is possible that
MKS Source may not encounter another $ until the file is checked out again. This
type of keyword use returns results that are similar to logging.

76

Member Operations

Example
Chad wants to see information about the member he is editing as a comment in the file. Chad
can do this through keywords. He decides to use the $Log$ keyword. Chad sets his
preferences to enable keyword expansion on checking out a member. He then places the
keyword in a member.

Locating Keywords
You can use the ident command in the command line interface to locate and display
keywords (expanded or unexpanded) in one or more members. For more information about
the ident command, see the MKS Source 2007 CLI Reference Guide or the online man pages.
This command displays the name of each member that contains keywords, as well as the
keywords themselves. This provides an easy way to extract identification information from
source files, as well as compiled object files.

Table of Keywords
MKS Source maintains several keywords that can be used in working files. Keywords are
case-sensitive.
Your administrator may create custom keywords. For information on using custom
keywords contact your administrator.
The following table describes default keywords and what each expands to.
Keyword

Expands To

$Author$

The name of the user who checked in the revision.

$CompanyInfo$

The name of the company and/or other company info including

address, E-mail and phone numbers.
You must enter a keyword policy for the company information that
you want displayed. Strings may contain standard escapes like
\n for new lines, but must be in ISO-646. For information on
setting keyword policies, see the MKS Integrity Server 2007
Administration Guide.

$Date$

The checkin date and time of the revision (as assigned at

checkin). The time is shown in Greenwich Mean Time (GMT/ or
Coordinated Universal Time).

$Header$

The file name of the archive, as well as the revision number, date
and time, author, state, and the user who has an exclusive lock (if
any).

$Id$

The same as $Header$, except that only the file name of the
archive is displayed, not the full path.

$Locker$

The user ID of the user who has an exclusive lock on the revision,
and the date and time that it was locked (empty if no exclusive
lock).

77

Chapter 4: Members

Keyword

Expands To

$Log$

The revision description supplied during checkin, preceded by the

archives member name, revision number, author, and revision
date.
Repeated checkout operations append revision descriptions,
rather than replacing existing ones.
Note: this keyword does not unexpand.

$Name$

The revision label (or labels) attached to a revision.

$ProjectLabel$

The label (or labels) associated with the checkpoint of the build
project the Sandbox is based on.
The $ProjectLabel$ keyword can only be used when the
Sandbox corresponds to a build project that has a label. If there
are multiple labels associated with the selected build project
checkpoint, the $ProjectLabel$ keyword uses a spaceseparated list of labels in alphabetical order.

$ProjectName$

The fully qualified name of the project of which the archive is a

member.

$ProjectRevision$

The revision number of the project that the archive is related. For
use in build Sandboxes only.

$ProjectSetting attribute$

The current value of the attribute defined in MKS Source. For

example, if the project contains set OS=unix, the keyword
$Setting OS$ is expanded to $Setting OS: unix$

$RCSfile$

The archives unqualified member name.

$Revision$

The revision number.

$SandboxSetting attribute$

The current value of the attribute defined in MKS Source. For

example, if the Sandbox contains set OS=unix, the keyword
$Setting OS$ is expanded to $Setting OS: unix$

$Setting attribute$

The current value of the attribute defined in MKS Source. For

example, if the member contains set OS=nt, the keyword
$Setting OS$ is expanded to $Setting: nt$.

$Source$

The same as $RCSfile$. The archives unqualified name.

$State$

The state setting of the revision. States are defined by your

administrator.

Adding Labels to Members

A revision label is a textual name that describes and refers to a revision. When a member is
checked in, you are given the option of assigning it a revision label. Labels can be based on
the product release the revision was included in, on the content of the revision, on changes
made to the revision, or any other sort of information that would be useful in identifying that
particular revision. Revisions in a history can be displayed and selected either by revision
number or revision label.

78

Member Operations

Labels cannot contain colons (:), square brackets ([ ]), leading spaces, numbers in the same
format as a valid revision number (1.23), or numbers without any spaces (14325). Numbers
that contain spaces are acceptable, for example, 2432 1234.
Although you generally add a label to a new revision upon check in, there may be times
when you want to add an additional label or change the label assigned to a revision. For
example, you might want to label each member in a project when you checkpoint the project.
NOTE In the Web interface, MKS Source displays up to three member labels in the
Labels column of the Project view. If a member has more than three labels,
MKS Source displays a link ( ) that you can click to view all the member labels.
Labels appear in alphabetical order in selection lists.
Interface

Procedure

GUI

Select Member > Properties > Add Label

Web

Select Member > Add Label

If the label you are adding already exists on another revision, click Options, and select the
Move Existing Label option.
TIP You can also add labels to the member in the Member Information dialog box or
Revision Information dialog box.

Deleting Member Labels

Sometimes you may want to delete a member label. For instance, you may decide the label no
longer accurately reflects that particular revision. In addition, if you have assigned the same
label to a number of members, you might want to remove them all with one command.
Interface

Procedure

GUI

Select Member > Properties > Delete Label. In the Delete Label dialog
box, select a label to delete from the Label list.

Web

Select Member > Delete Label. In the Delete Label dialog box, select a
label to delete from the Label list.

TIP You can also delete a members labels in the Member Information or Revision
Information dialog box.

79

Chapter 4: Members

Freezing Members
When your development team has largely finished a portion of a project and some project
members are in a stable state, you can freeze individual members within a project or
Sandbox.
Freezing a member places it in a state that prevents changes from being made to the member
information that resides in the project file. For example, you cannot update the member
revision or change the attributes of a frozen member. Freezing is the opposite of thawing a
member.
Freezing restricts member information from being updated, preventing these members from
being changed by accident. However, development work can still continue in the member file
itself. For example, if new revisions are checked into the members archive, MKS Source does
not update the member revision for the project.
Freezing is useful for facilitating:

project checkpointing

member promotion

software distribution

Freezing prevents changes to member information in the project, but does not affect the
member file itself. Revisions can still be checked out, modified, and checked in, but none of
the changes are included as part of the member information in the project.
You can change the label or state of frozen members, but not their attributes. Freezing can be
used immediately before a checkpoint operation to ensure no one changes the project or its
members before the checkpoint is complete.
When you want to allow project members to be changed, you can thaw them (see Thawing
Members on page 81).
If a member is frozen, MKS Source reports the availability of new revisions when anyone
checks them into the archive. MKS Source does not update the project to the latest revision,
so an appropriate person must make the decision to thaw the member and update the project
as a whole.

80

Interface

Procedure

GUI

Select Member > Properties > Freeze.

Web

Select Member > Freeze.

Member Operations

Example
A sample freezing sequence is as follows:

Working with the Apex.pj project, a release engineer freezes project member
utility.dll at revision 1.2.

The snowflake symbol displays beside utility.dll, revision 1.2 in the Apex.pj
Project view. (The snowflake symbol displays only in the context of the project.)

A developer checks out utility.dll, revision 1.2, modifies it, and checks it back in.

The new version of utility.dll is not accessible to the Apex.pj project until revision
1.2 is thawed.

Thawing Members
When you decide to allow project members to evolve again, you can thaw any frozen ones.
Thawing a member removes the restriction on changing member information in the project
and makes previously checked in member information available to the project. Thawing a
member is the opposite of freezing a member.
Interface

Procedure

GUI

Select Member > Properties > Thaw.

Web

Select Member > Thaw.

Example
A sample thawing sequence is as follows:

As part of the development cycle of the Apex.pj project, the release engineer freezes the
file utility.dll, revision 1.2.

A developer checks out utility.dll, revision 1.2, modifies it, and checks it back in.
The new version of utility.dll (that is, version 1.3) is not accessible to the Apex.pj
project until revision 1.2 is thawed.

The release engineer thaws utility.dll, revision 1.2. Thawing revision 1.2 of
utility.dll makes the changes available to the Apex.pj project. MKS Source notifies
that a newer revision of utility.dll (version 1.3) is available to the project.

Once the developers modifications are reviewed and accepted, the release engineer
incorporates the modifications by choosing Member > Properties > Update Revision in
the GUI or Member > Update Revision in the Web interface. MKS Source updates
Apex.pj to include the modifications previously checked in by the developer.

Revision 1.3 becomes the head revision for the project member utility.dll.

81

Chapter 4: Members

Deferring Member Operations

For certain operations in MKS Source, you can defer the completion of the command until a
later time. The defer option allows you to see the effect of the operation in your Sandbox
without affecting the project. The deferral of operations is provided as a selectable option in
two ways: through the GUI and in the command line interface as the --defer option.
You can apply the defer option to the following operations:

Adding Members to a Project on page 51

Adding Members From Archive to a Project on page 53

Moving Members on page 57

Dropping Members From a Project on page 60

Checking In a Member on page 66

Renaming a Member on page 69

Importing Members on page 55

Viewing an Annotated Revision on page 92

TIP You can apply the Deferred Items filter to display any members that are
associated with deferred operations. For more information on using the Deferred
Items filter, see the MKS Integrity Client 2007 Getting Started Guide.

A deferred member is a member that is associated with any deferred operation (add, drop,
checkin, rename, move, import, add from archive, update revision). A deferred member
displays in the Sandbox, but the deferred operation is not shown in the project until the
deferred operation is submitted.
Deferred operations are visible only from the client-side Sandbox and are seen in the project
only when they are submitted. It is important to note that deferred operations can be added
to a change package and then submitted as a group of changes, but the deferred operations
do not appear on the MKS Integrity Server until they are submitted to the project. For more
information, see Submitting Change Packages on page 125.
With the exception of deferred rename, move, and checkin operations, MKS Source supports
only single deferred operations on a member. If you try to perform multiple deferred
operations on a single member, MKS Source reports an error.
NOTE Once you have specified a deferred operation on a member, MKS Source does
not allow any further operations that would cause that member to be modified.

82

Deferring Member Operations

You can simultaneously defer rename, move and/or checkin operations on a single member.
When these deferred operations are submitted, MKS Source first performs the checkin
operation followed by the rename operation, then the move operation. The sequence for
performing these operations is set by default and is not configurable.
If change package reviews are mandatory, ensure that the deferred option is enabled in
command dialog boxes, or MKS Source creates pending entries (and if necessary pending
revisions) at the time the command operation is completed rather than when the associated
change package is submitted. For more information, see Change Package Reviews
Overview on page 128.

Example
Chad is assigned to change the current savings calculator menu image to match the other
menu images. To do this, he needs to drop the current image and add a new one. Chad uses a
deferred add and drop because he does not want to commit his changes until he finishes unit
testing his modifications.

Submitting Deferred Operations

To submit, or complete, a deferred operation, you use the Member > Submit Deferred
command. Submitting the operation completes the command and makes it visible in the
associated project.
IMPORTANT If exclusive locking is enabled, you cannot submit a member with a
deferred check in operation if you do not have a lock on the member. You must
check out or lock the member before submitting the deferred check in operation. For
more information on exclusive locking, see the MKS Integrity Server 2007 Installation
Guide.

By default, the change package that was specified during the deferred operation is used for
the Submit Deferred command To select a different change package or create a change
package, click Options and enable Override the change package to a specified value. For
detailed information on the deferred submit options, see the online help.
If change package reviews are mandatory, you do not need to submit deferred operations
prior to submitting the change package. For more information, see Submitting Change
Packages on page 125 and Change Package Reviews Overview on page 128.

Example
Chad completed his unit testing of the savings calculator with the new image. He can now
submit his deferred drop and add of the image files.

83

Chapter 4: Members

Canceling Deferred Operations

Once you defer an operation, you must use the Member > Revert command to cancel the defer
operation. For more information on the revert command, see Discarding Changes to a
Member on page 70.
When you revert a deferred add operation, MKS Source retains the working file for the
deferred member. After the revert operation, the file becomes a non-member, rather than a
former member, because it was never added to the project.

Resyncing Members With Deferred Operations

When you resynchronize a member associated with a deferred operation, MKS Source
performs the following deferred operations:

Deferred Add

When resynchronizing a member associated with a deferred add, MKS Source does not
make any changes to the working file.

Deferred Drop

When resynchronizing a member associated with a deferred drop, where the working
file is modified, MKS Source asks you if you want to overwrite the existing working file.

Deferred Rename

When resynchronizing a member associated with a deferred rename, MKS Source asks
you if you want to overwrite the existing working file. If the new working file is missing,
MKS Source resynchronizes it. The working file with the old name is then deleted from
the Sandbox.

Deferred Move

When resynchronizing a member associated with a deferred move, MKS Source informs
you that there is a deferred operation on the member and asks you if you want to
proceed. MKS Source then resynchronizes the working file to the version in the project
and in the new location. The deferred indicator remains after the resync completes.

Deferred Checkin

When resynchronizing a member associated with a deferred checkin, MKS Source asks
you if you want to overwrite the existing working file to correspond to the member
revision.

Deferred Update Revision

When resynchronizing a member associated with a deferred update revision,

MKS Source asks you if you want to overwrite the existing working file.

84

Working with Member Histories and Revisions

Deferred Import

When resynchronizing a member associated with a deferred import, MKS Source asks
you if you want to delete the existing working file.
For additional information on resyncing members, see Resyncing Members on page 71.

Working with Member Histories and Revisions

When you make changes to a member and check it back in, your changes are automatically
added to the member history as a revision.
A revision is a version of a file and is contained in a history. A new revision is produced in the
history each time a working file is checked in.
Each revision is assigned a unique revision number used to identify a revision in a history.
Revisions on the mainline are numbered as two-part decimals (such as, 1.1, 1.2, 1.3, 1.4, ).
Revisions on a branch are numbered by adding two-part decimals to the number of the
revision they branch from. For example, if a branch is started from revision 1.3, its revisions
would be numbered 1.3.1.1, 1.3.1.2, 1.3.1.3, and so on.
This section describes how to view member histories and work with revisions.
This section provides information on the following procedures:

Viewing a Member History on page 85

Updating a Member Revision on page 90

Setting a Member Rule on page 91

Deleting a Revision on page 91

Viewing an Annotated Revision on page 92

Working With Pending Revisions on page 94

Viewing a Member History

MKS Source maintains detailed information about each revision in the member history. In
the GUI, revision information displays in the Member History view.
Interface

Procedure

GUI

Select Member > Views > View History

Web

Select Member > View Member History

You can also view and modify revision information through the Revision Information view.

85

Chapter 4: Members

MKS Source maintains an archive of all the changes made to a member since it was put under
revision control.
An archive is a file containing the history of a member (a record of all the changes made to it
since it was put under revision control). From the information contained in the history,
MKS Source can reconstruct any previous version of the member.
MKS Source maintains historical information called archive information. This information
includes revision labels, users who have locks on revisions in the archive, the starting point of
the default branch revision, the data type (text or binary), whether the archive is compressed,
whether exclusive locking applies to the archive, and a description of the archive.
You can view and modify archive information through the Archive Information view. For
more information on this view, see the online help.

Working With the Member History View

By default, the member history view displays two panels: a panel showing the path of
development, and a panel showing details for a selected revision. In order for information to
display in the details panel, you must select a checkpoint in the GUI or click a checkpoint
number in the Revision column in the Web interface.
In the GUI, you can toggle between a graphical view and a list view by by clicking View > List
or View > Graphical.

86

Working with Member Histories and Revisions

Graphical Member History view

The information in the graphical view shows the path of development from revision to
revision, including branches and merge lines. You can change the information that displays
for each revision by selecting View > Show beside each node. If summary information is not
displayed in the view, it displays in a tooltip when you place your mouse pointer on a
specific revision.

87

Chapter 4: Members

List Member History view

The information in the list view is displayed in columns. For more information on the default
columns, see the online help.
The details panel in the graphical or list view displays additional details for a selected
revision. You can turn the display of this panel on or off using the View > Show Details
option. The following information can display in the member history details.

88

Field

Description

Revision

Revision number of the member.

Author

User who checked in the revision.

Date

Date the revision was created.

Change Package

Change package associated with the revision.

State

State of the revision. States are defined by your

administrator.

Revision Description

Brief description of the revision.

Working with Member Histories and Revisions

Field

Description

Locked By

All locks on the selected revision, including

information for each lock. Each lock is listed
separately, with the exclusive lock (if any) listed
first, followed by all other locks, sorted by
timestamp (newest first).
Note: The list of locks includes any that exist
outside the project and development path
context of the selected revision.

Member Revision

The project and development path that the

revision is the member revision in.
Note: If a revision is member revision in a shared
subproject, only the original project path is
displayed. Any projects where the subproject
was added as shared are not displayed.

Only projects that you have the OpenProject

permission for display.
Note: Member revision information is not
supported for an RCS type repository.

The maximum number of projects displayed is

controlled by the server limit, which is set at 5000
by default. Administrators can change the default
limit. If the number of projects exceeds the set
limit, MKS Source displays a message indicating
that there are too many results to display in the
view.

Filtering a Member History in the GUI

You can use the revision filter in the GUI to display any revisions of the selected member that
meet specified selection criteria. You can change the filter by selecting View > Change Filter.
This allows you to display a specific group of revisions for a member that might have
hundreds or thousands of revisions. Revisions selected with this command can be
manipulated as a group by other MKS Source commands. You can apply filters to a member
history in either the graphical history view or the list view.
Even with filtering, the number of revisions displayed can be too large to work with. By
default, a maximum of 200 trunk revisions are displayed (the revisions branched from these
trunk revisions are also displayed). You can change the maximum by selecting View >
Maximum trunk revisions. The number of revisions displayed is calculated based on the
number of visible mainline revisions; branched revisions are not included in the count.

Selecting Filter Criteria

You choose the selection criteria you want to use by selecting one or more check boxes in the
Filter Revisions dialog box, specifying filter values where required. For detailed information
on the Filter Revisions options, see the online help.

89

Chapter 4: Members

To invert a filter, click the filter a second time and the ! symbol displays. You would invert a
filter if you wanted to display, for example, revisions that are not locked.
If you choose more than one selection criteria, select whether the criteria should be combined
using a Logical AND or a Logical OR.

Updating a Member Revision

You can update a member revision without checking in a member by using the Update
Revision command.

The member revision is the default revision that users work with in all other Sandboxes. For
example, if demoapp.c 1.1 is the member revision, setting 1.2 as the member revision
makes it the default revision in all Sandboxes.
You can update the member revision to a pre-selected or pre-defined revision. This is useful
when you want the member revisions in a project to reflect revisions based on a symbolic
location in the development path (working file, head revision, trunk tip, or member branch
tip), property (state, label, or timestamp), current project configuration, or external project
configuration.
Interface

Procedure

GUI

Select Member > Update Member Revision.

Web

Select Member > Update Revision.

NOTE You cannot update a frozen member revision. You must first thaw the
member revision and then update it. For information on thawing members, see
Thawing Members on page 81.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118. For information on creating a change package, see Creating a
Change Package on page 117.
For detailed information on the Set Member Revision dialog box, see the online help .

Example
Code freeze has been reached on the stock calculator, and Steve has frozen all of the members
in that project. When all the project members are frozen, Quality Assurance tests the code. In
this case, they have found a bug in the stock calculator. Steve must now incorporate the fix
into the project by thawing the member revision, updating it to the head revision, and
freezing it again.

90

Working with Member Histories and Revisions

Setting a Member Rule

A member rule is a revisiontypically a symbolic revisionattached to a member. You can
use it with any command that allows you to specify a revision based on the member rule.
In the GUI, only the Check Out and Update Member Revision commands allow you to specify
a revision based on the rule defined for the member.
You can set a member rule to specify a revision based on a symbolic location in the
development path (working file, head revision, trunk tip, or member branch tip), property
(state, label, or timestamp), current project configuration, or external project configuration.
For example, if you wanted to share members in project A with project B without using
shared subprojects, you could apply a member rule to members in project B that links them to
the corresponding members in project A. Then, you would update the members in project B
by using the Update Member Revision command with the member rule.
To set a member rule, select Member > Properties > Set Member Rule. For detailed
information on the Set Member Rule dialog box, see the online help.
After you create a rule for a member, you can also view and edit the rule in the Member
Information view.
NOTE To create a rule, you require the ModifyMemberRule permission.

Using a Rule to Update a Member Revision in Another Project Configuration

By design, applying a rule to update a member revision does not dynamically update the
corresponding member revision in another project configuration. For example, if the member
revision for member_1 is updated in project_A, the corresponding member revision in a
variant of project_A with the rule configured to link to project_A is not updated with the
same member revision.
To update the corresponding member in the variant according to the member rule, you can
use the Update Member Revision command with the member rule, or your administrator can
configure the ClientLink.js sample event trigger script that enables dynamic updating of
linked member revisions under certain conditions. For more information, contact your
administrator.

Deleting a Revision
If you know you will never use a revision again, you can delete it, provided it is not a
pending revision associated with a change package in a state other than Closed or
Discarded, or if change packages are mandatory. For more information, see Working With
Pending Revisions on page 94 and Change Package Reviews Overview on page 128.

91

Chapter 4: Members

CAUTION Only delete a revision when you are certain you will never need it again.
Once you delete a revision, it cannot be retrieved. Any historical checkpoints based
on a particular revision become invalid if that revision is deleted. A revision cannot
be deleted if it is the starting point (root) of a branch. You should never delete the
head revision of an archive.

To delete a revision in the GUI, select a revision from a Member History view and select
Member > Revision > Delete.
NOTE Any existing locks on revisions are removed when those revisions are
deleted.

CAUTION If you are using a database type repository, by default MKS Source
determines if the revision exists in other locations. If the revision is used in other
projects, MKS Source warns you that deleting the selected revision will break the
listed items.

Viewing an Annotated Revision

MKS Source provides an annotated revision view for revisions. Use it when you want to find
out which revision introduced a particular change. Rather than searching the content of
revisions in the history one revision at a time, you can see the content and information for all
of the changes to the member in an annotated list.
In annotation blocks, each line of the revision displays with information about the last
modification made to each line of the revisions contents. By default, the annotated revision
list includes the revision number, author, date, line number, and revision contents.
When using the Annotated Revision view:

you can only view an annotation for one member at a time

you must close and then reopen the view to see subsequent updates to the member

only content that was added or changed on a per revision basis displays, but not deleted
content
NOTE The Annotated Revision view can only be displayed for members of text
format.

92

Working with Member Histories and Revisions

Example
Mary needs to know what changes were made to custom.css, including by whom and
when. She could use the Member History view, but that would not show her what lines of
code were changed or added. She could also view the differences between each revision one
at a time, but that would take too long. The Annotated Revision view displays all this
information in one window.

Annotated Revision View

In the GUI, select Member > Views > View Annotated, or in the Web, select History > View
Annotated Revision. The Annotated Revision view displays.

In the Web interface, the revision information for the specified revision displays in the
bottom frame.
Select View to perform the following tasks:

Find searches for the first instance of a text string in the revision contents column

and highlights the text.

Find Next applies the last search to the remaining revision contents column and

highlights the next instance the text displays.

Find Previous applies the last search for the text string to the revision contents

column in reverse order.

Go to Line displays a specific line of text. To go to a specific line, enter the number for the line,
for example, 33. The line of code displays in the center of the pane if it exists in a scrolling
region.

For details on the Annotated Revision view columns, see the online help.

93

Chapter 4: Members

Working With Pending Revisions

Pending revisions are created by MKS Source when a change package is submitted. If change
package reviews are mandatory, the revision remains pending until the change package is
accepted and is committed to the repository. When reviews are not mandatory, you only see
pending revisions if a deferred operation that would have created a new revision fails to
commit to the repository.
Pending revisions are denoted with pending in parenthesis in all views that display revision
numbers, for example 1.2 (pending).
In the case of a pending add member operation, the archive name for the pending revision is
reserved on the server, thereby preventing other users from specifying the same archive
name in any future add member operations.

Reviewing a Pending Revision

To review a pending revision created by the action of another user, do one of the following:

Obtain a working file for the revision by checking out the revision by its number (you
cannot obtain a lock on the pending revision).
NOTE Resyncing a pending revision from your Sandbox replaces the working file
(corresponding to the pending revision) with the member revision.

View the working file for the pending change package entry from the Change Package
view by selecting Member > Revision > View Contents (see Viewing Change Package
Details and Entries on page 124).

Key Considerations

94

Except where noted below, all commands that involve revisions can be performed on
pending revisions.

Pending revisions:

cannot be set as the member revision by a user

cannot be the basis for another revision, unless that revision is also a pending
revision created by the same user in the same change package

can only be locked by their respective creators

can only be deleted by discarding the corresponding pending entry from the change
package

are not recorded in a project checkpoint or Sandbox snapshot, and similarly do not
appear in project restore

cannot be imported into a project

Comparing Differences

When checking out a member that has a pending revision that was created by you, the
pending revision is selected by default in the GUI and Web interface if the change
package containing the pending operation is open.

Comparing Differences
With MKS Source you can compare:

Any two text-based revisions in a history

A text-based revision and its associated working file in a Sandbox (GUI only)

Any two text files

Your can also compare your checked out working file and the locked revision as part of the
check in procedure. This enables you to decide whether your changes should be checked in
or discarded. For details on viewing differences through the Check In dialog, see Checking
In a Member on page 66.
The commands discussed in this section for the GUI use MKS Visual Difference, a tool that
compares and merges members and revisions. For information on using MKS Visual
Difference, see Working With MKS Visual Difference on page 102.
MKS Source allows you to use a third party differencing tool in the GUI if you do not want to
use MKS Visual Difference. You can specify a third party difference tool in your preferences.
For information on setting up third party differencing tools, see the MKS Integrity Client 2007
Getting Started Guide.
To compare two members in the GUI
1 Select two revisions, or a revision and the working file.

Select a working file that has been modified or which has a new revision available.
2 Select Member > Views > View Differences. Visual Difference launches and displays the

two revisions or the working file and revision side-by-side, highlighting the differences
between them.

95

Chapter 4: Members

To compare two revisions in the Web interface

1 Select two revisions.
2 Select History > Differences. Both revisions and a summary of the differences between

them are shown in the Differences window.

96

Comparing Differences

You can also select from the following rules when viewing the comparison:

Ignore blanks ignores tabs and white space throughout lines in the revisions, but

does not ignore the splitting of a word

Ignore whitespace ignores tabs and white space within a line, and ignores the

splitting of a word

Ignore case ignores the type case when comparing the revisions

Diffs only displays only the difference blocks in the revisions

Wrap causes the text in the revisions to wrap at a specified character count. Enter the
number of characters at which you want the text to wrap within the pane. Wrap is

enabled by default.
3 To exit the Differences window, click OK.

To compare two text files in the GUI

1 Select File > Compare Files. The Compare Files dialog box displays.
2 Using the Browse buttons for each field, select the files you want to compare.
NOTE The dialog box keeps track of the last 10 files specified in both fields.

3 Click OK. Visual Difference launches and displays the two files side-by-side,

highlighting the differences between them, or MKS Source informs you there are no
differences between the files.

97

Chapter 4: Members

Branching and Merging Members

As your projects evolve, you may need to branch members to facilitate development in
multiple directions. When you want to combine the development occurring on different
branches, you can merge the revisions.
You may also want to merge revisions that are part of the same member history to
incorporate earlier development into the current development of the member, or vice versa.
MKS Source allows you to merge two revisions and the corresponding working file into a
single merged revision with the MKS Visual Merge tool.
This section explains the branching and merging tasks and the different ways you can
complete them.
Specific topics covered in this chapter include:

Branching and Merging Members Overview on page 98

Merging Modified Working Files on page 100

Merging Two Revisions on page 101

Working With MKS Visual Difference on page 102

Working With MKS Visual Merge on page 105

Resolving Merges on page 109

Branching and Merging Members Overview

Branching diverges from the mainline within an individual members history and creates a
new revision path. These revisions can then be merged with the member revision on the
mainline. Merging combines changes into a new revision, usually the head revision.
A branch can start from the mainline or another branch. Revision numbers contain the
complete number of the revision that started the branch, for example, 1.2 is branched into
1.2.1.1.

Branching Members
You can branch members while performing a check in operation in the GUI or Web interface
by selecting the Force Creation of New Branch option.
In addition, members can be branched when:

98

you check in a revision using an already existing revision number

you check in a revision when working in a variant Sandbox

Branching and Merging Members

When performing a branch on check in, the member is checked in but is not updated to the
member revision. The working revision number increments accordingly, and the original
member revision in the project remains unchanged.

Merging Branched Members

When you want to combine the development occurring on different branches, you can use
the Merge Branch command. The Merge Branch command merges the entire contents of a
branch into a single revision. MKS Source keeps track of the changes that have been merged
so that later revisions on the branch are not re-merged when the next Merge Branch
operation occurs. Any subsequent Merge Branch operations merge only changes since the
previous merge operation.
Merging operations are available only in the GUI and CLI.

Analyzing Merge Results

A merge conflict occurs if the revisions being merged both have changes in a common
segment of lines. MKS Source provides visual two- or three-way differencing and merging
tools. Depending on the operation, merging can launch the MKS Visual Difference tool and
the MKS Visual Merge tool to automatically highlight conflicts for resolution. MKS Source
also supports third-party merging and differencing tools such as Araxis and Beyond
Compare.
Even if a no conflict is reported as a result of a merge operation, there can still be
inconsistencies in the merge results that can only be detected by someone with an
understanding of the context of the change. Therefore, anytime a merge is performed, MKS
recommends that you examine and test the merged results before checking them into the
repository.
To merge branched members in the GUI
1 Select the revisions you want to merge.
IMPORTANT Revisions must be checked in prior to merging. An error occurs if the
working file is modified and not checked in.

2 Select Member > Merge > Merge Branch. The Merge Branch dialog box displays.
3 Specify the Target revision that the branch revision is merged into (typically the member
revision on the trunk). You can specify a revision by name from the Symbolic list, specify
a particular revision from the Revision list, or specify a revision by label from the Label

list.

99

Chapter 4: Members

4 Specify the Branch you want to merge with the Target revision. You specify the branch

by specifying a revision on that branch. All of the unmerged changes made on the
branch prior to the specified revision are merged with the target revision. You can
specify a revision by name from the Symbolic list, specify a particular revision from the
Revision list, or specify a revision by label from the Label list.
5 To modify the Merge Branch options, click Options. For detailed information on the

Merge Branch options, see the online help.

6 Under Change Package, select a change package to associate with the merged file from
the Change Package list, or click Create to create a new change package for the file.

For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
7 To merge the branch into the specified revision, click OK. To merge revisions of more
than one member, click OK to All. MKS Source merges all the changes to the working file

on the branch (from the point of branching up to the point of check in) into the member
revision for the project.
You now have working files in your Sandbox that correspond to the results of the Merge
Branch operation; however, they still need to be tested, then checked back into the trunk.
Until the changes are checked in, other users cannot see or use them.
TIP You can also merge branched members in the graphical Member History view
by dragging the revision at the tip of the branch you want to merge onto the revision
that you want to merge into.

Merging Modified Working Files

If you modify your working file without having a lock, you can merge your working file
changes with the member revision. This allows you to have the most complete working file
available.
You can merge your working file automatically when you perform a Check Out or Resync
operation on the member by selecting the Merge Working File If Changed option.
Depending on your Check Out options or the preferences you have set for the Resync
command, MKS Source takes one of the following actions when a conflict occurs:

100

MKS Source asks you to confirm the action to be taken.

MKS Source cancels the operation.

MKS Source exits the merge operation, and marks the working file with an unresolved
merge icon. For information on resolving merges, see Resolving Merges on page 109.

Branching and Merging Members

MKS Source automatically launches the MKS Visual Merge tool. For information on the
MKS Visual Merge tool, see Working With MKS Visual Merge on page 105.

MKS Source completes the merge automatically and highlights any conflicts in the
working file.

When merging on checkout, any changes to the working file are merged and the member is
checked out for editing.
When merging on resync, the selected member is updated and merged.

Example
The member revision of demoapp.c is 1.4. Todd has revision 1.3 in his Sandbox and has
made changes to the working file. He wants to check out the member revision, but he also
wants to merge the changes he made to the working file into the checked out member
revision. Todd uses the Automatic Merging on Checkout option.

Merging Two Revisions

When you want to combine individual revisions or a range of revisions (but not an entire
branch), you can use the Merge command.
You specify the root revision (the revision that you want to merge from) and the target
revision (the revision that you want to merge to). Any revisions between the root and the
target are included in the merge.

Example
Development has branched from revision 1.3, with maintenance occurring on the 1.3.1
branch. The tip of the branch is revision 1.3.1.5, the mainline member revision is 1.5, and
Todd has revision 1.5 in his Sandbox. Todd wants to get the changes from 1.3.1.3 to 1.3.1.5
into his working revision. He merges the differences between 1.3.1.3 (the root revision) and
1.5.
To merge two revisions in the GUI
1 Select the revisions you want to merge.
2 Select Member > Merge > Merge. The Merge dialog box displays.
3 Specify the revisions you want to merge. You can specify a revision by name from the
Symbolic list, specify a particular revision from the Revision list, or specify a revision by
label from the Label list.
4 Click OK to continue. The Merge dialog box displays.

101

Chapter 4: Members

5 Select Automatically and click OK. The revisions are merged.

Depending, on the preferences you have set for the checkout command, MKS Source
takes one of the following actions when a conflict occurs:

MKS Source asks you to confirm the action to be taken.

MKS Source cancels the operation.

MKS Source exits the merge operation and marks the working file with an
unresolved merge icon. For information on resolving merges, see Resolving
Merges on page 109.

MKS Source automatically launches the MKS Visual Merge tool. For information on
the MKS Visual Merge tool, see Working With MKS Visual Merge on page 105.

MKS Source completes the merge automatically and highlights any conflicts in the
working file.

6 Select an option, and click OK. MKS Source provides a message indicating why the

merge was canceled.

7 Check in the merged revision.
8 Examine and test the merged results before checking them into the repository.

Working With MKS Visual Difference

The MKS Visual Difference tool is a graphical application that allows you to compare
revisions. It offers two-way differencing of revisions where differences are highlighted for
you. MKS Visual Difference operates in two modes, difference mode and merge mode. You
must be in merge mode to merge revisions in MKS Visual Difference.
IMPORTANT Members must be checked out before you can merge them.

Merging Two Revisions

You can use MKS Visual Difference to merge differences between two revisions selected from
a member history or a revision and a working file. The GUI and CLI allow you to merge
differences between two revisions.
To merge two revisions in the GUI
1 Compare two revisions whose differences you want to merge (see Comparing

Differences on page 95).

2 In Visual Difference, select File > Merge. The Reassign Merge Roles dialog box displays.

102

Branching and Merging Members

3 Select from the list the revisions you want as the Merge From revision and the Merge To

revision.
4 Click OK to continue to Merge mode. MKS Visual Difference switches to the merge mode

split layout. For information on the MKS Visual Difference layouts, see the MKS Integrity
Client 2007 Getting Started Guide.

5 Complete the required changes by doing one of the following:

merging blocks (see Merging Blocks on page 104)

editing merge results (see Editing Merge Results on page 107)

6 To save the Merge Result, select File > Save As (or File > Save if you have already
specified a file name for the merge result). The Save merge result dialog box displays.

103

Chapter 4: Members

7 Type the file name you want to save your merge result as. By default, MKS Source

selects the file name corresponding to the member name.

8 Click Save to save the Merge Result.

Merging Blocks
Difference blocks are highlighted within each revision and may be insertions, deletions, or
changes. You can select the blocks you want to merge by this method.
The merging by blocks functions are accessible from the Edit menu and the shortcut menu.
The following outlines the operations you can use:

Merge Block replaces a block in the Merge Result. The block you select to merge is
inserted, replacing the corresponding block in the Merge Result.
Merge Block Above inserts the selected block above the adjacent block in the merge result

file.

Merge Block Below inserts the selected block below the adjacent block in the merge result

file.
You can also perform these operations in the following ways:

Double click a block in the Merge From or Merge To panes to replace the adjacent block in
the Merge Result.

Drag blocks from the Merge From and Merge To panes to the Merge Result pane.

You must save the merge result file to complete the merging operation. For information on
saving merge results, see Saving Merge Results on page 105.

Editing Merge Results

Once you are working in merge mode in MKS Visual Difference, you can directly edit the
merge result if necessary.
In MKS Visual Difference you can cut, copy, and paste text in the merge result. MKS Visual
Difference highlights the edited text and displays the edit icon ( ) next to the line number.
You can access editing functions in the following ways:

104

From the Edit menu, select Cut, Copy, Paste, or Select All.

From the toolbar, click the Cut, Copy, or Paste buttons.

From the shortcut menu, select Cut, Copy, Paste, or Select All.

Branching and Merging Members

Use the following shortcut keys:

Cut = CTRL+X

Copy = CTRL+C

Paste = CTRL+V

Select All = CTRL+A

You can also add and delete text by selecting a line within the merge result and type or delete
as required.

Reverting Merge Results

If you have made changes to the merge result file that you want to discard, you can revert the
merge result file to its last saved state or revert a particular block.
Operation

Procedure

To revert merge results in the GUI

Select Edit > Revert Merge Result File.

To revert merge results by block in

the GUI

Select the block you want to revert in the merge result file
and select Edit > Revert Block.

Saving Merge Results

Once you have edited or merged blocks into the merge result file, you must save the file. You
can save the file as the member and check it in to continue development or you can choose a
file name of your choice. If you do not save the merge result file as the member, MKS Source
does not recognize any changes to the member.
To save merge results in the GUI, select File > Save As, type the file name in the Save merge
result dialog box, and click Save to save the merge result file.
By default, if the working file is involved in the comparison, MKS Source selects the file name
corresponding to the member name.
NOTE If you save the merge result to your working file, MKS Visual Difference
automatically recalculates the differences when it is saved.

Once you have selected a file name and saved the merge result file, as you continue to make
changes you can select File > Save to save it.

Working With MKS Visual Merge

The MKS Visual Merge tool is a graphical application that allows you to compare, edit, and
merge revisions. It offers three-way differencing of revisions where conflicts are highlighted
for you. Open MKS Visual Merge by selecting Manually from the Merge dialog box (see
Merging Two Revisions on page 101).

105

Chapter 4: Members

Viewing Conflicts
Conflicts, if they exist, are highlighted and appear with a red flag next to the line number in
the view panes. Conflicts are also listed in the Difference Blocks list. You can decide which of
the conflicting blocks you want to incorporate into the merge result, and use the merging and
editing utilities to revise the merge result.
You can use the Next Conflict Block ( ) and Previous Conflict Block (
through the revisions and view all the conflicts.

) buttons to navigate

Merging Nonconflicting Blocks

Merging nonconflicting blocks allows you to merge without including any areas of conflict.
MKS Visual Merge incorporates all difference blocks (except conflict blocks) from the Merge
From revision into the merge result file.
To merge all nonconflicting blocks in MKS Visual Merge, select Edit > Merge All
Nonconflicting Blocks. All nonconflicting difference blocks are applied to the merge result
file.

106

Branching and Merging Members

Save the merge result file to retain the changes as described in Saving Merge Results on
page 108.

Merging Individual Blocks

If you do not want to merge entire revisions you can merge individual difference blocks or
lines. Difference blocks are highlighted within each revision and may be insertions, deletions,
changes, or conflicts.
The merging blocks functions are accessible from the Edit menu and the shortcut menu. The
following outlines the commands you can use:

Merge Block inserts the selected block or line into the merge result file in the same
location as it displays in the revision it originated from.

Merge Block Above inserts the selected block or line above the adjacent block in the

merge result file.

Merge Block Below inserts the selected block or line below the adjacent block in the

merge result file.

In addition to these commands, in MKS Visual Merge you can simply select a block and
double click it or drag it into the merge result file.
You must save the merge result file to complete the merging operation. For information on
saving merge results, see Saving Merge Results on page 108.

Editing Merge Results

While you are working in MKS Visual Merge, you can directly edit the merge result if
necessary. This is typically required for resolving merge conflicts, but can be used in other
situations as well.
In MKS Visual Merge you can cut, copy, and paste text in the merge result. MKS Visual
Merge highlights the edited text and displays the edit icon ( ) next to the line number. You
can access editing functions in the following ways:

From the Edit menu, select Cut, Copy, Paste, or Select All.

From the toolbar, click the Cut, Copy, or Paste buttons.

From the shortcut menu, select Cut, Copy, Paste, or Select All.

Use the following shortcut keys:

Cut = CTRL+X

Copy = CTRL+C

Paste = CTRL+V

Select All = CTRL+A

107

Chapter 4: Members

You can also add and delete text by selecting a line within the merge result and type or delete
as required.

Reverting Merge Results

If you have made changes to the merge result file that you want to discard, you can revert the
merge result file to its original state or revert a particular block or line.
To revert merge results to the original state in MKS Visual Merge, select Edit > Revert Merge
Result File. The merge result file reverts to its last saved state.

To revert merge results by block in MKS Visual Merge, select the block or line you want to
revert in the merge result file, and select Edit > Revert Block. The block or line is removed
from the merge result file.

Saving Merge Results

Once you have edited or merged blocks into the merge result file, you must save the file. You
can save the file as the member and check it in to continue development, or you can choose a
file name of your choice. If you do not save the merge result file as the member, MKS Source
does not recognize any changes to the member.
To save merge results in MKS Visual Merge, select File > Save As, type the file name in the
Save merge result dialog box, and click Save.
NOTE If you save the merge result to your working file, MKS Visual Merge
automatically recalculates the differences when it is saved.

Once you have selected a file name and saved the merge result file, as you continue to make
changes you can select File > Save to save it.

Suspending Merges
Once you have initiated a merge, you can suspend it and then resolve it at a later time.
Suspending merges allows you to mark the working file to indicate that merging is required.
This provides time you may need to investigate conflicts or difference blocks before finishing
the merge.
You can only suspend a merge operation if there are changes since the last time you saved the
merge result.
To suspend a merge, in MKS Visual Merge, click the Close button on the status bar, then click
Yes to mark the working file for merging at a later time. In your Sandbox view, the member
is marked with an unresolved merge symbol ( ), and in the member information pane
MKS Source indicates that resolution is required.

108

Locating Where a Member Is Used

Resolving Merges
During the process of merging revisions you may decide to suspend the operation and mark
the working files for merging at a later time. Working files that are marked for merging
appear with an unresolved merge symbol ( ) in the delta column in the Sandbox view.
If you have begun the merging process but decided to use the Mark for Later Merge option to
postpone the completion of the merge process, when you are ready to merge the selected
revisions you can use the Resolve Merge command to do so.
NOTE You cannot suspend a merge operation and mark the working files for
merging at a later time when using a third party merge tool.

To resolve a merge in the GUI

1 Select a member with an unresolved merge symbol (

).

2 Select Member > Merge > Resolve Merge. The Merge dialog box displays.
3 Select one of the following options for how you want to complete the merge, then click
OK:

Automatically completes the merge process without launching the MKS Visual

Merge tool.
If MKS Source encounters a conflict, depending on your preferences (see the online
help) the operation may be canceled, the revisions may be marked for merging later,
the output file may be highlighted, or the MKS Visual Merge tool may be launched.

Manually allows you to complete the merge operation through MKS Visual Merge or

a third party merge tool, based on your preferences. The merge tool appears in a
new window displaying the revisions you want to merge. Perform merging and
editing as required, then save the merge results and close the tool.
For information on using the MKS Visual Merge tool, see the MKS Integrity Client
2007 Getting Started Guide, and Working With MKS Visual Merge on page 105.
In your Sandbox view, a delta displays indicating that the merge is complete.

Locating Where a Member Is Used

As projects grow in complexity, it can be difficult to determine the relationships that
MKS Source objectsprojects, subprojects, and membershave with one another. Using the
Locate command, you can locate where a specific MKS Source object is used in your source
code repository. The search results appear in a Locate view, that allows you to refine and sort
the results, view each located object in greater detail, and perform basic operations on them,
such as viewing members.

109

Chapter 4: Members

For more information on locating a member, project, or subproject, see Locating Where an
MKS Source Object Is Used on page 30.

Generating Member Reports

In the GUI, MKS Source Reporter analyzes projects, their members, or individual archives,
and allows you to generate a variety of reports and graphs based on its findings. For
example, you could create a report to show the changes that have been made to a source file,
and which team members made them.
To generate a report, select a project or Sandbox, then select Project > Run Report. Select a
report type from the list of reports.
Reporter calculates a summary of the changes to a project or archive, then displays or prints
the summary as text or, for some reports, optionally as a graph. If you display a report as a
graph, you can define how you want it to look to suit your preferences or for quick, projectspecific identification. You can save Reporters data files (containing the results of its project
or archive analysis) as text files that most database applications can read.
To use Reporter, you must have a default printer installed, and you must have selected
Microsoft Access as your reporting application when you installed the MKS Integrity
Client. You can also create customized reports using MS Access.
If you installed MS Access after installing the MKS Integrity Client, contact your system
administrator to enable MKS Source reporting.
NOTE If you are integrated with MKS Integrity and your administrator has set up
MKS Integrity items to collect MKS Source project information, you can use the
expanded reporting capabilities provided by MKS Integrity. For more information,
see the MKS Integrity 2007 User Guide.

Types of Reports
Reporter generates the following summaries:

changes introduced by individual authors

changes between the member revision and a revision with a particular label

changes between the member revision and any other revision

a list of locked members and the names of users who locked them

a list of revisions with a particular label or state

project member history (including revision descriptions) by file

For more information on reports, see Generating Reports on page 32.

110

Promoting and Demoting Members

Promoting and Demoting Members

When MKS Source is used on its own, your administrator can define states that members
move through as part of the development process.
A state is free-form text used to classify the condition of a revision in a member history. For
example, a document could initially have a state of Draft. As work progresses it might be
changed to Review and eventually Complete. If no state is assigned to a revision, a
default value of Exp (for Experimental) is used.
To control member workflow more effectively, MKS recommends you use MKS Integrity
with MKS Source.
This section provides information on the following procedures:

Promoting Members on page 111

Demoting Members on page 112

Promoting Members
Promotion is the process of managing data as it moves through a structured development
cycle. Each phase is represented by states that are defined by the administrator. Project
members can also be demoted to a predefined lower state.
NOTE Promoting members is for historical purposes only. To control member
workflow more effectively, MKS recommends you use MKS Integrity.

At particular milestones, project members are ready to move to the next stage of their
development cycle (for example, from Development to Test). If no state system is defined, a
default value of Exp (Experimental) is assigned to all revisions.

Example
Patrick the project manager is notified that the ABC Financial Toolkit has reached code
freeze. He promotes the project and members to Testing and notifies Quality Assurance
that they can begin final testing of the toolkit.
Interface

Procedure

GUI

Select Member > Properties > Promote. In the Promote Member dialog
box, select a new state from the Promote to State list.

Web

Select Member > Promote. In the Promote Member dialog box, select a
new state from the Promote to State list.

111

Chapter 4: Members

Demoting Members
Project members can also be demoted to a predefined lower state of development.
NOTE Demoting members is for historical purposes only. To control member
workflow more effectively, MKS recommends using MKS Integrity.

112

Interface

Procedure

GUI

Select Member > Properties > Demote. In the Demote Member dialog
box, select a new state from the Demote to State list.

Web

Select Member > Demote. In the Demote Member dialog box, select a
new state from the Demote to State list.

CHAPTER FIVE

Change Packages

Controlling and Monitoring Project Development

When performing development work, you may need to change several members.
MKS Source provides change packages to group all of the necessary changes together.
Change packages provide an essential tool for controlling and monitoring development.
This chapter provides details on the following:

Change Package Overview on page 114

Creating a Change Package on page 117

Working With Change Package Entries on page 117

Working With Change Packages on page 122

Change Package Reviews Overview on page 128

Reviewing Change Packages on page 134

Apply CP and Resync CP Overview on page 136

Using the Apply CP Command on page 138

Using the Resync CP Command on page 151

Using the Resync By CP Command on page 164

113

Chapter 5: Change Packages

Change Package Overview

A change package is a group of changes made by a single user that can be considered a logical
unit of work. Only the creator of a change package can add entries to that change package.
Change package entries are added when you specify a change package while performing
member operations.
A change package acts as a log of both the changes to members and subprojects that have
already been committed to the repository (server), and the changes that are only visible to the
user on the desktop and not committed to the repository (deferred). When change package
reviews are mandatory, a change package acts as a control placed on changes to the
repository by making them pending before they are committed.
A change package is open until you close it, which signifies that work on the change is
completed. When reviews are mandatory, a change package has additional states before it is
closed.
The following rules apply when using change packages:

Each change package has a unique change package ID (CP ID). The CP ID is a colon
separated identifier of the form:
<container ID>:<relative change package number>
NOTE If the MKS Integrity integration is enabled, the item ID is used as the
container ID.

Only the creator of a change package or a change package administrator can close a
change package.

Once a change package is closed, it can only be re-opened by a change package

administrator. If a change package has been propagated through Apply CP or
Resync CP, it cannot be reopened, even by a change package administrator.

You can expand the capabilities of MKS Source change packages by associating them with
MKS Integrity items to take advantage of MKS Integritys workflow and process
management.
This section provides information on the following:

114

Integrating With MKS Integrity on page 115

Why Use Change Packages? on page 116

Using Change Packages to Control Development on page 116

Change Package Overview

Integrating With MKS Integrity

As part of the integration with MKS Integrity, you can associate change packages with
MKS Integrity items. Items provide more detailed information on the action that is required
and control the workflow of development and testing, known as the software development
cycle.
MKS Integrity items track changes in the software development cycle. For example, your
administrator can configure MKS Integrity in a way that a problem item may be associated
with a solution item for easy tracking and monitoring of both items. Each item has an audit
trail, which may be used to evaluate internal processes for the effectiveness of the problem
resolution process. In effect, items track all aspects of any engineering project.
Integrating with MKS Integrity allows you to specify groups of developers who are affected
by an item, who can then be notified using e-mail notification rules.
Administrators define what item types can use change packages and configure MKS Source
to integrate with MKS Integrity.
Change packages can be grouped together using an item to create a larger logical grouping of
changes. Each change package in an item can be created by a different user for team
development of an item.
Note the following rules that apply when using items and change packages:

Multiple change packages can be created for a single item. If the resolution of an item
requires more than one set of changes, a new change package can be created for each
new set of changes. This also allows multiple users to work on the same item.

If an item type does not allow open change packages, you cannot create and associate
new change packages with that item. Check with your administrator to find out which
item types allow open change packages.

Only item states specified by your administrator allow open change packages. When
attempting to advance to a state that does not allow open change packages,
MKS Integrity instructs you to first close the items change package.

Typically, an item cannot advance to the final state in an MKS Integrity workflow until
all change packages are closed. See your administrator for more information.

When the MKS Integrity integration is enabled, the change package ID is a colonseparated identifier of the form:
<item number>:<relative change package number>

For detailed information on MKS Integrity operations, see the MKS Integrity 2007 User Guide.

115

Chapter 5: Change Packages

Why Use Change Packages?

Change packages provide the following advantages:

Change packages allow related changes to be grouped as a logical unit.

Change packages allow work in progress to be submitted to the repository (server) all at
once (using submit change package), which prevents users from partially submitting
related work in progress.

Change packages provide a way to apply related changes to a project or Sandbox in one
operation.

Using change packages, users are able to resync the changes required to address a
specific item without resyncing the entire project.

Groups of changes can be reviewed as a unit. If reviews are mandatory, changes are
reviewed before they are committed to the server repository.

Using Change Packages to Control Development

The following is an example of a way to use change packages to control development. You
can combine this example with the review process to control what changes become a
permanent part of the repository (see Change Package Reviews Overview on page 128).
1 If you are integrated with MKS Integrity, submit an item that needs to be addressed. For

more information, see the MKS Integrity 2007 User Guide.

2 Create a change package (see Creating a Change Package on page 117) for the group of

tasks you need to perform to address an item. If you are integrated with MKS Integrity,
when creating the change package associate it with the item you created.
3 MKS Source assigns the change package an ID and leaves the change package in an open
state. You can see the change package listed in the Change Packages view.
4 As part of your development process, identify the members that are affected by the item.

Specify the change package when performing operations on the affected members (see
Specifying a Change Package for an Operation on page 118). The operations are listed
in the Change Package view.
5 When all of the development to address the item is completed, submit the change

package (see Submitting Change Packages on page 125). Any locked members are
converted to deferred checkin operations, then checked in. All of the deferred operations
are submitted.

116

Creating a Change Package

6 Close the change package when the work to address the item is completed. The change
package is moved to the Closed state, and the change package disappears from the
Change Packages view.

To find the change package and view its entries, see Finding Change Packages on
page 122).
7 If you are integrated with MKS Integrity, advance the item through the workflow. At

this point, the verification phase begins. If it is determined that more work needs to be
performed to address the item, the user moves the item to an earlier state in the
workflow, then you (or another developer) create an additional change package. The
process is repeated until the item is sufficiently addressed. For more information, see the
MKS Integrity 2007 User Guide.

Creating a Change Package

You can create a change package in MKS Source in one of the following ways:

Select Change Package > Create.

When performing a member operation, in the Change Package portion of the dialog box
that displays, click Create.

If the MKS Integrity integration is enabled, when creating a change package you can choose
an MKS Integrity item to associate with the change package. For more information on items,
see the MKS Integrity 2007 User Guide.
Your ability to create a change package associated with an item is based on the change
package creation policy for the item type.

Working With Change Package Entries

Once a change package is created, you can add entries to that change package by selecting it
in the Change Package portion of the dialog box or wizard when performing member and
subproject operations. To add change package entries to a change package, the MKS Integrity
Client must be connected to the server the change package resides on.
TIP You can also add an entry to a change package by dragging the member from a
Sandbox view to a Change Package view (or change package in the Change
Packages view). The Check Out dialog box displays with the change package
selected. For more information, see Checking Out a Member on page 63.

117

Chapter 5: Change Packages

After the operation is completed, the entry is added to the change package. Depending on the
operation, the change packages ID displays in one of the members CPID (change package
ID) columns in the Project or Sandbox view. Not all CPID columns appear by default. For
information on setting the default columns through view preferences, see the MKS Integrity
Client 2007 Getting Started Guide.
If the change package contains deferred operations or lock entries, a
icon displays beside
the change package ID in the Working CPID column of the Sandbox view.

Specifying a Change Package for an Operation

When performing an operation that can add entries to a change package, keep the following
in mind:

A change package can only be specified if your administrator has enabled the use of
change packages.

You must specify a change package if your administrator has made change packages
mandatory.

If change packages are not mandatory, and if no change package is applicable, you can
select <none> in the Change Package field.

Change Package Entry Types

The following table displays change package entry types and the operation that creates them.
Change Package Entry Types

Operation

Add

Add Member

AddFromArchive

Add Member From Archive

AddSubproject

Add Subproject

AddSharedSubproject

Add Shared Subproject

ConfigureSubproject

Configure Subproject

CreateSubproject

Create Subproject

Drop

Drop Member

DropSubproject

Drop Subproject

Import

Import Member

Lock

Lock Member, Check Out

Note: This entry is used for exclusive locks.

118

NonExclusiveLock

Lock Member, Check Out

MoveMember

Move Member

Working With Change Package Entries

Change Package Entry Types

Operation

MoveSubproject

Move Subproject

Rename

Rename Member

Update

Check In (with updating member revision)

UpdateRevision

Update Member Revision

UpdateArchive

Check In (without updating member revision)

Moving CP Entries
You can move change package entries from one change package to another. For example, if
you checked in a member with the incorrect change package, you can move that change
package entry to the correct change package, thereby ensuring auditing accuracy.

Key Considerations

Only the change package creator can move entries from one change package to another.

Both the originating and the target change packages must be open.

Only a change package administrator can move entries from one closed change package
to another open change package, and only if the closed change package is not one that
was reviewed. A change package administrator can also move entries from one open
change package to another open change package.

Moving a change package entry for a subproject operation moves any nested entries
(member or subproject) at the same time.

To move change package entries in the GUI

1 From the Entries panel on the Change Package view, select the change package entries

you want to move.

2 Select Change Package > Entry > Move. The Move Change Package Entry Settings dialog

box displays.
3 From the Target Change Package list, select the change package you want to move the

entries to. The change packages are listed with the C.P. ID and the summary.
4 If you want to create a new change package for the entries, click Create. For more

information, see Creating a Change Package on page 117.

5 If you are a change package administrator, the Show all open Change Packages option is

available. Select the option to make change packages that you did not create available in
the Target Change Package list.
6 When you are finished, click OK. The Confirm Move Change Package dialog box

displays.

119

Chapter 5: Change Packages

7 To move each entry presented, click Yes. To move all entries without viewing individual
prompts, click Yes to All. The change package entries are moved to the selected change

package.
TIP You can move change package entries by dragging them from one Change
Package view to another.

To move change package entries in the Web interface

1 From a Project or Member History view, click the change package ID. The Change
Package view displays.
2 Click the Entries tab. The Entries panel displays.
3 Select the change package entries you want to move.
4 Select Actions > Move Change Package Entry. The Move Change Package Entry dialog

box displays.
5 From the Target Change Package list, select the change package you want to move the

entries to. The change packages are listed with the C.P. ID and the summary, for
example, 10:1 help dialog broken.
6 If you want to create a new change package for the entries, click Create. For more

information, see Creating a Change Package on page 117.

7 When you are finished, click OK. The Confirm Move Change Package dialog box

displays.
8 To move the entry, click Yes. Repeat for additional entries. The change package entries

are moved to the selected change package.

Discarding CP Entries
You can remove entries from a change package by discarding them. To discard entries, the
change package must be in an Open or Rejected state. Only a change package administrator
can discard entries from closed change packages and only if reviews are not mandatory.
Interface

Procedure

GUI

From the Entries panel on the Change Package view, select the change
package entries you want to discard.
Select Change Package > Entry > Discard.

Web

From a Project or Member History view, click the change package ID.
From the Change Package view, click the Entries tab.
On the Entries panel, select the entries you want to discard and select
Actions > Discard Change Package Entry.

120

Working With Change Package Entries

When a change package entry is discarded, the following happens if applicable:

Deferred operations corresponding to deferred entries are reverted.

Locks on members corresponding to lock entries are released.

Pending operations corresponding to pending entries are reverted, and discarded entries
are created (to preserve the review history).

Pending revisions corresponding to pending entries are deleted.

Archives created for pending members associated with entries in the change package are
deleted from the server (pre-existing archives that were shared to create a pending
member are not deleted).

Any nested operations in a pending subproject are discarded at the same time as the
subproject.

Keep the following points in mind when discarding change package entries:

Only the creator of the change package or a change package administrator can discard
entries.

If change packages are mandatory, committed entries cannot be discarded (contact your
administrator for more information).

Viewing CP Entry Member Differences

From the Change Package view, you can view the member differences of any change package
entry.
Interface

Procedure

GUI

From the Entries panel on the Change Package view, select the change
package entry you want to difference.
Select Member > Views > View Difference.

Web

From a Project view, select a member that has a change package

associated with it.
Under the C.P.ID column, click the number link for the change
package.
From the Change Package view, select the change package entry you
want to difference and select Actions > View Member Differences.

For updates, MKS Source compares the most recent revision checked into the change package
with its immediately preceding revision. For example, if you want to view the differences for
the member readme.txt at revision 1.3, MKS Source compares revisions 1.3 and 1.2,
displaying them in the Differences window
For lock entries in the GUI, MKS Source compares the working file with the locked revision.
You cannot difference a lock entry that does not have an associated Sandbox.

121

Chapter 5: Change Packages

The Differences window displays the two revisions side-by-side, highlighting the differences
between them, or MKS Source informs you that there are no differences. For more
information, see Comparing Differences on page 95.

Working With Change Packages

You can search for change packages and view change package details. You can edit change
packages or discard them. Once all changes are complete, you can close a change package or,
if change package reviews are mandatory, submit it for review.
This section provides information on the following:

Finding Change Packages on page 122

Viewing Change Package Details and Entries on page 124

Editing a Change Package on page 125

Submitting Change Packages on page 125

Closing a Change Package on page 126

Discarding Change Packages on page 127

Reopening a CP on page 128

Finding Change Packages

MKS Source provides you with a way to search through all of the change packages created by
anyone, including closed change packages.
To find change packages, select Change Package > Find.

Searching By Filter
You can search for change packages using various filters on the By Filter tab.
For detailed information on the change package filters, see the online help.
To combine filters, select the desired filters, then select Logical AND or Logical OR to specify
their relationship.
To invert a filter, click the filter a second time and the ! symbol displays. For example, you
can search for change packages that are not associated with a specified project.

Searching By ID
You can search for change packages using the change package ID on the the By ID tab. You
can specify the following types of ID:

122

Working With Change Packages

A container ID, for example 12, finds all changes packages with that container ID. If the
MKS Integrity integration is enabled, the container ID is the same as the item ID.

The full change package ID, for example 12:1, finds the single change package.

You can serach by as many IDs as you want.

Searching By Query
If the MKS Integrity integration is enabled. you search for change packages by query on the
By Query tab. This enables you to find change packages based on complex criteria. For more
information on creating queries, see the MKS Integrity 2007 User Guide.
NOTE If you use a query that contains a symbolic date (for example, today), your
query results may be different than if you ran the same query in MKS Integrity. This
is because MKS Integrity uses the clients timezone while MKS Source uses the
servers timezone.

123

Chapter 5: Change Packages

Viewing Change Package Details and Entries

Once you add entries to a change package, you can use MKS Source to view the change
package information for the member or subproject.
Operation

Procedure

To view information for a change package in the

GUI

Select a change package in the Change

Packages view, and then select Change
Package > View Change Package Details

To view information for a change package

associated with a member operation in the GUI

Select the member in a Project or Sandbox view,

and then select Member > Change Package

To view information for a change package

associated with an annotated member revision in
the GUI

From the Annotated Revision view, select the

annotation block corresponding to the change
package you want to view, and then select
Change Package > View Change Package
Details

To view information for a change package

associated with a subproject operation in the
GUI

Select the subproject in a Project or Sandbox

view, and then select Project > Subproject

To view information for a change package in the

Web interface

Select a member or revision in the Project or

Member History view, and then select Change

Change Package

Package > View Change Package Details

Tip: You can also click the change package ID in
the Project or Member History view to view the

change package.

When viewing information for change packages associated with a member operation, you
can select one of the following:

View Working displays the change package associated with a deferred or lock operation

performed by the current user from the current Sandbox (available only through a
Sandbox context).

View Member displays the change package associated with the operation that set the

member revision.

View Creation displays the change package that created the revision that is currently the
member revision. This revision may be different from the member change package ID if
you used an import, add member from archive, or set member revision operation.

View Locker displays the change package associated with the non-exclusive lock on the

member revision. If you use a non-exclusive locking policy, there can be multiple locks
on the member revision. If there are multiple locks, the current users lock takes priority.
If the current user does not have a lock associated with a change package, the change
package associated with an exclusive lock displays. If there is no exclusive lock
associated with a change package, the first non-exclusive lock on the member revision
displays.

124

Working With Change Packages

View Pending displays the change package associated with a pending operation.

When viewing information for change packages associated with a subproject operation, you
can select one of the following:

View Member displays the change package associated with the current subproject

configuration.

View Pending displays the change package associated with a pending subproject

operation.

Editing a Change Package

You can update the summary, state, and description of a change package when necessary.
NOTE You can only edit a change package that you created, unless you have
administrator permissions.

If reviews are mandatory, change packages in state CommitFailed, Rejected, or Discarded can
be moved to the Open state as part of the state workflow. For more information, see Change
Package Reviews Overview on page 128.
Interface

Procedure

GUI

Select the change package you want to edit and select Change
Package > Edit.

Web

From a Project view, select the member that is associated with the
change package you want to edit. Under the C.P.ID column, click the
number link for the change package.

Submitting Change Packages

You submit a change package in order to commit the associated changes to the repository.
When reviews are mandatory, submitting a change package begins a review process that
must be completed before the changes are committed to the repository (see Change Package
Reviews Overview on page 128).
You can submit change packages containing any combination of deferred, pending, and
committed entries.
To submit a change package in the GUI, select the change package, and select Change
Package > Submit.

125

Chapter 5: Change Packages

Key Considerations

If exclusive locking is enabled, you cannot successfully submit a change package that
contains a deferred check in if you do not have a lock on the member. You must check
out the member before submitting the change package.

Locked change package entries must be converted to deferred check in entries in order
for the Submit CP operation to complete. The Check In dialog box displays when a
locked entry is encountered. If the Check In operation results in a revision conflict (the
revision being checked in is not the member revision) or a lock conflict (another user has
an exclusive lock on the member), you can still proceed with the Submit CP operation by
selecting the Force Creation of New Branch option.

You cannot succssfully submit a change package that contains deferred Rename or
deferred Move entries if another user has a lock on the member.

You cannot successfully submit a change package if the revision being updated is frozen.

If a change package is submitted only containing pending entries, you are prompted to
commit those pending entries, even if there are no deferred or lock entries. To set this
option as a default using command preferences, see the MKS Integrity Client 2007 Getting
Started Guide.

Closing a Change Package

Once the necessary changes are made to the members and subprojects, and they are
committed to the repository, you can close the change package by selecting Change Package
> Close.
In addition to this procedure, you can close a change package in the GUI by selecting the
Close Change Package option when performing member or subproject operations (see
Creating a Change Package on page 117).
If the MKS Integrity integration is enabled, closing a change package allows the item to move
forward in the MKS Integrity workflow. For more information, see Integrating With
MKS Integrity on page 115.
NOTE You can only close a change package that you have created unless you have
administrator permissions.

If reviews are mandatory, you cannot close a change package. It must follow the review
process and be closed by the MKS Integrity Server. For more information, see Change
Package Reviews Overview on page 128.

126

Working With Change Packages

Discarding Change Packages

MKS Source provides a way to remove change packages from active use by discarding them
when they are not needed.
Interface

Procedure

GUI

Select the change package you want to edit and select Change
Package > Discard.

Web

Display the change package you want to discard in the Change

Package view. Select Actions > Discard Change Package.

Change packages can only be discarded if they are in the Open or Rejected states. To
discard a change package, that change package must be both created by you and not contain
any committed entries. However, a change package administrator may discard a change
package created by another user.
TIP If you need to remove only specific entries from a change package, see Change
Package Reviews Overview on page 128.

When a change package is discarded, the following happens where applicable:

All uncommitted entries are removed from the change package.

All deferred operations corresponding to deferred entries are reverted.

Locks on members corresponding to lock entries are released.

All pending operations corresponding to pending entries are reverted and appear as
discarded entries in the review log (to preserve the review history).

All pending revisions that correspond to pending entries are deleted.

Any archives created for pending members associated with pending entries in the
change package are deleted from the server (pre-existing archives that were shared to
create a pending member are not deleted).

Key Considerations

The change package ID for the discarded change package can never be used for any
future change packages that are created.

Discarded change packages have a state of Discarded and can still be viewed using the
Committed or Pending filter (see Finding Change Packages on page 122).

If the change package has undergone a review, the review log persists.

You can open and reuse discarded change packages (see Reopening a CP on page 128).

127

Chapter 5: Change Packages

Reopening a CP
The Open state is the only state you can add new entries to a change package. As part of the
review workflow, change packages in the following states can be reopened: CommitFailed,
Rejected, and Discarded.
CAUTION

Only a change package administrator can reopen a change package in the

Closed state. Modifying closed change package contents can compromise the
integrity of the server repository.

A change package cannot be reopened if it has been propagated to another

development path. For more information, see Using the Apply CP Command
on page 138.

Interface
GUI

Procedure
Select the change package you want to reopen, and select Change
Package > Reopen.

Web

From a Project or Member History view, click the change package ID.
From the Change Package view, select Actions > Reopen.

Change Package Reviews Overview

A change package review is a review of changes by specified reviewers before the changes
are committed to the server repository.
If change package reviews are mandatory globally, then all change packages must progress
through the change package review process.
If change package reviews are mandatory at the project level only, then a change package
only progresses through the review process if it contains at least one entry associated with a
member in a project that requires a review. Change packages follow the review process
before the changes are successfully committed to the server repository. All other change
packages function as non-review change packages.
A change package reviewer is a user specified by your administrator to review change packages
containing members associated with specific projects. The reviewer may be individually
specified or a member of a specified reviewer group. In the case of a reviewer group, any
member of that group casts an accept or reject vote on behalf of the entire group.
A change package watcher is a user specified by your administrator who is notified when a
reviewed change package is closed after being successfully committed to the repository.
Change package watchers may be individually specified or a member of a specified watcher
group.

128

Change Package Reviews Overview

A super reviewer is a user with permission to vote on change packages, but who is not
required to be a listed reviewer for the change package. Voting as a super reviewer overrides
all other votes. For example, casting an accept vote as a super reviewer is sufficient for
accepting the change package.
This section contains information on the following:

How CP Review Works on page 129

CP Review Benefits on page 130

CP Review Workflow on page 130

CP Entry Categories on page 133

Pending Operations in CPs on page 134

How CP Review Works

The following summarizes how the change package review process works:
1 The review starts when a developer (change package creator) submits a change package

containing deferred and member lock entries and subproject entries (or any combination
of deferred, pending, or committed entries).
2 MKS Source creates a pending change package entry for each deferred and member lock

entry, and, where necessary, pending revisions.

3 Change package reviewers (possibly a mentor or a senior developer) accept or reject the

change package.
4 The change package entries are either committed to the database (accepted case), or the

developer opens the change package and continues development (rejected case)
NOTE Although the review process describes submitting change packages with
deferred entries thereby creating pending entries, if deferred operations are not
mandatory you can create pending entries at the time the operation is completed by
clearing the deferred option. You can then submit the change package containing
the pending entries for review. Subproject operations are always created as pending
entries in a change package when reviews are mandatory.

129

Chapter 5: Change Packages

Submit Change
Package
Developer

Open and Work

Pending Entries
and Revisions

Developer

Reject

Accept or Reject
Reviewers
Accept

Committed

Repository

Change Package review process

CP Review Benefits
The benefits of using reviews are:

Reviews provide a formal and enforceable review process.

Reviews force changes to be reviewed before they are committed to the repository
thereby providing control over what changes are accepted into a project by making
operations pending. Unlike deferred operations, which are stored only client side,
pending operations are stored server side and so are visible to all users. This can be
useful near the end of a release cycle as a pre-commit review of changes before they are
included in a release build.

Pending revisions are not a part of the current state of the project until they have been
reviewed (not at member revision); however, they remain in the member history and can
be checked out (without a lock) by users (other than the creator) for review.

If the project is one that users will be building from, reviews can remove the need for
using a variant project to review changes manually.

Reviews provide an alternative to manual post-commit review while recording all of the
review information.

CP Review Workflow
A change package under review progresses through states in a workflow.

130

Change Package Reviews Overview

The following table provides details on change package states. Where specified, some are
only used in the review workflow:
Change Package State

Details

Open

Only state where work can be performed using a change package (new
entries created).

Submitted

State the change package is in while it is being reviewed. All operations

are pending.

Accepted

Intermediate state denoting that the change package is accepted by all of

the reviewers. MKS Source automates the state change from Accepted to
Closed if the changes are successfully committed to the repository.

CommitFailed

State signifying that the pending changes could not be committed to the
repository.

Rejected

State denoting that the change package is rejected by a reviewer.

Creator must manually move the change package to Open to continue
development.

Discarded

Empty change packages or change packages with changes that do not

need to be committed to the repository are moved by the creator to the
Discarded state. Discarded change packages can be opened at a later
date if needed.

Closed

End state for the change package when pending changes are
successfully committed to the repository.

The following is the change package progression through the workflow:

1 A change package is created and in the Open state. The developer adds entries to the

change package.
2 The developer submits the change package to begin the change package review process

(see Submitting Change Packages on page 125), and MKS Source moves the change
package to the Submitted state. An e-mail automatically notifies the reviewers of the
change package submission (if the server is configured to send e-mail notifications). The
e-mail contains both change package and review information.
3 The reviewer or reviewers, either accept the change package or reject it. The following

can then happen:

If all individual reviewers and at least one reviewer from a reviewer group (if any
exist) accept the change package, it is moved to the Accepted state. For each vote
cast by a reviewer, MKS Source sends the reviewers an e-mail notification of the
accept vote. When all reviewers have voted to accept the change package,
MKS Source sends each reviewer and the creator an e-mail notification that the
change package is accepted.
MKS Source then commits the changes to the repository, and then closes the change
package. If MKS Source fails to commit the changes to the repository, it moves the

131

Chapter 5: Change Packages

change package to the CommitFailed state and an e-mail notification is sent to the
creator stating the commit failure and the error associated with that failure.
From the CommitFailed state, once the commit failure reason is remedied, the
creator can submit the change package again. Since the review is already completed,
the change package moves to the Closed state without requiring passage through
the review process an additional time, or any additional e-mail notifications to be
sent.
From the CommitFailed state, the creator can also move the change package back
to Open, continue development, and then submit it for review again.
If an accepted change package is successfully committed to the repository,
MKS Source then closes the change package and an e-mail notification is sent to the
change package watchers. Change packages in the Closed state cannot be opened.

If a reviewer (either an individual or a group member) rejects the change package,

MKS Source moves it to the Rejected state and an e-mail notification is sent to each
reviewer and the creator. The creator of the change package then moves the change
package to the Open state (by editing the change package and changing the state),
continues development, and then submits the change package again.
NOTE The creator of the change package continues development on pending
revisions by checking them out. For more information, see Working With Pending
Revisions on page 94.

The user can also discard the change package if it is no longer needed for
development (thereby discarding entries contained in the change package). Change
packages in the Discarded state can be moved back to the Open state if they are
needed again.

132

Change Package Reviews Overview

Open

Commit Failed

Submitted

Discarded

Accepted

Rejected

Closed

Change Package State Workflow

CP Entry Categories
There are four categories of change package entries: deferred, pending, discarded, and
committed. For a complete list of change package entry types, see Change Package Entry
Types on page 118.
The following are change package entry type categories and their descriptions:

deferred entries appear only when the change package is in the Open state (see
Deferring Member Operations on page 82). When the change package is submitted for
review, deferred entries become pending entries (see Submitting Change Packages on
page 125 and Submitting Deferred Operations on page 83). If exclusive locking is
enabled, you cannot submit a change package that contains deferred check in entries that
do not have corresponding locks.

pending entries can appear when a change package is in the Open, Submitted,
Accepted, Rejected, and CommitFailed states. For more information on pending
entries, see Pending Operations in CPs on page 134.

discarded entries can only be viewed from the review log. For more information on
reviewing a change package review log, see Change Package Reviews Overview on
page 128.

committed entries are entries that are committed to the repository. They are denoted
simply by the change package entry type name, for example, Update.

133

Chapter 5: Change Packages

NOTE For change packages that are not under review, only the deferred and
committed entry types are available for use in MKS Source.

Pending Operations in CPs

Pending operations are operations whose proposed changes reside on the server, but have not
been committed to the repository.
The changes are committed to the repository once the change package is accepted upon
review (see Change Package Reviews Overview on page 128). Pending operations can
create pending revisions, members, and subprojects. For more information on working with
pending revisions, see Working With Pending Revisions on page 94.
NOTE Pending revisions are not currently created for subproject operations.

When reviews are not mandatory, pending entries are created when the changes are not
successfully committed to the repository. MKS Source moves the change package to the
CommitFailed state. You can open the change package and then submit it again, or continue
development and submit it later.
Pending operations cannot be reverted, but must be discarded from the associated change
package. For more information, see Change Package Reviews Overview on page 128.
A pending member / subproject, is a member or subproject that is associated with a pending
operation that adds it to the project. The pending member or subproject is denoted by a
pending icon in the Name column of the Sandbox and Project views.

Reviewing Change Packages

If you administrator has set up e-mail notifications for change package reviews, e-mails are
sent to change package reviewers, watchers, and the change package creator at points
throughout the change package review process. For information on when e-mails are sent,
see CP Review Workflow on page 130.
You can view all the change packages waiting for your review by selecting Change Package >
View My Reviews in the GUI. The My Change Package Reviews <user> view displays.
NOTE It is possible for you to be a reviewer of a change package you created.
Contact your administrator for more information.

134

Reviewing Change Packages

You can use the Resync CP command to create working files in your Sandbox for all of the
changes in the change package you intend to review. For more information, see Using the
Resync CP Command on page 151. Once your review is complete, you can accept or reject
the change package.
MKS Source provides review logs as part of a complete review audit process. A log consists
of individual records for each reviewer. Each time the change package is submitted for
review, a new log is created.
To view the change package review log in the GUI and Web, from the Change Package view
click the Review Log tab. The Review Log panel displays.

Accepting a CP
After a change package is submitted, each individual reviewer and one member of each
reviewer group (if specified) in the reviewer list must accept the change package before it can
be committed to the repository and then closed. To see a list of reviewers for a change
package, view the change package review log.
NOTE To accept a change package, the MKS Integrity Client must be connected to
the server on which the change package resides.

To accept a change package in the GUI and Web interface

1 From the GUI, select the change package you want to accept and select Change Package
> Accept, or in the Web interface, with a Project or Member History view open, click the
change package ID. The Change Package view displays.

Select Actions > Accept Change Package. The Accept Change Package dialog box
displays. For detailed information on the Accept Change Package dialog box, see the
online help.
2 To accept the change package, click OK. The accept vote is cast and recorded in the

review log.
If there are reviewers in addition to yourself, an e-mail is sent to notify those reviewers
that you have cast an accept vote for the change package.
When all of the individual reviewers and at least one reviewer from each reviewer group
have accepted the change package, an e-mail is sent to notify the reviewers and the
creator that the change package is accepted.
Once the change package is accepted, it is committed to the server repository. If the
change package is successfully committed to the repository, it then moves to a state of

135

Chapter 5: Change Packages

Closed. For more information on change package states, see CP Review Workflow on

page 130.
If the change package under review is closed, an e-mail notification of the Closed state is
sent to the change package watchers.
All e-mail notifications contain change package and review information.

Rejecting a CP
If a reviewer of a change package determines that invalid changes were made or additional
development must be completed to resolve an item, the reviewer can reject the change
package. A single reviewer rejection is enough to reject a change package, even if there are
multiple reviewers. The creator of the change package can reject it without being listed as a
reviewer. To view the list of reviewers and reviewer groups, view the change package review
log.
To reject a change package in the GUI and Web interface
1 From the GUI, select the change package you want to reject and select Change Package >
Reject, or in the Web interface, with a Project or Member History view open, click the
change package ID. The Change Package view displays.

Select Actions > Reject Change Package. The Reject Change Package dialog box
displays. For detailed information on the Reject Change Package dialog box, see the
online help.
2 To reject the change package, click OK. The change package moves to a state of
Rejected and the vote is recorded in the review log. An e-mail notification of the

change packages rejection is sent to the reviewers and creator.

From the Rejected state, the change package can be discarded or reopened. For more
information on change package states, see CP Review Workflow on page 130.

Apply CP and Resync CP Overview

Apply Change Package (Apply CP) and Resynchronize Change Package (Resync CP)
represent two of the most powerful MKS Source features. In an environment where
development is constantly evolving to include bug fixes or new features, Apply CP and
Resync CP allow you to identify and incorporate only the specific bug fixes or content that
you want to include in a new project. The functionality allows you to move specific
changeswhether from the master project to a variant, from a variant to the master project,
or from a variant to another variant.

136

Apply CP and Resync CP Overview

Variant projects are projects that branch from the main trunk of development. Variant
projects are identified through development paths. For more information on creating
development paths, see Creating a Development Path on page 28.
Apply CP and Resync CP rely on the use of change packages to track individual changes that
modify project content or create new content. For more information on change packages, see
Change Package Overview on page 114.
If a development team does not use the change package methodology, isolating specific
content becomes a complex, manual task. In a large code project, this could mean searching
hundreds of files to determine which ones are related to a specific item. To build the project,
it would then be necessary to add, drop, rename, and move files; update file revisions; merge
around unwanted revisions; merge in required changes; and merge out any unwanted
changes.
If a development team uses change packages consistently, MKS Source can isolate all changes
related to a specific item because this information is recorded as part of the change package.
Once the dependencies are calculated, Apply CP performs the operations required to
propagate the desired changes. If merging is required, you can use the Resync CP command.
Resync CP allows you to either merge in desired changes or merge around unwanted
changes.
Apply CP is appropriate in a staging environment, where you know all changes have been
tested and can be propagated to the next stage as a group. Resync CP is appropriate for
situations where you want to select individual changes, and build and test the changes in
your Sandbox before propagating them.
The effectiveness of Apply CP and Resync CP relies on a change package methodology that
includes the following practices:

accurate and consistent use of change packages for logging items

associating related changes into a single change package that addresses the item in
question

Practices to avoid include the following:

including changes made on multiple variants in the same change package

including unrelated changes in a change package

Apply CP and Resync CP are most useful for code and other text files where differencing can
be performed. The operations are not recommended for binary files because of the difficulties
encountered in differencing and merging binaries.
NOTE For brevity, some of the Apply CP and Resync CP examples use the command
line interface to illustrate how a command works. For information on using Apply
CP (si applycp) and Resync CP (si resynccp) in the command line interface,
see the MKS Source 2007 CLI Reference Guide.

137

Chapter 5: Change Packages

Using the Apply CP Command

You use the Apply CP command to propagate changes recorded in change packages from
one project or development path to another. This enables you to propagate only the changes
that you want to. The Apply CP command is most useful for building software.
The Apply CP operation reads the entries in a change package and updates the project to the
revisions listed in that change package. This function of the command is an automated
process of the Update Revision command. The Apply CP operation may also require that
files or subprojects be added, dropped, renamed, or moved. This function of the command is
an automated process of the member and subproject commands.
Apply CP only operates on closed change packages and cannot perform merging. For more
information on resolving merge conflicts, see Using the Resync CP Command on page 151.
The Apply CP operation occurs in the project (whereas the Resync CP operation occurs only
in the Sandbox). If you run the Apply CP command from a Sandbox, the Sandbox acts as a
redirector to the project.
If you are applying a change package that contains moved members or subproject between
two projects, MKS Source automatically updates both projects.
The next sections describe how the Apply CP command works and how you can use it in
your development environment. The topics covered are:

Using Apply CP in Your Development Environment on page 138

Working With Subprojects on page 139

Applying a Change Package With No Dependencies on page 141

Using the Apply CP Backfill List on page 142

Using a Propagation Change Package with Apply CP on page 145

Resolving Conflicts on page 146

Apply CP Procedure on page 146

Using Apply CP in Your Development Environment

This section provides an example to show how Apply CP can be used in your environment.
In this example, the buildmaster brings a feature from the main trunk of project development
and applies it to an earlier release.
The abcBusiness software company has released their Aurora software, version 3.0. When the
release was completed, the project was checkpointed. The development team is now working
on a new set of features for the next release, 4.0. A new feature for this release is a timestamp
function. All the changes associated with the timestamp function are recorded in a set of
change packages, or set of items, that isolates the feature from other features.

138

Using the Apply CP Command

Now abcBusiness receives a request from a customer who has Release 3.0 but also needs the
new timestamp feature for its global operations. The code in development for Aurora 4.0 is
not stable enough for release and too many resources would be required to accelerate the
release schedule. How can abcBusiness provide the timestamp feature without affecting the
current release? Because the code for this feature is isolated within a set of change packages,
the Apply CP command can be used to propagate the feature to the earlier, stable release.
However, without the functionality of Apply CP, the buildmaster at abcBusiness would have
to search the required change package(s) manually and individually review all of the
associated files to isolate the changes related to the feature. The buildmaster would then have
to add, drop, rename, and move files manually; update file revisions; merge around
unwanted revisions; merge in required changes; and merge out any unwanted changes.
Using the functionality of Apply CP, this complicated process becomes largely automated. In
MKS Source, the Apply CP operation works directly in the project to add, drop, rename, and
move files and subprojects, and update file revisions as required to create the desired change.
MKS Source presents you with a listthe backfill listincluding all change packages
required to capture the changes. In the Apply CP operation, you must either accept or decline
the entire listyou cannot make selections. If you accept the list, the Apply CP command
propagates the changes directly to the project. If you decline the list, the Apply CP command
cannot complete.
If the Apply CP command fails because merging is required, you can run the Resync CP
command. Resync CP works in your Sandbox and allows you to make selections from the
backfill list. MKS Source then merges around unwanted changes and uses differencing to
merge files. For more information, see Using the Resync CP Command on page 151.
The buildmaster at abcBusiness would:

Create a variant project off the checkpoint for version 3.0. This variant project is isolated
from the rest of the development team so that unwanted changes are not added to the
main trunk of the development path.

Use Apply CP to apply the change packages to the variant project. The change packages
contain all the files that were changed or added to produce the timestamp feature. Apply
CP is essentially adding the feature to the variant of Aurora 3.0.

Create an executable of the software.

That executable can then be tested by Quality Assurance and shipped to the customer.

Working With Subprojects

Subprojects are created, added, moved, or dropped through the Apply CP command as a
result of subproject operations included in a change package. Subproject operations are
applied with the following restrictions:

Add subproject operations are ignored if the subproject already exists in the target
project and is configured the same way as is specified in the change package.

139

Chapter 5: Change Packages

You cannot apply configure subproject operations or operations that result in a

reconfiguration of a subproject, for example, adding a subproject that already exists on
on a different development path.

Move subproject operations are ignored if the subproject already exists in the target
location.

Drop subproject operations are ignored if the subproject does not exist in the target
location.

If you cannot include all change packages with subproject operations in the Apply CP
command, you have the option of applying subproject operations that are implied by
member operations included in a change package. This is known as implicitly propagating
subprojects, and is controlled by an option of the Apply CP command. Using implicit
subproject propagation enables you to propagate subproject changes without needing to
actually apply the change packages containing those subproject operations.
NOTE

Earlier versions of MKS Source (Source Integrity) always used implicit

propagation of subproject operations.

Using implicit subproject propagation can result in unsatisfactory results. For

example, if a change package used to create a subproject was also used to add a
member to the subproject, and you do not include this change package, you will
get an incomplete subproject.

How Subproject Changes Are Applied Implicitly

If a member operation implies the creation or addition of a subproject, MKS Source tries to
re-create the source environments project tree in the target environment. If part of the source
environments tree has been dropped, MKS Source attempts to re-create it based on the
nearest appropriate subproject.
A subproject is added only if it is located under the project location for the target project
environment and is configured the same way as the parent project. When added to a variant,
the subproject is added as a variant subproject on the same development path as the parent
project it is being added to. Apply CP does not detect or add any missing shared subprojects,
even if they are present in the source project.
The creation or addition of subprojects takes place early in the Apply CP process. If you
decide to cancel the operation when you are asked to confirm the changes to be applied, the
subproject changes remain in the target environment.

140

Using the Apply CP Command

Applying a Change Package With No Dependencies

This example illustrates a simplified application of the Apply CP command in the main trunk
of development for the Aurora project (f:/Aurora_Project/project.pj). The project
member, main.c, includes a bug fix that allows the printing of version information. Item 21
addresses the bug fix and is associated with the file main.c (revision 1.2) through change
package (CP) 21:1.
The buildmaster wants to pick up the changes that address the bug fix and apply these to a
variant project, Aurora_Variant_1_0. In the variant project, main.c is at revision 1.1.
Aurora_Project

main.c

1.2 CP 21:1

Aurora_Variant_1

main.c

1.1

1.1 CP 20:1

Before applying a change package (simple case)

To get the bug fix for the variant project (f:/Aurora_Variant_1_0/project.pj), the
buildmaster uses the si applycp command to apply CP 21:1:
si applycp -P f:/Aurora_Project/project.pj --devPath
Aurora_Variant_1_0 21:1

The command runs as follows:

Applying change packages...
21:1
***The following set of operations will be performed:
Project: f:/Aurora_Project/project.pj[Aurora_Variant_1_0]
Member main.c: update member revision to Revision 1.2
Are you sure you wish to proceed? [yn]<n>: y

Because CP 21:1 included only an updating of main.c from revision 1.1 to revision 1.2, Apply
CP updates the revision for main.c from 1.1 to 1.2 in the variant project

141

Chapter 5: Change Packages

.

Aurora_Project

main.c

1.2 CP 21:1

Aurora_Variant_1

main.c

1.2

1.1 CP 20:1

After applying a change package (simple case)

Using the Apply CP Backfill List

If the change packages you are applying are dependent on other change packages, the Apply
CP command presents you with a backfill list that includes all of the required change
packages. The following examples illustrate how the backfill list works in the Apply CP
command.
In the Apply CP operation, you must accept the entire backfill list or the operation fails. If
you do not want to accept the entire backfill list, you must instead perform a Resync CP
operation. The Resync CP command allows you to merge around unwanted revisions in your
Sandbox. For more information on resynchronizing change packages, see Using the Resync
CP Command on page 151.
NOTE The backfill list is not used when applying subproject operations. You must
explicitly specify all change packages containing subproject operations that you
wish to apply or select Implicitly for the Subproject Propagation option.

Using the Backfill List to Include Required Previous Revisions

In this example, the main project, f:/Aurora_Project/project.pj includes two bug fixes.
Item 21 addresses the first bug fix and is associated with the file main.c (revision 1.2)
through change package (CP) 21.1. Item 22 addresses the second bug fix and is associated
with the file main.c (revision 1.3) through CP 22:1.
The buildmaster wants to pick up the changes that address the second bug fix and apply
these to a variant project, Aurora_Variant_1_0. In the variant project, main.c is at revision
1.1.

142

Using the Apply CP Command

Aurora_Project

main.c

1.3 CP 22:1

Aurora_Variant_1

main.c

1.1

1.2 CP 21:1
1.1 CP 20:1

Before applying a change package that requires backfilling

To pick up the bug fix for the variant project, the buildmaster uses the si applycp
command to apply CP 22:1. By default, the backfill option is set to Entire Change Packages (-backfill=cp). The buildmaster enters the command:
si applycp -P f:/Aurora_Project/project.pj --devPath
Aurora_Variant_1_0 22:1

The command runs as follows:

Applying change packages...
22:1
The following warnings have occurred:
------------------The change package(s)
21:1 -- main.c(1.2)
are required in order to apply this list of change packages.
They will be automatically added to the list, since the backfill
option is set to Entire Change Package(cp).
-------------------*** The following set of operations will be performed:
Project: f:/Aurora_Project/project.pj[Aurora_Variant_1_0]
Member main.c: update member revision to Revision 1.3
Are you sure you wish to proceed? [yn](n): y

If you choose to proceed, you receive a notification listing the updates that have been
processed, and any updates that were not processed.
Apply CP updates the revision for main.c from 1.1 to 1.3 in the variant project. Revision 1.2
is automatically added to the variant project because it was accepted as part of the backfill list
(CP 21:1).

143

Chapter 5: Change Packages

Aurora_Project

main.c

1.3 CP 22:1

Aurora_Variant_1

main.c

1.3

1.2 CP 21:1
1.1 CP 20:1

After applying a change package that requires backfilling

Using the Backfill List to Include a New File

This example illustrates how Apply CP handles a more complex change packageone that
contains code modifications that are dependent on a new file. In this example, main.c is
revised to call a value defined in a new file, main.h.
The developer working on the code has checked in all these changes and associated both files
with CP 22:1. Development work then continues to include a further revision to main.c
which is checked in at revision 1.3 and associated with CP 23:1. The main project therefore
contains main.c at revision 1.3 and main.h at revision 1.1.

Aurora_Project

main.c

1.3 CP 23:1

Aurora_Variant_1

main.c

1.1

1.2 CP 22:1
1.1 CP 21:1
main.h

1.1 CP 22:1

Before applying a change package that contains an associated file

The buildmaster now wants to incorporate the changes into the variant project. The
buildmaster therefore uses the Apply CP command to apply CP 23:1 to
Aurora_Variant_1_0. This updates main.c to revision 1.3 and adds main.h revision 1.1.

144

Using the Apply CP Command

Aurora_Project

main.c

1.3 CP 23:1

Aurora_Variant_1

main.c

1.3

main.h

1.1

1.2 CP 22:1
1.1 CP 21:1
main.h

1.1 CP 22:1

After applying a change package that contains an associated file

Applying Back Revisions Only

The default backfill option for Apply CP is to propagate all entries required by the specified
change package, including all entries in any change packages in the backfill list. However,
there is a special case where you might want to backfill by Back Revisions Only. This option
only updates the target environment based on the directly associated revisions. It does not
process any change packages that are associated with intermediate revisions.
For example, if you chose the Back Revisions Only option in the previous example (Using
the Backfill List to Include a New File on page 144) main.c would still be updated to 1.3, but
but main.h would not be propagated since it is an entry in a backfill change package.
This option is useful where you are propagating a file that collects information and therefore
tends to be affected by all changes. In this case, you are only interested in the latest revision,
not the underlying changes that occurred as a result of all the changes to related files.

Using a Propagation Change Package with Apply CP

You can use another change package to record all the member and subproject changes made
by an Apply CP operation. A change package used for this purpose is called a propagation
change package.
NOTE If your administrator has set up change packages to be mandatory, you must
specify a propagation change package.

Using a propagation change package makes it easier to track what changes have been
propagated and to propagate the same changes to multiple variants. Any change packages
that the applied change package is dependent on which have already been applied to the
project by a previous Apply CP operation do not appear in the backfill list. You receive a
warning message about the change packages that have already been applied.

145

Chapter 5: Change Packages

You do not create a propagation change packageyou create a normal change package and
propagation information is recorded in the change package when you specify it during an
Apply CP operation. For the greatest level of control in isolating changes, it is recommended
that you start with an empty propagation change package. When the propagation change
package contains no previous entries, the only additions will be those that specifically relate
to the changes in question.
If reviews are mandatory, the changes made by an Apply CP operation are recorded as
pending entries in the propagation change package. The change package must then be
submitted, which starts the review process (see Change Package Reviews Overview on
page 128).
Once a propagation change package has been applied, you can see the list of change packages
that it propagated in the Change Package view. For example, if you created propagation
change package 10.6 to record changes made by an Apply CP operation, you would see the
propagated change packages in the Change Packages that this Change Package propagated
field on the Propagation tab of the Change Package view for 10.6. If you then applied
propagation change package 10.6 to a different variant, and created propagation change
package 10.8 to record the changes, you would see change package 10.8 listed in the Change
Packages that this Change Package was propagated by field for 10.6.

Resolving Conflicts
The Apply CP command detects as potential conflicts:

files that have been dropped or moved, but would be re-added by Apply CP due to a
revision update on that file in the set of change packages processed

file additions due to a revision update in the set of change packages processed, where an
alternate member using the same backing archive already exists

File additions due to an explicit request to add them from the set of change packages
processed are not considered conflicts.
If merging is required, the Apply CP operation fails. You need to use the Resync CP
command to merge files and resolve merge conflicts, tracking the changes and resolved
conflicts in a propagation change package. For more information, see Using the Resync CP
Command on page 151.

Apply CP Procedure
This section describes the step-by-step procedures required to perform the Apply CP
command in the GUI.

146

Using the Apply CP Command

CAUTION You cannot undo an Apply CP operation. Therefore, before applying any
change packages, you should checkpoint your project. You can then use the Restore
Project command to revert to the earlier version of the project. For more information
on checkpointing, see Checkpointing a Project on page 18. For more information
on restoring a project, see Restoring a Project on page 22.

NOTE A helpful practice prior to using Apply CP, is to start with a Resync CP
operation in a Sandbox, and then build and test the results, even if no merges are
required. Because the operation may be creating a combination of source code that
has never existed before, this step ensures that the results will build and work. Once
you are certain of the results, you can then use the Apply CP command and work
directly in the project. For more information, see Using the Resync CP Command
on page 151.

To apply a change package in the GUI

1 Select Change Package > Apply.
2 If you have a project selected, proceed to step 10. If you do not have a project selected,
the Apply Change Packages wizard opens, displaying the Specify the Project panel.
3 Click Select. The first panel of the Specify the mainline or variant project wizard displays.
4 Enter a project name and proceed to step 6, or click Select to choose a project from the

list.
For detailed information about entering project paths, see the MKS Integrity Client 2007
Getting Started Guide.
NOTE If you are applying the change package(s) to a variant or build subproject,
only enter the path and name of the root project in this field. You specify the
subproject later in the procedure.

For detailed information about selecting projects, see the MKS Integrity Client 2007
Getting Started Guide. Click OK.
5 Click Next. The second panel of the Specify the mainline or variant project wizard

displays.
6 Select the type of project you want to apply the CP(s) to by clicking a project type option.

The available types are:

Normal applies the CP (s) to a project based upon the current state of the project.
Click Finish and proceed to step 10.

Variant applies the CP(s) to a project based on a specific development path.

147

Chapter 5: Change Packages

From the Development Path Name list, select a development path name, for
example, Aurora_Beta_Variant.
NOTE The Variant option is unavailable if there are no available development paths.
To create a development path, see Creating a Development Path on page 28.

7 If you are applying the CP(s) to a subproject, click Next to select a subproject. The third
panel of the Specify the mainline or variant project displays.
8 Expand the project to select the specific subproject that you want to apply the CP(s) to.
Click Finish.
NOTE There are rules that control what project configuration you can jump to. For
more information, see the MKS Integrity Client 2007 Getting Started Guide. If your
selection breaks any of the rules, you cannot apply the change package(s).

9 Click Next. The Apply List panel of the Apply Change Packages wizard displays.

10 To add change packages to the Apply List, click Find. The Find Change Package dialog

box displays.
If you know the ID number of the change package(s) or item(s) you want to add, you can
also enter that number in the Add to List field and then click Add. For multiple numbers,
include a space between each change package ID.
11 Select filter criteria for the change package, or if the MKS Integrity integration is enabled,

select a query. For more information, see Finding Change Packages on page 122.

148

Using the Apply CP Command

12 After you specify the filter criteria or query, click OK. The Select Change Package(s)

dialog displays, populated with the filter or query results.

NOTE When using the Apply CP command, you can only apply closed change
packages. Because you cannot apply an open change package to a project, the option
for Allow Open Change Packages is disabled by default. If you need to work
with an open change package, you must use the Resync CP command. For more
information on resynchronizing change packages, see Using the Resync CP
Command on page 151.

For detailed information on the Select Change Packages dialog, see the online help.
13 To review details of a change package before applying it, right click the change package
and select View Change Package Details. The Change Package view displays for the

selected change package.

14 To add the change packages selected, click OK. The added change packages are

displayed in the Apply List.

To remove a change package from the Apply List, highlight the change package (or press
CTRL and click to highlight multiple members), and then click Remove.

149

Chapter 5: Change Packages

15 To select the command options you want MKS Source to use when carrying out the
Apply CP operation, click Options.

For detailed information on the Apply CP options, see the online help.
16 To record changes to members as a result of the Apply CP operation in a propagation
change package, select a change package in the Change Package field or create a new

one. Only open change packages are available for selection. For more information, see
Using a Propagation Change Package with Apply CP on page 145.
For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
17 To apply the list of change packages to the project, click Finish. If additional change
packages are required to apply the selected change package, the Confirm Project Backfill

dialog box displays.

NOTE Any change packages that the applied change package is dependent on which
have already been applied to the project by a previous Apply CP operation do not
appear in the backfill list. For operations involving a large number of change
packages, it may take several seconds for these calculations to be performed and the
backfill dialog box to display. You receive a warning message about the change
packages that have already been applied.

18 To accept the backfill list and have the listed change packages also applied to the project,
click Yes.

You must accept the backfill list as presented or the Apply CP operation cannot be
completed. If you do not want to accept the entire list, you must use the Resync CP
command instead. For more information on resynchronizing change packages, see
Using the Resync CP Command on page 151. The Confirm Change Package
Application dialog box displays indicating the operations to be performed.
19 To complete the operation(s) and apply the selected change package(s), click Yes. The
Change Package Processing Complete dialog displays, listing the updates that have

been processed, and any updates that were not processed.

Click Save to save the contents of the dialog in an external text file.
NOTE To see any change packages that have been applied between two revisions of
a project, use the View Project Differences command and, under Preferences, select
the option for Show Applied Change Packages. For more information on viewing
project modifications, see Viewing Project Differences on page 25.

150

Using the Resync CP Command

Using the Resync CP Command

You use the Resync CP command to preview the changes listed in change packages in the
context of a Sandbox before propagating them to the project. The Resync CP command
searches all files related to a selected change package, and all the change packages that may
be associated with the related files. Resync CP is most useful for incorporating new software
features or bug fixes during the software development process.
Resync CP provides additional options beyond those available for Apply CP, including
options for allowing open change packages, merging, resolving conflicts, and continuing the
resync operation when errors are encountered. MKS Source allows you to run the Apply CP
command first and then, if required, run the Resync CP command to perform any required
merge operations.
NOTE If you attempt to perform a Resync CP command on a member that was
previously dropped from a project, MKS Source instructs you to manually re-add
the member.

While working in your Sandbox, you can also use the Resync By CP command, which only
processes the change packages associated with the member you are resynchronizing. For
more information, see Using the Resync By CP Command on page 164.
The following sections describe how the Resync CP command works and how you can use
the Resync CP command in your development environment. The topics covered are:

Using Resync CP in Your Development Environment on page 151

Using the Resync CP Backfill List on page 152

Applying Changes From a Variant on page 155

Applying Change Packages From Two Variants on page 157

Using a Propagation Change Package with Resync CP on page 157

Resolving Binary Conflicts on page 160

Resync CP Procedure on page 160

Using Resync CP in Your Development Environment

This section provides an example to show how Resync CP can be used in your environment.
The example also illustrates how Resync By CP can be used in a developers Sandbox.
The development of a new release typically involves working on hundreds of files that span
many MKS Source projects. Whenever a fix is made, or a feature added, it may require the
manipulation of a single file, or many different files across multiple projects. A fix or new
feature may also include new dependencies within the source code.

151

Chapter 5: Change Packages

If developers resynchronize only a single file into their Sandboxes, their builds may break
because of new dependencies in the code. Such broken builds cause delays and prevent the
team from completing their work on time. However, it is possible to avoid this lost time by
using the Resync CP command.
Resync CP allows developers to specify a change package and have all changes associated
with that change package resynchronized into their Sandboxes. The commands save
development time because they:

automatically search for the required files

determine what other change packages the selection is dependant on (this is known as
the backfill list) and also resynchronize those change packages into the Sandbox

If the developer is working on a file conflict, Resync CP also merges new information into a
file. The merge operation ensures that the Sandbox is up-to-date and that no changes are lost.
The Resync CP command also allows a developer to remove a bug fix or feature that is
incomplete or not working.

Using the Resync CP Backfill List

If the change packages you are applying are dependent on other change packages, the Resync
CP command presents you with a backfill list that includes all of the required change
packages. The following examples illustrate how the backfill list works in the Resync CP
command.
NOTE The backfill list is not used when resyncing subproject operations. You must
explicitly specify all change packages containing subproject operations that you
wish to resync or select Implicitly for the Subproject Propagation option.

Using the Backfill List to Include Required Previous Revisions

The following example illustrates a simplified application of the Resync CP command in the
main trunk of development for the Aurora project (Aurora_Project.pj).
The project member tool.c includes a bug fix for item 24 and is associated with the file
tool.c (revision 1.7) through change package (CP) 24:1.
The developer wants to pick up the changes that address the bug fix and apply these in a
Sandbox. In the developers Sandbox, tool.c is at revision 1.2.
To apply the bug fix in the Sandbox, the developer uses the si resynccp command to apply
CP 24:1 as follows:
si resynccp -S c:/Aurora_Project/project.pj 24:1
Applying change packages...
24:1
The following warnings have occurred:

152

Using the Resync CP Command

------------------The change package(s)

20:1
21:1
22:1
23:1

-----

tool.c(1.3)
tool.c(1.4)
tool.c(1.5)
tool.c(1.6)

are required in order to apply this list of change packages. They will
be automatically added to the list, since the backfill option is set
to Entire Change Package(cp).
-------------------*** The following set of operations will be performed:
Project: f:/Aurora_Project/project.pj
Sandbox: c:\Aurora_Sandbox\project.pj
Member tool.c: resynchronize to Revision 1.7
Are you sure you wish to proceed? [yn]<n>: y

In this case, the Resync CP command updates the working file revision for tool.c from 1.2
to 1.7 in the Sandbox. This is done by checking out tool.c at 1.7 into the Sandbox. The
changes made from revisions 1.3 through 1.6 are already included in this checked out file.

Using the Backfill List to Merge Around Previous Revisions

You can merge around some or all of the required change packages that are presented to you
in the backfill list.
The main project, Aurora_Project.pj, now includes an additional bug fix for project
member, tool.c. Item 23 addresses that bug fix and is associated with the file tool.c
(revision 1.6) through CP 23:1.
The developer wants to pick up the changes that address the bug fix and apply these in a
Sandbox. In the developers Sandbox, tool.c is at revision 1.2.
Aurora_Project

tool.c

1.6 CP 23:1

Aurora_Sandbox

tool.c

1.2

1.5 CP 22:1
1.4 CP 21:1
1.3 CP 20:1
1.2 CP 19:1
1.1 CP 18:1

Picking up a specific change using the Resync CP command

153

Chapter 5: Change Packages

To pick up the bug fix, the developer uses the si resynccp command in a Sandbox. The
developer wants to decide on the specific change packages to include in the operation, so he
or she sets the backfill option to Ask to Specify (--backfill=ask). The command runs as
follows:
si resynccp -S c:/Aurora_Sandbox/project.pj --backfill=ask 23:1
Applying change packages...
23:1
*** The following list of change packages are used by revisions
before the revision that you require. Each change package is given,
along with the revisions which require them:
20:1 -- tool.c(1.3)
21:1 -- tool.c(1.4)
22:1 -- tool.c(1.5)
Reply with:
y to pick up all these change packages, along with their
associated changes,
s to skip all these revisions and merge around them (default)
c to cancel the command
or a space separated list of change package identifiers from the list
given to be *removed* from the list [y|s|c|#...]?
NOTE When selecting the change packages from the backfill list in the command
line interface, you enter the numbers for the change packages you want to exclude
from the resync operation; in the GUI, you select the change packages you want to
include in the resync operation.

The developer decides to merge around all the intermediate change packages and selects s
(skip). The command continues as follows:
The following warnings have occurred:
------------------The following members require a merge to be performed:
tool.c
You have not specified a change package, so merged members will not be
locked.
-------------------*** The following set of operations will be performed:
Project: f:/Aurora_Project/project.pj
Sandbox: c:\Aurora_Sandbox\project.pj

154

Using the Resync CP Command

Member tool.c: merge around differences: picking up revisions

1.2 through 1.6, excluding revisions 1.3, 1.4, 1.5, by
checking out Revision 1.2 into the working file, and merging
in the differences between Revision 1.6 and Revision 1.2 with
the differences between Revision 1.5 and Revision 1.3.
Are you sure you wish to proceed? [yn](n): y

If you choose to proceed, you receive a notification listing the updates that have been
processed, and any updates that were not processed.
Resync CP updates the working file revision for main.c by checking out revision 1.2 and
then merging into the working file the differences between 1.2 and 1.6. The intermediate
revisions are not added to the Sandbox because the skip option was selected. Because the
resync operation does not use a propagation change package to record the changes, the
merged member is not locked.

Applying Changes From a Variant

Working on a variant allows you to create a specific change, test it, and then bring that
change back into the main trunk of development. Within reason, this can be done even when
the main trunk includes further new development.
For example, a patch created in a variant project is needed in the master project. The file
utility.chas a head revision of 1.4 in the project. In the variant project, the file
utility.c version 1.2 is checked out to revision 1.2.1.1 and the code is revised. The file
utility.c is then checked in at 1.2.1.2 and associated with CP 5:1.
Variant Project

Master Project

utility.c

1.4
1.3

1.2.1.2

1.2
1.1
utility.c

1.2
1.2.1.1

Moving a patch from a variant project to a master project

Moving the patch from the variant to the master requires a three-way merge operation using
Resync CP. Because the master project contains further new development, updating the head
revision of utility.c from 1.4 to 1.2.1.2 would cause the new development work in
revisions 1.3 and 1.4 to be lost.

155

Chapter 5: Change Packages

Master Project

utility.c

1.4

Variant Project

Master Sandbox

utility.c

1.3

1.2.1.2
1.4

1.2.1.2

1.2
1.1

utility.c

1.2
1.2.1.1

The default Resync CP operation

In this situation, you must use the Merge On Branch option (--mergeOnBranch). This option
essentially allows the changes on the branch to be merged into the head revision file.
Selecting Merge On Branch allows MKS Source to perform a differencing between revision
1.2 and 1.2.1.2 and then merge the result into revision 1.4. Once the Resync CP operation
completes, the file must then be checked in to finalize the changes in the project.
Master Project

Master Sandbox

Variant Project

resync
utility.c

1.4
1.3
1.2
1.1

1.4
merge

utility.c

1.2.1.2

differences
1.2
utility.c

1.2.1.1

Using Resync CP with the Merge On Branch option

Cross-Branch Changes
The Ignore Cross-Branch Entries option allows you to use the most recent revision when
there are revisions of the same member on two different branches. This option can be used to
accommodate the situation where you need to propagate changes from a variant that has
temporary branches which were created in order to bypass locks. In this case, you do not
want to include the changes on the branches, which have already been merged into the
variant.

156

Using the Resync CP Command

Applying Change Packages From Two Variants

Another situation that warrants special consideration is the case where two change packages
must be applied from different variants. Unless the correct procedure is used, Resync CP will
fail because too many merges are required.
For example, the master project contains the file patch.c at revision 1.4. The variant project
used by the buildmaster contains a fix (patch.c, revision 1.2.1.2, CP 9:1) that is being rolled
out for a product patch. The variant project for the Maintenance Development team also
includes a bug fix for patch.c at revision 1.3.1.2, and this revision is associated with CP 10:1.
Both fixes are required for the master project.
Variant Project 1

Master Project

Variant Project 2

CP 10:1

CP 9:1

1.3.1.2
patch.c
1.3
1.3.1.1

patch.c

1.2.1.2
1.4
1.3
1.2
1.1

1.2
patch.c

1.2.1.1

Performing a Resync CP operation on two change packages from different variants

There are only two ways to successfully complete the preceding scenario without restrictions:
address it manually, or perform Resync CP and Apply CP twice (once for each change
package), checking in the merged changes at the head revision after each operation.

Using a Propagation Change Package with Resync CP

You can use another change package to record all the member changes made by a Resync CP
operation. A change package used for this purpose is called a propagation change package.
NOTE Even if your administrator has set up change packages to be mandatory, you
do not need to specify a propagation change package for a Resync CP operation.

You do not create a propagation change packageyou create a normal change package and
propagation information is recorded in the change package when you specify it during a
Resync CP operation. For the greatest level of control in isolating changes, it is recommended
that you start with an empty propagation change package. When the propagation change
package contains no previous entries, the only additions will be those that specifically relate
to the changes in question.
The propagation change package is populated with all the member and subproject changes
performed and the change packages propagated as a result of the resynchronization. You can
discard undesirable member changes and add resolved merge conflicts to the propagation

157

Chapter 5: Change Packages

change package. You can also add entries to the propagation change package as required
using MKS Source commands, for example, Check Out, Move, Rename, Update Member
Revision, or Create Subproject.
Once all changes are completed, the propagation change package can then be submitted to
update the project.
NOTE You can also submit the propagation change package without updating
member revisions; then the Buildmaster applies the propagation change package at
the time the software is built.

Entries in the propagation change package supersede corresponding entries in the

resynchronized change packages. Thus, if you perform a merge from a branch and check the
result into a propagation change package, the resulting revision supersedes any entries in the
listed change packages that might be on branches.

Advantages of Using a Propagation Change Package

Using a propagation change package ensures that other developers can apply the same set of
change packages without duplicating the effort of running the Resync CP command and
resolving any errors or merge conflicts.
Propagation change packages are also useful for assisting buildmasters to complete their
work. When an Apply CP operation has failed, developers can use the Resync CP command
on the same change package, identify the dependencies and required merges, and include all
the necessary changes in a single propagation package.
Propagation change packages allow you to incrementally propagate changes between
development paths by repeatedly using the Resync CP command to collect project changes,
rather than performing one large Resync CP operation that can take a long time.
If you use a propagation change package, any change packages that the applied change
package is dependent on that have already been applied to the project through a previous
Resync CP operation do not appear in the backfill list. You receive a warning message about
the change packages that have already been applied.
It is important to note that while Resync CP can be used to apply a propagation change
package, the results may not always be acceptable. For example, if your bug fix is in an
existing project member, there would already be an archive for that member in the project. As
a result, Resync CP would add the modified member on a branch. This additional branching
might not be acceptable in your project.

158

Using the Resync CP Command

Example of Using a Propagation Change Package

The abcBusiness company has two development teams:

a Product Team that develops new features and software for the main release cycle

a Maintenance Development Team that maintains the released software and addresses
bugs that are identified by customers

The Product Team (PT) implements new features and designs on the main development
path.
The Maintenance Development Team (MDT) works on a variant development path for
Release 2.0 and fixes any problems in the newly-released product. The main goal of this team
is to produce bug fixes for Release 2.0a. The work process for the MDT is:

A bug is reported by a customer.

A change package for the bug is created, in this case it has the container ID 1204. The
MKS Integrity integration is enabled, so an item is created and then associated with a
created change package.

An MDT developer is assigned to fix the problem.

The MDT developer creates a change package.

The MDT developer makes the necessary changes and tests the code.

The MDT developer checks the modified files back into the variant project, making sure
to associate the files with change package 1204:1.

In this case, all the work of the MDT developer is now checked into the variant development
path and will be part of release 2.0a. However, the MDT bug fix work needs to be transferred
back to the main development path so that it can be incorporated into the next product
release. A PT developer needs to pick up the changes that address the bug fix and apply them
in a Sandbox. The Resync CP command is the best option for applying the new fix.
The PT developer creates a second change package, 1204:2 for the same item. The second
change package includes the summary Applied fix to main development path. The PT
developer starts the Resync CP command, selects the main development Sandbox, and the
first change package1204:1in this item. The second change package1204:2is used as a
propagation change package.
Once all merge conflicts have been resolved, the developer submits the propagation change
package and MKS Source applies the changes from the referenced change packages.
The bug fix is now addressed in both the main and variant development paths, ensuring that
the problem is fixed in the Release 2.0a and the next major product release.

159

Chapter 5: Change Packages

Resolving Binary Conflicts

When a conflict between two revisions of a binary file is encountered, MKS Source replaces
the Sandbox working file for that member with the destination revision and marks it as a
conflict. The destination revision displays in the propagation change package as a Deferred
Check In entry (representing a deferred checkin of the working file). For example, if revision
1.1 and 1.1.1.1 are both update revision entries of a binary member in a change package that
require a merge with member revision 1.2, then the contents of revision 1.1.1.1 are used for
the Sandbox working file of member revision 1.2. Revision 1.2 displays as a Deferred Check
In entry in the propagation change package. No comparison of binary file content is
provided. When the change package is submitted (or member checked in) the member
revision is 1.3.
You can resolve the conflict in one of the following ways:

Use Target Revision

Submit the changes in the propagation change package, thereby checking in the
destination revision for the binary member (or manually submit the deferred checkin of
the destination revision).

Perform Manual Binary Merge

Using a third-party tool outside of MKS Source, perform a binary merge on the affected
member. Then submit the changes in the propagation change package (or manually
submit the deferred checkin of the destination revision).

Use Original Revision

Discard the Deferred Check In entry corresponding to the conflict, effectively using
the original revision instead of the destination revision. To resolve conflict, indicate the
desired revision by using a Deferred Update Revision operation that specifies the
desired revision.

Resync CP Procedure
This section describes the step-by-step procedure required to perform the Resync CP
command in the GUI.
Before performing the Resync CP command:

Make sure all working files are in synch with the server

Close all change packages you want to use for merging into the target environment

To resynchronize a change package in the GUI

1 Select Change Package > Resynchronize. The Select a Sandbox dialog box displays.
2 Select the Sandbox you want the Resync CP command to operate on.

160

Using the Resync CP Command

3 Click OK. The Resynchronize Change Packages wizard opens, displaying the Apply List

panel.

4 To add change packages to the Apply List, click Find. The Find Change Package Panel

displays.
If you know the ID number of the change package(s) or item(s) you want to add, you can
also enter that number in the Apply to List field and then click Add. For multiple
numbers, include a space between each change package ID.
5 Select filter criteria for the change package, or if MKS Integrity is enabled, select a query.
For more information, see Finding Change Packages on page 122. The Select Change
Package(s) dialog box displays, populated with the filter or query results.

NOTE Open change packages are allowed when resynchronizing change packages.
The option for Allow Open Change Packages is enabled by default. However, you
cannot resynchronize open change packages if you are recording changes in a
propagation change package.

For detailed information on the Select Change Package(s) dialog box, see the online
help.

161

Chapter 5: Change Packages

6 To review details of a change package before including it in the resync operation, right
click the change package and select View Change Package Details. The Change Package

view displays for the selected change package.

7 To add the change packages to the Apply List and return to the Apply List panel, click
OK. The list of change packages displays in the Apply List panel.

To remove a change package from the Apply List, highlight the change package(s) and
click Remove.

8 To record changes to members as a result of the Resync CP operation in a propagation

change package, select a change package in the Change Package field or create a new

one. Only open change packages can be selected. For more information, see Using a
Propagation Change Package with Resync CP on page 157.
For information on the Change Package field, see Specifying a Change Package for an
Operation on page 118.
For information on creating a change package, see Creating a Change Package on
page 117.
9 To select the command options you want MKS Source to use when carrying out the
Resync CP operation click Options. For detailed information on the Resync CP options,

see the online help.

162

Using the Resync CP Command

10 To run the Resync CP command with the selected options, click Finish. If you selected
the Backfill option Ask to Specify, the Select Change Package(s) for Backfill dialog

box displays.
NOTE If you specified a propagation CP, any change packages that the applied
change package is dependent on which have already been applied to the project by a
previous Resync CP operation do not appear in the backfill list. You receive a
warning message about the change packages that have already been applied.

11 To review details of a change package before including it in the resync operation, right
click the change package and select View Change Package Details. The Change Package

view displays for the selected change package.

12 Select the change package(s) you want to include in the resync operation and click OK.
The Confirm Change Package Application dialog box displays, providing information on

the operations to be performed, and any warnings.

13 To complete the Resync CP operation, click Yes.

Depending on the preferences you have set for the Resynchronize command (see the
MKS Integrity Client 2007 Getting Started Guide), you may be prompted to confirm
overwriting your working files for the members being updated. If a merge is required,
the Resynchronize command preferences also determines the type of merge used and
the actions MKS Source takes in the event of a merge conflict.
14 MKS Source completes the Resync CP operation and the Change Package Processing
Complete dialog displays, listing the updates that have been processed, and any updates

that were not processed.

To save the contents of the dialog to an external text file, click Save.
NOTE To see any change packages that have been applied between two revisions of
a project, use the View Project Differences command and, under Preferences, select
the option for Show Applied Change Packages. For more information on viewing
project modifications, see Viewing Project Differences on page 25.

163

Chapter 5: Change Packages

Using the Resync By CP Command

The Resync By CP command is primarily a tool for developers. When you want to
resynchronize files in your Sandbox, you usually do so by choosing individual files and then
using the Resynchronize (si resync) command. However, if the files you are
resynchronizing have changes that are linked to other files, the standard resync operation
would not include those related files. To resynchronize all related files, you would have to
manually search for all the changes associated with the change package on the member you
are resynchronizing.
The Resync By CP command automates this process by searching the change package
specified on the member revision you are resynchronizing and then bringing the changes
from the project to your Sandbox.
While the Resync CP command searches all files related to a selected change package, and all
the change packages that may be associated with the related files, the Resync By CP
command only processes the change packages associated with the member you are
resynchronizing.
To Resync By CP, from a Sandbox view, select one or more members that contain member
deltas, and select Member > Resynchronize By Change Package.
Depending on the preferences you have set for the Resynchronize command (see the
MKS Integrity Client 2007 Getting Started Guide), when you Resync By CP, the Confirm
Overwrite Working File dialog box displays. If you want to retain your changes in the working
file, click No (No to All for multiple members). If you want to compare your working file with
the revision you are resynchronizing it with, click Differences. To merge and resynchronize
the member, click Yes (for multiple members, click Yes to All).

How Does the Resync By CP Command Work?

In a Resync By CP operation, the change package list is computed based on the member you
are resynchronizing (whereas in a Resync CP operation, you explicitly state the list of change
packages).
The functioning of Resync By CP is affected by the settings you choose for the Resync CP
command under File > Edit Preferences. This includes the way the backfill list operates. For
example, if you specify ask, a backfill list displays. For more information on options for
Resync CP, see Using the Resync CP Command on page 151.

When Should I Use the Resync By CP Command?

Developers should use Resync By CP when they want to ensure that they have all dependent
changes associated with a member revision, even if these changes are contained in other files.
For example, a developer needs to check out (locked) a file and modify it. The developer
finds that other revisions have been checked in since the member was resynchronized in the

164

Using the Resync By CP Command

Sandbox. Because the Sandbox is quite large and contains many unrelated changes, the
developer does not want to perform a standard resynchronization. The Resync By CP option
can be used in this situation.
NOTE The functioning of Resync By CP is affected by the settings you choose for the
Resync CP command under File > Edit Preferences. The Resync By CP operation
always sets the backfill list to Entire Change Packages (cp).

Example of Resync By CP
Consider a case where a developer makes a change to project member main.c, and that
change requires an additional file, main.h. A standard resync operation for main.c would
not capture main.h.
In the initial stage, Sandboxes pointing to the project include main.c at revision 1.1.
Project

main.c

Developer 1 Sandbox

main.c

1.1 CP 21:1

1.1 CP 21:1

Developer 2 Sandbox

main.c

1.1 CP 21:1

Before using Resync By CP in a development environment

Developer 1 then performs the following tasks:

checks out and locks main.c, revision 1.1

makes an update to main.c that requires the main.h file

checks in the changes to main.c and associates these changes with CP 22:1

also against CP 22:1, adds main.h as a member of the project

165

Chapter 5: Change Packages

Project

main.c

1.1 CP 21:1
1.2 CP 22:1

main.h
Developer 1 Sandbox

1.1 CP 22:1
Developer 2 Sandbox

main.c

1.1 CP 21:1
1.2 CP 22:1

main.c

main.h

1.1 CP 22:1

main.h

1.1 CP 21:1
CP 22:1

After using Resync By CP in your Sandbox to capture all changes (including new
files) contained in the associated change package

When Developer 2 uses the Resync By CP command to resync main.c, his Sandbox is
updated to show that main.c is at 1.2 and that main.h has also been added to the project as
part of CP22:1.
IMPORTANT If the working file of the member you are resyncing is modified,
MKS Source asks you to confirm that you want to merge your modifications into the
working file. For more information on merging on a resync, see Merging Modified
Working Files on page 100.

166

APPENDIX

MKS Source Terms

Definitions of Common MKS Source Terms

The administrator installs MKS Source; defines and customizes projects
and policies; and creates and manages user accounts, allowing users to access the
program.

administrator

archive description The archive description contains text that describes the purpose of
an archive. Each time you create an archive, you can assign a description to it.

An archive is a file containing the history of a member (a record of all the

changes made to it since it was put under revision control). From the information
contained in the history, MKS Source can reconstruct any previous version of the
member.
archive

A branch is a revision path that diverges from the main line of development (or
trunk) in a member or project history.

branch

A propagation change package is a change package that,

in addition to recording a group of changes, also records the change packages(s) that it
propagated to a project.
change package (propagation)

A change package review is a review of changes by specified

reviewers before the changes are committed to the server repository.
change package review

change package reviewer A change package reviewer is a user specified by your

administrator to review change packages containing members associated with specific
projects. The reviewer may be individually specified or a member of a specified reviewer
group. In the case of a reviewer group, any member of that group casts an accept or
reject vote on behalf of the entire group.

A change package watcher is a user specified by your

administrator who is notified when a reviewed change package is closed after being
successfully committed to the repository. Change package watchers may be individually
specified or a member of a specified watcher group.

change package watcher

A change package is a group of changes made by a single user that can

be considered a logical unit of work. Only the creator of a change package can add
entries to that change package. Change package entries are added when you specify a
change package while performing member operations.

change package

167

Appendix : MKS Source Terms

Checking in a member creates a new revision of a member and adds it to the

member history. When a member is checked in to a revision other than the head revision or a
branch tip revision, a new branch is created.

check in

check out Checking out a member extracts the contents of a revision in a member history
and copies it to the working file. You can check out any revision by specifying either its
revision number or label.

Checkpointing a project creates a new revision of the project and adds it to

the project history. When you checkpoint a project, you save all the information needed to
recreate the project completely as it existed when you checkpointed it. The saved information
includes the project structure and the list of members with their revision numbers.
checkpointing

A development path is an identifier given to a new branch of software

development. Changes made through the new development path are kept separate from the
main development trunk unless you choose to merge them later.
development path

drop (a project) To drop a project means that the project is no longer registered with the
MKS Integrity Server. Dropped projects can still be accessed as read-only from the Change
Package and Locks views until the project is purged or reclaimed by your administrator.
freezing Freezing a member places it in a state that prevents changes from being made to
the member information that resides in the project file. For example, you cannot update the
member revision or change the attributes of a frozen member. Freezing is the opposite of
thawing a member.
importing (a project or member) Importing a project or member registers it with the
MKS Integrity Server. Once a project or member is imported, MKS Source commands can be
performed upon it.
keyword expansion Keyword expansion is the process of automatically adding or updating
information to a keyword reference when a revision is checked out or viewed.

A keyword is a placeholder that can be inserted into text-based working files. This
placeholder is a special variable (for example, $Date$, $Author$, $State$) used to
represent textual information in a working file. Keywords can be expanded (that is, replaced
with their literal values) when a revision is checked out.
keyword

A lock is a feature of MKS Source that controls how changes are made to revisions.
When a change is checked in, it requires the revision being updated to be locked, in order to
prevent more than one user from simultaneously checking in changes to the same revision.

lock

A deferred member is a member that is associated with any deferred

operation (add, drop, checkin, rename, move, import, add from archive, update revision). A
deferred member displays in the Sandbox, but the deferred operation is not shown in the
project until the deferred operation is submitted.

member (deferred)

168

member (former) A former member is one that is dropped from the project, but still has a
working file in the Sandbox. MKS Source retains the member history for former members as
part of the project. Depending on the options you select when dropping the member,
MKS Source can also delete the members working file and close any associated change
package.
member revision (updating) You can use the Update Member Revision option when you are
checking in a member to ensure the most recent revision of each member is added to the list
of members in the project. If the option is not enabled, the project list might not reflect the
most current revision of each members history. For example, if the current project member is
revision 2.7 of an archived file, but a newer revision 2.8 has been added to the members
history, you can update the member to the new revision.

The member revision is the default revision that users work with in all
other Sandboxes. For example, if demoapp.c 1.1 is the member revision, setting 1.2 as the
member revision makes it the default revision in all Sandboxes.

member revision

member

The files under version control in a project are known as members.

pending member / subproject A pending member / subproject, is a member or subproject

that is associated with a pending operation that adds it to the project. The pending member
or subproject is denoted by a pending icon in the Name column of the Sandbox and Project
views.

Pending operations are operations whose proposed changes reside on

the server, but have not been committed to the repository.

pending operations

An MKS Source project is any group of files under version control

that, taken together, forms a single body of work.

project (MKS Source)

Promotion is the process of managing development objects as they move

through a structured development cycle.

promoting

resynchronizing To update out of sync working files to the most current member revisions,
you resynchronize the members.
reverting Reverting a member discards any changes made to a members working file since
it was checked out, and then unlocks it.
revision (annotated) MKS Source provides an annotated revision view for revisions. Use it
when you want to find out which revision introduced a particular change. Rather than
searching the content of revisions in the history one revision at a time, you can see the content
and information for all of the changes to the member in an annotated list.

The head revision is the tip revision on the default branch or the trunk, if no
default branch is defined.

revision (Head)

169

Appendix : MKS Source Terms

Pending revisions are created by MKS Source when a change package is

submitted. If change package reviews are mandatory, the revision remains pending until the
change package is accepted and is committed to the repository. When reviews are not
mandatory, you only see pending revisions if a deferred operation that would have created a
new revision fails to commit to the repository.

revision (pending)

revision (tip)

The tip revision is the most recent revision on a branch in a history.

A revision description is text that becomes a permanent part of the

archives metadata. It allows you to provide a record of the changes you made and why you
made them. This can be of great value to you or other team members if it ever becomes
necessary to revise or update the member.

revision description

revision label A revision label is a textual name that describes and refers to a revision. When
a member is checked in, you are given the option of assigning it a revision label. Labels can be
based on the product release the revision was included in, on the content of the revision, on
changes made to the revision, or any other sort of information that would be useful in
identifying that particular revision. Revisions in a history can be displayed and selected
either by revision number or revision label.

Each revision is assigned a unique revision number used to identify a

revision in a history. Revisions on the mainline are numbered as two-part decimals (such as,
1.1, 1.2, 1.3, 1.4, ). Revisions on a branch are numbered by adding two-part decimals to the
number of the revision they branch from. For example, if a branch is started from revision 1.3,
its revisions would be numbered 1.3.1.1, 1.3.1.2, 1.3.1.3, and so on.
revision number

A revision is a version of a file and is contained in a history. A new revision is

produced in the history each time a working file is checked in.

revision

Sandbox (build) A build Sandbox is a Sandbox associated with a particular project

checkpoint and has no development path (since it is static and not meant for further
development). No further development can be carried out in a build Sandbox.

MKS Source provides a way to create a common build location using

shared Sandboxes. Shared Sandboxes provide developers and buildmasters with a window
into a single shared work location.

Sandbox (shared)

A Sandbox with no working files. A sparse Sandbox does not retain

working files when a member is checked in, and continues to function this way throughout
its use; however, once created, Sandbox directories and sub Sandboxes remain in the
Sandbox.

Sandbox (sparse)

Sandbox (variant) A variant Sandbox is based on a specific development path of a project.

When you create a variant Sandbox, you choose the development path to use. In the variant
Sandbox, you can see the current state of the project along that development path and the
changes made by other developers using it.

170

A Sandbox is a private workspace that resides on the client machine and mirrors
the content of a project on the server. Although it looks and acts like the project it mirrors, a
Sandbox is actually a collection of pointers to its real-life counterparts in the master project.
Sandboxes allow you to work locally in your own workspace, without interfering with the
work of others.

Sandbox

snapshot A snapshot captures the current state of a Sandbox, where each element in the
Sandbox can be identified with a pre-existing entity in the repository on the MKS Integrity
Server. The Sandbox snapshot creates a project checkpoint that you can create a build
Sandbox or development path from. The revision number of a checkpoint created by a
snapshot includes the revision number of the last checkpoint. For example, if the last
checkpoint of the project has a revision number of 1.1, then the revision number of the
checkpoint created by the snapshot is 1.1.1.1.

A state is free-form text used to classify the condition of a revision in a

member history. For example, a document could initially have a state of Draft. As work
progresses it might be changed to Review and eventually Complete. If no state is
assigned to a revision, a default value of Exp (for Experimental) is used.
state (revision)

A super reviewer is a user with permission to vote on change packages, but

is not required to be a listed reviewer for the change package. Voting as a super reviewer
overrides all other votes. For example, casting an accept vote as a super reviewer is sufficient
for accepting the change package.

super reviewer

Thawing a member removes the restriction on changing member information in

the project and makes previously checked in member information available to the project.
Thawing a member is the opposite of freezing a member.
thawing

Project members may be one of following types of files: archived

(files under MKS Source revision control) or subproject (another MKS Source project).

type (project member)

171

Appendix : MKS Source Terms

172

Index

administrator, described 1
annotated revision 92
apply change package 146
concepts 139
example 138
overview 136
procedure 146
using 138
using a propagation CP 145
using the backfill list 142
with no dependencies 141
archive
described 86
assumptions 3
Author keyword 77

change package
adding entries 117
advantages of using 116
apply
concepts 139
example 138
overview 136
procedure 146
resolving conflicts 146
using 138
using a propagation CP 145
using the backfill list 142
with no dependencies 141
closing 126
creating 117
described 114
discarding 127
editing 125
entries
differences 121
discarding 120
moving 119
finding 122
integrating with MKS Integrity using 115
overview 114
pending operations in 134
propagation, using with resync cp 157
resynchronize
example 151
overview 136
procedure 160
using 151
using the backfill list 152
resynchronize by
example 165
how it works 164
using 164
review 134
accepting change packages 135
benefits of 130
entry categories 133

B
backfill list
using with Apply CP 142
using with Resync CP 152
before using MKS Source 3
blocks
merging
individual 107
nonconflicting 106
using Visual Difference 104
branch
member, overview of 98
merge
branched member 99
branched members 99
by dragging 100
on check out 100
on resync 100
renaming member on branch 70
starting during check in 68
build sandbox
creating 40
using 39

173

Index
overview 128
rejecting change packages 136
reopening change packages 128
steps 129
workflow 130
specifying for an operation 118
submitting 125
using to control development 116
viewing details and entries 124
check in member 66
check out
automatic merging on check out 100
member 63
checkpoint project 18
command, ident 77
CompanyInfo keyword 77
compare
member differences 95
two text files 97
working file to member revision 95

D
Date keyword 77
deferred member, described 82
deferred operation 82
canceling 84
resynchronizing 84
submitting 83
demote
member 112
project 36
development path
creating 28
described 28
removing 30
difference
change package entries 121
comparing current to last checkpoint 26
comparing current to specified checkpoint
26
comparing for members 95
comparing two specified checkpoints 26
two text files 97
Visual Difference
editing merge results 104
merging 102
reverting merge results 105
saving merge results 105
working with 102
working file and member revision 95

174

drop project, described 8

E
encrypted archives 7

F
filter
member history 89
project history 22

H
Header keyword 77

I
Id keyword 77
ident command 77
import
member 55
project 7
sandbox 40
shared 43

K
keyword
Author 77
CompanyInfo 77
Date 77
Header 77
Id 77
locating 77
Locker 77
Log 78
Name 78
ProjectLabel 78
ProjectName 78
ProjectRevision 78
ProjectSetting 78
RCSfile 78
Revision 78
SandboxSetting 78
Setting 78
Source 78
State 78
table of 77
using 75

Index

L
label
adding
to member 78
to project 24
deleting
from member 79
from project 25
lock 44
described 72
downgrading 73
member 72
removing 73
viewing 74
Locker keyword 77
Log keyword 78

M
member
adding from archive 53
adding label to 78
adding to project 51
branch, merging 99
branch, overview of 98
checking in 66
checking out 63
deleting label 79
demoting 112
dropping 60
editing 65
former, described 60
freezing 80
history, filtering 89
importing 55
locating where used 30
locking 72
making working file writable 73
managing 50
merging
overview of 98
two revisions 101
moving from project 57
via dragging 60
operations
deferring 82
pending 134
performing 62
submitting deferred 83
promoting 111
removing from project 60

renaming 69
resynchronizing 71
reverting 70
revision, updating 90
rule, setting 91
selecting 62
thawing 81
unlocking 73
updating 71
view sandbox that locked member 44
viewing content of 65
viewing locked 74
merge
automatic merging on check out 100
automatic merging on resync 100
blocks using Visual Difference 104
by dragging 100
in Visual Difference 102
member
branched 99
overview of 98
resolving 109
results
editing in Visual Merge 107
reverting in Visual Merge 108
saving in Visual Merge 108
revision
in Visual Difference 102
in Visual Merge 105
suspending in Visual Merge 108
two member revisions 101
metrics, project 26
MKS Integrity
integration with MKS Source 115
using change packages with 115
MKS Visual Difference
See Visual Difference

N
Name keyword 78
non-member, displaying 50

P
pending
operations 134
revision
reviewing 94
working with 94
project

175

Index
adding 8
adding member 51
adding members from archive 53
basic operations 6
branching 27
checkpointing 18
configuration for sandbox 45
creating 6
demoting 36
difference
comparing current to last checkpoint
26
comparing current to specified
checkpoint 26
comparing two specified checkpoints
26
dropping 8
history 17
filtering 22
view 19
importing 7
importing members into 55
label
adding 24
deleting 25
locating where used 30
managing members 50
metric 26
MKS Source, described 5
opening 9
promoting 36
removing members 60
restoring 22
viewing differences 25
ProjectLabel keyword 78
ProjectName keyword 78
ProjectRevision keyword 78
ProjectSetting keyword 78
promote
member 111
project 36
propagation change package
using with apply cp 145
using with resync cp 157

R
RCSfile keyword 78
rename member 69
report
generating 32

176

type
by author 33
by author (summary) 33
member revision to label 34
member revision to revision 34
newer revision 33
project member history 35
revision locked 34
revision with label 35
revision with state 35
Reporter, described 32
resolving conflicts 146
resynchronize
automatic merging on resync 100
by change package
example 165
how it works 164
using 164
change package
applying change packages from two
variants 157
applying changes from a variant 155
binary conflicts 160
example 151
overview 136
procedure 160
using 151
using the backfill list 152
member 71
members with deferred operations 84
revert
member 70
merge results in Visual Difference 105
merge results in Visual Merge 108
review
change package
benefits of 130
entry categories 133
overview of 128
steps 129
workflow 130
pending revision 94
revision
annotated 92
assigning descriptions 67
described 85
merging
in Visual Difference 102
in Visual Merge 105
number, assigning 67
pending
reviewing 94

Index
working with 94
updating member revision 67
Revision keyword 78

T
table of keywords 77
thaw member 81
tip revision, renaming 70

S
sandbox
creating 40
described 37
dropping 43
importing 40
opening 44
retargeting 45
scanning for change 66
shared 41
configuring 42
importing 43
removing 43
snapshot 45
types of 38
using build sandbox 39
variant 38
viewing sandbox that locked member 44
SandboxSetting keyword 78
Setting keyword 78
shared sandbox 41
configuring 42
importing 43
removing 43
shared subproject, adding 12
snapshot sandbox 45
Source keyword 78
State keyword 78
submit
change packages 125
deferred member operations 83
subproject
adding 11
configuring 13
creating 10
dropping 17
locating where used 30
moving 15
pending operations 134
shared, adding 12
working with 10

U
unlock, member 73
user, described 1

V
variant project
applying changes from 155
applying changes from two variants 157
variant sandbox
creating 40
described 38
using 38
Visual Difference
editing merge results 104
merging 102
reverting merge results 105
saving merge results 105
working with 102
Visual Merge
editing merge results 107
merging revision 106
reverting merge results 108
saving merge results 108
suspending merges 108
viewing conflicts 106
working with 105

W
workflow, change package reviews 130
working file
comparing to member revision 95
discarding change 70
making writable 73

177

Index

178

Product Notices
Copyright 20012007 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved.
U.S. Government Restricted Rights. The software and
documentation provided to you (the Software and
Documentation) are commercial items, developed exclusively
at private expense, consisting of commercial computer
software and commercial computer software documentation
as such terms are defined in the applicable acquisition
regulations. If you are the U.S. Government or any agency or
department thereof (collectively referred to as the
Government), the Software and Documentation are licensed
hereunder (i) only as a commercial item and (ii) with only those
rights as are granted to all other end users to the extent that such
rights are consistent with this paragraph. If you are any agency of
the Department of Defense of the Government, the following
notice is given: The Software and Documentation are provided
with RESTRICTED RIGHTS. You shall not use, duplicate or
disclose the Software or Documentation in any way not
specifically permitted by MKS Software Inc. or mandated by U.S.
law. Manufacturer is MKS Software Inc., 410 Albert Street,
Waterloo, Ontario Canada N2L 3V3.
This product contains Apache Jakarta Commons HttpClient
software developed by The Apache Software Foundation
(http://www.apache.org/). Licensed under the Apache
License, Version 2.0 (the License); you may not use this file
except in compliance with the License. You may obtain a copy of
the License at http://www.apache.org/licenses/LICENSE2.0. Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an AS
IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express or implied. See the License for the
specific language governing permissions and limitations under
the License.
This product contains Apache Jakarta Commons Logging 1.0.3
software developed by The Apache Software Foundation http:/
/www.apache.org/). Licensed under the Apache License,
Version 2.0 (the License); you may not use this file except in
compliance with the License. You may obtain a copy of the
License at http://www.apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an AS
IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express or implied. See the License for the
specific language governing permissions and limitations under
the License.
This product contains Apache Tomcat v. 5.5.17 software
developed by The Apache Software Foundation (http://
www.apache.org/). Licensed under the Apache License, Version
2.0 (the License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at http:/
/www.apache.org/licenses/LICENSE-2.0. Unless required by
applicable law or agreed to in writing, software distributed under
the License is distributed on an AS IS BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied. See the License for the specific language governing
permissions and limitations under the License.
This product includes the Extreme! Computing XPP3-1.1.3.2.
software developed by the Indiana University Extreme! Lab
(http://www.extreme.indiana.edu/). Copyright 2002
Extreme! Lab, Indiana University. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Indiana University Extreme! Lab

(http://www.extreme.indiana.edu/).;
Alternately,
this
acknowledgment may appear in the software itself, if and
wherever such third-party acknowledgments normally appear. 4.
The names Indiana University and Indiana University
Extreme! Lab must not be used to endorse or promote products
derived from this software without prior written permission. For
written
permission,
please
contact
http://
www.extreme.indiana.edu/. 5. Products derived from this
software may not use Indiana University name nor may
Indiana University appear in their name, without prior written
permission of the Indiana University. THIS SOFTWARE IS
PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHORS, COPYRIGHT
HOLDERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This product contains Glazed Lists software developed by
publicobject.com and ODell Engineering. Copyright 2003
2005, publicobject.com, O'Dell Engineering Ltd. This library is
free software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version. Copyright 1991, 1999 Free
Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301 USA.This library is distributed in the hope that it
will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details. You should have received a copy of the
GNU Lesser General Public License along with this library; if not,
write to the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA.
This product contains Bean Scripting Framework Version 2.2
developed by The Apache Software Foundation (http://
www.apache.org/). Licensed under the Apache License, Version
1.1. Copyright 2002 The Apache Software Foundation. All
rights reserved. Redistribution and use in source and binary
forms, with or without modification, are permitted provided that
the following conditions are met: 1. Redistributions of source
code must retain the above copyright notice, this list of conditions
and the following disclaimer. 2. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/).; 4. The names BSF Apache and
Apache Software Foundation must not be used to endorse or
promote products derived from this software without prior
written permission. For written permission, please contact
[email protected]. 5. Products derived from this software may
not be called Apache, nor may Apache appear in their name,
without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR

Product Notices
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product contains IBM Toolbox for Java software.
Copyright up to and including 2006, International Business
Machines Corporation (IBM) and others. All Rights Reserved.
Licensed under the IBM Public License Version 1.0 (the
License); you may not use this file except in compliance with
the License. See the License at http://www-128.ibm.com/
developerworks/library/os-ipl.html for the specific
language governing permissions and limitations under the
License. THE SOFTWARE IS PROVIDED AS IS, WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE. IN NO EVENT SHALL THE CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE
This product contains ICU v. 1.8.1. Copyright 19952003
International Business Machines Corporation and others. All
rights reserved. Permission is hereby granted, free of charge, to
any person obtaining a copy of this software and associated
documentation files (the Software), to deal in the Software
without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, and/or sell copies of the
Software, and to permit persons to whom the Software is
furnished to do so, provided that the above copyright notice(s)
and this permission notice appear in all copies of the Software
and that both the above copyright notice(s) and this permission
notice appear in supporting documentation. THE SOFTWARE IS
PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OF
THIRD PARTY RIGHTS. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS
NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE. Except as contained in
this notice, the name of a copyright holder shall not be used in
advertising or otherwise to promote the sale, use or other
dealings in this Software without prior written authorization of
the copyright holder. All trademarks and registered trademarks
mentioned herein are the property of their respective owners.

This product contains Java BEEP Core Version 0.9.08 developed

by The Apache Software Foundation (http://www.apache.org/
) licensed under the Apache License, Version 1.1. Copyright
19992001 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/).; Alternately, this acknowledgement may
appear in the software itself, if and wherever such third-party
acknowledgements normally appear 4. The names The Jakarta
Project, Commons and Apache Software Foundation must
not be used to endorse or promote products derived from this
software without prior written permission. For written
permission, please contact [email protected]. 5. Products
derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission
of the Apache Software Foundation. THIS SOFTWARE IS
PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE APACHE SOFTWARE
FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This product contains Java BEEP Core Version 0.9.08. Blocks
Public License Copyright 20002001, Invisible Worlds, Inc. All
Rights Reserved. Redistribution and use in source and binary
forms, with or without modification, are permitted provided that
the following conditions are met: Redistributions of source code
must retain the above copyright notice, this list of conditions and
the following disclaimer. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. Neither the name,
trademarks, or trade names of Invisible Worlds, Inc., nor the
names, trademarks, or trade names of its contributors may be
used to endorse or promote products derived from this software
without specific prior written permission. THIS SOFTWARE IS
PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL INVISIBLE WORLDS OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

Product Notices
Cryptix General License Copyright 1995, 1997, 1998, 2000. The
Cryptix Foundation Limited. All rights reserved. Redistribution
and use in source and binary forms, with or without
modification, are permitted provided that the following
conditions are met: Redistribution of source code must retain the
above copyright notice, this list of conditions and the following
disclaimer. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution. THIS SOFTWARE IS PROVIDED BY THE
CRYPTIX FOUNDATION LIMITED AND CONTRIBUTORS AS
IS AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE CRYPTIX FOUNDATION LIMITED OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This package is a SSLv3/TLS implementation written by Eric
Rescorla (ekr\@rtfm.com) and licensed by Claymore Systems,
Inc. Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: Redistributions of source code must retain the
above copyright notice, this list of conditions and the following
disclaimer. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution. All advertising materials mentioning
features or use of this software must display the following
acknowledgement: This product includes software developed by
Claymore Systems, Inc. Neither the name or Claymore Systems,
Inc. nor the name of Eric Rescorla may be used to endorse or
promote products derived from this software without specific
prior written permission. THIS SOFTWARE IS PROVIDED BY
THE REGENTS AND CONTRIBUTORS AS IS AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This product contains Java Service Wrapper software developed
by Tanuki Software. Copyright 1999, 2006 Tanuki Software Inc.
Permission is hereby granted, free of charge, to any person
obtaining a copy of the Java Service Wrapper and associated
documentation files (the Software), to deal in the Software
without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sub-license, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software. THE
SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
Copyright 2001 Silver Egg Technology. Permission is hereby
granted, free of charge, to any person obtaining a copy of this
software and associated documentation files (the Software), to
deal in the Software without restriction, including without
limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so,
subject to the following conditions: The above copyright notice
and this permission notice shall be included in all copies or
substantial portions of the Software.
This product contains JavaScript for Java which is subject to the
Netscape Public License Version 1.1 (the License); you may not
use this file except in compliance with the License. You may
obtain a copy of the License at http://www.mozilla.org/NPL/.
Software distributed under the License is distributed on an
AS IS basis, WITHOUT WARRANTY OF ANY KIND, either
express or implied. See the License for the specific language
governing rights and limitations under the License. The Original
Code is Rhino code, released May 6, 1999. The Initial Developer of
the Original Code is Netscape Communications Corporation.
Portions created by Netscape are Copyright 19971999
Netscape Communications Corporation. All Rights Reserved.
Contributor(s): Norris Boyd
This product contains JBoss version 4.0.4. Copyright 20042007
JBoss, Inc. This library is free software; you can redistribute it
and/or modify it under the terms of the GNU Lesser General
Public License as published by the Free Software Foundation;
either version 2.1 of the License, or (at your option) any later
version. Copyright 1991, 1999 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.This
library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details. You should have received a copy of the
GNU Lesser General Public License along with this library; if not,
write to the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA.
This product contains Jdesktop Integration Components.
Copyright 2004 Sun Microsystems, Inc. This library is free
software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version. Copyright 1991, 1999 Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA. This library is distributed in the hope that it
will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details. You should have received a copy of the
GNU Lesser General Public License along with this library; if not,
write to the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA.
This product contains JFree Chart version 1.0.1. Copyright 2000
2006, by Object Refinery Limited and Contributors. This library is
free software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version. Copyright 1991, 1999 Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA. This library is distributed in the hope that it
will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details. You should have received a copy of the

Product Notices
GNU Lesser General Public License along with this library; if not,
write to the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA.
This product contains Xerces 2.6.0 developed by The Apache
Software Foundation (http://www.apache.org/) licensed
under the Apache License, Version 1.1. Copyright 20002002
The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/).; 4. The names Xerces, Apache and
Apache Software Foundation must not be used to endorse or
promote products derived from this software without prior
written permission. For written permission, please contact
[email protected]. 5. Products derived from this software may
not be called Apache, nor may Apache appear in their name,
without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product contains jTDS Drivers version 1.2 for MS SQL
Server. This library is free software; you can redistribute it and/
or modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
Copyright 1991, 1999 Free Software Foundation, Inc., 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA. This
library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details. You should have received a copy of the
GNU Lesser General Public License along with this library; if not,
write to the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA.
Copyright 1998, 1999, JXML, Inc. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: Redistributions of source code must retain the
above copyright notice, this list of conditions and the following
disclaimer. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution. All product materials mentioning features
or use of this software must display the following
acknowledgement: This product includes software developed by
JXML, Inc. and its contributors: http://www.jxml.com/mdsax/
contributors.html. Neither name of JXML nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission. THIS SOFTWARE IS PROVIDED BY JXML, INC.
AND CONTRIBUTORS AS IS AND ANY EXPRESS OR

IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,

THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL JXML OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY,
OR
CONSEQUENTIAL
DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product includes Log4J software developed by The Apache
Software Foundation (http://www.apache.org/) licensed
under the Apache Software License, Version 1.1. Copyright
1999 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/).; Alternately, this acknowledgment may
appear in the software itself, if and wherever such third-party
acknowledgments normally appear. 4. The names log4j and
Apache Software Foundation must not be used to endorse or
promote products derived from this software without prior
written permission. For written permission, please contact
[email protected]. 5. Products derived from this software may
not be called Apache, nor may Apache appear in their name,
without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product contains NSPR Library software. The contents of
this file are subject to the Mozilla Public License Version 1.1 (the
License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at http://
www.mozilla.org/MPL/. Software distributed under the License
is distributed on an AS IS basis, WITHOUT WARRANTY OF
ANY KIND, either express or implied. See the License for the
specific language governing rights and limitations under the
License. The Original Code is the Netscape Portable Runtime
(NSPR). The Initial Developer of the Original Code is Netscape
Communications Corporation. Portions created by Netscape are
Copyright 19982000 Netscape Communications Corporation.
All Rights Reserved.
This product contains OpenSSL software and is licensed under
the terms of the OpenSSL License and the SSLeay License.
Copyright 19982007 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain

Product Notices
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. All advertising
materials mentioning features or use of this software must
display the following acknowledgment: This product includes
software developed by the OpenSSL Project for use in the
OpenSSL Toolkit. (http://www.openssl.org/) 4. The names
OpenSSL Toolkit and OpenSSL Project must not be used to
endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[email protected]. 5. Products derived from this software
may not be called OpenSSL nor may OpenSSL appear in
their names without prior written permission of the OpenSSL
Project. 6. Redistributions of any form whatsoever must retain the
following acknowledgment: This product includes software
developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/) THIS SOFTWARE IS PROVIDED
BY THE OpenSSL PROJECT AS IS AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE. This product includes cryptographic software
written by Eric Young ([email protected]). This product
includes software written by Tim Hudson ([email protected]).
Copyright 19951998 Eric Young ([email protected]). All
rights reserved.
This package is an SSL implementation written by Eric Young
([email protected]). Redistribution and use in source and binary
forms, with or without modification, are permitted provided that
the following conditions are met: 1. Redistributions of source
code must retain the copyright notice, this list of conditions and
the following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. All advertising
materials mentioning features or use of this software must
display the following acknowledgement: This product includes
cryptographic
software
written
by
Eric
Young
([email protected]) The word cryptographic can be left out if
the routines from the library being used are not cryptographic
related. 4. If you include any Windows specific code (or a
derivative thereof) from the apps directory (application code) you
must include an acknowledgement: This product includes
software written by Tim Hudson ([email protected]) THIS
SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

This product contains Sapia Ubik software developed by Sapia

Open Source Software. Copyright 2002, 2003 Sapia Open
Source Software. All rights reserved. Redistribution and use in
source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution. The end-user documentation included with
the redistribution, if any, must include the following
acknowledgment: This product includes software developed by
Sapia Open Source Software Organization (http://www.sapiaoss.org/). Alternately, this acknowledgment may appear in the
software
itself,
if
and
wherever
such
third-party
acknowledgments normally appear. The names Sapia, Sapia
Open Source Software and Sapia OSS must not be used to
endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[email protected]. Products derived from this software may not
be called Sapia, nor may Sapia appear in their name, without
prior written permission of Sapia OSS. THIS SOFTWARE IS
PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE SAPIA OSS ORGANIZATION OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This product contains JDOM software. Copyright 20002004
Jason Hunter & Brett McLaughlin. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions, and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions, and
the disclaimer that follows these conditions in the documentation
and/or other materials provided with the distribution. 3. The
name JDOM must not be used to endorse or promote products
derived from this software without prior written permission. For
written
permission,
please
contact
<request_AT_jdom_DOT_org>. 4. Products derived from this
software may not be called JDOM", nor may JDOM appear in
their name, without prior written permission from the JDOM
Project Management <request_AT_jdom_DOT_org>. In addition,
we request (but do not require) that you include in the end-user
documentation provided with the redistribution and/or in the
software itself an acknowledgement equivalent to the following:
This product includes software developed by the JDOM Project
(http://www.jdom.org/).; Alternatively, the acknowledgment
may be graphical using the logos available at http://
www.jdom.org/images/logos.
THIS
SOFTWARE
IS
PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE JDOM AUTHORS OR THE
PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY

Product Notices
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
Portions of this product are Copyright 2007, Microsoft
Corporation. All rights reserved.
This product contains W3C Sirpac. This work (and included
software, documentation such as READMEs, or other related
items) is being provided by the copyright holders under the
following license. By obtaining, using and/or copying this work,
you (the licensee) agree that you have read, understood, and will
comply with the following terms and conditions. Permission to
copy, modify, and distribute this software and its documentation,
with or without modification, for any purpose and without fee or
royalty is hereby granted, provided that you include the
following on ALL copies of the software and documentation or
portions thereof, including modifications: The full text of this
NOTICE in a location viewable to users of the redistributed or
derivative work. Any pre-existing intellectual property
disclaimers, notices, or terms and conditions. If none exist, the
W3C Software Short Notice should be included (hypertext is
preferred, text is permitted) within the body of any redistributed
or derivative code. Notice of any changes or modifications to the
files, including the date changes were made. (We recommend you
provide URIs to the location from which the code is derived.)
THIS SOFTWARE AND DOCUMENTATION IS PROVIDED
AS IS,
AND
COPYRIGHT
HOLDERS
MAKE
NO
REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
PURPOSE OR THAT THE USE OF THE SOFTWARE OR
DOCUMENTATION WILL NOT INFRINGE ANY THIRD
PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER
RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR
ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE
OR DOCUMENTATION. The name and trademarks of copyright
holders may NOT be used in advertising or publicity pertaining
to the software without specific, written prior permission. Title to
copyright in this software and any associated documentation will
at all times remain with copyright holders.
This product contains XML Parsing Library for C version 2.6.7.
Copyright 19982003 Daniel Veillard. All Rights Reserved.
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the Software), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions: The above
copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software. THE
SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
FOR
A
PARTICULAR
PURPOSE
AND
NONINFRINGEMENT. IN NO EVENT SHALL THE DANIEL
VEILLARD BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
This product contains the Sun Java 1.5.0 Update Platform which
may include the following software:
The following software may be included in this product: CS
CodeViewer v1.0; Use of any of this software is governed by the
terms of the license below: Copyright 1999 by CoolServlets.com.
This software is distributed under the terms of the BSD License.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the

following disclaimer. 2. Redistributions in binary form must

reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. Neither name of
CoolServlets.com nor the names of its contributors may be used
to endorse or promote products derived from this software
without specific prior written permission. THIS SOFTWARE IS
PROVIDED BY COOLSERVLETS.COM AND CONTRIBUTORS
AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
ANY
DIRECT,
INDIRECT,
INCIDENTAL,
SPECIAL,
EXEMPLARY,
OR
CONSEQUENTIAL
DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The following software may be included in this product: Crimson
v1.1.1; Use of any of this software is governed by the terms of the
license below: / The Apache Software License, Version 1.1
Copyright 19992000 The Apache Software Foundation. All
rights reserved. Redistribution and use in source and binary
forms, with or without modification, are permitted provided that
the following conditions are met: 1. Redistributions of source
code must retain the above copyright notice, this list of conditions
and the following disclaimer. 2. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/).; Alternately, this acknowledgment may
appear in the software itself, if and wherever such third-party
acknowledgments normally appear. 4. The names Crimson and
Apache Software Foundation must not be used to endorse or
promote products derived from this software without prior
written permission. For written permission, please contact
[email protected]. 5. Products derived from this software may
not be called Apache, nor may Apache appear in their name,
without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The following software may be included in this product: Xalan J2;
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://
www.apache.org/licenses/LICENSE-2.0 Unless required by
applicable law or agreed to in writing, software distributed under
the License is distributed on an AS IS BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied. See the License for the specific language governing
permissions and limitations under the License.

Product Notices
The following software may be included in this product: NSIS
1.0j; Use of any of this software is governed by the terms of the
license below: Copyright 19992000 Nullsoft, Inc. This software
is provided as-is, without any express or implied warranty. In
no event will the authors be held liable for any damages arising
from the use of this software. Permission is granted to anyone to
use this software for any purpose, including commercial
applications, and to alter it and redistribute it freely, subject to the
following restrictions: 1. The origin of this software must not be
misrepresented; you must not claim that you wrote the original
software. If you use this software in a product, an
acknowledgment in the product documentation would be
appreciated but is not required. 2. Altered source versions must
be plainly marked as such, and must not be misrepresented as
being the original software. 3. This notice may not be removed or
altered from any source distribution. Justin Frankel
[email protected] Some Portions licensed from IBM are
available at: http://oss.software.ibm.com/icu4j/ Portions
Copyright Eastman Kodak Company 1992 Lucida is a registered
trademark or trademark of Bigelow & Holmes in the U.S. and
other countries. Portions licensed from Taligent, Inc.
The following software may be included in this product: IAIK
PKCS Wrapper; Use of any of this software is governed by the
terms of the license below: Copyright 2002 Graz University of
Technology. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, are permitted
provided that the following conditions are met: 1. Redistributions
of source code must retain the above copyright notice, this list of
conditions and the following disclaimer. 2. Redistributions in
binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution. 3. The
end-user documentation included with the redistribution, if any,
must include the following acknowledgment: This product
includes software developed by IAIK of Graz University of
Technology. Alternately, this acknowledgment may appear in
the software itself, if and wherever such third-party
acknowledgments normally appear. 4. The names Graz
University of Technology and IAIK of Graz University of
Technology must not be used to endorse or promote products
derived from this software without prior written permission. 5.
Products derived from this software may not be called IAIK
PKCS Wrapper, nor may IAIK appear in their name, without
prior written permission of Graz University of Technology. THIS
SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE LICENSOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
The following software may be included in this product:
Document Object Model (DOM) v. Level 3; Use of any of this
software is governed by the terms of the license below: W3C
SOFTWARE NOTICE AND LICENSE http://www.w3.org/
Consortium/Legal/2002/copyright-software-20021231

This work (and included software, documentation such as

READMEs, or other related items) is being provided by the
copyright holders under the following license. By obtaining,
using and/or copying this work, you (the licensee) agree that you
have read, understood, and will comply with the following terms
and conditions. Permission to copy, modify, and distribute this
software and its documentation, with or without modification,
for any purpose and without fee or royalty is hereby granted,
provided that you include the following on ALL copies of the

software and documentation or portions thereof, including

modifications: 1. The full text of this NOTICE in a location
viewable to users of the redistributed or derivative work. 2. Any
pre-existing intellectual property disclaimers, notices, or terms
and conditions. If none exist, the W3C Software Short Notice
should be included (hypertext is preferred, text is permitted)
within the body of any redistributed or derivative code. 3. Notice
of any changes or modifications to the files, including the date
changes were made. (We recommend you provide URIs to the
location from which the code is derived.) THIS SOFTWARE AND
DOCUMENTATION IS PROVIDED AS IS, AND COPYRIGHT
HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO,
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
ANY PARTICULAR PURPOSE OR THAT THE USE OF THE
SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE
ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS
OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE
LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF
THE SOFTWARE OR DOCUMENTATION. The name and
trademarks of copyright holders may NOT be used in advertising
or publicity pertaining to the software without specific, written
prior permission. Title to copyright in this software and any
associated documentation will at all times remain with copyright
holders. This formulation of W3Cs notice and license became
active on December 31, 2002. This version removes the copyright
ownership notice such that this license can be used with materials
other than those owned by the W3C, reflects that ERCIM is now a
host of the W3C, includes references to this specific dated version
of the license, and removes the ambiguous grant of use.
Otherwise, this version is the same as the previous version and is
written so as to preserve the Free Software Foundations
assessment of GPL compatibility and OSI's certification under the
Open Source Definition. Please see our Copyright FAQ for
common questions about using materials from our site, including
specific terms and conditions for packages like libwww, Amaya,
and Jigsaw. Other questions about this notice can be directed to
[email protected].
The following software may be included in this product: Xalan,
Xerces; Use of any of this software is governed by the terms of the
license below: / The Apache Software License, Version 1.1
Copyright 19992003 The Apache Software Foundation. All
rights reserved. Redistribution and use in source and binary
forms, with or without modification, are permitted provided that
the following conditions are met: 1. Redistributions of source
code must retain the above copyright notice, this list of conditions
and the following disclaimer. 2. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/). Alternately, this acknowledgment may
appear in the software itself, if and wherever such third-party
acknowledgments normally appear. 4. The names Xerces and
Apache Software Foundation must not be used to endorse or
promote products derived from this software without prior
written permission. For written permission, please contact
[email protected]. 5. Products derived from this software may
not be called Apache, nor may Apache appear in their name,
without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER

Product Notices
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The following software may be included in this product: W3C
XML Conformance Test Suites v. 20020606; Use of any of this
software is governed by the terms of the license below: W3C
SOFTWARE NOTICE AND LICENSE Copyright 19942002
World Wide Web Consortium, (Massachusetts Institute of
Technology, Institut National de Recherche en Informatique et en
Automatique, Keio University). All Rights Reserved. http://
www.w3.org/Consortium/Legal/ This W3C work (including
software, documents, or other related items) is being provided by
the copyright holders under the following license. By obtaining,
using and/or copying this work, you (the licensee) agree that you
have read, understood, and will comply with the following terms
and conditions: Permission to use, copy, modify, and distribute
this software and its documentation, with or without
modification, for any purpose and without fee or royalty is
hereby granted, provided that you include the following on ALL
copies of the software and documentation or portions thereof,
including modifications, that you make: 1. The full text of this
NOTICE in a location viewable to users of the redistributed or
derivative work. 2. Any pre-existing intellectual property
disclaimers, notices, or terms and conditions. If none exist, a short
notice of the following form (hypertext is preferred, text is
permitted) should be used within the body of any redistributed
or derivative code: Copyright up to and including 2006 World
Wide Web Consortium, (Massachusetts Institute of Technology,
Institut National de Recherche en Informatique et en
Automatique, Keio University). All Rights Reserved. http://
www.w3.org/Consortium/Legal/ 3. Notice of any changes or
modifications to the W3C files, including the date changes were
made. (We recommend you provide URIs to the location from
which the code is derived.) THIS SOFTWARE AND
DOCUMENTATION IS PROVIDED AS IS, AND COPYRIGHT
HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO,
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
ANY PARTICULAR PURPOSE OR THAT THE USE OF THE
SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE
ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS
OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE
LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF
THE SOFTWARE OR DOCUMENTATION. The name and
trademarks of copyright holders may NOT be used in advertising
or publicity pertaining to the software without specific, written
prior permission. Title to copyright in this software and any
associated documentation will at all times remain with copyright
holders. This formulation of W3Cs notice and license became
active on August 14 1998 so as to improve compatibility with
GPL. This version ensures that W3C software licensing terms are
no more restrictive than GPL and consequently W3C software
may be distributed in GPL packages. See the older formulation
for the policy prior to this date. Please see our Copyright FAQ for
common questions about using materials from our site, including
specific terms and conditions for packages like libwww, Amaya,
and Jigsaw. Other questions about this notice can be directed to
[email protected].
The following software may be included in this product: W3C
XML Schema Test Collection v. 1.16.2; Use of any of this software
is governed by the terms of the license below: W3C DOCUMENT
NOTICE AND LICENSE Copyright 1994-2002 World Wide
Web Consortium, (Massachusetts Institute of Technology, Institut
National de Recherche en Informatique et en Automatique, Keio
University). All Rights Reserved. http://www.w3.org/
Consortium/Legal/ Public documents on the W3C site are
provided by the copyright holders under the following license.
The software or Document Type Definitions (DTDs) associated
with W3C specifications are governed by the Software Notice. By
using and/or copying this document, or the W3C document from

which this statement is linked, you (the licensee) agree that you
have read, understood, and will comply with the following terms
and conditions: Permission to use, copy, and distribute the
contents of this document, or the W3C document from which this
statement is linked, in any medium for any purpose and without
fee or royalty is hereby granted, provided that you include the
following on ALL copies of the document, or portions thereof,
that you use: 1. A link or URL to the original W3C document. 2.
The pre-existing copyright notice of the original author, or if it
doesn't exist, a notice of the form: Copyright yyyy [$date-ofdocument] World Wide Web Consortium, (Massachusetts
Institute of Technology, Institut National de Recherche en
Informatique et en Automatique, Keio University). All Rights
Reserved.
http://www.w3.org/Consortium/Legal/
(Hypertext is preferred, but a textual representation is permitted.)
3. If it exists, the STATUS of the W3C document. When space
permits, inclusion of the full text of this NOTICE should be
provided. We request that authorship attribution be provided in
any software, documents, or other items or products that you
create pursuant to the implementation of the contents of this
document, or any portion thereof. No right to create
modifications or derivatives of W3C documents is granted
pursuant to this license. However, if additional requirements
(documented in the Copyright FAQ) are satisfied, the right to
create modifications or derivatives is sometimes granted by the
W3C to individuals complying with those requirements. THIS
DOCUMENT IS PROVIDED AS IS, AND COPYRIGHT
HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE;
THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE
FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF
SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY
PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY
DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT
OR THE PERFORMANCE OR IMPLEMENTATION OF THE
CONTENTS THEREOF. The name and trademarks of copyright
holders may NOT be used in advertising or publicity pertaining
to this document or its contents without specific, written prior
permission. Title to copyright in this document will at all times
remain with copyright holders. This formulation of W3Cs notice
and license became active on April 05 1999 so as to account for the
treatment of DTDs, schema's and bindings. See the older
formulation for the policy prior to this date. Please see our
Copyright FAQ for common questions about using materials
from our site, including specific terms and conditions for
packages like libwww, Amaya, and Jigsaw. Other questions
about this notice can be directed to [email protected].
webmaster (last updated by reagle on 1999/04/99.)
The following software may be included in this product:
Common Unix Printing System API Libraries (CUPS API library);
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version. This
library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU Library General Public
License for more details. You should have received a copy of the
GNU Library General Public License along with this library; if
not, write to the Free Software Foundation, Inc., 51 Franklin
Street, Fifth Floor, Boston, MA 02110-1301 USA.
The following software may be included in this product: Mesa
3-D graphics library v. 5; Use of any of this software is governed
by the terms of the license below: core Mesa code include/GL/
gl.h Brian Paul Mesa GLX driver include/GL/glx.h Brian Paul
Mesa Ext registry include/GL/glext.h SGI SGI Free B include/
GL/glxext.h Mesa license: The Mesa distribution consists of
several components. Different copyrights and licenses apply to

Product Notices
different components. For example, GLUT is copyrighted by
Mark Kilgard, some demo programs are copyrighted by SGI,
some of the Mesa device drivers are copyrighted by their authors.
See below for a list of Mesa's components and the copyright/
license for each. The core Mesa library is licensed according to the
terms of the XFree86 copyright (an MIT-style license). This allows
integration with the XFree86/DRI project. Unless otherwise
stated, the Mesa source code and documentation is licensed as
follows: Copyright 19992003 Brian Paul All Rights Reserved.
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the Software), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions: The above
copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software. THE
SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
FOR
A
PARTICULAR
PURPOSE
AND
NONINFRINGEMENT. IN NO EVENT SHALL BRIAN PAUL BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE. SGI FREE SOFTWARE LICENSE B
(Version 1.1 [02/22/2000]) Except to the extent portions of this
file are made subject to an alternative license as permitted in the
SGI Free Software License B, Version 1.1 (the License), the
contents of this file are subject only to the provisions of the
License. You may not use this file except in compliance with the
License. You may obtain a copy of the License at Silicon Graphics,
Inc., attn: Legal Services, 1600 Amphitheatre Parkway, Mountain
View, CA 94043-1351, or at: http://oss.sgi.com/projects/
FreeB Note that, as provided in the License, the Software is
distributed on an AS IS basis, with ALL EXPRESS AND
IMPLIED WARRANTIES AND CONDITIONS DISCLAIMED,
INCLUDING, WITHOUT LIMITATION, ANY IMPLIED
WARRANTIES AND CONDITIONS OF MERCHANTABILITY,
SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT. Original Code. The
Original Code is: [name of software, version number, and release
date], developed by Silicon Graphics, Inc. The Original Code is
Copyright [dates of first publication, as appearing in the Notice
in the Original Code] Silicon Graphics, Inc. Copyright in any
portions created by third parties is as indicated elsewhere herein.
All Rights Reserved. Additional Notice Provisions: [such
additional provisions, if any, as appear in the Notice in the
Original Code under the heading Additional Notice
Provisions]
The following software may be included in this product: Byte
Code Engineering Library (BCEL) v. 5; Use of any of this software
is governed by the terms of the license below: Apache Software
License / The Apache Software License, Version 1.1 Copyright
2001 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The end-user
documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes
software developed by the Apache Software Foundation (http:/
/www.apache.org/). Alternately, this acknowledgment may
appear in the software itself, if and wherever such third-party
acknowledgments normally appear. 4. The names Apache and
Apache Software Foundation and Apache BCEL must not be
used to endorse or promote products derived from this software
without prior written permission. For written permission, please

contact [email protected]. 5. Products derived from this

software may not be called Apache, Apache BCEL, nor may
Apache appear in their name, without prior written permission
of the Apache Software Foundation. THIS SOFTWARE IS
PROVIDED AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE APACHE SOFTWARE
FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
The following software may be included in this product: Regexp,
Regular Expression Package v. 1.2; Use of any of this software is
governed by the terms of the license below: The Apache Software
License, Version 1.1 Copyright 2001 The Apache Software
Foundation. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, are permitted
provided that the following conditions are met: 1. Redistributions
of source code must retain the above copyright notice, this list of
conditions and the following disclaimer. 2. Redistributions in
binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution. 3. The
end-user documentation included with the redistribution, if any,
must include the following acknowledgment: This product
includes software developed by the Apache Software Foundation
(http://www.apache.org/). Alternately, this acknowledgment
may appear in the software itself, if and wherever such thirdparty acknowledgments normally appear. 4. The names
Apache and Apache Software Foundation and Apache
Turbine must not be used to endorse or promote products
derived from this software without prior written permission. For
written permission, please contact [email protected].
5. Products derived from this software may not be called
Apache, Apache Turbine, nor may Apache appear in their
name, without prior written permission of the Apache Software
Foundation. THIS SOFTWARE IS PROVIDED AS IS AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The following software may be included in this product: CUP
Parser Generator for Java v. 0.10k; Use of any of this software is
governed by the terms of the license below: CUP Parser
Generator Copyright Notice, License, and Disclaimer Copyright
19961999 by Scott Hudson, Frank Flannery, C. Scott Ananian
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both the copyright notice and this permission
notice and warranty disclaimer appear in supporting
documentation, and that the names of the authors or their
employers not be used in advertising or publicity pertaining to

Product Notices
distribution of the software without specific, written prior
permission. The authors and their employers disclaim all
warranties with regard to this software, including all implied
warranties of merchantability and fitness. In no event shall the
authors or their employers be liable for any special, indirect or
consequential damages or any damages whatsoever resulting
from loss of use, data or profits, whether in an action of contract,
negligence or other tortious action, arising out of or in connection
with the use or performance of this software.
The following software may be included in this product: JLex: A
Lexical Analyzer Generator for Java v. 1.2.5; Use of any of this
software is governed by the terms of the license below: JLEX
COPYRIGHT NOTICE, LICENSE AND DISCLAIMER. Copyright
19962003 by Elliot Joel Berk and C. Scott Ananian Permission to
use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both the copyright notice and this permission
notice and warranty disclaimer appear in supporting
documentation, and that the name of the authors or their
employers not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission. The authors and their employers disclaim all
warranties with regard to this software, including all implied
warranties of merchantability and fitness. In no event shall the
authors or their employers be liable for any special, indirect or
consequential damages or any damages whatsoever resulting
from loss of use, data or profits, whether in an action of contract,
negligence or other tortious action, arising out of or in connection
with the use or performance of this software. Java is a trademark
of Sun Microsystems, Inc. References to the Java programming
language in relation to JLex are not meant to imply that Sun
endorses this product.
The following software may be included in this product: SAX v.
2.0.1; Use of any of this software is governed by the terms of the
license below: Copyright Status SAX is free! In fact, it's not
possible to own a license to SAX, since it's been placed in the
public domain. No Warranty Because SAX is released to the
public domain, there is no warranty for the design or for the
software implementation, to the extent permitted by applicable
law. Except when otherwise stated in writing the copyright
holders and/or other parties provide SAX as is without
warranty of any kind, either expressed or implied, including, but
not limited to, the implied warranties of merchantability and
fitness for a particular purpose. The entire risk as to the quality
and performance of SAX is with you. Should SAX prove
defective, you assume the cost of all necessary servicing, repair or
correction. In no event unless required by applicable law or
agreed to in writing will any copyright holder, or any other party
who may modify and/or redistribute SAX, be liable to you for
damages, including any general, special, incidental or
consequential damages arising out of the use or inability to use
SAX (including but not limited to loss of data or data being
rendered inaccurate or losses sustained by you or third parties or
a failure of the SAX to operate with any other programs), even if
such holder or other party has been advised of the possibility of
such damages. Copyright Disclaimers This page includes
statements to that effect by David Megginson, who would have
been able to claim copyright for the original work. SAX 1.0
Version 1.0 of the Simple API for XML (SAX), created collectively
by the membership of the XML-DEV mailing list, is hereby
released into the public domain. No one owns SAX: you may use
it freely in both commercial and non-commercial applications,
bundle it with your software distribution, include it on a CDROM, list the source code in a book, mirror the documentation at
your own web site, or use it in any other way you see fit. David
Megginson, [email protected] 1998-05-11 SAX 2.0 I hereby
abandon any property rights to SAX 2.0 (the Simple API for
XML), and release all of the SAX 2.0 source code, compiled code,

and documentation contained in this distribution into the Public

Domain. SAX comes with NO WARRANTY or guarantee of
fitness
for
any
purpose.
David
Megginson,
[email protected] 2000-05-05.
The following software may be included in this product: Cryptix;
Use of any of this software is governed by the terms of the license
below: Cryptix General License Copyright 19952003 The
Cryptix Foundation Limited. All rights reserved. Redistribution
and use in source and binary forms, with or without
modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
the copyright notice, this list of conditions and the following
disclaimer. 2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution. THIS SOFTWARE IS PROVIDED BY THE
CRYPTIX FOUNDATION LIMITED AND CONTRIBUTORS
AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE CRYPTIX FOUNDATION LIMITED OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
This product contains DOM4J 1.6.1. Copyright 2001-2005
MetaStuff, Ltd. All Rights Reserved. Redistribution and use of
this software and associated documentation (Software), with or
without modification, are permitted provided that the following
conditions are met: 1. Redistributions of source code must retain
copyright statements and notices. Redistributions must also
contain a copy of this document. 2. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other
materials provided with the distribution. 3. The name DOM4J
must not be used to endorse or promote products derived from
this Software without prior written permission of MetaStuff, Ltd.
For
written
permission,
please
contact
[email protected]. 4. Products derived from this Software may
not be called DOM4J nor may DOM4J appear in their names
without prior written permission of MetaStuff, Ltd. DOM4J is a
registered trademark of MetaStuff, Ltd. 5. Due credit should be
given to the DOM4J Project - http://www.dom4j.org. THIS
SOFTWARE IS PROVIDED BY METASTUFF, LTD. AND
CONTRIBUTORS AS IS AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL METASTUFF, LTD. OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.