User Guide - Mks.com

6RXUFH ,QWHJULW\
(QWHUSULVH (GLWLRQ
User Guide
Z Z Z P N V F R P

MKS Source Integrity® Enterprise Edition 8.6
User Guide
Copyright © 2001–2004 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved.
MKS Source Integrity, MKS Integrity Manager, MKS Code Integrity, Implementer, MKS Toolkit, Sandbox, DISCOVER,
SDM, NuTCRACKER, Integrity Solution, AlertCentre, MKS Track Integrity, NewVersion, and Build Better Software are
registered trademarks of MKS Inc. All other trademarks or registered trademarks are the property of their respective
holders.
Contains Java software developed by Sun Microsystems, Inc. © Copyright Sun Microsystems, Inc. All Rights
Reserved. Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United
States and other countries.
Portions of this product are based upon copyrighted materials of BEA Systems Inc. All rights reserved.
Portions of this product are based upon copyrighted materials of Sitraka Inc. (formerly KL Group) or its suppliers. All
rights reserved.
IBM Bean Scripting Framework (BSF) is incorporated in this product and is provided by International Business
Machines or one of its subsidiaries (IBM) and is copyrighted and licensed. MKS does not make or imply any
representations or warranties on behalf of IBM.
Mozilla Public License. The Source Code version of the Covered Code is available under the terms of the Mozilla Public
License Version 1.1.
CORPORATE HEADQUARTERS WORLDWIDE OFFICES:
410 Albert Street
Waterloo, ON N2L 3V3
Canada
tel: 519 884 2251
fax: 519 884 8861
sales: 800 265 2797
www.mks.com
4.6KYAK-0304
15 Third Avenue
Burlington, MA USA
01803
tel: 781 359 3300
fax: 781 359 3399
2500 S. Highland Avenue
Lombard, IL USA
60148
tel: 630 495 2108
fax: 630 495 3591
sales: 800 633 1235
12450 Fair Lakes Circle
Suite 400
Fairfax, VA USA
22033
tel: 703 803 3343
fax: 703 803 3344
sales: 800 265 2797
This document is uncontrolled when printed or copied.
Martinstraße 42-44
73728 Esslingen
Germany
tel: +49 711 351775 0
fax: +49 711 351775 11
Third Floor, Duke’s Court
Duke Street, Woking
Surrey
GU21 5BH
United Kingdom
tel: +44 (0)1483 733900
fax: +44 (0)1483 733901
sales: +44 (0)1483 733919

Table of Contents
Chapters 1 Welcome to Source Integrity Enterprise Edition . . . . . . . . 1
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Your Feedback Is Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Where To Go From Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Understanding Source Integrity . . . . . . . . . . . . . . . . . . . . 13
Projects and Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Working With Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
File and Object Histories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
How Files and Objects Are Stored . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
What Is a Project Member? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
History File: Storing Deltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Project Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Source Integrity Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Working With Variants and Development Paths . . . . . . . . . . . . . . . 21
Integrations Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Getting Started Using Source Integrity. . . . . . . . . . . . . . . 23
Installing the Integrity Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Browser Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Configuring Environment Variables for UNIX . . . . . . . . . . . . . . . . . 29
Uninstalling the Integrity Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Before You Start the Integrity Client . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Understanding Access Permissions . . . . . . . . . . . . . . . . . . . . . . . 30
Understanding Access Control Lists . . . . . . . . . . . . . . . . . . . . . . 31
Viewing Group Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Administrator Defined Client Settings . . . . . . . . . . . . . . . . . . . . 34
Starting the Source Integrity Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Logging In to Source Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Connecting to Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
General Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Connection Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
i

Table of Contents
ii
Command Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
View Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Editor Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Difference Tool Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Shutdown Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Managing Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Quitting a Source Integrity Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Logging Out of Source Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Closing the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Shutting Down the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4 Source Integrity Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 75
Source Integrity Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . 76
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Printing Lists and Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Quick Access Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Configuring the Source Integrity Column Set . . . . . . . . . . . . . . 80
Configuring the Source Integrity Toolbars . . . . . . . . . . . . . . . . 82
Dialog Box Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Source Integrity Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Viewing Available CLI Commands . . . . . . . . . . . . . . . . . . . . . . . 98
Using the Graphical User Interface From the CLI . . . . . . . . . . . 98
Command Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Member Name Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
MKS Visual Difference Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
MKS Visual Merge Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5 Project and Sandbox Operations . . . . . . . . . . . . . . . . . . 115
Working With Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Creating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Importing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Dropping a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Adding a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Opening or Viewing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
u s e r g u i d e

Table of Contents
Working With Subprojects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Creating a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Adding a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Adding a Shared Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Configuring a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Dropping a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Working With Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Creating a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Importing a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Sharing Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Dropping a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Opening or Viewing a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . 144
Viewing Which Sandbox Locked a Member . . . . . . . . . . . . . . 145
Creating Variant Sandboxes and Development Paths . . . . . . 146
Removing a Development Path . . . . . . . . . . . . . . . . . . . . . . . . . 149
Using Build Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6 Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Managing Project Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Displaying Non-Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Adding Members to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Adding Members From Archive to a Project . . . . . . . . . . . . . . 166
Importing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Dropping Members From a Project . . . . . . . . . . . . . . . . . . . . . . 172
Performing Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Selecting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Checking Out a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Viewing and Editing a Member . . . . . . . . . . . . . . . . . . . . . . . . . 184
Checking In a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Renaming a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Discarding Changes to a Member . . . . . . . . . . . . . . . . . . . . . . . 196
Resyncing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Locking a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Unlocking a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Deferring Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Submitting Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . 202
Cancelling Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . 203
Resyncing Members With Deferred Operations . . . . . . . . . . . 203
Pending Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Resyncing Pending Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Comparing Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Using Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Locating Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Table of Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
iii

Table of Contents
iv
7 Using Change Packages and Reviews . . . . . . . . . . . . . . 213
What Are Change Packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Operations That Add Entries to a Change Package . . . . . . . . . . . . 215
Why Use Change Packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Using Change Packages to Control Development . . . . . . . . . . . . . . 216
Creating a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Adding Entries to a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . 219
Managing Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Finding Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Viewing Change Package Details and Entries . . . . . . . . . . . . . 226
Editing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Closing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Discarding Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Submitting Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Change Package Review Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
How the CP Review Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
CP States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CP Review Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
CP Entry Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Reviewing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Accepting a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Rejecting a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Opening Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
CP Review Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Viewing Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Viewing Your Pending Reviews . . . . . . . . . . . . . . . . . . . . . . . . . 250
Viewing the CP Review Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Managing Change Package Entries . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Moving CP Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Discarding CP Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Viewing CP Entry Member Differences . . . . . . . . . . . . . . . . . . 255
8 Viewing and Editing Projects, Sandboxes,
and Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Controlling Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Viewing and Editing Project Information . . . . . . . . . . . . . . . . . 258
Viewing a Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Opening a Build Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Adding Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Deleting Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Promoting a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Demoting a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Checkpointing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Restoring a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Viewing Project Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
u s e r g u i d e

Table of Contents
Controlling Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Viewing General Sandbox Information . . . . . . . . . . . . . . . . . . . 280
Viewing Project Attributes From a Sandbox . . . . . . . . . . . . . . 281
Viewing Sandbox Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Taking Sandbox Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Controlling Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Viewing and Editing Member Information . . . . . . . . . . . . . . . 287
Updating a Member’s Revision . . . . . . . . . . . . . . . . . . . . . . . . . 293
Adding Labels to Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Deleting Member Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Promoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Demoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Freezing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Thawing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
About the Report Information . . . . . . . . . . . . . . . . . . . . . . . . . . 303
About Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Creating a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
9 Viewing and Editing Member Histories and Revisions . 309
Viewing a Member History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Viewing and Editing Archive Information . . . . . . . . . . . . . . . . . . . . 312
Viewing and Editing Revision Information . . . . . . . . . . . . . . . . . . . 314
Viewing an Annotated Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Viewing and Editing Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . 319
Adding Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Deleting Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Viewing a Member’s Working File or Revision . . . . . . . . . . . . . . . . 322
Promoting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Demoting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Locking Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Unlocking Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Locking Multiple Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Managing Revision Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Setting the Member Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Deleting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Comparing Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Working With Pending Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
v

Table of Contents
vi
10 Branching and Merging Revisions . . . . . . . . . . . . . . . . . 337
Branching Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Making Locked Members Writable . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Merging Branched Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Merging on Check In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Merging Revisions by Dragging . . . . . . . . . . . . . . . . . . . . . . . . . 348
Automatic Merging on Check Out . . . . . . . . . . . . . . . . . . . . . . . 350
Automatic Merging on Resync . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Merging Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Merging Revisions Automatically . . . . . . . . . . . . . . . . . . . . . . . 354
Working With MKS Visual Difference . . . . . . . . . . . . . . . . . . . 356
Working With MKS Visual Merge . . . . . . . . . . . . . . . . . . . . . . . 361
Merging in the Command Line Interface . . . . . . . . . . . . . . . . . 366
Resolving Merges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
11 The Integrity Manager Integration. . . . . . . . . . . . . . . . . . 371
Integrating With Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 372
How the Integration Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Creating a Change Package for an Issue . . . . . . . . . . . . . . . . . . . . . . 375
Adding Entries to an Issue’s Change Package . . . . . . . . . . . . . . . . . 376
Viewing a Change Package’s Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Finding Change Packages Using a Query . . . . . . . . . . . . . . . . . . . . . 378
12 Advanced Change Package Operations. . . . . . . . . . . . . 381
Change Package Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Change Package Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Change Package Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Resolving Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Using the Apply CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Key Apply CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
How Apply CP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Apply CP Backfill List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Apply CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Using the Resync CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Key Resync CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
How Resync CP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Resync CP Backfill List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Working on a Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Resync CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Working With a Resolution CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Key Resolution CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
How Resolution CPs Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Using a Resolution CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Resolution CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Using the Resync By CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . 436
u s e r g u i d e

Table of Contents
Appendixes A Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Annotated Revision View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Archive Information View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Change Package View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Change Packages View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Graphical History View (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Locks View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Member History View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Member Information View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Non-Members View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Project View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Project History View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Project Differences View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Project Information View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Registered Projects View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Registered Sandboxes View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Revisions Information View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Sandbox View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Sandbox Information View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
B Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
vii

Table of Contents
viii
u s e r g u i d e

Welcome to Source
Integrity Enterprise Edition
1
Increased software complexity, globally distributed development
operations, higher expectations for software quality and reliability,
e-business development initiatives, mergers and acquisitions, Web and
intranet site management—all are factors driving the need for robust
software configuration management in the global software development
organization.
MKS Source Integrity® Enterprise Edition (also referred to as simply
Source Integrity) addresses these challenges. It is the best of breed,
enterprise choice for comprehensive, cross-platform software
configuration management.
Its platform transparent, advanced multi-tier architecture is scalable in
local and distributed environments, and its flexibility allows for high
quality integrations into other industry leading IDEs and developer
productivity tools including MKS Integrity Manager for powerful,
workflow enabled SCM.
Source Integrity is the ideal SCM solution for large, distributed
development organizations with complex development environments.
Briefly, there are two main roles when using Source Integrity: the
administrator and the user.
The administrator installs Source Integrity; 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 Source Integrity projects.
The Source Integrity Enterprise Edition User Guide provides details on the
user role and explains how to approach the day-to-day tasks in
Source Integrity.
1

Chapter 1: Welcome to Source Integrity Enterprise Edition
About This Guide
2
This guide provides details on the user role, explaining how to approach
the day-to-day tasks in Source Integrity.
This chapter introduces you to the Source Integrity Enterprise Edition User
Guide and its contents. The following is a list of the guide’s other chapters,
with a brief description of the topics covered by each chapter:
Chapter 2: “Understanding Source Integrity” on page 13
Describes how Source Integrity works together with the Integrity
Server and Integrity Manager to provide a complete versioning
control solution.
Chapter 3: “Getting Started Using Source Integrity” on page 23
Describes installing and uninstalling the Integrity client, starting the
Source Integrity client, logging in, setting preferences, logging out,
and quitting a Source Integrity session.
Chapter 4: “Source Integrity Interfaces” on page 75
Describes the various Source Integrity interfaces that you can work in,
including the Source Integrity graphical user interface, the
Source Integrity Web interface, the Source Integrity command line
interface, and the MKS Visual Difference and MKS Visual Merge
interfaces.
Chapter 5: “Project and Sandbox Operations” on page 115
Describes the basic tasks to work with projects, sandboxes, and
members, for example, creating a sandbox, adding members, and
checking out members for editing.
Chapter 6: “Member Operations” on page 153
Describes the operations to peform on members, for example adding,
dropping, checking in, checking out, and deferring.
Chapter 7: “Using Change Packages and Reviews” on page 213
Describes how to use change packages and reviews, for example
adding entries to a change packge, submitting change packages, and
reviewing change packages.
Chapter 8: “Viewing and Editing Projects, Sandboxes, and
Members” on page 257
Describes how to manage projects, sandboxes, and members, for
example, viewing and editing project information, adding labels to
projects, and freezing members.
u s e r g u i d e

About This Guide
Chapter 9: “Viewing and Editing Member Histories and Revisions”
on page 309
Describes how to manage member histories and revisions, for
example, viewing and editing revision information, deleting revisions,
and promoting revisions.
Chapter 10: “Branching and Merging Revisions” on page 337
Describes the advanced tasks of branching and merging revisions and
the different methods and tools used for these tasks, including the
MKS Visual Merge tool.
Chapter 11: “The Integrity Manager Integration” on page 371
Describes creating a change package, adding project members to an
issue’s change package, viewing change package information, and
closing change packages in Source Integrity.
Chapter 12: “Advanced Change Package Operations” on page 381
Describes the Apply CP and Resync CP commands—functionality that
relies on the use of change packages that track changes in a project.
Using Apply CP and Resync CP, specific code content can be
identified and isolated, and then moved to a new development path.
Appendix A: “Views” on page 441
Describes the views that are available in Source Integrity.
Appendix B: “Glossary of Terms” on page 473
Provides a glossary of common terms and definitions for
Source Integrity.
3

Chapter 1: Welcome to Source Integrity Enterprise Edition
Related Documentation
4
To provide you with the most convenient means of retrieving information,
product documentation is available in several formats: print, Adobe
Acrobat’s Portable Document Format (PDF), online help, and manual
pages (man).
Documentation Print PDF Online Man
Integrity Server Installation and
Administration Guide
Integrity Server Administration
CLI Reference Guide
What’s New in Source Integrity
Enterprise Edition
Features and Benefits in
Source Integrity Enterprise
Edition
Source Integrity Enterprise
Edition Datasheet
Source Integrity Enterprise
Edition User Guide
Source Integrity Enterprise
Edition CLI Reference Guide
Integrity Solution Integrations
User Guide
Yes Yes AA, IM, SI a
No Yes Yes Yes
No Yes No No
No Yes No No
No Yes No No
Yes Yes Yes No
No Yes Yes Yes
No Yes Yes No
What’s New in Integrity Manager No Yes No No
Features and Benefits in
Integrity Manager
No Yes No No
Integrity Manager Datasheet No Yes No No
Integrity Manager User Guide Yes Yes Yes No
Integrity Manager CLI Reference
Guide
Integrity Solution Integrations
Builder Guide
No Yes Yes Yes
No Yes No No
Using MKS Make No Yes No No
Release Notes No No Yes No
a For Authorization Administration graphical user interface, Integrity Manager, and Source Integrity policies only.
u s e r g u i d e
No

Related Documentation
PDF files are located in the \documentation subdirectory of the
distribution CD. To view them you must have the Acrobat Reader
installed on your machine. You can install the reader by running the setup
program in the \support\acrobat subdirectory on the CD. Once you
install the reader, whenever you open a PDF file the reader starts
automatically.
In addition to the Integrity Server Installation and Administration Guide, the
other documentation included in this release is as follows:
Integrity Server Administration CLI Reference Guide provides details on
the command line utilities available for administration tasks.
Integrity Solution Integrations User Guide describes how to access the
functionality of Source Integrity and Integrity Manager while working
within your favorite integrated 3rd party tool, such as Sybase
PowerBuilder and Microsoft Project.
What’s New in Source Integrity Enterprise Edition describes the new
features in this release of Source Integrity.
Features and Benefits in Source Integrity Enterprise Edition provides a
complete list of Source Integrity features and benefits.
Source Integrity Enterprise Edition Datasheet provides a summary of
features and capabilities for Source Integrity.
Source Integrity Enterprise Edition User Guide tells users how to get the
most out of Source Integrity and explains how to approach day-to-day
tasks.
Source Integrity Enterprise Edition CLI Reference Guide gives details on
the command line utilities included with Source Integrity.
What’s New in Integrity Manager describes the new features in this
release of Integrity Manager.
Features and Benefits in Integrity Manager provides a complete list of
Integrity Manager features and benefits.
Integrity Manager Datasheet provides a summary of features and
capabilities for Integrity Manager.
Integrity Manager User Guide tells users how to get the most out of
Integrity Manager and explains how to approach day-to-day tasks.
Integrity Manager CLI Reference Guide gives details on the command
line utilities included with Integrity Manager.
Integrity Solution Integrations Builder Guide provides the information
you need to create your own integrations through the Application
Programming Interface (API).
5

Chapter 1: Welcome to Source Integrity Enterprise Edition
6
Using MKS Make describes the MKS Make tool offering developers,
project managers, and authors an efficient way to automate the
production and maintenance of any project, large or small. Whenever
you make changes to an element of a development project, MKS Make
automatically recompiles all related files and no others, saving
valuable time and eliminating errors.
Online help is accessible from within the graphical user interfaces.
Online man (manual) pages for the command line utilities are available
on the client by using the man command in the command line
interface.
Online release notes provide the most up-to-date details about this
release. You should review these notes as they may contain
information that only became available after the printed
documentation went to press. You can read the release notes from the
CD Browser as HTML documents in a Web browser.
NOTE
Typographical Conventions
In addition, you can browse to www.mks.com/products/
whitepapers.shtml to view and download white papers that cover best
practices and more in-depth applications of the Integrity Solution.
Throughout the manuals, the following typographical conventions identify
the features, functions, and components of the Integrity Solution.
Items in documentation Appear as
Menus, commands Tools > Preferences
Graphical user interface commands the Member command
Command line commands si co
Dialog boxes, features Demote Member, Cancel, OK
Screen information, messages Type a name for this
development path:
Environment variables TMPDIR
Path names c:\srcint\work
u s e r g u i d e

Assumptions
Items in documentation Appear as
New terms appear in italics the first time
NOTE
Assumptions
Keyboard keys appear in caps, for example: ENTER;
CTRL; ALT, F, S
Procedures for the graphical user
interface, command line interface, and
Web interface
A note provides you with information that supplements the key points of the
subject. A note may also supply information that applies only in particular
cases.
TIP
A tip provides you with information for using the product effectively.
IMPORTANT
An important note provides you with information that is essential for
completing a task.
CAUTION
A caution note advises you about situations that have the potential to result in
a loss of data.
Before using Source Integrity, MKS assumes that you have experience with
the following:
Windows (if you are using the Windows client and/or server)
Solaris (if you are using the Solaris client and/or server)
Linux (if you are using the Linux client and/or server)
7

Chapter 1: Welcome to Source Integrity Enterprise Edition
Getting Help
8
IBM AIX (if you are using the AIX client and/or server)
HP-UX (if you are using the HP-UX client and/or server)
your chosen Integrated Development Environment (IDE), for
example, Sybase PowerBuilder (if you are using the integrations with
Source Integrity)
MKS Customer Care is focused on delivering the right solutions to issues
as they arise. For assistance, you can choose online support or telephone a
Technical Support Representative.
For online support, browse to www.mks.com/support. There you will find
easy access to e-mail, Web request services, automatic product
notifications, and the Customer Community—a secure database that
provides helpful resources such as product documentation, knowledge
base articles, product downloads, user forums, presentations, and more.
MKS’s global support professionals comprise a tightly knit team of
problem solvers, sharing critical information to help you resolve issues in
the shortest possible time with optimal results. Support representatives can
provide you with a variety of product related tips and innovative solutions
to your unique problems.
Online Web www.mks.com
E-mail support@mks.com
Telephone Toll Free North America 800 219 4842
Outside North America 00800 219 484 24
Direct North America 519 884 2270
UK +44 (0) 1483 733910
Germany +49 711 351775 7575
Fax North America 519 884 8861
UK +44 (0) 1483 733901
Germany +49 711 351775 7555
u s e r g u i d e

Professional Services
The hours of operation for Customer Care are as follows:
Professional Services
North America: 8:00 A.M. to 8:00 P.M., Monday to Friday, Eastern
Standard Time (GMT-5)
United Kingdom: 9:00 A.M. to 5:30 P.M., Monday to Friday, British
Standard Time (GMT)
Germany: 9:00 A.M. to 5:30 P.M., Monday to Friday, West Europe
Standard Time (GMT+1)
A successful configuration management system is not built on software
alone. At MKS, our professional services team is committed to
understanding the ever changing development environments of our
clients. The professional services team can provide training, upgrade,
migration, implementation, and installation services that meet your unique
requirements.
MKS professional services can help guide you through process analysis,
software installation, source code archive migration, and product and
process training for the entire suite of MKS products—MKS Source
Integrity Enterprise Edition, MKS Integrity Manager, MKS Implementer
for iSeries, and MKS Code Integrity Enterprise. This ensures that the
implementation of your new solution goes smoothly, while allowing your
developers to make progress on critical projects.
The professional services team can truly add value to your MKS
technology investment by providing the following services:
process assessment
best practice consultation
migration services
upgrade services
implementation services
education and training
9

Chapter 1: Welcome to Source Integrity Enterprise Edition
10
For more information on MKS professional services:
Your Feedback Is Welcome
Online Web Global www.mks.com/services
MKS welcomes your feedback on the documentation included with this
product. If you have comments or suggestions about any of the guides or
the online help, send them to:
pubs-mgr@mks.com
Include the following information with your feedback:
product name and version number (from the About box)
title of manual or online help topic
page number (for manuals only)
your suggested correction or improvement
NOTE
E-mail North America consulting@mks.com
Europe europe@mks.com
Telephone North America 800 633 1235
UK +44 (0) 1483 733900
Germany +49 711 351775 0
The e-mail address is provided for comments on the MKS documentation only.
You may not receive a reply to your e-mail. For technical questions or for
software support, you should contact MKS Global Customer Care
(support@mks.com).
u s e r g u i d e

Where To Go From Here
To Do This … See …
Where To Go From Here
Install the Integrity Client. “Installing the Integrity Client” on
page 24
Log in to Source Integrity. “Logging In to Source Integrity” on
page 36
Set Source Integrity preferences. “Setting Preferences” on page 40
Create a project. “Creating a Project” on page 116
Create a sandbox. “Creating a Sandbox” on page 135
Add members to a Source Integrity
project.
“Adding Members to a Project” on
page 157
Check out a member. “Checking Out a Member” on
page 178
Check in a member. “Checking In a Member” on page 186
Create a change package “Creating a Change Package” on
page 217
View a project history. “Viewing a Project History” on
page 263
View a member history. “Viewing a Member History” on
page 310
Use Integrity Manager with
Source Integrity.
“Integrating With Integrity Manager” on
page 372
Learn Source Integrity terms. “Glossary of Terms” on page 473
11

Chapter 1: Welcome to Source Integrity Enterprise Edition
12
u s e r g u i d e

Understanding Source Integrity
2
KEY TERMS: concepts, client, version control, project, sandbox, history, member,
delta, checkpointing, variant, development path, integrated
development environment
Source Integrity is a comprehensive, project-oriented, software
configuration management system that gives you control over the changes
to your software applications. Source Integrity not only documents the
changes made to your files, but it also tracks who made them, when they
were made, and the reasons why.
Source Integrity provides project-based functionality that allows team
members to:
group related files into projects that follow your development cycle
effectively manage multiple development projects
secure software assets
meet deadlines
contribute throughout the application lifecycle
Source Integrity has extensive options to support a configuration
management system that conforms with your established policies.
Whether you work in a small development group or as part of a large
team, Source Integrity has the features to help you get the job done.
Source Integrity is also an integral part of the MKS Integrity Solution. The
Integrity Solution manages software applications across your enterprise
with a streamlined process for the creation and approval of mission-critical
business applications. Based on a unique, open, application server
architecture, the Integrity Solution includes:
workflow (Integrity Manager) for collaboration, approval, and change
management
version control (Source Integrity) and configuration for software
management
13

Chapter 2: Understanding Source Integrity
Projects and Sandboxes
Working With Projects
14
A project is any group of files that, taken together, forms a single body of
work. Projects are presented in Project views, which list the members of the
project and provide access to them.
In a development environment using Source Integrity, for example, a
project might include source code files required to build a program
element. In Source Integrity, the files in the project are known as members.
Your organization can use projects to manage a variety of development
initiatives.
All top-level projects and subprojects reside on the Integrity Server.
Source Integrity 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.
Sandboxes can reside on the client machines and allow you to work locally
in your own workspace, without interfering with the work of others. You
can think of the sandbox as a local pointer to the project residing on the
Integrity Server. A sandbox is a mirror image of a Source Integrity project.
Although it looks and acts like the project it mirrors, it is actually a
collection of pointers to its real-life counterparts in the master project.
In basic terms, when a user is ready to work with a file from the
development project or Web site, a check out operation downloads the file
from the server project to the client sandbox. Similarly, a check in operation
updates the server project with content from the sandbox.
Organizing your files in a project allows you to perform configuration
management operations on the files as a group. When an administrator is
ready to place a group of development files under Source Integrity control,
the first step is to create a project on the Integrity Server.
All projects must be registered with the Integrity Server and member
histories are added as members of the registered project.
All files and projects have one thing in common: Source Integrity can save
them as revisions in a history file and then recreate them at any time. An
object’s content is stored in something known as an archive; for many files,
the content is simply lines of HTML, code, or JavaScript.
u s e r g u i d e

File and Object Histories
File and Object Histories
For projects, however, the saved content is different. A project is a
development object whose content consists of metadata that describes all
the other development objects (that is, the project’s members) and the
relationships between them.
Metadata is composed of all of the information about a revision or archive,
as opposed to the information that is part of the object. For example, a
revision’s Revision Description is metadata since it is information about
the revision, while the contents of the revision is part of the revision itself
and, hence, is not metadata.
Metadata includes:
revision number of the project
location and names of all project members
type and revision number of each member
project-specific configuration
Source Integrity creates a history for each file or object stored in the server
projects. Each submitted update is recorded in an object’s history as a
version and given a sequential number for reference. The original version is
numbered 1.1, and each subsequent version increases the number to the
right of the decimal point by one (for example, 1.2). Each version of the
object can be viewed individually.
15

Chapter 2: Understanding Source Integrity
16
The history for an object with its versions.
How Files and Objects Are Stored
Source Integrity stores your development files and Web objects in projects
and archives, and then manages access to them through sandboxes.
The data preserved in Source Integrity histories can be one of two types,
Binary or Text. Binary is a file containing unprintable characters, or lines
too long to be handled by text editors. Text is the file format expected by
MS-DOS and Windows text file editors. When a file of type “Text” is
checked out, Source Integrity adds the appropriate line ending character
for that type of client.
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, Source Integrity can reconstruct any
previous version of the member. The archive is sometimes referred to as
the RCS file, for historical reasons.
This procedure has a number of advantages over other software
configuration management systems in that it:
simplifies the identification and retrieval of earlier versions of
development objects
provides control over access to data files
keeps team members well informed on project status
u s e r g u i d e

What Is a Project Member?
What Is a Project Member?
You must manage all development objects. This lets you maintain a
complete change history as objects pass through the development cycle.
The administrator is responsible for including these pre-existing objects in
a project to establish their place in the overall development plan. New
objects are then added as your developers create them.
An object under Source Integrity control has three main components:
working file where you make your changes (always in a sandbox)
member history file where your history of changes is stored
revision number identifying (per project or variant) which version of
the object is relevant for a given point in time
In a project, a project member is a specific revision of a development object.
When you check out a project member, it is a specific revision of the object
that is copied to a working file, where you can work with it. When you
finish making changes and check the working file back into the history,
Source Integrity creates a new revision in the object’s archive.
At this point, you have the option of updating the project to use the new
revision of the object. In this way, the project stays current with the most
recent changes to its members.
The project has its own history, and so does each individual member.
17

Chapter 2: Understanding Source Integrity
History File: Storing Deltas
18
Keeping a project current with the most recent member changes is the
default behavior for Source Integrity, and it is the recommended way for
most people. If for some reason you need to check in a member without
updating the member revision, the check in process lets you choose.
When Source Integrity performs a check in operation with a text file, it
calculates and stores the changes that must be made to the new revision to
recreate the previous revision in the history.
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.
The set of differences (stored in a history) between one revision and its
immediate ancestor, is known as a delta. Using deltas, the program can
reconstruct the exact contents of any revision without having to store
complete copies. Known also as reverse delta storage, it is the standard RCS
format for archives.
In theory, saving only the changed portion of each revision produces a
smaller history file than if the entire file were saved each time. There are
situations, however, where this method may not be the most efficient.
When Source Integrity compares the file being checked in to the previous
revision, it compares them line by line. While this is a logical and efficient
way to handle text files, it is not always effective with binary files. A
relatively small change at the beginning of a binary file can affect all
subsequent data in the file.
A binary file contains unprintable characters, or lines too long to be handled
by text editors.
As a consequence, the record of changes (that is, the delta) for some binary
files may be as large as, or larger than, the file itself. Source Integrity also
rewrites the member history after each check in operation, making
operations slow for large histories.
To keep the size of the member history relatively small, they can be stored
in the reference format. In this format, the program stores each revision
separately from the member history. The member history then stores a
reference to the revision.
u s e r g u i d e

Project Checkpointing
The member history describes the file’s revisions and the differences
between them.
Project Checkpointing
Source Integrity provides a number of configuration options relating to
how member histories and deltas are stored. For more information on
configuring these options, see the Integrity Server Installation and
Administration Guide.
Just as you can check in a source file to preserve the changes made to it
from one revision to another, you can also track the changes to a project. In
Source Integrity, this process is called checkpointing.
Checkpointing saves a copy of the project as a baseline in the project’s
history as a revision, including the list of members along with their
revision numbers and project and member attributes.
You can use the project’s revision number to keep track of your projects,
but to simplify post-release maintenance, you can 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.
19

Chapter 2: Understanding Source Integrity
20
Some sites check in projects daily, while others wait until significant new
functionality is added or until important members reach a particular
promotion state. This diagram shows a series of project checkpoints.
Source Integrity can checkpoint subprojects when a project is
checkpointed.
Using checkpointed projects, Source Integrity also allows you to view a
summary of the changes that have occurred between two versions of a
project.
Source Integrity Change Packages
Work may need to be performed on several members in order to address a
development issue. Source Integrity provides change packages that act as a
container to group all of the necessary changes together.
When used to control development, deferred member operations can be
recorded as change package entries, and then submitted at once to ensure a
complete resolution of the issue. If using change package reviews, changes
for pending operations require review acceptance before commitment to
the repository.
u s e r g u i d e

Working With Variants and Development Paths
Working With Variants and Development
Paths
Regular sandboxes are based on the current state of the project. You can
also create a sandbox that is based on a previously checkpointed revision
of the project. This type of sandbox is called a variant.
When you create a variant project, you choose a checkpoint (baseline) of
your project and use it as the starting point for a new branch of
development. Source Integrity allows you to do this by defining a new
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.
The trunk is the primary line of a file’s change history in a history. The first
member of the trunk is always the original file checked into the archive.
Source Integrity 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 that
development path and the changes made by other developers using it.
Development paths are useful for:
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
21

Chapter 2: Understanding Source Integrity
Integrations Support
22
Source Integrity supports the following integrations::
IDE Versions
Borland CodeWright 7.0c
Borland Delphi 7.0
Borland JBuilder 8.0 Enterprise, and 9.0 Enterprise
Borland Together ControlCenter 6.1
Eclipse (open source) 1.0.0, 2.0.2, 2.1.1, 2.1.x
IBM Rational Rose Enterpise Edition 2000
IBM WebSphere Studio Application
Developer
IBM WebSphere Studio Application
Developer Integration Edition
IBM WebSphere Studio Site
Developer
IBM WebSphere Development Studio
Client for iSeries
IBM WebSphere Development Studio
Client Advanced Edition for iSeries
4.0.x, 5.0, 5.1, 5.1.x
Source Integrity documents the changes made to your files, and also tracks
who made them, when they were made, and the reasons why.
5.0
4.0.x, 5.0, 5.1
5.0 and 5.1
5.0 and 5.1
Mercury Interactive TestDirector 7.6 and 8.0
Microsoft Visual Basic 6.0
Microsoft Visual C++ 6.0
Microsoft Visual J++ 6.0
Microsoft Visual Studio .NET Enterprise Edition 2003
Microsoft Windows Explorer Windows 98 Second Edition, ME,
2000, NT 4.0
Sybase PowerBuilder 8.0.3, and 9.0
u s e r g u i d e

Getting Started Using
Source Integrity
KEY TERMS: Integrity Client, permissions, access control list, preferences
3
Source Integrity uses client/server architecture to protect and manage
your files. Project files reside on the server and are accessed by requests
from the client application on your workstation. Therefore, to access your
project files on the Integrity Server, you must first open a connection
through the Source Integrity client.
This chapter describes the basic steps necessary to start, configure, and
close a session in Source Integrity. Specific topics covered in this chapter
include:
“Installing the Integrity Client” on page 24
“Configuring Environment Variables for UNIX” on page 29
“Uninstalling the Integrity Client” on page 29
“Before You Start the Integrity Client” on page 30
“Starting the Source Integrity Client” on page 34
“Logging In to Source Integrity” on page 36
“Connecting to Multiple Servers” on page 39
“Setting Preferences” on page 40
“Managing Integrations” on page 70
“Quitting a Source Integrity Session” on page 72
23

Chapter 3: Getting Started Using Source Integrity
Installing the Integrity Client
Browser
Support
24
The Intgrity Client contains the Source Integrity graphical user interface.
IMPORTANT
If you are using integrations with Source Integrity, disable all integrations
before you install the new client.
Before installing the Integrity Client, you must have removed any earlier MKS
or Vertical Sky Client (including Source Integrity, Change Integrity, Vertical
Sky Software Manager, or Vertical Sky Collaboration Manager). Failure to do
so may cause operational problems later on.
To install the integrity client from the CD
The Integrity Solution supports Internet Explorer and Netscape browsers.
Specifically, Integrity Manager and Source Integrity Web interfaces require
Internet Explorer 5.5/6.0 (all service packs), or Netscape 6.2.3/7.1.
1 Insert the Integrity Client CD from your package into the CD-ROM
drive.
The Integrity Client CD browser starts automatically and allows you
to select from the following options:
RELEASE NOTES allows you to view the release notes for the
Integrity Client components.
DOCUMENTATION allows you to view the product documentation
in Adobe Acrobat PDF format.
INSTALL allows you to install the Integrity Client.
2 To start the installation process, do one of the following:
From the Integrity Client CD browser, click INSTALL.
A page is displayed allowing you to start the installation program
for your particular platform.
For Windows, click the link.
For UNIX, follow the written instructions.
u s e r g u i d e

NOTE
Installing the Integrity Client
For UNIX systems, the Integrity Client installation program reports an error if
there is insufficient free space in the /tmp directory in the $HOME directory.
MKS does not certify any PC X-Servers. If your PC X-server provides full
support for Xwindows, the MKS client may operate.
For Windows, a dialog box is displayed asking you if you want to
run or save the installation program. The installation program file
name is mksclient.exe. Specify one of the following:
Run the installation program directly from its current
location (the CD).
Save the installation program to disk (a location you specify),
and run it from there.
Run, as appropriate for your platform, mksclient.exe or
mksclient.bin, which is located on the Integrity Client CD
in the appropriate installs directory.
3 If you are installing on a UNIX platform, complete the following steps
before continuing; otherwise, go to step 4.
Copy mksclient.bin to a temporary directory on your server
computer.
Make sure the environment variable $DISPLAY is set, if
appropriate.
To make mksclient.bin executable, run:
chmod +x mksclient.bin
To run the installation, type
./mksclient.bin
4 The InstallAnywhere window opens as the files needed for the
installation are extracted, followed by the License Agreement panel.
Before you can continue with the installation, you must read the
license agreement and indicate your acceptance. The default setting is
I do NOT accept the terms of the License Agreement.
To accept the license agreement and continue with the
installation, select I accept the terms of the License Agreement
and click Next.
If you do not accept the license agreement, click Cancel. The
Integrity Client is not installed.
25

Chapter 3: Getting Started Using Source Integrity
26
If you accept the license agreement, the Select Integrity Client
Components panel is displayed.
5 Depending on the product components you are licensed to use, select
Integrity Manager, Source Integrity, Administration Client, or a
combination of your choice.
NOTE
To perform configuration tasks for the Integrity Server, administrators should
select Administration Client.
6 To continue, click Next.
The Integrity Client Installation Location panel is displayed.
7 To specify where you want to install the Integrity Client, do one of the
following:
To accept the default path location, click Next. For example, by
default, the Windows Integrity Client is installed to:
C:\Program Files\MKS\IntegrityClient
To find the directory where you want to install the Integrity
Client, click Browse. To continue, click Next.
Type the path of the directory where you want to install the
Integrity Client. If the directory does not exist, it is automatically
created. To continue, click Next.
NOTE
If at any time you want to restore the default location, click Restore Default
Directory and then click Next to continue.
8 In step 5, if you chose to install more than one product, the Specify
Server Connection Default panel is displayed. Select one of the
following options and click Next to continue:
Same Integrity Server for all components
Different Integrity Server for each component
In step 5, if you chose to install only one product component, the
Specify Integrity Server Connections panel is displayed, displaying
fields for server host name(s) and port(s) based on the product you
chose to install. Enter the server host name and port information and
click Next to continue.
u s e r g u i d e

NOTE
Installing the Integrity Client
By default, the listening port for the Integrity Server is 7001. Administrators
must notify users of the assigned port number.
Administrators can change the default listening port for their site by modifying
the property for weblogic.system.listenPort under /
mksis/weblogic.properties. If the Integrity Manager component is
running on a different server, the Integrity Manager listening port is set by
modifying the property for im.port under /mksis/
si.properties.
The Specify Integrity Server Connections panel is displayed.
The following shows an example of a completed panel for Specify
Integrity Server Connections where different servers are selected for
each product. By default, the Administration Client uses the server
and port specified for Source Integrity.
The Select Source Integrity Reporting Application panel is displayed.
The Source Integrity Reporter utility helps you analyze projects, their
members, or individual archives, and allows you to generate a variety
of graphs and reports based on its findings. The Source Integrity
Reporter utility stores its data using Microsoft Access 97.
27

Chapter 3: Getting Started Using Source Integrity
28
Depending on what version of Microsoft Access you have on your
system, the following Source Integrity Reporter options may appear:
Use Existing Microsoft Access 2000 Retail is displayed when you
have Microsoft Access 2000 on your system. Selecting this option
allows Source Integrity’s Reporter utility to use the full version of
Access 2000.
Use Existing Microsoft Access 97 Retail is displayed when you
have Microsoft Access 97 on your system. Selecting this option
allows Source Integrity’s Reporter utility to use the full version of
Access 97.
Install and Use Microsoft Access 97 Runtime allows
Source Integrity’s Reporter utility to use the minimal install of
Access 97 Runtime. This option is available even if you have a full
version of Access already installed on your system.
Use Existing Microsoft Access 97 Runtime is displayed only if you
had a previous version of Source Integrity on your system.
Selecting this option allows the Source Integrity Reporter utility
to use the existing minimal install Access 97 Runtime application.
Do Not Use Source Integrity Reporting means that
Source Integrity’s Reporter utility will not be available.
9 Select a Source Integrity Reporter option and click Install.
The Integrity Client program files are installed on your computer and
the Install Complete panel is displayed.
10 To continue, click Next.
The System Environment Changed panel is displayed, informing you
that your system environment has changed and that you need to log
out and reboot your system for the changes to take effect.
11 To quit the installer, click Done.
12 Restart your computer to have the system environment changes take
effect.
IMPORTANT
For AIX and SuSE Linux, the IntegrityClient.rc file cannot be on an
NFS-mounted drive. Source Integrity cannot be started if $HOME is pointing to
a drive mounted on NFS or NIS. If the system is pulling the NFS mounts over
NIS, then -noac is ignored in the NIS mount options. Select the NIS option for
mounting NFS with -o noac.
u s e r g u i d e

Configuring Environment Variables for
UNIX
Configuring Environment Variables for UNIX
On UNIX, you can decide to configure the following environment
variables once you have installed the Integrity Client:
Add the /bin directory to the PATH
environment variable.
Modifying the PATH environment variable eliminates the requirement
to type the full path to executables for Source Integrity,
Integrity Manager, and the Authorization Administration application.
Add the /etc directory to the MANPATH
environment variable.
Modifying the MANPATH environment variable ensures that the man
command can access the man pages for Source Integrity,
Integrity Manager, and the Authorization Administration application.
The is the path to the directory where you
installed the Integrity Client.
Uninstalling the Integrity Client
If you have installed and enabled the Windows Explorer integration, you
must exit Windows Explorer before beginning the uninstall process.
To uninstall the Integrity Client on Windows
1 Do one of the following:
From the Windows Start menu, select Programs > MKS Integrity >
Uninstall > Integrity Client Uninstall.
Run the uninstall program file:
\uninstall\IntegrityClientUninstall.exe
where is the path to the directory where you
installed the Integrity Client.
The InstallAnywhere Uninstaller panel is displayed. The uninstall
program removes all installed components, except any files or folders
created after the installation.
2 To run the uninstall program, click Uninstall.
29

Chapter 3: Getting Started Using Source Integrity
30
3 To exit the uninstall program, click Done.
To uninstall the Integrity Client on UNIX
Run the uninstall program file:
/uninstall/IntegrityClientUninstall
where is the path to the directory where you installed the
Integrity Client.
The InstallAnywhere Uninstaller panel is displayed. The uninstall program
removes all installed components, except any files or directories created
after the installation.
Before You Start the Integrity Client
Understanding
Access
Permissions
Before you start the Source Integrity client, ensure you have the following:
the name and port number of the Integrity Server you want to connect
to
a copy of the Source Integrity client installed locally on your computer
your Source Integrity user name and password
NOTE
Your administrator provides you with a server name, port number, user name,
and password.
Your ability to perform tasks in Source Integrity depends on the
permissions granted to you by your administrator. Access to all functions
is managed through a database that controls the permitted activities for all
Source Integrity users.
Permissions are a collection of pre-defined functionality and operations that
can be assigned to users, granting access to certain Source Integrity tasks.
The set of assigned permissions determines each user’s access to the
various functions of Source Integrity. If a user is not granted the
permission, that user is not able to complete the task. For example,
checking out files in Source Integrity requires the FetchRevision and
Lock permissions.
Depending on your permissions, you can view the permissions assigned
for both projects and project members, but only your administrator can
modify the permissions.
u s e r g u i d e

Understanding
Access Control
Lists
Before You Start the Integrity Client
To view project permissions in the graphical user interface
Do one of the following:
From a Project view, select Project > Properties > Project Permissions.
From a Sandbox view, select Sandbox > Properties > Project
Permissions.
The Project Permissions dialog box opens and displays the assigned access
permissions for the selected project.
To view member permissions in the graphical user interface
From a Project or Sandbox view, select Member > Properties > Member
Permissions.
The Member Permissions dialog box opens and displays the assigned
access permissions for the selected member.
If you find you are unable to perform necessary operations, you must
contact the administrator responsible for Source Integrity at your site to
review the permissions assigned to you. For example, if you are unable to
create a new project, it may mean that you have not been assigned the
required permissions for this operation.
IMPORTANT
If your administrator has assigned you a new set of permissions, you must
update your permissions by disconnecting your Source Integrity client and
then reconnecting to the Integrity Server. An out-of-date permission set may
cause unpredictable behavior when attempting to open projects or perform
other tasks. To disconnect from the server, see “Logging Out of Source
Integrity” on page 72.
An Access Control List (ACL) is a collection of entries that permits or limits
entry to the functionality of a software program or server. The Access
Control List allows the administrator to manage user access by requiring
authentication of the user’s identity or membership in a predefined group.
Access is then granted according to the assigned permissions. Access
Control Lists (ACLs) store security, configuration, and administrative
information for the Integrity Server and Source Integrity. They work in
conjunction with your network’s authentication system to provide control
over features and functions.
31

Chapter 3: Getting Started Using Source Integrity
32
ACLs comprise principals and permissions. Principals control the users
and groups who have access to the functionality of Source Integrity
operations. Permissions specify the particular operations that are available.
Each ACL entry identifies the allowance or denial of pre-defined sets of
permissions. These permissions are configured by your administrator.
You can view ACLs through Source Integrity to see which permissions
your administrator has or has not assigned to you.
To view ACLs in the graphical user interface
1 From the Source Integrity application window, do one of the
following:
Select Tools > Manage Projects.
Select Tools > Manage Sandboxes.
A list of the registered projects or sandboxes is displayed in the
Registered Projects or Registered Sandboxes view respectively.
2 Select the project or sandbox you want to view ACLs for.
TIP
The Registered Projects view supports standard shortcut menus. To display
the menu of actions you can perform, select a project and right click.
Source Integrity displays the applicable shortcut menu.
3 Click Permissions.
The ACL dialog box opens and displays the ACLs for the selected
project or sandbox.
u s e r g u i d e

Before You Start the Integrity Client
You can expand each principal to view the permissions.
IMPORTANT
While Source Integrity does allow users to view their ACLs, it is not
recommended that users attempt to modify these ACLs or create any specific
ACLs. For more information on ACLs, see your administrator, and consult the
Integrity Server Installation and Administration Guide.
33

Chapter 3: Getting Started Using Source Integrity
Viewing Group
Membership
Administrator
Defined Client
Settings
34
When your ACLs are based on group membership, it can be useful to use
the command line interface to view the groups that you belong to.
To view groups in the command line interface
Use the aa users command
where
aa users --groups username
username specifies the ID of the user who you want to view group
membership for.
As a result of certain Administrator settings, you may experience
additional Integrity Client dialog prompts or behavior that is not
documented in this guide. Contact your administrator for more
information.
Starting the Source Integrity Client
The Source Integrity client is accessible in three interfaces: the graphical
user interface, the Web interface, and the command line interface.
The Source Integrity Web interface is available for performing a variety of
tasks.
NOTE
You do not need to install the Integrity Client to access the Source Integrity
Web interface.
You can also choose to work alternately between the graphical user
interface and the command line interface, because most Source Integrity
commands are available in these two interfaces. For example, you can
perform a command in the command line interface and view the results in
the graphical user interface.
Instructions for quitting a session are provided in the section entitled
“Quitting a Source Integrity Session” on page 72.
u s e r g u i d e

IMPORTANT
Starting the Source Integrity Client
Ensure that the Integrity Server you are connecting to is the same version as
your Source Integrity client. Attempting to connect with an incompatible client
(for example, from an earlier version of Source Integrity or Vertical Sky
Software Manager) results in error messages and unpredictable behavior. To
determine the version of your Source Integrity client, select Help > About. The
client version is displayed on the dialog box. To determine the version of the
Integrity Server, contact your administrator, or in the command line interface,
use the si servers --showversion command.
To start the Source Integrity client graphical user interface on
Windows
Select Start > Programs > MKS Integrity > Source Integrity (default Start
menu shortcut).
To start the Source Integrity client graphical user interface on UNIX
1 Open a shell.
2 Type si gui or si -g.
To start the Source Integrity Web interface
1 Open a Web browser and, in the location or address field, type the
URL of the Integrity Server, for example:
http://abc.Business.com:7001
2 Press ENTER.
The Integrity Server welcome page opens.
The Integrity Server welcome page provides a link to the read-only
version of the Web interface. You can connect to the read-only Web
interface by clicking the read-only mode link displayed under Start
Source Integrity Enterprise Web Interface.
3 Click Start Source Integrity Web Interface.
The Enter Network Password dialog box is displayed.
4 Type your user ID and password, and press ENTER.
The Source Integrity Web interface opens in a new browser window.
35

Chapter 3: Getting Started Using Source Integrity
Logging In to Source Integrity
36
Source Integrity uses client/server architecture to protect and manage
your files. Project files reside on the server and are accessed by requests
from the client application on your workstation.
Problems and error messages on the Source Integrity client are logged to
/bin/IntegrityClient.log.
For both the graphical user interface and the command line interface, you
must establish a connection with the Integrity Server before you can
perform any Source Integrity operations on projects or sandboxes.
IMPORTANT
Ensure that the Integrity Server you are connecting to is the same version as
your Source Integrity client. Attempting to connect with an incompatible client
(for example, from an earlier version of Source Integrity or Vertical Sky
Software Manager) results in error messages and unpredictable behavior. To
determine the version of your Source Integrity client, select Help > About. The
client version is displayed on the dialog box. To determine the version of the
Integrity Server, contact your administrator, or in the command line interface,
use the si servers --showversion command.
All Source Integrity commands automatically prompt you for information
and will connect you to the appropriate server if you are not already
connected. If your system is appropriately configured, there may be
nothing for you to specify. Additionally, if you are using a Win32 system
connecting to an NT server with single signon enabled, you are
automatically authenticated as the current user on your local system.
NOTE
All or some of the login dialog boxes may appear, depending on the
configuration set up by your administrator.
To log in using the graphical user interface
1 Do one of the following:
Select File > Server Connection > Connect.
Click .
The Specify Server Connection dialog box is displayed.
u s e r g u i d e

NOTE
Logging In to Source Integrity
If your preferences are not set to prompt for a server connection, the Specify
Server Connection dialog box does not appear. For more details on
preferences, see “Connection Preferences” on page 43.
2 In the Host Name field, type the name of the Integrity Server you want
to connect to, for example, abcBusiness_nt, or the numerical IP
address, for example 1.2.34.56.
3 In the Port Number field, type the port number.
4 To accept the server information, click OK.
The Enter Credentials dialog box is displayed.
5 In the User Name field, type your user name.
Your user name is displayed by default in the User Name field.
6 In the Password field, type your password.
7 To accept the user information, click OK.
Source Integrity establishes a connection with the server.
To verify your connection, select File > Server Connection. If you are
connected, your user name, server name, and port number appear in
the Server Connection menu.
37

Chapter 3: Getting Started Using Source Integrity
38
IMPORTANT
In the Server Connection menu, the active connection is displayed with a bullet
next to the connection information. If the bullet does not appear, you are not
connected to the server.
In the lower right corner of the graphical user interface, the following
three icons indicate the status of the server:
Icon Type of Server Connection
To log in using the Web interface
1 Start your Web browser.
2 Browse to the location of the Source Integrity home page. Your
administrator can provide you with its location.
The URL for the Integrity Server home page is displayed in the form:
http://:
for example,
Connected to the Integrity Server.
You are logged in and have an active client session.
Disconnected from the Integrity Server.
You have logged out and closed your client session.
Offline from the Integrity Server.
The connection to the Integrity Server has been dropped or the
network connection is down.
http://intra-wif:7001
The MKS Integrity Server home page is displayed.
3 Click Start Source Integrity Enterprise Web Interface.
A browser password dialog box is displayed, prompting you for your
Source Integrity user name and password.
4 In the User Name field, enter your user name.
5 In the Password field, enter your password.
6 To save your password so you do not need to enter it each time you
log in, select the Save this password in your password list option. This
option is available only in Internet Explorer.
u s e r g u i d e

7 To accept the log in information, click OK.
Connecting to Multiple Servers
Source Integrity validates your login information, then the
Source Integrity Web interface is displayed.
When you point to the Source Integrity icon ( ) a ToolTip is displayed
showing your user name, server, and port number for the session. This
information also is displayed in the status bar at the bottom of the browser
window, for example, mkern@dev_nt:7001.
Connecting to Multiple Servers
Source Integrity allows you to work with projects residing on different
Integrity Servers in a single client session.
Connect to multiple servers in the graphical user interface and command
line interface by following the procedure for logging in. Follow the
procedure twice, specifying a different server each time to establish
different connections. For more information on connecting to multiple
servers by logging in, see “Logging In to Source Integrity” on page 36.
The steps required to log in depend on the configuration set up by your
administrator.
In the graphical user interface, to determine which server a project resides
on, use the mouse pointer and pause over a sandbox name displayed in the
Select a Sandbox dialog box. A ToolTip displays the directory path for the
project mirrored by that sandbox. The server name and port number are
displayed in parentheses. For more information, see “Opening or Viewing
a Sandbox” on page 144.
Accessing any Source Integrity operation on a project or sandbox residing
on a server you are not connected to invokes the user login so that you can
switch between connections as you continue to work.
In the command line interface, you can use commands without explicitly
specifying a sandbox option, and Source Integrity determines the sandbox
to operate on based on the directory you are working in.
IMPORTANT
If you create two or more sandboxes in the same directory, Source Integrity
cannot clearly determine which sandbox to use in that directory. If this
happens, you are prompted to specify the name of the sandbox you want to
use. In general, you should not create multiple sandboxes in the same
directory.
39

Chapter 3: Getting Started Using Source Integrity
Setting Preferences
40
To disconnect from multiple Integrity Servers in the graphical user
interface
1 Close the projects or sandboxes you are working in.
2 To disconnect from a server, select File > Server Connection and
choose the target server from the list.
3 Select File > Server Connection > Disconnect.
A dialog box is displayed asking you to confirm that you want to
disconnect your server connection.
4 To disconnect from the server, click Yes.
The target server is disconnected.
5 Repeat steps 2 to 4 to close the remaining server connections.
You can customize your Source Integrity client session by editing the client
preferences. For your convenience, preferences for all clients are available
from the same dialog box. Only Source Integrity client and Integrity Client
specific preferences are documented in this guide.
Options that appear in bold are those that are set locally by you. You can
reset to the default settings by clicking the Clear Local Settings button
(available only on the applicable panels).
IMPORTANT
Your administrator may enforce server-side preferences making them
unavailable to you. These server enforced preferences depend on the server
you are connected to while viewing the preferences. If you are not connected or
logged in to a server, Source Integrity displays the local defaults for all
preferences.
To set your preferences accurately, login to the server you want to work from
before setting preferences. The Preferences dialog box displays the server you
are currently connected to in the title bar. For information on how to login to a
server, see “Logging In to Source Integrity” on page 36.
A blank check box ( ) means the option is not enabled, a check mark ( )
means the option is enabled, and a question mark ( ) means you will be
prompted to confirm or specify the option.
u s e r g u i d e

General
Preferences
Setting Preferences
To open the Preferences Configuration dialog box, do one of the following:
Select Tools > Preferences.
Click .
The Preferences Configuration dialog box is displayed.
You can set your general preferences for the following:
look and feel of the graphical user interface
time delay for pop-up windows
the maximum amount of memory reserved for the Source Integrity
client at runtime
To set general preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), in the tree pane, click Integrity Client >
General.
The General pane is displayed.
2 To set the appearance of the graphical user interface, select an option
from the Look and Feel list. The available choices are System,
Windows, Motif, and Metal.
NOTE
You must restart the Source Integrity client for the new look and feel changes
to take effect. See “Shutting Down the Client” on page 74.
3 To set the time in milliseconds before a command’s status is displayed
in the graphical user interface, type a numeric value in the GUI field
under Popup Status Delay or use the up and down arrows to select a
value. The default value is 2500.
To set the time in milliseconds (ms) that a command’s status is
displayed in the command line interface, type a numeric value in the
CLI field under Popup Status Delay or use the up and down arrows to
select a value. The default value is 0.
41

Chapter 3: Getting Started Using Source Integrity
42
4 To set the maximum amount of memory reserved for the Integrity
client at runtime, under Miscellaneous in the Maximum heap size field,
enter a value in megabytes (MB), or use the up and down arrows to
select a value. The minimum value is 5, and the maximum value is
dependent on your available system memory. The default value is 48.
CAUTION
Changing the heap size setting may unfavorably affect the performance of the
Integrity Client and your system. Consult your administrator before making
changes.
For the heap size change to take effect, restart the Integrity client.
Setting Desktop Preferences
You can set desktop preferences specifically for Source Integrity.
To set desktop preferences for Source Integrity in the graphical user
interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), in the tree pane, click Source Integrity >
Desktop.
The Desktop pane is displayed.
2 To restore all active windows when you restart Source Integrity,
under Miscellaneous, select the Restore Desktop option.
IMPORTANT
You must restart the Source Integrity graphical user interface to activate the
Restore Desktop option.
u s e r g u i d e

Connection
Preferences
Setting Preferences
The Restore Desktop option remembers which windows were open
when you last exited the Source Integrity graphical user interface.
When you restart the Source Integrity graphical user interface the
active windows appear automatically in the main view. Restore
Desktop remembers a maximum of 10 windows.
If you were accessing projects or sandboxes residing on different
servers, when you close and restart the Source Integrity graphical user
interface you must log in again. Source Integrity automatically
restores the windows that were open for that particular server
connection.
You can configure the default settings for server and proxy connections.
You can override the default settings when manually connecting to the
Integrity Server.
To set connection preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), in the tree pane, click Source Integrity >
Connection.
The Connection pane is displayed.
2 On the Connection pane configure the following options:
Under Default Server Connection specify the following options:
To specify a default Integrity Server to connect to in the Host
Name field, type the name of the server, for example, abc_nt,
or the numerical IP address, for example, 1.2.34.56.
In the Port field, type the port number.
43

Chapter 3: Getting Started Using Source Integrity
44
To be prompted for the default Integrity Server name and
port number each time you log in to Source Integrity, select
the Prompt for Host Name and Port option.
Under User you can specify the following options:
In the User Name field, type the user name you want to set as
the default user.
In the Password field, type a password for the user.
If you want to be prompted for the default user name each
time you log in to Source Integrity, select the Prompt for: User
Name option.
If you want to be prompted for the default password each
time you log in to Source Integrity, select the Prompt for:
Password option.
NOTE
If the security scheme at your site is NT Single Signon (NTSS) the Prompt for:
User Name and Prompt for: Password options are ignored unless you specify a
user name that is different than the logged in user name. For information about
your security scheme, see your administrator.
3 Click OK to save your connection preferences.
Your connection preferences are saved.
Proxy Preferences
You can specify advanced proxy server settings for the Source Integrity
client.
Use of a proxy is optional and based on server configuration by your
administrator. Detailed information about proxies at your site, including
host names, port numbers, and connection types are supplied by your
administrator. For more information about using a proxy, contact your
administrator.
For a detailed discussion about using a proxy, see “Implementing
Federated Server Architecture” in the Integrity Server Installation and
Administration Guide.
MKS Federated Server Architecture is an implementation of the Integrity
Server structured to serve client requests through a proxy. The proxy
provides access to project members residing on the Integrity Server by
retrieving information from its local cache or, if changes are detected,
directly from the server.
u s e r g u i d e

To configure proxy preferences in the graphical user interface
Setting Preferences
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), in the tree pane, click Integrity Client >
Servers > Proxies. The Proxy pane is displayed.
CAUTION
Do not change proxy settings when the client is connected to the
Integrity Server.
2 On the Proxy pane configure the following options:
NOTE
The names “direct” and “default” in any case, or combination of case, cannot
be used as proxy host names.
Source Integrity considers spaces and commas in the Host Name field invalid
characters.
Host names and port numbers must match to connect to a proxy successfully.
Source Integrity does not search for the correct port number if you provide an
incorrect one.
Select Use same username and password for proxy and server if
you want the same user name and password to be used when
connecting to both the proxy and server.
Selecting this option does not necessarily ensure that
Source Integrity prompts you only once for your user name and
password. If the authentication schemes used do not match,
45

Chapter 3: Getting Started Using Source Integrity
46
Source Integrity prompts you for your user name and password
again.
For information about the authentication schemes used, contact
your administrator.
Select Always confirm proxy username and password if you want
Source Integrity to prompt you for the user name and password
each time you connect to the proxy.
Select Reuse current proxy username and password for all
connections if you want to use the same proxy user name and
password when connecting to multiple remote servers.
Select Use default proxy for all unlisted connections if you want to
specify the proxy server as the default server for unlisted
connections. This option is only enabled when you complete the
details for a default proxy described next.
To specify a default proxy, under Default proxy complete the
following:
In the Host Name field type the name of the server, for
example, proxyhost, or the numerical IP address, for
example, 1.2.34.67.
In the Port field, type the port number, for example, 7761. If
you do not specify a port number, or use 0 as the port
number, Source Integrity assumes a direct connection.
To configure multiple servers you want to connect to, under
Server, do the following:
Click Add. The Add new server connection dialog box is
displayed.
In the Host Name field type the name of the server or the
numerical IP address.
In the Port field, type the port number.
u s e r g u i d e

TIP
Setting Preferences
Select the type of connection you want by clicking it. Direct
connection specifies connecting without a proxy. Use default
proxy specifies connecting using the proxy specified as the
default on the Proxy pane. To specify a different proxy, select
Proxy and complete the Hostname and Port fields.
Click OK to save the server details and return to the Proxy
pane. The server is displayed in the Server list, for example,
proxyhost:7761 with the connection details that you
selected displayed below. You can review the server details
for each server you configure by selecting it from the list.
To edit a previously configured server, select it from the Server list and click
Edit. The Edit server connection dialog box is displayed. Edit the server details
as required and click OK to save your changes.
To delete a previously configured server, select it from the Server list and click
Delete. The server disappears from the Server list.
SOCKS Preferences
You can specify a network proxy.
To configure the SOCKS preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), select Integrity Client > Servers > SOCKS.
The SOCKS pane is displayed.
2 In the Host Name field type the name of the server or the numerical IP
address.
3 In the Port field, type the port number.
4 To save your preferences, click OK.
47

Chapter 3: Getting Started Using Source Integrity
Command
Preferences
48
The Commands pane in the Preferences dialog box contains default
settings for Source Integrity commands. Default settings can always be
overridden for individual commands at the time of their use.
Some preferences may be enforced by the server and not available for
configuration. For information on server side preferences, see your
administrator.
To set command preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), in the tree pane, click Source Integrity >
Commands.
The commands appear as a list of nodes.
2 From the list of command names in the tree pane, select a command to
configure. The available commands and their options are discussed in
detail in the proceeding table.
NOTE
Options that appear in bold indicate local settings configured by you.
3 If necessary, select a command’s option.
4 To restore a command’s default options, click Clear Local Settings.
u s e r g u i d e

Command Options
Modify options for commands as listed in the following table:
Setting Preferences
Add Member Attribute Recurse Into Subprojects adds member attributes recursively to selected subproject
members.
Add Label Move Existing Label moves the label, if it already exists, to the revision specified.
Recurse Into Subprojects adds the label recursively to subproject members.
Add Members Author is the author name applied to the new members. Type a name in the Author
field. If you do not type a name, Source Integrity uses the current user name.
Add Members From
Archive
Data Type specifies the member’s data type. To let Source Integrity determine the data
type automatically, select Auto from the Data Type list. To specify a text file, select
Text from the Data Type list. To specify a file containing unprintable characters, or
lines too long to be handled by text editors, select Binary from the Data Type list.
The On Existing Archive options apply in the event that Source Integrity finds an
existing archive for the member you want to add. Query User causes
Source Integrity to ask you for confirmation on the action to be taken if an existing
archive is found. Share Archive causes Source Integrity to use the existing archive
for the new member. Create New Archive causes Source Integrity to create a new
archive for the new member. Source Integrity automatically generates the archive
name and leaves the old archive unmodified. Cancel causes Source Integrity to
cancel the operation if an existing member archive is found.
Save Working File Timestamp sets the timestamp of the revision in the history to the
timestamp of the working file, rather than the time of check in.
Close Change Package causes Source Integrity to close any change package
associated with the member revision.
Recurse Into Directories adds members that exist in directories of the current location.
Unexpand Keywords replaces literal values in the working file with keywords.
Defer Add delays the add operation in the project until the deferred operation is
submitted. The operation in the sandbox still takes place immediately.
Lock Revision causes Source Integrity to lock the member revision immediately upon
adding it to the project.
Create Subprojects causes Source Integrity to create subprojects for each
subdirectory encountered when adding members.
Create Subprojects causes Source Integrity to create subprojects for each
subdirectory encountered when adding members.
Recurse Into Directories adds members that exist in directories of the current location.
Close Change Packages causes Source Integrity to close any change package
associated with the member revision.
Defer Add From Archive delays the add operation in the project until the deferred
operation is submitted. The operation in the sandbox still takes place immediately.
Add Project Label Move Existing Label moves the label, if it already exists, to the revision specified.
49

Chapter 3: Getting Started Using Source Integrity
Command Options
50
Add Subproject Select one of the following options as the preferred type of subproject when adding a
subproject to a project:
Normal adds a subproject based on the current state of the project.
Variant adds a subproject based upon a specific revision of the master project and
is used for branching off the main development path.
Build adds a static subproject based upon a specific revision of the master project
that is used for building or testing the project, but not for further development.
Default adds a subproject based on the parent project type. For more information on
the default type, see your administrator.
Append Revision
Description
Recurse Into Subprojects appends the revision description recursively to subproject
members.
Apply Change Package Use Master causes Source Integrity to operate on the top-level sandbox. When the
selected change package is associated with a member in a subsandbox,
specifying Use Master causes the command to operate on the top-level sandbox for
that subsandbox.
Confirm Actions causes Source Integrity to confirm all operations with you before
starting them.
Verbose provides additional information to track the current state of the command.
Other Project is Error terminates the command if the member being applied is in
another project. If this setting is negated (as in noOtherProjectIsError), the
information is displayed as a warning.
Span Projects applies the command to any member in the specified in the change
package, even if this involves a different project than you are starting from. Warning:
This is the only operation that has the potential to affect other projects.
Ignore Cross-Branch Entries causes Source Integrity to use the most recent revision
when it encounters two revisions of the same member on two development paths.
Close Change Package closes the change package when the command completes.
Already in Project is Error terminates the command if the member being applied is
already in the project. If this setting is negated (as in
noAlreadyInProjectIsError), the information is displayed as a warning.
Ignore Server in Change Package causes Source Integrity to perform the Apply CP
operation even if the change package members reside on different servers.
Create Variants causes Source Integrity to create variant projects within the new
project as required to apply the change package members. This option does not affect
the Apply CP command.
u s e r g u i d e

Command Options
Apply Change Package
continued
Setting Preferences
Backfill determines how dependent change packages are treated. You can select from
the following options:
Entire Change Package chooses all historic revisions required by the specified
change packages and applies them by updating the member revisions, adding files,
or dropping files. The user is not prompted to confirm the backfill list.
Back Revisions Only processes only the specified change package(s) and
chooses only directly-associated revisions. It does not process any change
packages that are associated with intermediate revisions.
Error terminates the operation if other change packages are required but are not
specified.
Skip Revisions causes Source Integrity to merge around specified backfill
revisions. Because the Apply CP command does not perform merging, this is
treated as an error.
Ask to Specify allows you to select the specific change packages you want to
include. For the Apply CP operation, a list of additional change packages is
displayed. The presented list of change packages cannot be manipulated. You must
either accept the entire list or the operation fails.
Ignore Update Revision Entries ignores update revision entries in a change package.
There is no user prompt.
Checkpoint Apply Label to All Members applies the checkpoint label to all project members.
Apply State to All Members applies the checkpoint state to all project members.
Notify when Complete causes Source Integrity to confirm that the checkpoint
operation has finished.
Recurse Into Subprojects recursively checkpoints subprojects.
Author is the author name applied to the checkpoint. Type a name in the Author field.
If you do not type a name, Source Integrity uses the current user name.
Check In Move Existing Label moves the label, if it already exists, to the revision specified.
Lock Revision causes Source Integrity to check in the working file, then immediately
lock the new revision. This allows you to update the archive while retaining control of
the revision.
If this option is not set, the new revision is not locked following the check in.
Close Change Package causes Source Integrity to close any change package
associated with the member revision.
Defer Check In causes Source Integrity to delay the check in of the revision. Your lock
remains on the revision and Source Integrity displays version information for both the
working and member revisions. Once you submit the check in, your lock is removed
and the member revision moves to the next number in the sequence, as in the case of
a standard check in operation.
Check In if Unchanged checks in the working file even if it has not changed since it
was checked out.
Update Member Revision makes the new revision the member revision in the project,
replacing the existing member revision.
Author is the author name applied to the revision. Type a name in the Author field. If
you do not type a name, Source Integrity uses the current user name.
51

Chapter 3: Getting Started Using Source Integrity
Command Options
Check In continued Update Member Revision Even on Branch causes Source Integrity to update the
member revision upon check in, even when the locked revision is on a different
branch.
Unexpand Keywords replaces literal values with keywords in the checked in revision.
Force Creation of New Branch causes Source Integrity to create a branch off of the
revision you are checking in.
Save Working File Timestamp sets the timestamp of the revision in the history to the
timestamp of the working file, rather than the time of check in.
Check Out Lock Revision checks out a writable working file, and ensures that no one else can
make changes to the revision while you have it checked out. A revision must be
checked out locked if strict locking is enabled, and you intend to make changes to it.
Overwrite Working File if Changed overwrites the working file even if the member has
changed since it was last checked in.
Overwrite if Deferred Operation Pending overwrites the working file if there is a
deferred operation pending on the member.
Update Member Revision causes the revision you check out to become the new
member revision of the project. For example, if the current project member is listed as
Revision 2.3 and you check out Revision 1.7 with the Update Member option selected,
Revision 1.7 replaces Revision 2.3 as the member of the project.
52
Force Creation of New Branch causes Source Integrity to force the creation of a new
branch on check out, eliminating the chance of a locking conflict.
Merge Working File if Changed automatically merges any changes from the working
file into the revision being checked out.
Restore Revision Timestamp sets the timestamp of the working file (that the revision is
checked out to) to the date and time of the revision in the history. If this option is
cleared, the working file’s timestamp is set to the current date and time.
Create Branch if Variant causes Source Integrity to create a branch off of the revision
you are checking out, if you are working in a variant sandbox and this is the first time
the member is checked out. This reduces the possibility of locking conflicts with the
member while work is being done in the variant and regular sandboxes.
Keywords allows you to select keyword expansion options when checking out a
member. To leave keywords unexpanded, select Do Not Expand from the Keywords
list. To replace keywords in the revision with literal values in the working file, select
Expand from the Keywords list. To replace literal values in the revision with keywords,
select UnExpand from the Keywords list.
On Lock allows you to select the way Source Integrity will handle automatic branching
and merging. To be asked to confirm the required action each time you check out a
member, select Query User. To create a branch upon locking the working file, select
Branch. To make the working file writable upon lock, select Make Writable. To be
asked to confirm branching, select Query User to Branch. To be asked to confirm
that you want the working file to be writable, select Query User to Make
Writable. To cancel the On Lock option, select Cancel.
By default, Source Integrity asks you to confirm the required action each time you
check out a member.
u s e r g u i d e

Command Options
Setting Preferences
Check Out continued Merge Type specifies the action to be taken when merging revisions. Select one of the
following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time you
merge upon check out.
Cancel causes Source Integrity to cancel the operation.
Automatic causes Source Integrity to perform an automatic merge. For more
information on automatic merging, see “Step Two: Merge Branch” on page 345
Manual (Launch Tool) causes Source Integrity to initiate the MKS Visual Merge
tool.
On Conflicts specifies the action to be taken when merge conflicts occur. Select one of
the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time a
conflict occurs.
Cancel causes Source Integrity to cancel the operation when a conflict occurs.
Mark For Later Merge causes Source Integrity to mark the files for merging at
another time, allowing you to resolve the conflict first.
Launch Tool causes Source Integrity to initiate the MKS Visual Merge tool.
Highlight Output File causes Source Integrity to highlight conflicts in the
resulting merged revision.
Error causes Source Integrity to display an error message prompt.
Ask for change package causes Source Integrity to ask for a change package when
performing a check out.
Close Change Package Release Locks causes Source Integrity to release all locks on members in the change
package.
Allowed Orphaned Deferred Operations allows the change package to be closed
without first submitting its deferred entries.
Note: Orphaned Deferred operations can never be submitted using the Submit
Change Package command.
Configure Subproject Select one of the following options as the preferred type of subproject when
configuring a subproject:
Normal configures a subproject based on the current state of the project.
Variant configures a subproject based upon a specific revision of the master project
and is used for branching off the main development path.
Build configures a static subproject based upon a specific revision of the master
project that is used for building or testing the project, but not for further
development.
Reset to default value configures a subproject based on the parent project type. For
more information on the default type, see your administrator.
53

Chapter 3: Getting Started Using Source Integrity
Command Options
54
Create Sandboxes Populate Sandbox causes Source Integrity to add working files to the sandbox.
Recurse Into Subprojects creates subsandboxes recursively from subprojects.
Line Terminator determines the type of line terminator Source Integrity uses when
dealing with sandbox members: Native (or automatic, the default setting), LF (or line
feed, primarily for UNIX applications), or CR/LF.
Make Sandbox Sparse creates a sandbox with no working files.
View Sandbox After Creation displays the sandbox after it is created.
Make Sandbox Shared creates a sandbox configured as shared.
Delete Label Recurse Into Subprojects deletes the label recursively from members in subprojects.
Delete Revision Confirm Delete causes Source Integrity to prompt you for confirmation before the
revision is deleted from the project.
Recurse Into Subprojects deletes the revision recursively in members of subprojects.
Demote Recurse Into Subprojects recursively demotes subproject members.
Diff Ignore Blanks ignores whitespace at the end of lines when comparing the selected
revision and the member’s working file or another revision.
Ignore Whitespace ignores tabs and spaces anywhere in a line when comparing the
selected revision and the member’s working file or another revision.
Ignore Case ignores differences between uppercase and lowercase text when
comparing the selected revision and the member’s working file or another revision.
Discard Change Package Confirm Discard confirms the removal of a change package from the repository.
Discard Change Package
Entry
Confirm Discard confirms the removal of a change package entry from the change
package.
Drop Delete Working File deletes the member working file when dropped from the project.
Confirm Drop causes Source Integrity to prompt you for confirmation before the
member is dropped from the project.
Defer Drop Member delays the drop operation in the project until the deferred
operation is submitted. The operation in the sandbox still takes place immediately.
Close Change Package causes Source Integrity to close any change package
associated with the member upon dropping that member.
Drop Member Attribute Recurse Into Subprojects recursively drops member attributes from members in
subprojects.
Drop Sandboxes Delete allows you to select delete options when dropping a sandbox. To drop the
sandbox without deleting any members, select Nothing from the Delete list. To delete
sandbox members only, select Sandbox Members Only from the Delete list. To
delete the sandbox directory and all of its contents, select Entire Sandbox
Directory from the Delete list.
Confirm Drop causes Source Integrity to confirm that the sandbox will be dropped
before it is dropped.
Freeze Recurse Into Subprojects recursively freezes members in subprojects.
u s e r g u i d e

Command Options
Import Members Author allows you to specify the author of the member.
Setting Preferences
Data Type specifies the member’s data type. To let Source Integrity determine the data
type automatically, select Auto from the list. To specify a text file, select Text from the
list. To specify a file containing unprintable characters, or lines too long to be handled
by text editors, select Binary from the list.
Create Subprojects automatically creates a subproject (based on the subdirectories in
which members are located), for imported members.
Recurse Into Directories imports all members in the specified directory location.
Close Change Package closes the change package upon command completion.
Unexpand Keywords replaces literal values in the revision with keywords.
Defer Import defers the operation until it is submitted individually or as part of a change
package.
Lock Force Creation of New Branch causes Source Integrity to create a branch off of the
revision being locked.
Recurse Into Subprojects locks all members in subprojects.
Create Branch if Variant causes Source Integrity to create a branch off of the revision
you are checking out, if you are working in a variant sandbox and this is the first time
the member is checked out. This reduces the possibility of locking conflicts with the
member while work is being done in the variant and regular sandboxes.
Ask for change package causes Source Integrity to ask for a change package when
performing a lock.
Merge Branch Lock target revision locks the merged revision when the merge is complete.
Force Creation of New Branch causes Source Integrity to create a branch for the
merged revision.
Create Branch if Variant causes Source Integrity to create a branch for the merged
revision, if you are working in a variant sandbox.
Merge Type specifies the action to be taken when merging revisions. Select one of the
following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time you
merge revisions.
Cancel causes Source Integrity to cancel the operation.
Automatic causes Source Integrity to perform an automatic merge. For more
information on automatic merging, see “Step Two: Merge Branch” on page 345
Manual (Launch Tool) causes Source Integrity to initiate the MKS Visual Merge
tool.
55

Chapter 3: Getting Started Using Source Integrity
Command Options
56
Merge Branch continued On Conflicts specifies the action to be taken when merge conflicts occur. Select one of
the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time a
conflict occurs.
Cancel causes Source Integrity to cancel the operation when a conflict occurs.
Mark For Later Merge causes Source Integrity to mark the files for merging at
another time, allowing you to resolve the conflict first.
Launch Tool causes Source Integrity to initiate the MKS Visual Merge tool.
Highlight Output File causes Source Integrity to highlight conflicts in the
resulting merged revision.
Error causes Source Integrity to display an error message prompt.
Merge Merge Type specifies the action to be taken when merging revisions. Select one of the
following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time you
merge revisions.
Cancel causes Source Integrity to cancel the operation.
Automatic causes Source Integrity to perform an automatic merge. For more
information on automatic merging, see “Merging Revisions Automatically” on
page 354.
Manual (Launch Tool) causes Source Integrity to initiate the MKS Visual Merge
tool.
On Conflicts specifies the action to be taken when merge conflicts occur. Select one of
the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time a
conflict occurs.
Cancel causes Source Integrity to cancel the operation when a conflict occurs.
Mark For Later Merge causes Source Integrity to mark the files for merging at
another time, allowing you to resolve the conflict first.
Launch Tool causes Source Integrity to initiate the MKS Visual Merge tool.
Highlight Output File causes Source Integrity to highlight conflicts in the
resulting merged revision.
Error causes Source Integrity to display an error message prompt.
Move Change Package
Entry
Confirm Move confirms the movement of a change package entry from one change
package to another change package.
Promote Recurse Into Subprojects promotes all members in subprojects.
u s e r g u i d e

Command Options
Setting Preferences
Rename Member Rename Working File renames the working file in your sandbox and preserves any
changes made to that file. If not set, the working file is not renamed and becomes a
former member which will be confirmed for deletion the next time the sandbox is
resynchronized. This setting has no effect if the command is performed directly from a
Project view.
Confirm Rename causes Source Integrity to confirm that you want to rename the
selected member.
Close Change Package closes the specified change package after performing the
rename operation.
Overwrite Existing File replaces the existing working file in the sandbox.
Defer Rename delays the rename operation in the project until the deferred operation
is submitted.
Resynchronize Restore Revision Timestamp sets the timestamp of the working file (that the revision is
checked out to) to the date and time of the revision in the history. If this option is not
set, the working file’s timestamp is set to the current date and time.
Force Overwrite Even if Unchanged overwrites the working file even if it is unchanged.
Overwrite if Pending overwrites the working file even if it is a pending revision.
Recurse into Subprojects recursively resynchronizes members in subprojects.
Overwrite Working File if Changed overwrites the working file even if it has changed.
Overwrite if Deferred Operation Pending overwrites the working file if there is a
deferred operation pending on the member.
Merge Working File if Changed merges the modified working file with the member
revision.
Confirm Populate of a Sparse Sandbox causes Source Integrity to prompt you to
confirm if you want to populate a sparse sandbox.
Keywords allows you to select keyword expansion options when resynchronizing. To
replace keywords in the revision with literal values in the working file, select Expand
from the Keywords list. To leave keywords unexpanded, select Do Not Expand from
the Keywords list. To replace literal values in the revision with keywords, select
Unexpand from the Keywords list.
Merge Type specifies the action to be taken when merging revisions. Select one of the
following options from the list:
Confirm causes Source Integrity to confirm the action to be taken when merging
upon resync.
Cancel causes Source Integrity to cancel the operation.
Automatic causes Source Integrity to perform an automatic merge. For more
information on automatic merging, see “Step Two: Merge Branch” on page 345
Manual (Launch Tool) causes Source Integrity to initiate the MKS Visual Merge
tool.
57

Chapter 3: Getting Started Using Source Integrity
Command Options
58
Resynchronize continued On Conflicts specifies the action to be taken when merge conflicts occur. Select one of
the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken each time a
conflict occurs.
Cancel causes Source Integrity to cancel the operation when a conflict occurs.
Mark For Later Merge causes Source Integrity to mark the files for merging at
another time, allowing you to resolve the conflict first.
Launch Tool causes Source Integrity to initiate the MKS Visual Merge tool.
Highlight Output File causes Source Integrity to highlight conflicts in the
resulting merged revision.
Resynchronize Change
Package
Use Master causes Source Integrity to operate on the top-level sandbox. When the
selected change package is associated with a member in a subsandbox, specifying
Use Master causes the command to operate on the top-level sandbox for that
subsandbox.
Overwrite Working File if Changed overwrites the working file even if it has changed.
Perform Merges prompts you for confirmation before performing a merge operation.
Confirm Actions causes Source Integrity to confirm all operations with you before
starting them.
Verbose provides additional information to track the status of the command.
Already in Project is Error causes Source Integrity to terminate the operation if the
member being applied is already in the project. If this setting is negated (as in
noAlreadyInProjectIsError), the information is displayed as a warning.
Ignore Server in Change Package causes Source Integrity to perform the Resync CP
operation even if the change package members reside on different servers.
Span Projects applies the command to any member specified in the change package,
even if this involves multiple projects. This option allows Source Integrity to search
across local sandboxes for all entries in the selected change package(s).
Ignore Cross-Branch Entries causes Source Integrity to use the most recent revision
when it encounters two revisions of the same member on different branches.
Restore Revision Timestamp sets the timestamp of the working file to the date and
time of the last checked-in revision in the history. If this option is cleared, the working
file’s timestamp is set to the current date and time. The time stamp is only changed if
the working file is modified. If the resynchronize does not change the working file, its
timestamp remains the same.
Other Project is Error terminates the command if the member is not in the project you
are applying to, or in its variant.
Allow Open Change Packages allows Source Integrity to work with open change
packages. This facilitates the application of a resolution change package.
Create Variants causes Source Integrity to create new variant subprojects within the
variant project as required to apply the change package members. If the main project
contains required files that reside in a subproject, the Create Variants option creates
variant subprojects for these files to be placed into.
u s e r g u i d e

Command Options
Resynchronize Change
Package continued
Setting Preferences
Merge on Branch causes Source Integrity to perform a merge if the target revision is
on a branch. Source Integrity differences the two file revisions and merges any
changes into the working file without modifying its revision number. You must then
check in the working file to advance the revision to the next available revision number.
Keywords allows you to select keyword options when resynchronizing a member. To
leave keywords unexpanded, select Do Not Expand from the Keywords list. To
replace keywords in the revision with literal values in the working file, select Expand
from the Keywords list. To replace literal values in the revision with keywords, select
Unexpand from the Keywords list.
Backfill determines how dependent change packages are treated. You can select from
the following options:
Entire Change Packages chooses all historic revisions required by the
specified change packages and applies them by updating the member revisions,
adding files, or dropping files. The user is not prompted to confirm the backfill list.
Back Revisions Only processes only the specified change package(s) and
chooses only directly-associated revisions. It does not process any change
packages that are associated with intermediate revisions.
Error terminates the operation if other change packages are required but are not
specified.
Skip Revisions causes Source Integrity to merge around specified backfill
revisions.
Ask to Specify allows you to select the specific change packages you want to
include.
Merge Type determines what occurs if a merge is required to resynchronize the
change package.
Confirm causes Source Integrity to confirm the merge.
Cancel causes Source Integrity to stop the merge from occurring.
Automatic causes Source Integrity to perform the merge without prior
confirmation.
Manual (Launch Tool) launches the default differencing tool.
On Conflicts determines how conflicting rows are treated.
Confirm causes Source Integrity to request input from the user to resolve the
conflict.
Cancel causes Source Integrity to stop the resynchronize.
Mark For Later Merge marks the conflicting lines so they can be addressed at
a later date.
Launch Tool causes Source Integrity to launch the default differencing tool.
Highlight Output File highlights each line conflict in working file.
Error causes Source Integrity to display an error message prompt.
Ignore Update Revision Entries ignores update revision entries in a change package.
There is no user prompt.
59

Chapter 3: Getting Started Using Source Integrity
Command Options
Revert Restore Revision Timestamp sets the timestamp of the working file (that the revision is
checked out to) to the date and time of the revision in the history. If this option is not
set, the working file’s timestamp is set to the current date and time.
Force Overwrite Even if Unchanged overwrites the working file even if it is unchanged.
60
Recurse Into Subprojects recursively reverts members in selected subprojects.
Overwrite Working File if Changed overwrites the working file if it has changed.
Overwrite if Deferred Operation Pending overwrites the working file if there is a
deferred operation pending on the member.
Keywords allows you to select keyword options when reverting a member. To leave
keywords unexpanded, select Do Not Expand from the Keywords list. To replace
keywords in the revision with literal values in the working file, select Expand from the
Keywords list. To replace literal values in the revision with keywords, select Unexpand
from the Keywords list.
Snapshot Sandbox Apply Label to All Members applies the snapshot label to all project members.
Notify when Complete to confirms that the snapshot operation has finished.
Apply State to All Members applies the snapshot state to all project members.
Recurse into Subsandboxes recursively snapshots subsandboxes.
Author is the author name applied to the snapshot. Type a name in the Author field. If
you do not type a name, Source Integrity uses the current user name.
Submit Use the change package provided when the element was deferred selects the change
package that was originally associated with the deferred item.
Override the change package to a specified value allows you to select a different
change package from the one that was originally associated with the deferred item.
Close Change Package closes the change package after the element is submitted.
Submit Change Package Close Change Package closes the change package after submitting the item and
completing the associated deferred operation.
Commit Changes/Submit for Review (if reviews are mandatory) creates pending
entries without submitting the change package for review.
Allow submit to proceed with deferred entries submits the changes to the repository
(or for review) even there are deferred entries retained through the cancel of an
operation during the submit. For example, cancelling a check in of an unchanged file.
Apply Resolution Change Package applies the change package if it is resolution
change package.
Ignore Absence of Deferred/Lock Entries submits the changes package even if there
are no deferred or lock entries.
Thaw Recurse Into Subprojects recursively thaws members in subprojects.
Unlock Break Lock breaks locks held by other users.
Recurse Into Subprojects recursively unlocks members in subprojects.
Update Revision Recurse Into Subprojects updates the member revision of members in subprojects.
Defer Update Revision delays the update operation until the deferred operation is
submitted. The operation in the sandbox takes place immediately.
Close Change Package closes the associated change package upon command
completion.
u s e r g u i d e

View
Preferences
Setting Preferences
The Views pane in the Preferences Configuration dialog box contains
default option settings for Source Integrity views. At any time, you can
reset the default settings for a view by clicking Clear Local Settings.
You can also configure toolbars for Source Integrity views. To configure
select the view and click Toolbar at the bottom left of the Views pane. For
more information on configuring toolbars, see “Configuring the Source
Integrity Toolbars” on page 82.
To set view preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), click the Views node.
The views appear as a list of nodes.
2 Select a view node to configure. The settings for that view appear in
the Views pane. The available views and their options are discussed in
detail in the proceeding table.
If necessary, select a view’s option check box.
To restore a view’s default options, click Clear Local Settings.
61

Chapter 3: Getting Started Using Source Integrity
62
View Options
Modify options for the views as listed in the following table:
Annotated Revision View Under Columns, you can select which columns you want displayed in the
Annotated Revision view:
Author displays the author of the revision.
Labels displays revision labels.
Revision Contents displays the text contained in a revision.
C.P. ID displays the revision’s associated change package ID.
Line displays the line number for each line of text in the revision (for use when
Revision Contents is selected).
Date displays the date each revision in the history was created.
Revision displays the member’s revision number.
Archive Information View Show Labels displays archive labels.
Show Locks displays locks.
Change Package View Show Uncommitted Entries displays deferred entries that have not been
submitted and therefore committed to the repository. Also displays lock entries.
Show Pending Entries displays pending entries that are not committed to the
repository.
Show Committed Entries displays entries that have been committed to the
repository.
Show Review Information displays the Review Log panel containing review
information.
Under Columns, you can select which columns you want displayed in the
Change Package View:
Archive displays the archive name of member in the change package entry.
Project displays the name and path of the project where the member revision
change package entry occurred. If the entry occurred from a shared subproject, it
is the subproject name and path that are displayed.
Server displays the host name of the server the entry was made on.
Date Changed displays the date the entry was made.
Revision displays the number of the revision in the change package entry.
Type is the entry type of the change package entry (see “Change Package Entry
Types” on page 220).
Member displays name of the member in the change package entry.
Sandbox displays the name of the sandbox where the deferred operation or
check out took place.
Variant displays the name of the variant development path (if a variant was used)
the change package entry occurred on.
u s e r g u i d e

View Options
Setting Preferences
Change Packages View Under Columns, you can select which columns you want displayed in the
Change Packages View:
Closed Date displays the date the change package was closed.
Description displays the description provided for the change package.
Issue displays the issue ID if the Integrity Manager integration is enabled.
State displays current state of the change package, which can be Open or
Closed.
Created Date displays the date the change package was created.
ID displays the change package ID.
Reason is only relevant when applying change packages, and is not used in the
standalone Change Packages view.
Summary displays the summary statement for the change package.
Creator displays the username who created the change package.
Is Resolution displays yes if the change package is a resolution change
package, and no if it is not.
Resolutions represent the list of change packages that the target change
package addresses.
Member History View Initial View allows you to set the default view for the window, either the
Graphical View, or the List View.
Show Legend displays the legend for the graphical history view.
Show Labels displays the revision labels for the graphical history view.
Show Metadata displays a box containing truncated metadata beside each
revision in the graphical history view. Point to the box to display a tooltip that
contains the full metadata for the revision.
Under Columns, you can select which columns you want displayed in the
Member History List view:
Author displays the author of the member.
Labels displays member labels.
Locker displays who has a member locked.
Locker Host displays the host name of the computer that locked the member.
Revision displays the member’s revision number.
C.P. ID displays the change package ID associated with the revision number.
Lock Timestamp displays the date and time a member is locked.
Locker C.P. ID displays the change package ID for the associated lock entry.
Locker Project displays the name and path of the project where the member
revision was locked from. If the member revision was locked from a shared
subproject, it is the subproject name and path that are displayed.
Revision Description displays the revision description assigned to the project
member.
Date displays the date each revision in the history was created.
Locked Icon displays the padlock icon to indicate a file is locked.
63

Chapter 3: Getting Started Using Source Integrity
View Options
64
Member History View continued Locker Development Path displays the name of the development path where the
lock on the revision was made from. This information is relevant when the locking
policy is set to devpath, allowing a single user to have a single lock on an
archive per development path. Contact your administrator for more information.
Locker Sandbox displays the name of the sandbox where the lock on the revision
was made, and is relevant when viewing the information from the Locker Host.
State displays the state of the member revision.
Member Information View Show Attributes displays member attributes.
Show Labels displays member labels.
Show Change Package Information displays change package information (only if
change packages are enabled).
Member Labels View Recurse Into Subprojects displays the hierarchy of subprojects.
Non-Members View Include specifies file types to include in the Non-Members view. Click Change to
modify the settings (see “Filtering Non-Member Files” on page 156).
Exclude specified files types to exclude from the Non-Members view. Click
Change to modify the settings (see “Filtering Non-Member Files” on page 156).
Recurse Into Subprojects specifies if to apply the Non-Member Filter recursively
to subprojects.
Include Former Members specifies if to include members that have been dropped
from the project, but where there still exists a working file in the sandbox
directory.
Under Columns, you can select which columns you want displayed in the
Non-Members view:
Absolute Path displays the absolute file path of the file.
Last Modified displays the date that the file was last modified.
Closest Project displays the project associated with the sandbox that is closest to
the directory containing the file.
Member ID displays the default member name for the file as it would appear if it
was added to the nearest project. In the case where the nearest project is
subproject, the relative path is displayed with the member name.
Closest Sandbox displays the sandbox that is closest to the directory containing
the file.
Size displays the size of the file in bytes.
Locks View Under Columns, you can select which columns you want displayed in the Locks
View:
Archive Name displays the name of the locked archive.
Host displays the hostname of the computer which the lock was performed on.
Revision displays the locked revision number.
User displays the user holding the lock.
C.P. ID displays the change package ID associated with the lock.
Member Name displays the name of the locked member.
Sandbox displays the name of the sandbox where the lock on the revision was
made, and is relevant when viewing the information from the locker host.
u s e r g u i d e

View Options
Setting Preferences
Locks View continued Development Path displays the name of the development path where the lock on
the revision was made from. This information is relevant when the locking policy
is set to devpath, allowing a single user to have a single lock on an archive per
development path.
Project displays the name and path of the project where the member revision
was locked from. If the member revision was locked from a shared subproject, it
is the subproject name and path that are displayed.
Time displays the time the archive was locked.
Project View Recurse Into Subprojects displays the hierarchy of subprojects.
Under Columns, you can select which columns you want displayed in the Project
view.
Attributes displays project attributes.
Labels displays member labels.
Locker displays who has a member locked.
Locker Host displays the host name of the computer that locked the member.
Member CPID displays the change package associated the operation that set the
member revision.
Member Rev. Timestamp displays the date and time the member revision is set.
Pending CPID displays the change package associated with a pending operation.
Creation CPID displays the change package that created the revision that is
currently the member revision. This revision may be different from the Member
CPID if an import, add member from archive, or set member revision operation
was used.
Lock Timestamp displays the date and time a member is locked.
Locker CPID displays the change package associated with the lock on the
member revision.
Locker Project displays the name and path of the project where the member
revision was locked from. If the member revision was locked from a shared
subproject, it is the subproject name and path that are displayed.
Member Rev. displays the member’s revision number.
Name displays the project, subproject, and the project members by file name.
State displays the state of the member revision.
Frozen indicates which project members are frozen with a snowflake icon.
Locked Icon displays the padlock icon to indicate a file is locked.
Locker Development Path displays the name of the development path where the
lock on the revision was made from. This information is relevant when the locking
policy is set to devpath, allowing a single user to have a single lock on an
archive per development path. Contact your administrator for more information.
Locker Sandbox displays the name of the sandbox where the lock on the revision
was made, and is relevant when viewing the information from the Locker Host.
Member Rev. Description displays the revision description assigned to the
project member.
New Revision Delta displays a delta icon to indicate that a new revision for the
member is available.
Type displays the type of each project, and project member.
65

Chapter 3: Getting Started Using Source Integrity
View Options
Project Differences View Show Applied Change Packages displays all the change packages applied
between two project revisions.
Show Revision Changes displays all modifications to each revision.
Show Change Packages displays a list of revision modifications that can be
associated with change packages and a list of those that cannot.
66
Member Attribute Changes displays all modifications of member attributes
between two project revisions.
Show Revision Description displays the content of the revision description.
Recurse into Subprojects displays the hierarchy of subprojects.
Project History View Initial View allows you to set the default view for the window, either the
Graphical View, or the List View.
Show Legend displays the legend for the graphical history view.
Show Labels displays the revision labels for the graphical history view.
Show Metadata displays a box containing truncated metadata beside each
revision in the graphical history view. Point to the box to display a tooltip that
contains the full metadata for the revision.
Under Columns, you can select which columns you want displayed in the Project
History List view:
Author displays the author of the project.
Revision displays the project’s revision number.
Date displays the date each revision in the history was created.
State displays the state of the project revision.
Labels displays project labels.
Project Information View Show Attributes displays project attributes.
Show Development Paths displays development paths for creating variant
sandboxes.
Registered Projects View Show Subprojects displays registered subprojects.
Registered Sandboxes View Show Subsandboxes displays registered subsandboxes.
Revision Information View Show Labels displays labels on the revision.
Show Change Package Information displays change package information (only if
change packages are enabled).
Sandbox View Recurse into Subprojects displays the hierarchy of subprojects.
Under Columns, you can select which columns you want displayed in the
Sandbox view.
Attributes displays member attributes.
Frozen indicates which sandbox members are frozen with a snowflake icon.
Locked Icon displays the padlock icon to indicate a file is locked.
Locker Development Path displays the name of the development path where the
lock on the revision was made from. This information is relevant when the locking
policy is set to devpath, allowing a single user to have a single lock on an
archive per development path. Contact your administrator for more information.
Locker Sandbox displays the name of the sandbox where the lock on the revision
was made, and is relevant when viewing the information from the Locker Host.
u s e r g u i d e

View Options
Setting Preferences
Sandbox View continued Member Rev. Description displays the revision description assigned to the
sandbox member.
New Revision Delta displays a delta icon to indicate that a new revision for the
member is available.
State displays the state of the member revision.
Working File Delta displays a delta icon to indicate that your working file has
changed.
Creation CPID displays the change package that created the revision that is
currently the member revision. This revision may be different from the Member
CPID if an import, add member from archive, or set member revision operation
was used.
Labels displays member labels.
Locker displays who has a member locked.
Locker Host displays the host name of the computer that locked the member.
Member CPID displays the change package associated the operation that set the
member revision.
Member Rev. Timestamp displays the date and time the member revision is set.
Pending CPID displays the change package associated with a pending operation.
Type displays the type of each sandbox, and sandbox member.
Working Rev. displays the checked out revision number that corresponds to the
member’s working file.
Deferred displays a icon to indicate that an operation on a member is
deferred.
Lock Timestamp displays the date and time a member is locked.
Locker CPID displays the change package associated with the lock on the
member revision.
Locker Project displays the name and path of the project where the member
revision was locked from. If the member revision was locked from a shared
subproject, it is the subproject name and path that are displayed.
Member Rev. displays the member’s revision number.
Name displays the sandbox, subsandbox, and the sandbox members by file
name.
Revision Sync Delta displays a delta icon to indicate that your working revision
does not match the member revision (usually due to branching).
Working CPID displays the change package associated with a deferred or a lock
operation performed by the current user from the current sandbox.
Sandbox Information View Show Attributes displays the Project Attributes and Sandbox Attributes tabs.
67

Chapter 3: Getting Started Using Source Integrity
Editor
Preferences
68
The Editor pane in the Preferences Configuration dialog box contains
default settings for the file editor tool used by Source Integrity when
editing members.
To set editor preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), click the Editor node.
The Editor pane is displayed.
2 Select one of the following options:
Use System Editor uses the system’s default editor for the type of
file being edited, for example, Notepad, to edit text files.
Editor allows you to choose the editor. Click Browse, then select
an editor, such as vi.
The Warn when trying to edit more than __ file(s) option prompts
you with a warning when you attempt to edit more than the
specified number of files.
3 Click OK to save your preferences.
u s e r g u i d e

Difference Tool
Preferences
Setting Preferences
The Diff Tool pane in the Preferences Configuration dialog box contains
default settings for the differencing tool used by Source Integrity.
To set difference tool preferences in the graphical user interface
1 From the Preferences Configuration dialog box (see “Setting
Preferences” on page 40), click the Diff Tool node.
The Diff Tool pane is displayed.
2 Select one of the following options:
Select the MKS Visual Difference Tool option to use the MKS
Visual Difference program to view differences between revisions.
For more information on the MKS Visual Difference Tool, see
“MKS Visual Difference Interface” on page 100.
Select the Third Party Difference Tool option if you want to use
one of the following programs to view differences:
Araxis Merge, Araxis Ltd.
Beyond Compare 1.x, Scooter Software
Beyond Compare 2.x, Scooter Software
MKS Visual Difference (Classic), MKS Inc.
Windiff, Microsoft
Select Custom Command to specify a particular program to view
differences.
In the field type the location and executable file name for the
program you want to use, or click the Browse button to browse to
the executable file.
3 Click OK to save your preferences.
69

Chapter 3: Getting Started Using Source Integrity
Shutdown
Preferences
70
You can specify shutdown preferences for all clients globally from one
location.
Disconnection Preferences
When disconnecting from an Integrity Server, you can specify client
preferences.
To specify disconnection preferences in the graphical user interface
From the Preferences Configuration dialog box (see “Setting Preferences”
on page 40), click Commands > Disconnect From Server.
The Disconnect From Server pane is displayed.
Confirm Disconnect specifies if to confirm disconnecting from the server
when using the File > Server Connection > Disconnect command.
Exit Preferences
When shutting down the client, you can specify preferences.
To specify exit preferences in the graphical user interface
From the Preferences Configuration dialog box (see “Setting Preferences”
on page 40), click Commands > Exit.
The Exit pane is displayed.
Managing Integrations
Shutdown all Integrity Clients specifies if to shut down all clients when
shutting down a client using the File > Shutdown command.
Source Integrity includes functionality for enabling and disabling
supported integrations. Using the Integrations command, you can select
from a list of available integrations and enable or disable them as required.
There is no requirement to re-install the Integrity Client.
NOTE
Using the Enable/Disable Integrations dialog box or the command:
si integrations --action=enable
you can always restore an available integration at a later date.
You can have only one of the following versions of Sybase PowerBuilder
installed: 7.0, or 8.0.3.
u s e r g u i d e

For complete information on using third party integrations with
Source Integrity, see the Integrity Solution Integrations User Guide.
Managing Integrations
To enable integrations for the Integrity Client using the graphical user
interface
1 Start the Integrity Client.
2 To open the Enable/Disable Integrations dialog box select Tools >
Integrations.
The Enable/Disable Integrations dialog box opens.
3 In the Disabled Integrations list, select the available integration(s) that
you want to enable.
4 To move the selected integrations to the Enabled Integrations list,
click . To move all disabled integrations to the Enabled
Integrations list, click .
TIP
You can select multiple integrations by using CTRL + click.
The selected integration is moved to the Enabled Integrations list and
is displayed in bold type.
5 To activate the selected integration(s), click OK.
The selected integration is activated.
6 To complete the activation, restart your computer.
To disable integrations for the Integrity Client using the graphical
user interface
1 Start the Integrity Client.
2 To open the Enable/Disable Integrations dialog box, select Tools >
Integrations.
The Enable/Disable Integrations dialog box opens.
3 In the Enabled Integrations list, select the Source Integrity
integration(s) that you want to disable.
TIP
You can select multiple integrations by using CTRL + click.
71

Chapter 3: Getting Started Using Source Integrity
72
4 To move the selected integration(s) to the Disabled Integrations list,
click . To move all enabled integrations to the Disabled
Integrations list, click .
The selected integration is moved to the Disabled Integrations list.
5 To disable the selected integration, click OK.
The selected integration is disabled.
6 To complete the process, restart your computer.
Quitting a Source Integrity Session
Logging Out of
Source Integrity
When you are finished working on files in the Source Integrity client, you
have three options for ending your session. You can log out of
Source Integrity, close the client window (but leave Source Integrity
running), or shut down the client completely.
Since the Source Integrity Web interface does not involve a client, logging
out is sufficient.
You can log out of Source Integrity and log in as another user, or allow
another user to log in.
To log out of Source Integrity using the graphical user interface
1 Select File > Server Connection > Disconnect.
Depending on your system preferences, a dialog box is displayed
asking you to confirm that you want to close all current views and
disconnect your server connection. To disable this dialog box, see the
Disconnect From Server command in “Command Preferences” on
page 48.
2 To disconnect from the server, click Yes.
NOTE
Disconnecting from the server closes all current views, such as Sandbox views.
The Confirm Disconnect dialog box is displayed.
u s e r g u i d e

Closing the
Client
3 Do one of the following:
Quitting a Source Integrity Session
To disconnect all clients that are connected to that server, click
Yes.
To cancel the disconnect, click No.
If you clicked yes, the server connection is disconnected for all clients.
If multiple servers are available in your Server Connection list, all
clients running will automatically connect using the next available
server for that product. For example, Integrity Manager connects to
the next available Integrity Manager enabled server in the Server
Connection list.
To log in again, see “Logging In to Source Integrity” on page 36.
To log out of a Source Integrity session the Source Integrity Web
interface
1 To quit the Source Integrity Web interface, do one of the following:
Click File > Logout.
Click .
The Logout dialog box confirms that you have successfully logged out.
To start a new session in the Source Integrity Web interface, click the
link for MKS Source Integrity Enterprise Edition.
You can close the Source Integrity client so that is no longer displayed on
the desktop, but leave it running in the background, logged in and client
windows intact.
To quit a Source Integrity session in the graphical user interface
Select File > Exit.
The Source Integrity graphical user interface closes. Even though the client
is not displayed on the desktop, it is still running in the background.
Display the client by clicking the application shortcut (see “Starting the
Source Integrity Client” on page 34).
73

Chapter 3: Getting Started Using Source Integrity
Shutting Down
the Client
74
When you are finished using Source Integrity, you can shut down the
Source Integrity client completely in one action.
To shut down the Source Integrity client in the graphical user
interface
1 Select File > Shutdown.
The Confirm MKS Integrity Client Shutdown dialog box is displayed.
IMPORTANT
Clicking Yes will shut down all clients in addition to Source Integrity, such as
Integrity Manager.
2 Do one of the following:
To shut down all clients, click Yes.
To shut down just the Source Integrity client, click No.
If you clicked Yes, all Integrity GUI clients close, the connection to the
server is disconnected, then the client process shuts down.
If you clicked No, only the Source Integrity GUI closes.
u s e r g u i d e

Source Integrity Interfaces
4
KEY TERMS: filters, graphical user interface, Web interface, command line interface,
environment variables, MKS Visual Difference, MKS Visual Merge
Source Integrity includes a number of interfaces that you can use to
accomplish your tasks. These interfaces provide you with the flexibility to
work in the environment that is most comfortable and suitable for you.
NOTE
If LDAP is used for user authentication with the Integrity Server, all
Source Integrity interfaces display full user names with the corresponding user
IDs in brackets, for example, James Riley (jriley). In addition, the
Websphere Studio Application Developer integration with Source Integrity
displays full user names.
If the full user name attribute is missing on the LDAP server, or a user’s full
user name entry is blank, the client interfaces display the user ID.
Anywhere that you as a user need to log in or authenticate, a user ID must be
entered, not the LDP user name.
This chapter provides an overview of the interfaces available in
Source Integrity. Specific topics covered in this chapter include:
“Source Integrity Graphical User Interface” on page 76
“Source Integrity Web Interface” on page 94
“Command Line Interface” on page 98
“MKS Visual Difference Interface” on page 100
“MKS Visual Merge Interface” on page 107
75

Chapter 4: Source Integrity Interfaces
Source Integrity Graphical User Interface
Application
Window
76
Source Integrity includes a graphical user interface from which you can
access all of the Source Integrity features for members in both sandbox and
project views.
The application window contains a number of common features explained
in this section.
Title Bar
The title bar is the uppermost component of the application window. On
the left side, the title bar displays the name of the software program. On
the right side, the title bar displays the standard Windows buttons for
minimizing, resizing, and closing the application window.
Menu Bar
The menu bar is located directly below the title bar. Each menu contains
available commands. When you first start Source Integrity, there are four
menus in the menu bar: File, Tools, Window, and Help. The list of available
menus and commands varies depending on which view or window is
active (for example, working with a member history or a sandbox).
To see a list of recently used project and sandbox files, select File from the
menu bar. Recently used files are displayed in a numbered list at the
bottom of the File menu.
u s e r g u i d e

Toolbar
Source Integrity Graphical User Interface
Immediately below the menu bar is a toolbar that provides easy access to
the most commonly used Source Integrity commands.
You can configure the toolbar to suit your needs. For information on
configuring the toolbar, see “Configuring the Source Integrity Toolbars”
on page 82.
Most toolbar buttons only become available when an item is selected in a
certain window. For example, selecting a project in a Project view displays
project command toolbar buttons.
ToolTips, which explain the function of each toolbar button, appear when
you hold the mouse pointer over the button.
Project or Sandbox View
Project and Sandbox views display the project members and hierarchy for
projects registered with the Integrity Server.
The Project view gives you access to project-level functions and a limited
number of member-level functions. The Sandbox view mirrors the content
of the project and allows you to manage the project and work directly with
its members. Typically, you create your own Sandbox for a selected project
and then work with that project through your Sandbox.
For more information on Sandbox and Project views, see “Project Views
(GUI)” on page 457.
TIP
When items in the Name column are too large to see in the current column
width, place the mouse pointer over the item to view a ToolTip of the full
name.
Shortcut Menu
Source Integrity supports standard shortcut menus. To display the menu
of actions you can perform on a selected item, select and right click:
a member in a Project or Sandbox view
a revision in a Project or Member History view
a project in the Registered Projects view
a sandbox in the Registered Sandboxes view
Source Integrity displays the applicable shortcut menu.
77

Chapter 4: Source Integrity Interfaces
Printing Lists
and Views
78
Member Information Pane
The member information pane displays details on the working file and
member revision numbers that are available in the project. When there are
size differences between the working file and member revision, the
member information pane also displays this difference (in kilobytes).
Status Bar
When you select a command from a Source Integrity menu, a brief
explanation of its purpose and status displays in the status bar. The status
bar also displays the progress and status for commands launched from the
graphical user interface. In addition, when you point to a toolbar button,
you can see an explanation of its function.
Workspace
Everything between the toolbar and the status bar is considered the
workspace. This is where Source Integrity displays windows containing
your projects, sandboxes, or member histories. For example, when you
open a sandbox, its members display in a Sandbox view in the workspace.
When you first start Source Integrity, the workspace is empty.
Filter List
Beside the toolbar is an optional list of built-in filters that allows you to
focus your view on a subset of project members you are currently
interested in. Source Integrity displays only those members that meet the
criteria specified by the filter.
The list of built-in filters only displays when a Project or Sandbox view is
active.
For more information on filters, see “Using Filters” on page 86.
You can print the information from all tabular lists and graphical history
views in the Source Integrity graphical user interface.
To print tabular lists and views in the Source Integrity graphical user
interface
1 Display the window that contains the list or view you want to print.
What is displayed in the window on the screen is what is printed. The
following are some tips on printing tabular lists and views:
Resize the window width to fit columns.
Resize the column widths to fit cell contents.
u s e r g u i d e

Quick Access
Keys
Source Integrity Graphical User Interface
2 With the desired information displayed in the window, do one of the
following:
Select File > Print.
Click .
The Print dialog box is displayed.
3 If necessary, modify the general, page setup, and appearance options.
The following are some page setup tips for fitting more information on
a page:
Change the paper orientation to landscape to accommodate larger
window widths.
Decrease page margins to fit more information on a page.
If your printer supports multiple page sizes, select a larger paper
size to fit more information on a page.
NOTE
Information from rows is not split across multiple printed pages.
4 Click OK to print.
The information is printed.
Each printed page contains a header that displays the printing date,
the user printing the document, and the window title. Each printed
page is numbered in the footer.
By default, this guide describes how to perform steps using the mouse. For
your convenience, an alternate way to perform many of those same steps is
available using the keyboard.
Access Keys
Keyboard access keys appear as underlined letters on a menu command, or
as a dialog box option, allowing you to access most items on the interface.
You use the access keys by pressing and holding the ALT key, then the key
indicated by the underlined letter.
Access keys can also be used in a sequence, for example, ALT, F, S. This
sequence means press down and hold ALT, and then press F, and then S. In
the main application window, performing this sequence would open the
Select a Sandbox view.
79

Chapter 4: Source Integrity Interfaces
Configuring the
Source Integrity
Column Set
80
Shortcut Keys
For some commands, shortcut keys are provided as well as access keys.
Shortcuts appear on menus opposite their command names. For example,
in the Sandbox view:
pressing the INSERT key is the same as selecting the Add Members
command from the Sandbox menu or the Import Members command
from the Project menu.
pressing the F2 function key is the same as selecting the Check Out
command from the Member menu.
The information in any window displays in columns with headings and
icons. You can configure these columns in many different ways to suit your
needs, including changing the sort order, and adding or removing
columns.
Configuring Column Sorting
You can sort the information in each column in an ascending or descending
order. An arrow is displayed indicating the sort order and the members are
sorted accordingly.
Columns such as Name, Label and State are sorted alphabetically, while
columns such as Member Rev., and C.P.ID are sorted numerically. The
Locked column first sorts alphabetically by the locker’s name (the user that
has a lock on the member) and then it sorts numerically by the date of the
lock timestamp. The delta column is sorted by the delta types. The default
sort order for columns is descending.
To sort a column in the graphical user interface
Do one of the following:
Click the column heading.
The sort order inverts and the members are sorted accordingly.
Right click the column heading and select Sort > Ascending or Sort >
Descending.
The sort order is changed and the members are sorted accordingly.
Adding, Removing, and Repositioning Columns
You can change the columns that appear in your windows. You can add
and remove columns or change the order in which they appear within the
windows.
u s e r g u i d e

To add a column in the graphical user interface
Source Integrity Graphical User Interface
Do one of the following:
Right click a column heading and select the column you want to add
from the menu, for example Attributes.
The column is displayed in the window.
Right click a column heading and select Columns.
The Columns dialog is displayed where you can select the column that
you want to add from the Not Visible list and add it to the Visible list
by clicking . Click OK to finish the operation.
The column is displayed in the window.
To remove a column in the graphical user interface
Do one of the following:
Right click the column you want to remove and select Hide.
The column is removed from the window.
Right click a column heading and select Columns.
The Columns dialog is displayed where you can select the column you
want to remove from the Visible list and add it to the Not Visible list by
clicking . Click OK to finish the operation.
The column is removed from the window.
To change the column order in the graphical user interface
1 Right click a column heading and select Columns.
The Columns dialog is displayed
2 Select the column you want to move in the Visible list.
3 Use the and buttons to move the column up or down in the
column order.
4 Click OK to finish the operation.
The columns appear in the new order in the window.
TIP
You can also drag a column to a new location. Click the column heading you
want to move, then drag it to the new location in the column set.
81

Chapter 4: Source Integrity Interfaces
Configuring the
Source Integrity
Toolbars
82
The main Source Integrity toolbar is fully customizable to suit your
individual preferences. Changes made to the main toolbar are displayed
immediately.
Buttons on the main toolbar deal primarily with project and sandbox-level
operations. You can configure the main toolbar to display only those
buttons that you normally use and then position the buttons to suit your
workflow.
You can also define your own toolbar buttons to link to tasks that you
perform frequently, for example, buttons that link to build scripts or other
programs. Use separators to visually separate buttons and arrange
functional groups to suit your workflow.
You can customize the main toolbar by:
hiding or showing specific buttons according to your preferences
changing the sequence of the buttons
using separators to group specific buttons according to your
preferences
resequencing toolbar buttons according to your preferences
adding a custom toolbar button to link to frequently performed tasks
In addition to configuring the main Source Integrity toolbar, you can
configure toolbars associated with all of the views. For more information,
see “To configure a view’s toolbar in the graphical user interface” on
page 86.
To customize the main toolbar in the graphical user interface
1 Select Tools > Preferences.
The Preferences dialog box opens.
2 Under the General tab in the Look And Feel area, click .
The Configure main toolbar dialog box opens.
You can customize the main toolbar in the following ways:
To add a button to the main toolbar, under Available Buttons,
select the desired button. Then under Toolbar Contents, select the
button you want the new button to appear below.
Click .
u s e r g u i d e

Source Integrity Graphical User Interface
The target button is moved to the list of Toolbar Contents and
appears on the main toolbar.
To remove a button from the main toolbar, under Toolbar
Contents, click to highlight the target button and then
click .
The target button is moved to the list of Available Buttons and no
longer appears on the main toolbar.
To add a separator, under Toolbar Contents, click to highlight the
button you want the separator to appear below, then under
Available Buttons, select a separator.
Click .
A separator is added at the specified location under Toolbar
Contents.
On the main toolbar, the separator is positioned to the right of the
existing button or separator. You can remove the separator the
same way as removing a button.
To change the sequence of a button or separator, remove it from
the Available Buttons list and then add it to the desired location.
3 To accept the changes, click OK.
The Configure main toolbar dialog box closes.
4 To close the Preferences dialog box, click OK.
Your changes display immediately on the main toolbar. The target
button no longer appears on the main toolbar.
To add a custom toolbar button to the main toolbar in the graphical
user interface
When adding a new button to the Toolbar Contents, the new button is
inserted below the selected toolbar button or separator. On the graphical
user interface toolbar, the new button is positioned to the right of the
existing button or separator.
83

Chapter 4: Source Integrity Interfaces
84
You can also use separators to separate buttons visually and arrange
functional groups to suit your workflow. For more information on using
separators, see “To customize the main toolbar in the graphical user
interface” on page 82.
NOTE
You cannot delete a custom toolbar button once it is created. You can only hide
the button or redefine it.
1 Select Tools > Preferences.
The Preferences dialog box opens.
2 Under the General tab, Look And Feel, click .
The Configure main toolbar dialog box opens.
3 Under Available Buttons, click User 1 or another available custom
toolbar button, then click .
The Customize User Button dialog box opens.
Enter the following information into the text fields:
Program is the path to the program or script file that you want
Source Integrity to run.
To select the program, do one of the following:
Enter the path to the program.
Click Browse to select the program.
Parameters are the options or flags the program requires to run. If
no parameters are required, you can leave this field blank.
Description is the descriptive ToolTip text that appears when the
mouse pointer is paused over the button. This field is optional.
Icon File is the path to the icon file that Source Integrity uses to
represent the selected program or script.
u s e r g u i d e

To select the icon file, do one of the following:
Enter the path to the icon file.
Click Browse to select the icon file.
Source Integrity Graphical User Interface
Environment File is a path to a text file that stores environment
variables when the button is used. This field is optional. For more
information on environment variables, see “Environment
Variables” on page 92.
To select the environment file, do one of the following:
Enter the path to the environment file.
Click Browse to select the environment file you have already
created.
4 To accept the changes, click OK.
The Configure main toolbar dialog box closes.
5 To close the Preferences dialog box, click OK.
Your changes display immediately on the main toolbar. The new
button icon is now positioned to the right of the selected toolbar
button.
To remove the button from the main toolbar, see “To customize the
main toolbar in the graphical user interface” on page 82.
To redefine a custom toolbar button in the graphical user interface
1 Select Tools > Preferences.
The Preferences dialog box opens.
2 Under the General tab, Look And Feel, click .
The Configure main toolbar dialog box opens.
3 Under Toolbar Contents, double click the custom toolbar button you
want to redefine.
The Customize User Button dialog box opens.
Redefine the text fields as required to select a new program or script.
For more information on the Customize User Button dialog box, see “To
add a custom toolbar button to the main toolbar in the graphical user
interface” on page 83.
4 To accept the changes, click OK.
The Configure main toolbar dialog box closes.
85

Chapter 4: Source Integrity Interfaces
Dialog Box
Options
Using Filters
86
5 To close the Preferences dialog box, click OK.
Your changes display immediately on the main toolbar. The new
button icon is now positioned to the right of the selected toolbar
button.
To configure a view’s toolbar in the graphical user interface
1 Select Tools > Preferences.
The Preferences dialog box opens.
2 Click the Views tab, then from the View list, select a view.
3 Click .
The Configure toolbar dialog box opens.
4 Configure the toolbar as desired. For more information, see “To
customize the main toolbar in the graphical user interface” on page 82.
Dialog boxes that you may encounter include check boxes for many
options. A blank check box ( ) means the option is not enabled, a check
mark ( ) means the option is enabled, and a question mark ( ) means
you will be prompted to confirm or specify the option.
For large projects, use filters to display only the relevant members for your
task. Filters allow you to view and manipulate a predefined subset of
project members that are grouped according to their properties.
NOTE
The list of built-in filters only displays if a Project or Sandbox view is active.
You must expand your project (including subprojects), or your sandbox
(including subsandboxes), to view the filtered members.
In the graphical user interface, and Project and Sandbox views, filters
appear in the Filter list located on the toolbar.
Filters for the Project History and Member History views are also available.
For information on applying filters in the Project History view, see “Project
History Filters” on page 264. For information on applying filters in the
Member History view, see “Member History Filters” on page 311.
By selecting the option for Hide Empty Sandboxes or Hide Empty Projects,
you can also choose to remove any sandboxes or projects that do not
contain members.
u s e r g u i d e

Source Integrity Graphical User Interface
Selecting the Hide Empty Sandboxes or Hide Empty Projects filters causes
Source Integrity to recursively search each subproject for members and is
therefore a server resource intensive operation. If you have a complex
project with numerous members, you may want to limit your use of this
filtering option.
NOTE
All filters, except the Deferred Items filter, incorrectly show former members in
the filtered view.
Choose one of the following filters, and your view is filtered accordingly:
All Members shows all members of the current project or sandbox.
Any Member Deltas shows only members with working file changes or
out of sync members.
Modified Working Files shows only members with a working file that is
modified.
Out of Sync Members shows only members where the sandbox
revision is not the same as the member revision in the corresponding
project.
New Revision Available shows only those members where a new
revision is available.
NOTE
If you apply the New Revision Available filter in a variant sandbox, the filter
returns only new revisions available in the variant sandbox, it does not return
new revisions from the master project.
Working File Size Deltas shows members with changes in the size (in
bytes) of the working file.
Missing Working Files shows only those members with missing
working files.
Existing Working Files shows members with existing working files.
New Members shows only those members that are newly added to the
project and that have not yet been modified.
Working File on Branch shows members where the working file is on a
branch from a given development path that is not the trunk
development path.
Unresolved Merges shows members affected by unresolved merges.
87

Chapter 4: Source Integrity Interfaces
88
Work in Progress combines the Deferred Items, Members Locked By
Me, and Modified Working Files filters to show members that are
considered work in progress.
Locked Members shows those members locked by any user.
Members Locked By Me shows only members locked by you.
Frozen Members shows only frozen members.
Members with Attribute shows only members with a particular
attribute. If you choose this filter, Source Integrity prompts you for the
target attribute and value. For more information on member
attributes, see “Working With Member Attributes” on page 290.
Enter the target attribute name in the Attribute field and the value for
that attribute in the Value field, then click OK.
Members at Label shows only members that have the specified label
assigned at the member revision. If you choose this filter,
Source Integrity prompts you for the target label.
Enter the label name in the Label field, then click OK.
Members with Label shows only members with the specified label
somewhere in their member history. If you choose this filter,
Source Integrity prompts you for the target label.
Enter the label name in the Label field, then click OK.
Members at State shows only member revisions that have been
assigned a specific promotion state. If you choose this filter,
Source Integrity prompts you to identify the target state. For more
information on promotion states, see “Promoting Members” on
page 299.
Enter a state in the State field, then click OK.
Members with Name shows only members with the specified name. If
you choose this filter, Source Integrity prompts you to identify the
target name.
Enter a name, including the file extension, in the Name field (for
example, utility.dll), then click OK.
Members on Branch shows only members that are off the main
development trunk.
Pending Operations shows any members in your sandbox that are
associated with a pending operations. For more information, see
“Pending Operations” on page 204.
u s e r g u i d e

Source Integrity Graphical User Interface
Deferred Items shows any members in your sandbox that are
associated with a pending deferred operation, such as a deferred add,
drop, check in, or rename.
Once a filter is applied to a project, operations performed on all project
members apply only to those members shown as a result of the filter. For
example, if you apply the filter for Modified Working Files and then
perform a Member > Lock operation for that project, the lock operation
applies only to those members shown by the Modified Working Files filter.
Regular Expression Filter (GUI)
A regular expression is a set of symbols and syntactic characters used to
match patterns of text. The Regular Expression filter allows you to apply a
standard regular expression as a filter to a particular selection within
specific dialog boxes in Source Integrity.
There are three selection elements that the Regular Expression filter applies
to, development paths, revisions, and labels. You can, for example, filter a
long list of development paths to find the particular one you are looking
for without scrolling through that long list.
The following table outlines the specific dialog boxes and selection
elements that you can apply the Regular Expression filter to:
à Ã
Create Sandbox On the Specify Type of Sandbox panel, you can filter on
Variant Development Path Name list, Build Revision
list, and Build Label list.
Check Out Under Revision to Check Out, you can filter on the
Revisions list and Labels list.
Create Development
Path
Remove
Development Path
Under Revision, you can filter on the Revisions list and
Labels list.
You can filter on the Development Path list.
Merge Branch Under Target or Branch, you can filter on the Revision
list.
Member Information On the General panel, you can filter on the Member
Revision list.
Delete Label You can filter on the Label list.
Update Revision Under Revision to Set, you can filter on the Revisions
list and Labels list.
Restore Project Under Revision, you can filter on the Revisions list and
Labels list.
89

Chapter 4: Source Integrity Interfaces
90
If you are unfamiliar with using regular expressions, the following
resources can provide more details:
“Matchmaking with regular expressions” by Benedict Chng at
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713regex.html
Mastering Regular Expressions by Jeffrey E. F. Friedl, published in 1997
by O’Reilly (www.oreilly.com)
To apply the Regular Expression filter in the Check Out, Create
Development Path, Update Revision, or Restore Project dialog box in
the graphical user interface
1 Click the selection element you want to filter, for example, the
Revisions list.
An example of the Revisions list highlighted as the selection element for
filtering.
2 On the keyboard press CTRL + F3 to initiate the filter.
The Please Supply A Pattern To Use dialog box is displayed.
3 In the Filter Pattern field, type the expression you want to use, for
example, a[bc]*.
TIP
The Regular Expression filter remembers up to 5 previous expressions used in
any given session. To use an expression again, select it from the Filter Pattern
list, and click OK.
To undo a filter and return to your original unfiltered selection list,
select No Filter from the Filter Pattern list, and click OK.
u s e r g u i d e

Source Integrity Graphical User Interface
4 Select the column you want to apply the filter to from the Column to
Filter on list.
5 Click OK to complete the operation.
The selection is filtered. Only files matching your expression
arguments appear available in the selection list.
To apply the Regular Expression filter in the Remove Development
Path, Merge Branch, Member Information, Delete Label or Create
Sandbox dialog box in the graphical user interface
1 Click the selection element you want to filter, highlighting it, for
example, the Revisions list.
An example of the Revisions list highlighted as the selection element for
filtering.
2 On the keyboard press CTRL + F3 to initiate the filter.
The Please Supply A Pattern To Use dialog box is displayed.
3 In the Filter Pattern field, type the expression you want to use, for
example, a[bc]*.
TIP
The Regular Expression filter remembers up to 5 previous expressions used in
any given session. To use an expression again, select it from the Filter Pattern
list, and click OK.
To undo a filter and return to your original unfiltered selection list,
select No Filter from the Filter Pattern list, and click OK.
91

Chapter 4: Source Integrity Interfaces
Environment
Variables
92
4 Click OK to complete the operation.
The selection is filtered. Only files matching your expression
arguments appear available in the selection list.
Environment variables are accessed by external programs configured
under the user toolbar buttons. When using these variables, the names
must be in uppercase or Source Integrity will not recognize them. You can
use the environment variables listed in this section.
Window Type Opened Associated Environment Variable
All The environment variable MKSSI_WINDOW is set in all cases.
If there is no active window, or no window, then:
MKSSI_WINDOW=none
If there is an active window, then:
MKSSI_WINDOW=[project|sandbox|projecthistory]
Otherwise, the value is set to a window-specific value:
MKSSI_WINDOW=archive
If the active window is a different window, then:
MKSSI_WINDOW=unknown
For example, a Project Modifications window that does not produce any specific
environment variables:
MKSSI_WINDOW=unknown
Note: For the values none and unknown, no other variables are set.
All known window types set three variables for the server:
MKSSI_HOST
MKSSI_PORT
MKSSI_USER
Because Source Integrity supports multiple connections to the server, you should
specify the following environment variables when running a command line
operation from the toolbar:
si --host=$MKSSI_HOST --port=$MKSSI_PORT
--user=$MKSSI_USER
u s e r g u i d e

Window Type Opened Associated Environment Variable
Project For an open project window:
Source Integrity Graphical User Interface
MKSSI_WINDOW=project
MKSSI_FILE=server-side-project-path
MKSSI_NMEMBER=number of MKSSI_MEMBERxx entries
MKSSI_NSUBPROJECT=number of MKSSI_SUBPROJECTyy entries
If any members are selected, then the following variables apply:
MKSSI_MEMBERxx=path-relative-to-project
MKSSI_MEMBER_PROJECTxx=server-side-project/subproject-path
If any subprojects are selected, then the following variables apply:
MKSSI_SUBPROJECTyy=path-relative-to-project
MKSSI_SUBPROJECT_PROJECTyy=server-side-project/subprojectpath
That is, if there are n members selected and m subprojects selected then you have
n occurrences of MKSSI_MEMBER numbered from 1 to n and the number n is also
passed in MKSSI_NMEMBER. There are also occurrences of MKSSI_SUBPROJECT,
numbered from 1 to m, and the number m is passed in MKSSI_NSUBPROJECT.
If a subdirectory is selected, then it is as if that subdirectory is recursively
expanded (only the directories, not subprojects) and all members are selected.
Because a given member may not be in the top level project that is open in the
view, each variable for MKSSI_MEMBER and MKSS_SUBPROJECT has a
corresponding entry for MKSSI_MEMBER_PROJECTxx and
MKSSI_SUBPROJECT_PROJECTxx. Therefore, each MEMBER/SUBPROJECT
variable is relative to its corresponding PROJECT entry, not to the top level
indicated in MKSSI_FILE.
For example:
i=1
while [ $i -le $MKSSI_NMEMBER ]
do
eval si command
-P\${MKSSI_MEMBER_PROJECT$i}\${MKSSI_MEMBER$i}
let i=i+1
done
Note: If set, the environment variables MKSSI_VARIANT and MKSSI_BUILD are
also exported when invoking an si command with the options for --devpath and
--projectrevision.
Sandbox For an open sandbox window:
MKSSI_WINDOW=sandbox
MKSSI_FILE=full-path-to-sandbox
MKSSI_NMEMBER=number of MKSSI_MEMBER objects
MKSSI_NSUBPROJECT=number of MKSSI_SUBPROJECT objects
Note: The variables MKSSI_MEMBERxx= and MKSSI_SUBPROJECTxx= take the
same settings as for a project window. The corresponding variables
MKSSI_MEMBER_SANDBOXxx and MKSSI_SUBPROJECT_SANDBOXxx are also as
described for a project. If applicable, MKSSI_VARIANT and MKSSI_BUILD are
also set.
93

Chapter 4: Source Integrity Interfaces
Window Type Opened Associated Environment Variable
Member History For an open member history window:
MKSSI_WINDOW=archive
MKSSI_FILE=pathname-relative to project/sandbox of archive
If the window was opened via a sandbox:
MKSSI_WORKINGFILE=full-path-to-working-file
MKSSI_SANDBOX=full-path-to-sandbox
Note: MKSSI_WORKINGFILE is not set if the working file does not exist.
If the window was opened via a project:
MKSSI_PROJECT=server-path-to-project
If the project/sandbox was a variant:
MKSSI_VARIANT=variant-name
If the project/sandbox was a build:
MKSSI_BUILD=build-number
If revisions were selected:
MKSSI_REVISION=highest revision in selection
MKSSI_REVISIONxx=1.2
That is, there are n variables from MKSSI_REVISION1 to MKSSI_REVISIONxx,
containing each selected revision number.
Project History For an open project history window:
MKSSI_WINDOW=projecthistory
MKSSI_FILE=server-side-project-path
Note: MKSSI_REVISIONxx is set in the same way as a member history.
Source Integrity Web Interface
94
Source Integrity includes a Web interface that allows project managers to
perform key tasks related to project members. Using the Source Integrity
Web interface, you can manage projects and project members, view project
and member histories, and work with project and member attributes—and
this functionality is available without you having to install the
Source Integrity client on your machine.
The Web interface is a program interface that appears in a Web browser,
such as Netscape Navigator and Microsoft Internet Explorer. Working in a
Web interface offers the familiar functionality of a Web browser with no
client installation required.
The Source Integrity Web interface accesses only the Project view and
functionality related to managing project members. For example, you can
view a member revision, check out and check in a member. Similarly, you
can view differences between revisions, but you cannot merge those
revisions.
u s e r g u i d e

Application
Window
Source Integrity Web Interface
The Integrity Server welcome page provides a link to the read-only version
of the Web interface. You can connect to the read-only Web interface by
clicking the read-only mode link displayed under Start Source Integrity
Web Interface.
NOTE
Other functionality related to sandboxes is available only through the graphical
user interface and the command line interface.
The Source Integrity Web interface window contains a number of common
features explained in this section.
Title Bar
The title bar is the uppermost component of the application window. On
the left side, the title bar displays the name of the software program. On
the right side, the title bar displays the standard Windows buttons for
minimizing, resizing, and closing the application window.
You can also use the active links in the title bar to navigate within the
project. To navigate to a subproject, click the applicable portion of the link.
Menu Bar
The menu bar is located directly below the title bar. Each menu contains
available commands. When you first start the Source Integrity Web
interface, there are three menus in the menu bar: File, Tools, and Help. The
list of available menus and commands varies depending on the function
you are performing (for example, working with a project or with a member
history).
95

Chapter 4: Source Integrity Interfaces
96
NOTE
In the Source Integrity Web interface, application functionality is not available
through the shortcut menu.
To see the current user and server that the Source Integrity Web interface is
connected to, point to the Source Integrity icon ( ). A ToolTip appears
displaying the user and server, for example, mkern@abc_server:7001.
Toolbar
Immediately below the menu bar is a toolbar that provides easy access to
the most commonly used Source Integrity commands. Toolbar functions
are carried out by clicking the appropriate toolbar button with the left
mouse button. ToolTips, which explain the function of each toolbar button,
appear when you hold the mouse pointer over the button.
Most toolbar buttons only become available when an item is selected in a
certain window. For example, selecting a project in a Project view displays
project command toolbar buttons.
Project View
The Source Integrity Web interface provides access to the Project view. The
Project view displays the project members and hierarchy for projects
registered with the Integrity Server.
The Project view also gives you access to project-level functions and a
limited number of member-level functions.
Status Bar
When you select a command from a Source Integrity menu, a brief
explanation of its purpose and status displays in the status bar. The status
bar also displays the user, server and port number currently logged in for
the session. In addition, when you point to a toolbar button, you can see an
explanation of its function.
Filter List
Beside the toolbar is an optional list of built-in filters that allow you to
focus your view on a subset of the project members you are currently
interested in. Source Integrity displays only those members that meet the
criteria specified by the filter.
u s e r g u i d e

Using Filters
Source Integrity Web Interface
For large projects, use filters to display only the relevant members for your
task. Filters allow you to view and manipulate a predefined subset of
project members that are grouped according to their properties.
The Source Integrity Web interface provides a reduced set of filters related
to managing project members. The filters appear in the Filter list located on
the toolbar.
Choose one of the following filters and your view is filtered accordingly:
All Members shows all members of the current project.
Locked Members shows those members locked by any user.
Members Locked By Me shows only members locked by you.
Frozen Members shows only frozen members.
Members at Label shows only members that have the specified label
assigned at the member revision. If you choose this filter,
Source Integrity prompts you for the target label. For more
information on member attributes, see “Working With Member
Attributes” on page 290.
Under Specify a Label, enter the label name in the field, then click OK.
Members with Label shows only members with the specified label
somewhere in their member history. If you choose this filter,
Source Integrity prompts you for the target label.
Under Specify a Label, enter the label name in the field, then click OK.
Members at State shows only member revisions that have been
assigned a specific promotion state. If you choose this filter,
Source Integrity prompts you to identify the target state. For more
information on promotion states, see “Promoting Members” on
page 299.
Under Specify a State, enter the state name in the field, then click OK.
Members with Attribute shows only members with a particular
attribute. If you choose this filter, Source Integrity prompts you for the
target attribute and value.
Under Specify a Member Attribute, enter the attribute name in the
field, then click OK. Enter the target attribute name in the Attribute
field and the value for that attribute in the Value field, then click OK.
Member on Branch shows only members that are off the main
development trunk.
97

Chapter 4: Source Integrity Interfaces
Command Line Interface
Viewing
Available CLI
Commands
Using the
Graphical User
Interface From
the CLI
98
Once a filter is applied to a project, operations performed on project
members apply only to those members shown as a result of the filter. For
example, if you apply the filter for Members at State and then perform a
Member > Lock operation for that project, the lock operation applies only to
those members shown by the Members at State filter.
Source Integrity provides a command line interface (CLI) to manage your
projects, sandboxes, and members, and to configure Source Integrity. To
access the command line interface from a computer running Windows,
from the Start menu select MS-DOS Prompt or Command Prompt
(depending on the version of Windows).
The command line interface, or CLI, is a program that allows a user to
enter keywords as instructions to a computer or device to perform specific
tasks. (The MS-DOS® Command Prompt is an example of a CLI.) Results
are typically outputted as simple text to the user’s terminal.
The Source Integrity Enterprise Edition CLI Reference Guide and man pages
provide complete information about all Source Integrity commands and
their options.
NOTE
If you are using the command line interface with a Linux, Solaris, AIX, or
HP-UX client, you must manually add /bin/ to your
default PATH, located in your home directory startup files.
If you are working within the sandbox directory where you want to perform
commands you do not need to specify the sandbox name in the command
options.
You can view available Source Integrity commands by typing si.
To view a list of a command’s options, add -? or --usage to the end of the
command, for example, si connect -?.
In addition to using the command line interface by itself, you can also
combine the graphical user interface with commands entered in the
command line interface. This can be useful if you prefer to perform certain
operations in the command line interface and others in the graphical user
interface.
u s e r g u i d e

Command
Prompts
Member Name
Arguments
Command Line Interface
For example, you can use the si co command to check out a file, attaching
-g or --gui to the end of the command to view the Check Out dialog box.
You can then select check out options.
This allows you to use the Check Out dialog box without having to launch
the graphical user interface.
For more information on using the graphical user interface with the
command line interface, see the Source Integrity Enterprise Edition CLI
Reference Guide and the online man pages.
You can use some Source Integrity commands without specifying any
options, for example, si connect. Entering only the command prompts
you to add additional information that you would normally add in the
form of command options. This is useful for commands, such as si
connect, because the prompts may contain default information, for
example, your default Integrity Server and port number. This information,
if it exists, is in your IntegrityClient.rc or
IntegrityClientSite.rc file.
For project and sandbox commands, member refers to members of an
Integrity Server project. If the member argument is omitted for project or
sandbox commands, the command is applied to all of the members of the
project or sandbox. The member element must be the last entry of a
command statement.
There are three ways to apply a command to multiple members:
Type Multiple Member Names
You can enter two or more member names, separated by spaces, as the
member component. For example, the command:
si co -S project.pj prog.c brochur.toc brochur.idx
checks out all three members. You can name as many members as you
like on the command line (subject to the line length limitations of your
operating system).
NOTE
Source Integrity commands do not span command shell line lengths.
99

Chapter 4: Source Integrity Interfaces
100
Use Wildcards
Use wildcards in the member component. For example, the command:
si ci -S c:\work\project.pj brochur.*
checks in all members with the base name brochur and any
extension.
Specify a Member List
A member list (specified with the -F member option) is a text file
containing the names of the members a command should be applied
to. For example, the command:
si ci -S c:\work\project.pj -F flist.lst
checks in all the members listed in the flist.lst file.
Members named in the member element may have any level of path
qualification.
A member list is a text file containing a list of member names, with each
name on a line by itself. When you pass a member list to Integrity Server, it
reads the member names and applies the command to them in sequence.
You can create a member list with any text editor by typing member
names—one name per line—in a plain text file. Alternatively, you can
compile a list of members with the find command and copy them to a text
file. The find command is a standard UNIX utility and is available on
Win32 based systems with MKS Toolkit.
MKS Visual Difference Interface
The MKS Visual Difference tool is a graphical application that allows you
to compare a working file and a member revision, or two revisions. It
offers two-way differencing of revisions where differences are highlighted
for you.
u s e r g u i d e

Application
Window
MKS Visual Difference Interface
Similar to the Source Integrity application window, MKS Visual Difference
contains a number of common features explained in this section.
Title Bar
The title bar is the uppermost component of the application window. On
the left side, the title bar displays the name of the application and the
member name. On the right side, the title bar displays the standard
Windows buttons for minimizing, resizing, and closing the application
window.
Menu Bar
The menu bar is located directly below the title bar. Each menu contains
available operations. When you first start MKS Visual Difference, there are
three menus in the menu bar: File, View, and Help. The list of available
menus and operations varies depending on the function you are
performing (for example, working in differences mode or merge mode).
101

Chapter 4: Source Integrity Interfaces
102
Toolbar
Immediately below the menu bar is a toolbar that provides easy access to
the most commonly used Visual Difference operations. Toolbar functions
are carried out by clicking the appropriate toolbar button. Point to a button
to display a ToolTip that contains a description for that button.
Toolbar buttons become available and unavailable for use depending on
the mode you are in. For more information, see “Modes” on page 104.
Located immediately below the toolbar buttons are display controls that
change what appears in the view panes. These controls are also available in
the View menu.
NOTE
The Ignore Whitespace, Ignore Case, and Ignore Blanks display controls can
only be adjusted before making changes to the Merge Result. Once you begin
to make changes, (merging or editing), the options become unavailable.
Difference Blocks is a list containing all of the difference blocks in the
revisions, including the type of difference (change, insertion, deletion),
and the line numbers. If you are working in Merge mode, the
Difference Blocks list also includes edit blocks.
To move to a particular difference block, select the block from the
Difference Blocks list.
The selected difference block appears.
Ignore Whitespace ignores tab and white space throughout the lines in
the revisions.
Ignore Case ignores the type case when comparing the revisions.
NOTE
Under the View menu, the following controls are also available:
Synchronize Scrolling causes all of the panes to scroll simultaneously. This
control is enabled by default.
Ignore Blanks ignores white space at the end of lines, and changes it to white
space elsewhere in the line.
u s e r g u i d e

View Panes
MKS Visual Difference Interface
The view panes appear within the MKS Visual Difference window and
display the revisions you are comparing including line numbers for
navigation (line numbers can be removed through the MKS Visual
Difference options). Scrolling in the view panes is synchronized.
In Merge mode, there are two different layouts for the view panes, vertical
layout and split layout.
The vertical layout displays two revisions side-by-side for comparison.
You can view either the Merge From and Merge To, or by clicking the View
Merge Result button, you can view the Merge From and the Merge Result.
The split layout displays three revisions for comparison. The Merge From
and Merge To are displayed side-by-side, and the Merge Result pane
appears below them.
In the Merge Result a number immediately to the left of the line numbers
appears to indicate which revision, Merge From (1) or Merge To (2), the
block originated from.
To change the layout of the view panes in Merge mode, use the View
vertical layout and View split layout buttons on the toolbar, or select View >
Vertical Pane Layout or View > Split Pane Layout.
To display a specific line of code, select View > Go to Line or click . In
the Go to dialog box, from the File list, select the file that contains the line
you want to view. In the Go to Line field, enter the number of the line, for
example, 33. The line of code is displayed in the center of the pane if it
exists in a scrolling region.
The Merge From is the revision or working file (as specified by the
Reassign Merge Roles dialog box), from which blocks are merged. For
information on the Reassign Merge Roles dialog box, see “Merging Two
Revisions” on page 356.
The Merge To is the revision or working file (as specified by the Reassign
Merge Roles dialog box), that the Merge Result file is based on.
The Merge Result file is the file that blocks are merged into, and can be
edited and saved to contain the output of the merge.
The Differences mode uses only the vertical layout, which displays the two
selected revisions side-by-side for comparison.
103

Chapter 4: Source Integrity Interfaces
Modes
104
Shortcut Menu
MKS Visual Difference supports standard shortcut menus in Merge mode.
To display the menu of actions you can perform, select a line in any pane
and right click. MKS Visual Difference displays the applicable shortcut
menu.
The available actions displayed in the shortcut menu depends on whether
you right click within the Merge From, Merge To or the Merge Result view
panes.
Shortcut Keys
For some operations, shortcut keys are provided. Shortcut keys appear on
menus opposite their operation names.
NOTE
In MKS Visual Difference, the operations available in a given menu depends on
which mode you are working in. For information on modes, see “Modes” on
page 104
Status Bar
The status bar provides a short summary of the difference blocks for Merge
From and Merge To. It shows insertions, deletions, and changes with a
number indicating how many of each exist.
MKS Visual Difference can operate in two different modes depending on
what it is being used for. Since Visual Difference is both a differencing tool
and a merging tool, it has a Differences mode and a Merge mode.
The Differences mode is used to compare revisions and display the
differences between them. No merging operations are available in the
Differences mode.
The Merge mode is used for all merging related operations and editing.
You can toggle between the two modes in Visual Difference by selecting
File > Differences or File > Merge, or you can click the Differences or Merge
buttons on the toolbar.
When you switch from the Differences mode to the Merge mode, the
Reassign Merge Roles dialog box is displayed. This dialog box allows you
to specify which revision you want as the Merge From and Merge To.
A bullet is displayed next to the mode currently being used.
u s e r g u i d e

Preferences
MKS Visual Difference Interface
Preferences allow you to customize the appearance of the MKS Visual
Difference interface. You can configure general preferences, and font and
color preferences.
Setting General Preferences
Under the General tab, you can set your options for the toolbar, line
numbers, and tab expansion.
To set general preferences in the MKS Visual Difference interface
1 Select View > Preferences.
The Preferences dialog box is displayed.
2 To configure your toolbar, click the Toolbar button.
3 Configure the toolbar as desired. For more information, “To customize
the main toolbar in the graphical user interface” on page 82.
NOTE
The toolbar buttons available for configuration varies depending on which
mode you are working in.
105

Chapter 4: Source Integrity Interfaces
106
4 Under Miscellaneous, set the following options:
To display line numbers in the revisions, select Show Line
Numbers. Clear this option if you want to remove line numbers.
To set the tab size, in the Expand tabs to field enter the number of
spaces you want tabs expanded to. Changes to tab size do not
take effect until the tool is invoked again.
5 Click OK to save your changes.
Setting Font and Color Preferences
Under the Fonts & Colors tab, you can set your preferences for the colors
and fonts used in MKS Visual Difference.
You can use the Reset to Defaults button to reset the display to the original
fonts and colors.
To set font and color preferences in the MKS Visual Difference
interface
1 Select View > Preferences.
The Preferences dialog box is displayed.
2 Click the Fonts & Colors tab.
The Fonts & Colors panel is displayed.
u s e r g u i d e

MKS Visual Merge Interface
3 To change the background color of a particular block (Unchanged,
Inserted, Deleted, Changed, Edited), click the corresponding
Background button.
The Choose Background Color dialog box is displayed.
4 Set your preferred color on the Swatches, HSB or RGB tabs. The
Preview at the bottom of the dialog box displays the selected color for
you.
5 Click OK to set the background color.
6 To change the foreground color of a particular block (Unchanged,
Inserted, Deleted, Changed, Edited) click the corresponding
Foreground button.
The Choose Foreground Color dialog box is displayed.
7 Set your preferred color on the Swatches, HSB, or RGB tabs.
The Preview at the bottom of the dialog box displays the selected color
for you.
8 Click OK to set the foreground color.
9 To set the display font for a particular block (Unchanged, Inserted,
Deleted, Changed, Edited), click the corresponding Font button.
The Choose Font dialog box is displayed.
10 Select the Font, Style and Size from the corresponding list.
The Sample at the bottom of the dialog box displays the selected font,
style and size for you.
11 Click OK to set the font.
12 Click OK to save your font and color changes.
MKS Visual Merge Interface
MKS Visual Difference is updated with your changes.
The MKS Visual Merge tool is a graphical application that allows you to
compare revisions and perform edits and merges. It offers three-way
differencing of revisions where conflicts are highlighted for you. It features
in-line editing, differencing, and conflict resolution. It is similar to MKS
Visual Difference in look and feel, but includes many advanced features
used for complicated merging tasks.
107

Chapter 4: Source Integrity Interfaces
Application
Window
108
The three-way differencing in MKS Visual Merge allows you to compare
the two revisions selected for merging, the Merge From revision and the
Merge Base revision, as well as the working file or Merge To file for the
member. The revisions are highlighted for differences and conflicts
allowing you to choose the blocks you want to merge from each revision
and save to the Merge Result file.
Conflicts, if they exist, are highlighted and appear with a red flag next to
the line number. With all three files available for comparison in MKS
Visual Merge you can decide which of the conflicting blocks you want to
incorporate into the merge result, or you can use the editing utilities to
insert blocks from each revision into the merge result.
Similar to the Source Integrity application window, MKS Visual Merge
contains a number of common features explained in this section.
u s e r g u i d e

Title Bar
MKS Visual Merge Interface
The title bar is the uppermost component of the application window. On
the left side, the title bar displays the name of the application and the
member name. On the right side, the title bar displays the standard
Windows buttons for minimizing, resizing, and closing the application
window.
Menu Bar
The menu bar is located directly below the title bar. Each menu contains
available commands. MKS Visual Merge has four menus in the menu bar:
File, Edit, View, and Help. The list of available commands varies depending
on the function you are performing.
Toolbar
Immediately below the menu bar is a toolbar that provides easy access to
the most commonly used MKS Visual Merge commands. Toolbar functions
are carried out by clicking the appropriate toolbar button. Point to a button
to display a ToolTip that contains a description for that button.
Located immediately below the toolbar buttons are display controls that
change what appears in the view panes. These controls are also available in
the View menu.
NOTE
The Ignore Whitespace, Ignore Case, and Ignore Blanks display controls can
only be adjusted before making changes to the Merge Result. Once you begin
to make changes, (merging or editing), the options become unavailable.
Difference Blocks is a list containing all of the difference blocks in the
revisions, including the type of difference (change, insertion, deletion,
and conflict), and the line numbers.
To move to a particular difference block, select the block from the
Difference Blocks list.
The selected difference block is displayed.
Ignore Whitespace ignores tab and white space throughout the lines in
the revisions.
Ignore Case ignores the type case when comparing the revisions.
109

Chapter 4: Source Integrity Interfaces
110
NOTE
Under the View menu, the following controls are also available:
Synchronize Scrolling causes all of the panes to scroll simultaneously. This
control is enabled by default.
Ignore Blanks ignores white space at the end of lines, and changes it to white
space elsewhere in the line.
View Panes
The view panes appear within the MKS Visual Merge window and display
the revisions you are comparing including line numbers for navigation
(line numbers can be removed through the MKS Visual Merge options).
There are two different layouts for the view panes, vertical layout and split
layout.
The vertical layout displays the three revisions side-by-side for
comparison. You can view the Merge From, Merge Base and Merge To
revisions.
The split layout displays in four panes for comparison. The Merge From,
Merge Base and Merge To revisions are displayed side-by-side, and the
Merge Result appears below them.
In the Merge Result pane a number immediately to the left of the line
numbers appears to indicate which revision — Merge From (1), Merge Base
(2) or Merge To (3) — the block originated from.
To change the layout of the view panes, use the View vertical layout and
View split layout buttons on the toolbar, or select View > Vertical Pane
Layout or View > Split Pane Layout.
To display a specific line of code, select View > Go to Line or click . In
the Go to dialog box, from the File list, select the file that contains the line
you want to view. In the Go to Line field, enter the number of the line, for
example, 33. The line of code is displayed in the center of the pane if it
exists in a scrolling region.
The Merge From is the revision from which blocks are merged.
The Merge Base is the revision you want to use as the base for calculating
differences against the Merge From to be applied to the Merge To.
The Merge To is the working file, and is used as the basis for the Merge
Result file.
The Merge Result file is the file that blocks are merged into, and can be
edited and saved to contain the output of the merge.
u s e r g u i d e

Preferences
Scrolling in the view panes is synchronized.
Shortcut Menu
MKS Visual Merge Interface
MKS Visual Merge supports standard shortcut menus. To display the
menu of actions you can perform, select a line in any pane and right click.
MKS Visual Difference displays the applicable shortcut menu.
The available actions displayed in the shortcut menu depends on whether
you right click within the Merge From, Merge Base, and Merge To view
panes or the Merge Result view pane.
Shortcut Keys
For some operations, shortcut keys are provided. Shortcut keys appear on
menus opposite their operation names.
Status Bar
The status bar provides a short summary of the difference blocks for each
revision. It shows conflicts, insertions, deletions, and changes with a
number indicating how many of each exist in each file. For example, the
summary, Inserted: 0/2/5, means that in the Merge From there are no
insertions, while in the Merge Base there are two insertions, and in the
Merge To there are 5 insertions.
Conflict statistics show the total number of conflicts.
Preferences allow you to customize the appearance of the MKS Visual
Merge interface. You can configure general options and font and color
options.
Setting General Preferences
Under the General tab, you can set your preferences for the toolbar, line
numbers, and tab spacing.
To set general preferences in the MKS Visual Merge interface
1 Select View > Preferences.
The Preferences dialog box is displayed.
111

Chapter 4: Source Integrity Interfaces
112
2 To configure your toolbar, click the Toolbar button.
Customize the toolbar as desired. For more information, see “To
customize the main toolbar in the graphical user interface” on page 82.
3 Under Miscellaneous, set the following options:
To display line numbers in the revisions, select Show Line
Numbers. Clear this option if you want to remove line numbers.
To set the tab size, in the Expand tabs to field enter the number of
spaces you want tabs expanded to. Changes to tab size do not
take effect until the tool is invoked again.
4 Click OK to save your changes.
Setting Font and Color Options
Under the Fonts & Colors tab, you can set your options for the colors and
fonts used in MKS Visual Merge.
You can use the Reset to Defaults button to reset the display to the original
fonts and colors.
To set font and color preferences in the MKS Visual Merge interface
1 Select View > Preferences.
The Preferences dialog box is displayed.
2 Click the Fonts & Colors tab.
The Fonts & Colors panel is displayed.
u s e r g u i d e

MKS Visual Merge Interface
3 To change the background color of a particular block (Unchanged,
Inserted, Deleted, Changed, Edited, Conflict), click the corresponding
Background button.
The Choose Background Color dialog box is displayed.
4 Set your preferred color on the Swatches, HSB or RGB tabs. The
Preview at the bottom of the dialog box displays the selected color for
you.
5 Click OK to set the background color.
6 To change the foreground color of a particular block (Unchanged,
Inserted, Deleted, Changed, Edited, Conflict), click the corresponding
Foreground button.
NOTE
The foreground color changes the color of the text that is displayed in a
particular block. If the foreground and background colors of a block are the
same you will not be able to read the text.
The Choose Foreground Color dialog box is displayed.
7 Set your preferred color on the Swatches, HSB or RGB tabs. The
Preview at the bottom of the dialog box displays the selected color for
you.
8 Click OK to set the foreground color.
113

Chapter 4: Source Integrity Interfaces
114
9 To set the display font for a particular block (Unchanged, Inserted,
Deleted, Changed, Edited, Conflict) click the corresponding Font
button.
The Choose Font dialog box is displayed.
10 Select the Font, Style and Size from the corresponding list. The Sample
at the bottom of the dialog box displays the selected font, style and
size for you.
11 Click OK to set the font.
12 Click OK to save your font and color changes.
MKS Visual Merge is updated with your changes.
u s e r g u i d e

Project and Sandbox
Operations
KEY TERMS: project, subproject, sandbox, member, revision, variant, build,
development path, deferred operations, keywords
5
This chapter describes the Source Integrity project related features you
will use in your day-to-day activities, such as creating a sandbox.
The tasks you can perform are restricted by the permissions assigned to
you by your administrator. If you find you are unable to perform necessary
operations, you must contact the administrator responsible for
Source Integrity at your site to review the permissions assigned to you.
NOTE
If your administrator has assigned you a new set of permissions, you must
update your permissions by disconnecting your Source Integrity client and
then reconnecting to Integrity Server. An out-of-date permission set may cause
unpredictable behavior when attempting to open projects or perform other
tasks.
This chapter provides details on the following:
“Working With Projects” on page 116
“Working With Subprojects” on page 124
“Working With Sandboxes” on page 135
115

Chapter 5: Project and Sandbox Operations
Working With Projects
Creating a
Project
116
When you are ready to place a related group of files under Source Integrity
control, the first step is to create a project. A project is a container for a
group of files that reside on the Integrity Server.
In addition to creating a project, you can import an existing project from an
earlier version of Source Integrity or, if a project is no longer active, you
may also want to drop the project from the Integrity Server.
This section provides the procedures for:
creating a project
importing a project
dropping a project
adding a project
opening or viewing a project
When creating a project, you only create the project file. To add files, or
members to the project, you must create a sandbox that points to the project
and then add the project members through that sandbox.
You can create a project from the Registered Projects view. With the
Registered Projects view open, click Create (or select Create from the
shortcut menu), and the Specify Project to Create dialog box is displayed.
Specify the location for the project (by typing the path and file name, or
browsing), and specify a project name, then click OK. The project appears
in a Project view.
TIP
For suggested best practices on creating projects, see the Integrity Server
Installation and Administration Guide.
To create a project in the graphical user interface
1 Do one of the following:
Select File > New Project.
Click .
The Specify the Project to Create dialog box is displayed.
u s e r g u i d e

Importing a
Project
Working With Projects
2 If your administrator has specified multiple server roots, from the
Look in list select a location where you want to create the project.
Otherwise, go to the next step.
If multiple server roots are specified, the Look in list contains the
possible choices. Once you select a location, its name appears in
brackets in the title bar of the dialog box, for example, (c:/). For
more information on multiple server roots, consult your administrator
or see the Integrity Server Installation and Administration Guide.
3 Enter the path and file name, or browse to a location on the Integrity
Server where you want to create the project, for example, C:/
Aurora_Program.
If the project path does not exist on the Integrity Server, the new path
is created.
NOTE
When you specify the name of the new project, Source Integrity automatically
assigns the .pj file extension. If you specify a .pj file extension in uppercase
or mixed case, Source Integrity replaces that file extension with the correct
lowercase .pj file extension. If you specify a file extension other than .pj,
Source Integrity 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.
4 Enter a name for the project, for example, project.pj.
IMPORTANT
A single project name can be used only once in the same location.
Source Integrity 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 Source Integrity asks you to specify a different path and file name, or
a different project name.
5 Click OK.
The project appears in a Project view (see “Project View” on page 457).
You can now create a sandbox, then add members to the sandbox. For
more information, see “Working With Sandboxes” on page 135.
When you create a project, it is automatically registered with the Integrity
Server; however, projects created with older versions of Source Integrity
must be imported and registered with the Integrity Server.
117

Chapter 5: Project and Sandbox Operations
118
Importing a project registers it with the Integrity Server. Once a project is
imported, Source Integrity commands can be performed upon it.
NOTE
To add projects that were previously dropped from Source Integrity, see
“Adding a Project” on page 120.
To import a project in the graphical user interface
1 Do one of the following:
Select Tools > Manage Projects.
Click .
The Registered Projects view is displayed.
TIP
The Registered Projects view supports standard shortcut menus. To display
the menu of actions you can perform, select a sandbox and then right click it.
Source Integrity displays the applicable shortcut menu.
2 Click Import.
The Select One or More Projects dialog box is displayed.
3 Browse to the project file on the server.
To filter the dialog box to display only project files, from the Files of
type list, select MKS Source Integrity Project files.
NOTE
If your connection to the Integrity Server is disconnected while you are
browsing for a file, the file browser does not show any files or directories.
4 Click OK.
u s e r g u i d e

Dropping a
Project
IMPORTANT
Working With Projects
You cannot import a project that is already registered. Source Integrity 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
Source Integrity does not import the project.
The project is added to the Registered Projects view.
When a project has outlived its usefulness or just does not belong on the
Integrity Server anymore, you can remove it at any time.
To drop a project means that the project is no longer registered with the
Integrity Server. Once a project is dropped, it cannot be accessed with
Source Integrity. However, if the project is not deleted and you can import
it again if you want it to be accessible in Source Integrity.
To add projects that were previously dropped from Source Integrity, see
“Adding a Project” on page 120.
To drop a project in the graphical user interface
1 Do one of the following:
Select Tools > Manage Projects.
Click .
The Registered Projects view appears.
119

Chapter 5: Project and Sandbox Operations
Adding a
Project
120
TIP
The Registered Projects view supports standard shortcut menus. To display
the menu of actions you can perform, select a sandbox and then right click it.
2 Select the project you want to drop.
3 Click Drop.
The Confirm Project Drop dialog appears.
4 To drop the selected project click Yes.
The project is removed from the list of registered projects.
5 Close the Registered Projects view.
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
a project that was imported but not added to Source Integrity
To add a project in the graphical user interface
1 Do one of the following:
Select Tools > Manage Projects.
Click .
The Registered Projects view appears.
2 Click Add.
The Select One or More Projects dialog box appears.
3 Enter the path and file name, or browse to a location on the Integrity
Server the project is located.
4 Click OK.
The project is added to Source Integrity and is displayed on the
Regular panel in the Registered Projects view.
5 Close the Registered Projects view.
u s e r g u i d e

Opening or
Viewing a
Project
Working With Projects
Opening a project in the graphical user interface allows you to view the
project and perform certain commands with its members.
The Project view displays the members and subprojects of a project.
To open a project in the graphical user interface
1 Do one of the following:
Select File > Open Project.
Click .
The Open Project Wizard appears.
2 In the Project Name field, enter the path and name of the project, or
click Select and choose a project from the list.
3 Click Next.
The second panel of the Open Project Wizard appears.
121

Chapter 5: Project and Sandbox Operations
122
4 Select the type of project you want to open by clicking a project type
option. The available types are:
Normal opens a project based upon the current state of the project.
Variant opens a project based upon a specific revision of the
master project and is used for branching off the main
development path.
NOTE
From the Development Path Name list, select a development path
name, for example, Aurora_Beta_Variant.
The Variant option is unavailable if there are no available development paths.
To create a development path, see “Creating a Development Path” on page 147.
A variant project must be based on a top-level project only.
Build opens a static project based upon a specific revision of the
master project that is used for building or testing the project, but
not for further development.
To specify a revision to base the build project, do one of the
following:
Select Revision, and from the list, select a project revision
number, for example, 1.1.
Select Label, and from the list, select a project label.
u s e r g u i d e

TIP
Working With Projects
You can also open a project from the Registered Projects view. With the
Registered Projects view open, select the project you want to open and click
Open, or select Open from the shortcut menu. The project appears in a Project
view.
5 To accept the options, click Finish. To modify the options, click Back.
The project opens in a Project view.
To open a project in the Web interface
1 Select File > Open Project.
The Select Project dialog box is displayed.
2 Click to highlight the project you want to open.
3 Click OK.
The project opens.
To open a variant project, select File > Open Variant Project. You can
also open a variant project from a Project view by choosing Project >
Open Variant Project.
To open a build project, select File > Open Build Project.
You can also 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.
123

Chapter 5: Project and Sandbox Operations
Working With Subprojects
Creating a
Subproject
124
Source Integrity allows you to create large projects composed of smaller
component projects. These smaller projects are known as subprojects.
Subprojects behave in the same way as projects, and can be accessed with
most project and sandbox commands.
Once you create a subproject, it is considered a member of the project. For
suggested best practices on creating subprojects, see the Integrity Server
Installation and Administration Guide.
Components usually fall into the following categories:
source files for creating individual executables
source files for common libraries
graphic files
documentation
This section discusses the procedures for:
creating a subproject
adding a subproject
creating a shared subproject
configuring a subproject
dropping a subproject
You can create a new subproject with the Subproject > Create command.
Once you have created a subproject you can add members and configure
the subproject if necessary.
To create a subproject in the graphical user interface
1 With a Project or Sandbox view open, select the project or sandbox to
add the subproject to.
2 From a Project view, select Project > Subproject > Create.
From a Sandbox view, select Sandbox > Subproject > Create.
The Specify the Subproject to Create on localhost:portnumber dialog
box is displayed.
3 Select the subproject to create, or enter the name for the subproject, for
example, applications.pj.
u s e r g u i d e

Adding a
Subproject
4 Click OK.
Working With Subprojects
The subproject appears in a Project or Sandbox view (see “Project
View” on page 457 or “Sandbox View” on page 469).
You can now add members to the subproject as you would with a
project.
When a subproject is dropped from a project the subproject’s historical
information remains. The Subproject > Add command allows you to re-add
a dropped subproject.
NOTE
In a variant sandbox, you cannot add an existing subproject that does not have
the variant defined.
To add a subproject in the graphical user interface
1 With a Project or Sandbox view open, select the project or sandbox
you want to add the subproject to.
2 From a Project view, select Project > Subproject > Add.
From a Sandbox view, select Project > Subproject > Add.
The Add Subproject Wizard appears.
125

Chapter 5: Project and Sandbox Operations
126
3 In the Subproject Location field, browse to the subproject to add, or
enter the path and name for the subproject, for example,
Libra_Project/applications.pj, and click Next.
Click Finish to add the subproject without specifying a type. The
subproject is added as the default type. For information on the default
type, see your administrator.
The Specify Type of Subproject to Add panel appears.
4 Select one of the following options for the type of subproject you want
to add:
Normal adds a subproject based upon the current state of the
subproject.
Variant adds a subproject based upon a specific revision of the
master project and is used for branching off the main
development path.
NOTE
From the Development Path Name list, select a development path
name, for example, Libra_Beta_Variant.
The Variant option is unavailable if there are no available development paths.
To create a development path, see “Creating a Development Path” on page 147.
u s e r g u i d e

Adding a
Shared
Subproject
Working With Subprojects
Build adds a static subproject based upon a specific revision of the
project that is used for building or testing the project, but not for
further development.
To specify a revision to base the build project, do one of the
following:
Select Revision, and from the list select a project revision
number, for example, 1.1.
Select Label, and from the list select a project label.
Default creates a project based on the type specified in the server
preferences. For information on what the default type is, see your
administrator.
5 To accept the options, click Finish. To modify the options, click Back.
The subproject appears in the Project or Sandbox view (see “Project
View” on page 457 or “Sandbox View” on page 469).
A shared subproject is a subproject that is a member of more than one
project. Source Integrity 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.
The first step to sharing a subproject is to select an existing subproject, or
master project that you want to add to another project. This existing
subproject will continue to reside within its original master project, but
will be referenced by the other project and shown as a shared subproject.
The next step is creating a new subproject file to represent the shared
subproject. In reality, a shared subproject is actually a new project which
shares the same archive as its original project.
Once you have selected a subproject you want to share and the project you
want to share it to, you can decide what type of subproject you want it to
be to complete the operation.
A shared subproject functions the same as an unshared subproject and is
accessible by the most commands.
127

Chapter 5: Project and Sandbox Operations
128
NOTE
When working with shared subprojects, Source Integrity uses the actual name
of the subproject in the file system, rather than its relative name in the project
hierarchy. This enhances the portability of change packages across different
projects.
You cannot import members into a shared subproject from its shared location.
Shared subprojects (out-of-tree subprojects) that were created in a previous
version of Source Integrity (Standard Edition) are detected as they are
accessed by Source Integrity Enterprise Edition without disrupting the
operation. The format of these subprojects is retained until you change or
update it to the new format by re-configuring it.
To add a shared subproject in the graphical user interface
1 With a Project or Sandbox view open, select the project or sandbox
you want to add the shared subproject to.
2 From a Project view, select Project > Subproject > Add Shared.
From a Sandbox view, select Sandbox > Subproject > Add Shared.
The Add Shared Subproject Wizard appears.
u s e r g u i d e

Working With Subprojects
3 In the Project to be Shared field, click Select to browse to the
subproject to add, or enter the path and name for the subproject, for
example, c:/Libra_Program/tools/project.pj.
The subproject you select in this step is the subproject you want to
reference.
4 Click Next.
The Specify the subproject to add panel appears.
5 In the Subproject Name field, browse or enter the path for the location
of the shared subproject.
The project you select in this step is the project that you want to share
the subproject (selected in step 3) to.
NOTE
The Subproject Name must be in-tree.
6 Click Next.
Click Finish to add the shared subproject without specifying a type.
The subproject is added as the default type. For information on the
default type, see your administrator.
The Specify Type of Subproject to Add panel appears.
129

Chapter 5: Project and Sandbox Operations
130
7 Select one of the following options for the type of shared subproject
you want to add:
Normal adds a subproject based upon the current state of the
subproject.
Variant adds a subproject based upon a specific revision of the
master project and is used for branching off the main
development path.
NOTE
From the Development Path Name list, select a development path
name, for example, Aurora_Beta_Variant.
The Variant option is unavailable if there are no available development paths.
To create a development path, see “Creating a Development Path” on page 147.
Build adds a static subproject based upon a specific revision of the
master project that is used for building or testing the project, but
not for further development.
To specify a revision to base the build project, do one of the
following:
Select Revision, and from the list select a project revision
number.
Select Label, and from the list select a project label.
u s e r g u i d e

Configuring a
Subproject
Working With Subprojects
Default adds a subproject based on the parent project type.
8 To accept the options, click Finish. To modify the options, click Back.
The shared subproject appears in the Project or Sandbox view with a
shared icon (Project view: or Sandbox view: ). For more
information, see “Project View” on page 457 or “Sandbox View” on
page 469.
Once you have created or added a subproject you can modify the type to
suit your needs. For example, you can change a normal subproject to a
build subproject in order to suspend development, or you can change a
variant subproject to a normal subproject to continue development on the
main trunk.
Any changes you make when configuring a subproject will affect the
project as a whole and any shared subprojects within it. Deltas reflecting
these changes appear in the Project or Sandbox view. Some of the
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.
Subproject that existed as members in the original version of the
subproject but do not exist in the configured subproject display as
former subprojects.
Resynchronize the subproject to resolve the differences.
When configuring shared subprojects it is important to remember that each
shared subproject is configured independently. This means that when you
configure a shared subproject that the re-configuration does not change all
instances of that subproject. For example, if the subproject tools.pj is
shared in the two projects, Aurora.pj and Libra.pj, a change to the
configuration of Aurora/tools.pj does not affect the configuration of
Libra/tools.pj.
Configured subprojects, or frozen subprojects that were created in a
previous version of Source Integrity (Standard Edition) are detected as
they are accessed by Source Integrity Enterprise Edition without
disrupting the operation. The format of these subprojects is retained until
you change or update it to the new format by re-configuring it.
131

Chapter 5: Project and Sandbox Operations
132
To configure a subproject in the graphical user interface or the Web
interface
1 With a Project or Sandbox view open, select the subproject you want
to configure.
2 In the GUI, from a Project view, select Project > Subproject >
Configure.
In the GUI, from a Sandbox view, select Sandbox > Subproject >
Configure.
In the Web, from a Project view, select Project > Configure Subproject.
The Configure Subproject dialog box is displayed.
3 Under Options, select the configuration type you want for the
subproject. The available types are:
Normal configures a subproject based upon the current state of the
subproject.
Variant configures a subproject based upon a specific revision of
the master project and is used for branching off the main
development path.
NOTE
From the Development Path Name list, select a development path
name, for example, Aurora_Beta_Variant.
The Variant option is unavailable if there are no available development paths.
To create a development path, see “Creating a Development Path” on page 147.
u s e r g u i d e

Dropping a
Subproject
Working With Subprojects
Build configures a static subproject based upon a specific revision
of the master project that is used for building or testing the
project, but not for further development.
To specify a revision to base the build project, do one of the
following:
Select Revision, and from the list select a project revision
number.
Select Label, and from the list select a project label.
Reset to default value configures a subproject to the parent project
type.
4 Click OK to complete the operation.
The subproject is re-configured.
Subprojects configured as a build subproject appear with a build
project icon (Project view: or Sandbox view: ), and the revision
or label that the build project is based on, for example, tools.pj
(1.1).
Subprojects configured as a variant subproject appear with a variant
project icon (Project view: or Sandbox view: ), and the
development path that the variant project is based on, for example,
tools.pj (release_1).
Subprojects configured as a normal subproject appear with the
standard project and sandbox icons.
Depending on what the default project type is, subprojects configured
as default projects, may or may not appear with a different icon.
If a subproject has outlived its usefulness or just does not belong in a
project anymore, you can remove it at any time. You can remove a
subproject through a Project view or through a Sandbox view. For more
details on removing a subproject through a Sandbox view, see “Dropping
Members From a Project” on page 172.
After you remove a subproject from a project, it is no longer listed as part
of the sandbox or master project, but the subproject’s 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.
133

Chapter 5: Project and Sandbox Operations
134
To drop a subproject in the graphical user interface
1 With the Manage Projects dialog box, or a Project or Sandbox view
open, select one or more subprojects to remove.
NOTE
In the Manage Projects dialog box, you can only drop one subproject at a time.
2 From the Manage Projects dialog box, click Drop.
From the Project view, select Project > Drop Members.
From the Sandbox view, select Sandbox > Drop Members.
The Drop Subproject dialog box is displayed.
3 Under Options, select Confirm Drop to have Source Integrity prompt
you to confirm the operation.
The Confirm Drop message appears.
If you did not select the Confirm Drop option on the Drop Subproject
dialog box, the Confirm Drop dialog box does not appear.
4 To remove the subproject, click Yes (for multiple subprojects, click Yes
to All).
The project is updated to reflect the removed subproject.
The subproject is removed from the project.
To retain the subproject, click No (for multiple subprojects, click No to
All).
u s e r g u i d e

Working With Sandboxes
Creating a
Sandbox
Working With Sandboxes
When you want to work with a project, you create a sandbox. A sandbox
resides on your local drive and is a mirror image of the project. Working in
a sandbox allows you to operate in your own workspace without
interfering with the work of others.
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.
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.
The following provides procedures for creating sandboxes—normal,
variant, and build—using the graphical user interface. You can also create
subsandboxes.
A subsandbox is a sandbox within a sandbox. Subsandboxes are typically
smaller components of a sandbox, such as documentation or graphic files.
NOTE
While it is possible to create more than one sandbox in a single directory it is
not recommended.
To create a sandbox in the graphical user interface
1 Do one of the following:
Select File > New Sandbox.
Click .
The Create Sandbox Wizard appears.
2 In the Project Name field, enter the path and name of the project, or
click Select.
If you have a Project view open, the project path and name appears in
the Project Name field. If you click Select, the Select One or More
Projects dialog box is displayed.
3 Select a project.
135

Chapter 5: Project and Sandbox Operations
136
4 Click Next.
The second panel of the Create Sandbox Wizard appears.
5 In the Sandbox Location field, enter the directory in which you want
to create the sandbox, or click Browse, then browse to a location on
your local drive.
6 Under Options, choose sandbox options by selecting check boxes.
The available options are:
Populate Sandbox adds working files to the sandbox.
Recurse into Subprojects creates subsandboxes recursively from
subprojects and populates the subsandboxes with working files.
If you choose not to recurse into subprojects when creating a
sandbox, subprojects are still created but they are not populated
with working files. To create working files for members at a later
date, use the Resynchronize command (see “Resyncing
Members” on page 197).
Line Terminator determines the type of ASCII character
Source Integrity recognizes as the end of a line of text: Native (or
automatic, the default setting), LF (or line feed, primarily for
UNIX applications), or CR/LF.
u s e r g u i d e

Working With Sandboxes
Make Sandbox Sparse creates a sandbox with no working files. A
sparse sandbox does not retain working files even when a
member is checked in, and continues to function this way
throughout its use.
View Sandbox After Creation displays the sandbox after it is
created.
Make Sandbox Shared creates a sandbox that is available for
sharing with other users (see “Sharing Sandboxes” on page 139).
7 Click Next.
If the directory you specify does not exist, a Confirm Create Sandbox
Location dialog box is displayed asking if you want to create the new
location. To create the path, click Yes. To change the sandbox location,
click No.
The third panel of the Create Sandbox Wizard appears.
8 Select the type of sandbox you want to create by clicking a sandbox
type option. The available types are:
Normal creates a sandbox based upon the current state of the
project.
137

Chapter 5: Project and Sandbox Operations
Importing a
Sandbox
138
Variant creates a sandbox based upon a specific revision of the
master project and is used for branching off the main
development path. For more information on variant sandboxes,
see “Creating Variant Sandboxes and Development Paths” on
page 146.
NOTE
From the Development Path Name list, select a development path
name, for example, Aurora_Beta_Variant.
The Variant option is unavailable if there are no available development paths.
To create a development path, see “Creating a Development Path” on page 147.
Build creates a static sandbox based upon a specific revision of the
master project that is used for building or testing the project, but
not for further development. For more information on build
sandboxes, see “Using Build Sandboxes” on page 150.
To specify a revision to base the build project, do one of the
following:
Select Revision, and from the list select a project revision
number, for example, 1.1.
Select Label, and from the list select a project label.
9 To accept the options, click Finish.
The sandbox appears in a Sandbox view (see “Sandbox View” on
page 469).
To modify the options, click Back.
You can also create a sandbox from the Registered Sandboxes view.
With the Registered Sandboxes view open, click Create. Specify the
server name and port number in the Specify Server Connection dialog
box, and click OK. The Create Sandbox Wizard appears. To finish
creating your sandbox complete previous steps 2 through 9.
When you create a sandbox, it is automatically registered with the Integrity
Server; however, sandboxes created with earlier versions of
Source Integrity must be imported to register them with the Integrity
Server.
u s e r g u i d e

Sharing
Sandboxes
NOTE
The master project of the sandbox must also be registered with the
Integrity Server before the sandbox is imported.
To import a sandbox in the graphical user interface
1 Do one of the following:
Select Tools > Manage Sandboxes.
Click .
The Registered Sandboxes view is displayed.
Working With Sandboxes
TIP
The Registered Sandboxes view supports standard shortcut menus. To display
the menu of actions you can perform, select a sandbox and right click.
Source Integrity displays the applicable shortcut menu.
2 Click Import.
The Select One or More Files dialog box is displayed.
3 Browse to the sandbox file on your local drive.
If your connection to the Integrity Server is disconnected while you
are browsing for a file, the file browser does not show any files or
directories.
4 Click Open.
The Specify Server Connection dialog box is displayed.
5 Specify the host name and port number for the server on which the
corresponding project resides.
6 Click OK.
The sandbox is added to the Registered Sandboxes view.
Source Integrity 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.
The following is the intended use for sandbox sharing:
1 There exists a common build location that contains files that
developers need to access in order to build their source before
checking it into the build.
139

Chapter 5: Project and Sandbox Operations
140
2 Users share the sandbox by importing it through the network or
mapped drive. The imported sandbox is by reference, so no working
files are stored on the users’ machines.
3 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
Source Integrity 8.6 or later.
Imported
Sandbox 1
References
Working Files
Shared Sandbox
Common
Location With
Working Files
Imported
Sandbox 2
References
Working Files
Sandbox Shared With Multiple Users
Users sharing sandboxes:
must select View > Scan for Changes 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
can see deferred operations in their sandbox views that were created
by other users, but those operations do not appear as entries in their
individual Change Package views for the change packages
corresponding to the deferred operations
u s e r g u i d e
Imported
Sandbox 3
References
Working Files

Working With Sandboxes
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 subsandboxes)
CAUTION
In a shared sandbox, to prevent overwriting another user’s changes, do not
make changes to working files for member revisions that are locked by another
user.
Configuring a Sandbox as Shared
For users to share a sandbox, the creator of the sandbox must first
configure the sandbox as shared. Only the sandbox creator can configure
the sandbox as shared. When a top-level sandbox is configured to be
shared, all subsandboxes are shared as well. Subsandboxes cannot be
individually configured to be shared or not shared.
To share out a sandbox in the graphical user interface
1 Do one of the following:
From a Sandbox view, select Sandbox > Properties > Sandbox
Information.
From the Registered Sandboxes view, select a sandbox. Then
click Information.
The Sandbox Information dialog box is displayed with the General
panel displayed.
2 Enable the Shared option.
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.
141

Chapter 5: Project and Sandbox Operations
142
3 To finish and share the sandbox, click OK.
If the Sandbox view is open, the title displays Shared. Otherwise, the
the title displays Shared the next time the sandbox is opened in a
Sandbox view.
Importing a Shared Sandbox
Access another user’s shared sandbox using the Import command. Do so by
browsing through the network to the user’s shared sandbox directory. For
more information on importing sandboxes, see “Importing a Sandbox” on
page 138. When you share another user’s sandbox, no working files are
stored on your local machine.
Only import another user’s sandbox through the network if that sandbox
has sharing enabled. For more information, see “Configuring a Sandbox as
Shared” on page 141.
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 graphical user interface
1 Do one of the following:
From a Sandbox view, select Sandbox > Properties > Sandbox
Information.
From the Registered Sandboxes view, select a sandbox. Then
click Information.
The Sandbox Information dialog box is displayed with the General
panel displayed.
2 Clear the Shared option selection.
u s e r g u i d e

Dropping a
Sandbox
3 To finish and remove sharing, click OK.
Working With Sandboxes
The sandbox is no longer shared. If the Sandbox view is open, Sharing
is removed from the title. Otherwise, the next time you open the
Sandbox view, Sharing does not appear in the title bar.
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.
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
Integrity Server. Once a sandbox is dropped, it cannot be accessed with
Source Integrity. However, the sandbox is not deleted and you can import
it again if you want it to be accessible in Source Integrity.
To drop a sandbox in the graphical user interface
1 Do one of the following:
Select Tools > Manage Sandboxes.
Click .
The Registered Sandboxes view is displayed.
TIP
The Registered Sandboxes view supports standard shortcut menus. To display
the menu of actions you can perform, select a sandbox and right click.
Source Integrity displays the applicable shortcut menu.
2 Select the sandbox you want to drop.
3 Click Drop.
4 Confirm that you want to drop the sandbox by clicking OK.
The Drop Sandbox dialog box is displayed.
143

Chapter 5: Project and Sandbox Operations
Opening or
Viewing a
Sandbox
144
5 From the Delete list, select a delete option.
Nothing does not delete any files from the sandbox directory.
Sandbox Members Only deletes the sandbox members.
Entire Sandbox Directory deletes the sandbox directory and
all of its contents.
CAUTION
If you select the Entire Sandbox Directory option, Source Integrity
deletes all files in the sandbox directory and all files in subdirectories, if any
exist. This includes files not created by Source Integrity.
6 To drop the sandbox, click OK (for multiple sandboxes, click OK to
All).
The sandbox is removed from the list of registered sandboxes.
7 Close the Registered Sandboxes view.
Opening a sandbox in the graphical user interface allows you to view and
work with the sandbox and its members.
The Sandbox view displays the members and subsandboxes of a single
sandbox.
To see a list of recently used files, select File from the menu bar. Recently
used files displays in a numbered list at the bottom of the File menu.
To open a sandbox in the graphical user interface
1 Do one of the following:
Select File > Open Sandbox.
Click .
The Select a Sandbox dialog box is displayed.
u s e r g u i d e

Viewing Which
Sandbox
Locked a
Member
2 To select a sandbox type, click a sandbox type tab.
Regular is a sandbox used for regular development.
Working With Sandboxes
Variant is a sandbox used for branching off the main development
path of another project.
Build is a sandbox based upon a specific revision of a project, but
is used for building or testing the project, not for further
development.
3 Select a sandbox from the displayed sandbox list.
4 Click OK.
The sandbox opens in a Sandbox view.
You can also open a sandbox from the Registered Sandboxes view.
With the Registered Sandboxes view open, select the sandbox you
want to open, and click Open, or select Open from the shortcut menu.
The sandbox appears in a sandbox view (see “Sandbox View” on
page 469).
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, see “View
Preferences” on page 61.
145

Chapter 5: Project and Sandbox Operations
Creating Variant
Sandboxes and
Development
Paths
146
While a regular sandbox is based on the current state of the project, a
variant sandbox is based on a previously checkpointed revision of the
project. When you create a variant sandbox, you choose a checkpoint
(snapshot) of your project and use it as the starting point for a new branch
of development. Source Integrity allows you to do this by defining a new
development path.
NOTE
You must define the development path before creating the variant sandbox.
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.
Source Integrity 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 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.
Development paths are 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
Variant sandboxes pointing to a post-release development path allow you
to make changes to a previous revision of a project. Any fixes, patches, or
changes you check in go into a branch and do not affect the main project,
unless you later choose to merge them.
u s e r g u i d e

Working With Sandboxes
Preventing Conflicts With Other Development Paths
Development paths can conflict when developers working on different
paths need to work on the same revision of a file. There is also the potential
for conflict when development paths access the same member histories.
For example, the current version of a project includes utility.dll,
version 1.4 and the variant sandbox contains utility.dll, version 1.3.
Both versions are stored in the same member history.
Other potential conflicts include:
a developer with a variant sandbox locks revisions needed by
developers working in regular sandboxes
work on one development path locks out those working on a different
development path
To prevent potential conflicts, Source Integrity assumes that locking a
revision is appropriate when you check out a revision when working in a
variant sandbox. You are further prompted to branch the member history
when you check out a revision with a potential conflict, for example:
The project Apex.pj, version 1.2 was checkpointed at version 1.2 and
included utility.dll version 1.2 and library.lib version 1.3.
A development path is created for Apex.pj, version 1.2.1.1 and
includes the same file versions for utility.dll (version 1.2) and
library.lib (version 1.3).
Branching the member history gives each development path its own copy
of the revision.
Creating a Development Path
A variant sandbox uses a project checkpoint as the starting point for new
development. In Source Integrity, you define a new development path for
the variant sandbox.
The development path:
identifies a new direction of development
includes a new revision history
keeps changes separate from the main development path or trunk
You must first create and name the development path, and then create the
variant sandbox.
147

Chapter 5: Project and Sandbox Operations
148
To create a development path in the graphical user interface and Web
interface
1 With a Project, Project History, or Sandbox view open, select the
project you want to create the development path.
To create a variant sandbox using the graphical user interface, see
“Creating a Sandbox” on page 135. from. For more information on
working with subprojects, see “Working With Subprojects” on
page 124.
NOTE
You cannot create a development path based on a variant subproject or build
subproject.
2 In the GUI, from a Project view, select Project > Development Path >
Create.
3 In the Web, from a Project view, select Project > Create Development
Path.
From a Project History view, select History > Create Development Path.
From a Sandbox view, select Sandbox > Development Path > Create.
The Create Development Path dialog box is displayed.
u s e r g u i d e

Removing a
Development
Path
Working With Sandboxes
4 Under Revision, click the desired tab, then modify the Create
Development Path options.
The Selection tab allows you to select the revision to create a
development path from.
To create a development path from a particular type of revision, select
the Pre-Defined Revision option, then choose a revision type from the
list.
Head creates a development path from the head revision in the
project.
Trunk Tip creates a development path from the latest revision in
the trunk, independent of default branch settings.
To create a development path from a specific revision, select the
Specific Revision option, then click the Revisions or Labels tabs to
choose the revision.
The Revisions tab allows you to create a development path from a
specific revision.
The Labels tab allows you to create a development path from a
specific labeled revision.
5 In the Development Path Name field, enter a name for the development
path, for example, Aurora_Beta_Variant.
6 To create the development path, click OK.
The development path is created.
Once a development path is no longer needed or useful, you can remove it
at any time.
CAUTION
If you remove a development path that is referenced by a variant sandbox, you
cannot open that variant sandbox.
To remove a development path in the graphical user interface and
Web interface
1 With a Project, Project History, or Sandbox view open, select the
project.
149

Chapter 5: Project and Sandbox Operations
Using Build
Sandboxes
150
2 In the GUI, from a Project view, select Project > Development Path >
Remove.
In the Web, from a Project view, select Project > Remove Development
Path.
From a Project History view, select History > Remove Development
Path.
From a Sandbox view, select Sandbox > Development Path > Remove.
The Remove Development Path dialog box is displayed.
3 From the Development Path list, select a development path to remove.
For more information, see “Controlling Projects” on page 258.
4 To remove the development path, click OK.
The development path is removed.
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, 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.
A build sandbox is a sandbox associated with a particular project revision,
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.
To create a build sandbox, see “Creating a Sandbox” on page 135. To view
a build project, see “Opening or Viewing a Project” on page 121.
Within a build sandbox, you can:
change labels and states
resynchronize your sandbox
compare a member revision in the build sandbox to another revision
u s e r g u i d e

Working With Sandboxes
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 project revisions, such as changes to a
project since it was last checkpointed
When you create a build sandbox, you choose the project revision on
which to base the build sandbox.
However, with a build sandbox, you cannot:
check out, lock, or check in members
add or remove members
set the development path
calculate dependencies
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.
151

Chapter 5: Project and Sandbox Operations
152
u s e r g u i d e

Member Operations
6
KEY TERMS: member, revision, defer, resync, rename, lock, submit, resynchronize
This chapter describes the Source Integrity member related features you
will use in your day-to-day activities, such as adding and checking out
members.
The tasks you can perform are restricted by the permissions assigned to
you by your administrator. If you find you are unable to perform necessary
operations, you must contact the administrator responsible for
Source Integrity at your site to review the permissions assigned to you.
NOTE
If your administrator has assigned you a new set of permissions, you must
update your permissions by disconnecting your Source Integrity client and
then reconnecting to Integrity Server. An out-of-date permission set may cause
unpredictable behavior when attempting to open projects or perform other
tasks.
This chapter provides details on the following:
“Managing Project Members” on page 154
“Performing Member Operations” on page 176
“Deferring Member Operations” on page 200
“Comparing Differences” on page 205
“Using Keywords” on page 207
153

Chapter 6: Member Operations
Managing Project Members
Displaying
Non-Members
154
You can manage project members by adding them to a project, importing
them into Source Integrity, or dropping them from a project.
From Source Integrity, you can view non-member files residing in your
sandbox directory. The Non-Members view is useful when used
recursively to identify all of the files that need to be placed under source
control. By default, former members are not displayed in the
Non Members view (to modify the default view settings, see “View
Preferences” on page 61). You cannot display multiple Non-Members
views for the same sandbox.
The Non-Members view does not display files that are:
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
Non-members can only be viewed in a sandbox context, and not from any
project view operation.
To display non-member files located in the sandbox directory in the
graphical user interface
1 From a Sandbox view with a project, subproject, or member selected,
select Sandbox > View Non-Members.
The Non-Members view is displayed.
2 By default, if no filter criteria is specified, all non-members are
displayed. To specify filter criteria, see “Filtering Non-Member Files”
on page 156.
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.
u s e r g u i d e

Managing Project Members
The Non-Members view displays the following information:
Closest Project displays the project or subproject, with file path,
corresponding to the sandbox that is closest to the directory
containing the file.
Closest Sandbox displays the sandbox or subsandbox, with file
path, that is closest to the directory containing the file.
Member ID displays the default member name for the file as it
would appear if it was added to the nearest project. In the case
where the nearest project is a subproject, the relative path is
displayed with the member name.
Absolute Path displays the absolute file path of the file.
Size displays the size of the file in bytes.
Last Modified displays the date that the file was last modified.
You can modify which columns appear in the Non-Members view by
changing the Non-Members view preferences. For more information,
see “View Preferences” on page 61. You can also right-click column
headers and select columns to view.
3 From the Non-Members view, you can perform the following
operations:
To add non-member files to the project, select the member in the
list, then do one of the following:
Select Non-Member > Add.
Click .
For more information, see “Adding Members to a Project” on
page 157.
To delete non-member files from the sandbox directory, select the
members in the list, then do one of the following:
Select Non-Member > Delete.
Click .
To edit non-member files, select the members in the list, then do
one of the following:
Select Non-Member > Edit.
Click .
155

Chapter 6: Member Operations
156
To exclude non-members by name, including non-members in
subdirectories, select the non-member files in the list; then select
Non-Member > Exclude with Name. Each file name appears in the
Exclude panel in the Non-Member Filter the next time it is
opened, though the information does not persist once the Non-
Member view is closed.
To exclude non-members by file extension, select the nonmembers
in the list, then select Non-Member > Exclude with
Extension. Files that do not have an extension are not excluded.
The file extension appears in the Exclude panel in the Non-
Member Filter the next time it is opened, though the information
does not persist once the Non-Member view is closed. The
wildcard (*) is used to specify all files of a specified extension, for
example, *.java.
To change the filter criteria (include and exclude settings), do one
of the following:
Select View > Filters.
Click .
For more information, see “Filtering Non-Member Files” on
page 156.
To refresh the contents of the view and display non-members
further added to the sandbox directory, select View > Refresh.
TIP
To add selected non-member files to a project or subproject, with a Sandbox
view open, drag the files from the Non Members view to the sandbox or
subsandbox that corresponds to that project or subproject to which you want to
add the project. Subdirectories that do not correspond to subprojects are not
maintained.
Filtering Non-Member Files
You can add filters to determine what file types and folders are displayed
in the Non-Member view.
To filter non-member files in the graphical user interface
1 Select View > Filters.
The Non-Member Filter dialog box is displayed with the Include panel
displayed.
u s e r g u i d e

Adding
Members to a
Project
NOTE
Managing Project Members
If filters are specified in the Non-Members view preferences, those filter
settings appear in the Non-Member Filter dialog box. Only modifications made
to the filter settings in the Preferences Configuration dialog box are saved. For
more information, see “View Preferences” on page 61.
The Include panel displays the Files and Directories tabs. You can add
any combination of files or directories to appear in the Non-Member
view by adding them from the Include panel. By specifying files types
to include, all file types not specified are excluded. To include all
possible file types, clear the list.
Similarly, on the Exclude panel, you can add files or directories to the
exclude list, thereby preventing them from appearing in the
Non-Member view. All file types not specified are included.
In the event of a conflict, the values in the Exclude panel supersede the
values in the Include panel.
2 To add a file or directory, click the appropriate tab to display the
panel.
3 In the text entry field, enter the name of the file or directory, then click
Add.
TIP
To specify all files with a specific file extension, use the wildcard (*), for
example, *.java.
To edit the name of the file or directory, select the name in the list,
then click Edit.
To remove a file or directory, select the name in the list, then click
Remove.
4 When you are finished, click OK to save the filter settings.
Once you create a project, you can add files to it, making them members of
that project.
A project member is any file that is included in a project. Project members
are displayed in the Project view.
In the graphical user interface you can add members through the sandbox.
In the Web interface, because sandboxes do not exist, you can add
members through the project only.
157

Chapter 6: Member Operations
158
Once you have added members to your project, you can check them out for
editing, and then check them in to preserve your changes.
Project members may be one of following types of files: archived (files
under Source Integrity revision control), or subproject (another
Source Integrity project).
NOTE
Adding a large number of members, or a directory with a large number of
members to a Source Integrity sandbox may cause the client to stall if the
Integrity Server does not have the recommended system configuration.
Consult your administrator for more information.
A batch server-side utility, the si import command, is available for
adding files. For more information on this advanced administration task,
see the Integrity Server Installation and Administration Guide.
You can import members in the graphical user interface. For information
on importing members, see “Importing Members” on page 169.
You can also add members that are dropped from a project, using the
working file as the file selection. If no working file exists, use the Add
Members From Archive command to add the member from an archive
located on the server (see “Adding Members From Archive to a Project” on
page 166).
You can also 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 200.
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.
To add members in the graphical user interface
1 With a Sandbox view open, select the sandbox or subsandbox you
want to add members to.
u s e r g u i d e

2 Do one of the following:
Select Sandbox > Member > Add New Members.
Click .
The Add Members Wizard appears.
3 To add a list of files to the project, click Add File.
Managing Project Members
4 To add a directory of files to the project, click Add Directory.
The Select One or More Members to Add to the Sandbox dialog box is
displayed.
5 Select one or more files from the displayed file list, navigating to the
desired directory if necessary.
By default, Non-Members is selected in the Files of type list, which
displays files that are located in the sandbox directory, but are not
members.
TIP
To select multiple files in the graphical user interface, hold CTRL and click the
left mouse button while highlighting each file you want to add.
6 Click Open.
The files are added to the members list. To remove files, select the files,
then click Remove.
159

Chapter 6: Member Operations
160
7 To add members recursively to the project, select Recurse Into
Directories.
8 To create subprojects, select Create Subproject.
9 To complete the operation, click Finish. To make changes, click Back.
The Create Archive dialog box is displayed.
10 Modify the following Create Archive options as necessary:
In the Archive Description field, describe the purpose of the
member archive.
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.
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 more information, see “Creating a Change
Package” on page 217.
In the Author field, if necessary, enter your user name. The user
name specified in the Add Members command configuration
appears by default.
u s e r g u i d e

Managing Project Members
In the Revision Number field, if necessary, enter a revision
number for the member. Source Integrity creates the revision
number 1.1 by default.
In the Data Type field, select a file data type from the list. The
archive is stored in the specified format. The available options are:
Auto means the file data type is determined automatically by
Source Integrity. For binary files less than 16K, specify the
Binary file data type.
Text is the file format expected by text file editors.
Binary is file data type containing unprintable characters or
lines too long to be handled by text editors.
In the field for On Existing Archive, the following options apply in
the event that Source Integrity finds an existing archive for the
member you propose to add:
Query User causes Source Integrity to ask you for
confirmation on the action to be taken.
Share Archive causes Source Integrity to use the existing
archive for the new member.
Create New Archive causes Source Integrity to create a
new archive for the new member. Source Integrity
automatically generates the archive name and leaves the old
archive unmodified.
Cancel causes Source Integrity to cancel the operation.
To set the timestamp of the revision in the history to the
timestamp of the working file, rather than the time the member
was added, select the Save Working File Timestamp option.
To close the associated change package, select the Close Change
Package option.
To replace literal values in the revision with keywords, select the
Unexpand Keywords option.
To defer adding the member to the project, select Defer Add. This
delays the add operation in the project until the deferred
operation is submitted (see “Submitting Deferred Operations” on
page 202). The operation in the sandbox still takes place
immediately and Source Integrity displays the icon.
If the change package reviews are mandatory, select this option to
create a pending entry for this operation at the time of change
package submission. If this option is not enabled, Source Integrity
161

Chapter 6: Member Operations
162
creates the pending entry at the completion of this procedure. For
more information, see “Change Package Review Process” on
page 240. When a deferred add member operation is submitted as
part of a review, a pending member is created (see “Working
With Pending Revisions” on page 335).
To lock the revision, select the Lock Revision option.
To keep the working file of a newly added member, select the
Retain Working File option.
11 To accept the information, click OK. To accept the information for
multiple members, click OK to All.
If you are adding a dropped member and the member’s archive still
exists, the Existing archive detected dialog box is displayed informing
you that an archive already exists for the member.
12 Select from the following available options:
To add the member and associate it with the existing archive,
select Share the existing archive.
To create a new archive for the member, select Create new archive.
A new archive name is generated automatically and the old
archive is left unmodified.
To cancel the operation and not associate or create an archive,
select Cancel this operation.
13 To complete the operation, click OK.
To complete an operation affecting multiple files, click OK to All.
14 Repeat steps 1 to 12 for the remaining members, if necessary.
The newly added members appear in your Sandbox view.
u s e r g u i d e

To add members in the Web interface
Managing Project Members
1 With the project you want to add a member to open, do one of the
following:
Select Project > Add Member.
Click .
The Non-Member Selection dialog box is displayed.
2 In the field, enter the name of the new member, including the file
extension. For example, features.gif.
3 Click OK.
The Create Archive dialog box is displayed.
4 Modify the following Create Archive options as necessary:
In the Archive Description field, enter a description of the
member.
163

Chapter 6: Member Operations
164
IMPORTANT
The Change Package options, such as Close Change Package, appear only
if change packages are enabled.
In the Author field, if necessary, enter your user name. The user
name specified in the Add Members command configuration
appears by default.
In the Revision Number field, if necessary, enter a revision
number for the member. Source Integrity creates the revision
number 1.1 by default.
In the Data Type field, select a file data type from the list. The
archive is stored in the specified format. The available options are:
Auto means the file data type is determined automatically by
Source Integrity.
Text is the file format expected by text file editors.
Binary is file data type containing unprintable characters or
lines too long to be handled by text editors.
In the field for On Existing Archive, the following options apply in
the event that Source Integrity finds an existing archive for the
member you propose to add:
Query User causes Source Integrity to ask you for
confirmation on the action to be taken.
Share Archive causes Source Integrity to use the existing
archive for the new member.
Create New Archive causes Source Integrity to create a
new archive for the new member. Source Integrity
automatically generates the archive name and leaves the old
archive unmodified.
Cancel causes Source Integrity to cancel the operation.
In the field for Close Change Package, select one of the following
options:
Yes causes Source Integrity to close the associated change
package.
No causes Source Integrity to keep the associated change
package open.
u s e r g u i d e

Managing Project Members
Confirm causes Source Integrity to ask you for confirmation
on the action to be taken.
To lock the revision, select the Lock Revision option.
To replace literal values in the revision with keywords, select the
Unexpand Keywords option.
5 To accept the information, click OK.
The Specify Source File dialog box is displayed.
6 In the field, enter or browse to the source file for the member you want
to add and click OK.
If you are re-adding a dropped member and the member’s archive still
exists, the Existing archive detected dialog box is displayed informing
you that an archive already exists for the member.
Select from the following available options:
To add the member and associate it with the existing archive,
select Share the existing archive.
To create a new archive for the member, select Create new archive.
A new archive name is generated automatically and the old
archive is left unmodified.
To cancel the operation and not associate or create an archive,
select Cancel this operation.
165

Chapter 6: Member Operations
Adding
Members From
Archive to a
Project
166
7 Click OK.
8 Repeat steps 2 through 6 for other members you want to add to the
project.
The member is added and appears in your Project view.
The Add Members From Archive command can be used for the following:
Add previously dropped members without requiring a sandbox
working file, while preserving the member history.
Add a member that shares the history of another existing member,
where the source member can be located in another project from the
added member.
Note the following about the command:
It can be deferred when performed from a sandbox.
It may be part of change package review (displayed as pending
members in the project).
It supports multiple selection of archives using the wizard.
To add members from archive in the graphical user interface
1 Do one of the following:
With a Sandbox view open, select the sandbox or subsandbox you
want to add members to.
With a Project view open, select the project or subproject you
want to add members to.
2 Where applicable, do one of the following:
Select Sandbox > Member > Add Members From Archive.
Select Project > Member > Add Members From Archive.
The Add Members From Archive wizard is displayed.
u s e r g u i d e

Managing Project 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 is displayed.
Select the archives corresponding to the members you want to
add to the project. Archives are identified by the icon, and by
default are located in the subdirectory named rcs.
To add the selection as an entry in the list, click OK.
In the first field, enter the name that represents the member being
added. Then enter 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 in the
following tabular list:
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.
167

Chapter 6: Member Operations
168
To remove an entry from the list, click Remove. Repeat to remove
additional entries.
4 When you are finished specifying entries to add, click Finish.
The Add Member From Archive dialog box is displayed.
5 The archive location is displayed in the Archive Location field. To
change the location, specify a new location in the field, or click Locate
Archive to select it.
6 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 more information, see “Creating a Change Package” on page 217.
7 To specify the revision for the added member, in the Revision Number
field, enter the revision number.
8 If desired, select from the following options:
To create subprojects for each subdirectory encountered when
adding members, select Create Subprojects.
To recursively add members that exist in the specified directory
location, select Recurse into Directories.
To close the associated change package after the operation is
complete, select Close Change Package.
To delay the add operations in the project until the deferred
operation is submitted, select Defer Add From Archive (only
available from Sandbox view).
If reviews are mandatory and this option is not selected, a
pending member (and a pending change package entry) is created
when the operation is completed. For more information, see
“Change Package Review Process” on page 240.
u s e r g u i d e

Importing
Members
Managing Project Members
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. The member appears in the
Sandbox or Project view.
When you add a member, it is automatically registered with the Integrity
Server; however, members added with earlier versions of Source Integrity
or server resident files must be imported to register them with the Integrity
Server.
NOTE
The master project must be registered with the Integrity Server before the
member is imported.
You cannot import members into a shared subproject. For more information on
shared subprojects, see “Adding a Shared Subproject” on page 127.
Do not use the Import Member command to add members that are dropped
from a project. Instead, use the Add Members From Archive command (see
“Adding Members From Archive to a Project” on page 166).
To import a member in the graphical user interface
1 Do one of the following:
From a Project view, select Project > Member > Import Members.
From a Sandbox view, select Sandbox > Member >
Import Members.
The Import Members Wizard is displayed.
169

Chapter 6: Member Operations
170
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 is
displayed.
3 Select one or more files from the displayed list, navigating to the
desired directory if necessary. To select multiple files in the graphical
user interface, hold CTRL and click the left mouse button while
highlighting each file you want to add.
NOTE
If your connection to the Integrity Server is disconnected while you are
browsing for a file, the file browser does not show any files or directories.
4 Click Open.
The files are added to the members list.
To remove files, select the files, then click Remove.
5 Click Next to specify options, or click Finish to import files without
specifying options.
The next panel of the Import Members Wizard appears.
u s e r g u i d e

Managing Project Members
6 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 more information, see “Creating a Change Package” on page 217.
7 Under Options, you can specify the following information:
In the Author field, if necessary, enter your user name. The user
name specified in the command configuration appears by default.
In the Data Type field, select a file data type from the list. The
archive is stored in the specified format. The available options are:
Auto: file type determined automatically by Source Integrity.
Text: file format expected by text file editors.
Binary: file containing unprintable characters or lines too
long to be handled by text editors.
In the Revision Number field, if necessary, enter a revision
number for the member. Source Integrity creates the revision
number 1.1 by default.
In the Description field, enter a description of the member.
To create subprojects, select the Create Subprojects option.
To import members that exist in the specified directory location
recursively, select the Recurse into Directories option.
171

Chapter 6: Member Operations
Dropping
Members From
a Project
172
To close the change package, select the Close Change Package
option.
To replace literal values in the revision with keywords, select the
Unexpand Keywords option.
To defer importing the member into the project, select Defer
Import (only available when the operation is performed from a
Sandbox view). This delays the import operation in the project
until the deferred operation is submitted (see “Submitting
Deferred Operations” on page 202). The operation in the sandbox
still takes place immediately.
If the change package reviews are mandatory, select this option to
create a pending entry for this operation at the time of change
package submission. If this option is not enabled, Source Integrity
creates the pending entry at the completion of this procedure. For
more information, see “Change Package Review Process” on
page 240. When a deferred import member operation is
submitted as part of a review, a pending member is created (see
“Working With Pending Revisions” on page 335).
To complete the operation, click Finish. To make changes, click Back.
The members appear in the Project or Sandbox view.
If a member has outlived its usefulness or just does not belong in a project
anymore, you can remove it at any time.
In the graphical user interface, you can remove a member through a
Sandbox view, or through a Project view. For more details on removing
members through a Project view, see “Dropping a Subproject” on
page 133.
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 member’s 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. Source Integrity
retains the member history for former members as part of the project.
Depending on the options you select when dropping the member,
Source Integrity can also delete the member’s working file and close any
associated change package.
u s e r g u i d e

NOTE
Managing Project Members
You cannot check in a member that is associated with a deferred drop
operation.
To drop a member in the graphical user interface
1 With a Project or Sandbox view open, select one or more members to
remove from the project or sandbox.
2 From a Project view, do one of the following:
Select Project > Drop Members.
Click .
From a Sandbox view, do one of the following:
Select Sandbox > Drop Members.
Click .
The Drop Member dialog box is displayed.
3 Choose the options you want to apply by selecting a check box.
IMPORTANT
The Change Package options, such as Close Change Package, appear only
if change packages are enabled.
The Drop Member options are:
Change Package displays the associated change package, if any.
Delete Working File deletes the working files of the members
being dropped.
173

Chapter 6: Member Operations
174
Confirm Drop prompts you to confirm the drop for each selected
member.
Defer Drop Member delays the drop operation in the project until
the deferred operation is submitted (see “Submitting Deferred
Operations” on page 202). The operation in the sandbox still takes
place immediately and Source Integrity displays the icon.
If the change package reviews are mandatory, select this option to
create a pending entry for this operation at the time of change
package submission. If this option is not enabled, Source Integrity
creates the pending entry at the completion of this procedure. For
more information, see “Change Package Review Process” on
page 240.
Close Change Package closes any associated change package.
For information on the Integrity Manager integration see, “The
Integrity Manager Integration” on page 371.
4 To drop the selected member, click OK. To drop multiple members,
click OK to All.
IMPORTANT
If change packages are enabled, the Associate Change Package with dropped
member dialog box is displayed.
The project or sandbox is updated to reflect the removed member, and
the member is removed from the project.
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 197.
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 Do one of the following:
Select Project > Drop Members.
Click .
The Drop Member dialog box is displayed.
u s e r g u i d e

Managing Project Members
3 Choose the options you want to apply by selecting from the drop
down list or a check box.
The Drop Member options are:
Change Package displays the associated change package, if any.
Confirm Drop prompts you to confirm the drop for each selected
member.
Close Change Package closes any associated change package.
Select one of the following options:
Yes causes Source Integrity to close the associated change
package.
No causes Source Integrity to keep the associated change
package open.
Confirm causes Source Integrity to ask for confirmation
about the action to be taken.
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 is displayed.
To drop the selected member(s), click Yes. To cancel the operation,
click No.
IMPORTANT
If change packages are enabled, the Associate Change Package with dropped
member dialog box is displayed. For information on the Integrity Manager
integration see, “The Integrity Manager Integration” on page 371.
175

Chapter 6: Member Operations
Performing Member Operations
Selecting
Members
176
The member is dropped from the project. The project is updated to
reflect the dropped member.
During development, operations can be performed on project 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
Source Integrity commands.
To select specific members (graphical user interface only)
1 With a Project or Sandbox view open, do one of the following:
Select View > Select.
Click .
The Select Members dialog box is displayed.
2 Choose the selection criteria you want to use by selecting a check box.
The available options are:
All Members selects all visible members.
u s e r g u i d e

Performing Member Operations
Changed Members selects members that have specific changes to
them.
To choose all members that have changes, from the Changed
Members list, select All Changes.
To choose all members that have working file changes, from the
Changed Members list, select Working File Changes.
To choose members whose working file revision is different from
the member revision, from the Changed Members list, select Out
of Sync Members.
To choose members that have a new revision available, select New
Revision Available from the Changed Members list.
Members Locked By selects members locked by a specific user.
To choose members locked by you, select from the Members
Locked By list.
To choose members locked by any user, select from the
Members Locked By list.
To choose members locked by a specific user, select a user name,
for example, , from the Members Locked By list.
Members With Label selects members with a specific label. Select a
label from the Members With Label list.
To choose members with any label, select from
the Members With Label list.
Members With State selects members with a specific state. Select a
state from the Members With State list.
Members With Attribute selects members with a specific attribute.
Select an attribute from the Members With Attribute list.
Deferred Items selects members with a deferred operation
associated with it. Select a deferred operation from the Deferred
Items list.
Frozen Members selects all frozen members (members that are in
a state that prevents changes being made to the member
information).
Members With Name selects members with a specific name. Enter
a member name in the Members With Name field. Wildcards such
as ? and * are supported.
177

Chapter 6: Member Operations
Checking Out a
Member
178
Working revision branched from Member Revision selects
members where the working file is on a branch from a given
development path that is not the trunk development path.
Members on Branch selects only members that are off the main
development trunk.
Pending Operations selects members with pending operations
associated with them. Select the pending operation from
the Pending Operations list.
NOTE
All options only apply to visible members. Members in unexpanded directories
and subprojects are not selected.
3 If two or more criteria are selected, they can be joined using the
Logical AND or Logical OR option.
4 To accept the selection criteria, click OK.
The members are selected in the Project or Sandbox view.
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, Source Integrity does not perform the check out a
second time. While the check out dialog does appear, the original check out
stands.
If you already have a member checked out, and you make changes, and
then attempt to check out the member a second time, the Confirm Working
File Update dialog box is displayed. If you want to retain your changes in
the working file, click Yes (Yes to All for multiple members). If you do not
want to retain your changes in the working file, click No (No to All for
multiple members).
In the Source Integrity 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.
u s e r g u i d e

To check out a member in the graphical user interface
Performing Member Operations
1 With a Sandbox or Member History view open, select one or more
members to check out.
2 From the Sandbox view, do one of the following:
Select Member > Check Out.
Click .
From the Member History view, do one of the following:
Select History > Check Out.
Click .
The Check Out dialog box is displayed.
3 Click the desired tab, then modify the check out options. For more
information, see “Check Out Options” on page 182.
179

Chapter 6: Member Operations
180
NOTE
If the change packages are enabled, the Change Package options appear on the
General tab.
4 To check out a single selected member, click OK. To check out all
selected members, click OK to All.
The member is checked out for editing, indicated by a lock icon, who
locked the revision, and when it was locked.
For information on advanced check in and check out operations, see
“Branching and Merging Revisions” on page 337.
To check out a member in the Web interface
1 With a Project or Member History view open, 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 check out cause an error.
2 From the Project view, do one of the following:
Select Member > Check Out
Click .
From the Member History view, do one of the following:
Select History > Check Out.
Click .
The Check Out dialog box is displayed.
u s e r g u i d e

Performing Member Operations
3 Click the desired tab, then modify the check out options. For more
information, see “Check Out Options” on page 182.
NOTE
If the change packages are enabled, the Change Package options appear on the
General tab.
4 To check out the member, click OK.
The File Download dialog box is displayed.
NOTE
Once you have reached the file download stage of the check out 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 have cancelled the file download, select the
member by clicking the corresponding check box and then select Member >
Unlock.
181

Chapter 6: Member Operations
182
5 To download the member, select either 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:
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 is displayed. 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 is displayed. Specify a location for the
member and click Save.
The member is checked out for editing, indicated by a lock icon, who
locked the revision, and when it was locked.
Check Out Options
Check Out Dialog Box Tab Revision to Check Out Options
Selection Specifies which revision of the member to check out.
To check out a pre-defined revision, click Pre-Defined Revision, then select a
revision type from the list. The available options are:
Member checks out the member revision, that is, the revision shown in the
Sandbox view (this is the default). Head checks out the head revision. Trunk
Tip checks out the latest member revision in the trunk. Member Branch Tip
checks out the latest revision along the member’s current branch of development.
To check out the latest revision, select Specific Revision. The Specific Revision
option selects the most recent revision by default and displays it in brackets, for
example, (1.1).
To check out a revision by state, click Latest revision with State, then select a
state from the list. The options in the list depend on the states configured by your
administrator. This option is only available when Promotion is enabled by your
administrator and is only visible in the graphical user interface.
Revisions Allows you to select a specific member revision to check out. Select a revision
from the member history.
Labels Allows you to select a revision to check out by label. Select a label from the label
list.
u s e r g u i d e

Check Out Dialog Box Tab Revision to Check Out Options
Project allows you set the member revision for the following options:
Performing Member Operations
Member revision on Variant allows you to make a specific variant revision the
member revision.
Member revision on a Project Build allows you to make a specific build revision
the member revision.
General Specifies the following general check out options:
Lock Revision checks out a writable working file and ensures that other users
cannot make changes to the revision by locking the revision. A revision must be
checked out locked if strict locking is enabled, and you intend to make changes
to it.
Overwrite Working File if Changed (graphical user interface only) overwrites the
working file even if it is modified.
Overwrite if Deferred Operation Pending (graphical user interface only)
overwrites the working file if the file has changed and there is a deferred
operation pending on the member.
Change Package options, appear only when change packages are enabled.
Line Terminator (Web interface only) determines the type of line terminator
Source Integrity uses when dealing with members: lf (or line feed, primarily for
UNIX applications), or crlf.
Advanced Specifies the following advanced check out options:
Update Member Revision causes the revision you check out to become the new
member revision of the project. For example, if the current project member is
listed as Revision 2.3 and you check out Revision 1.7 with the Update Member
Revision option selected, Revision 1.7 replaces Revision 2.3 as the member
revision of the project.
Force Creation of New Branch causes Source Integrity to force the creation of a
new branch on check out.
Merge Working File if Changed (graphical user interface only) automatically
merges any changes from the revision being checked out into the working file.
Restore Revision Timestamp (graphical user interface only) sets the timestamp
of the working file, to which the revision is checked out, to the date and time of
the revision in the history. If this option is not set, the working file’s timestamp is
set to the current date and time.
Create Branch if Variant causes Source Integrity to create a branch off of the
revision you are checking out, if you are working in a variant sandbox and this is
the first time the member is checked out. This reduces the possibility of locking
conflicts with the member while work is being done in the variant and regular
sandboxes.
In the Web interface only, select from one of the following options:
Select Yes to create a branch.
Select No to not create a branch.
Select Confirm to be asked for confirmation of the action to be taken.
183

Chapter 6: Member Operations
Check Out Dialog Box Tab Revision to Check Out Options
Advanced continued Keywords allows you to select keyword expansion options when checking out a
member. To leave keywords unexpanded, select Do Not Expand from the
Keywords list. To replace keywords in the revision with literal values in the
working file, select Expand from the Keywords list. To unexpand keywords in the
working file, select Unexpand from the Keywords list.
On Lock allows you to select a locked file for check out. To be asked to confirm
the required action each time you check out a member, select Query User. To
create a branch upon locking the working file, select Branch. To make the
working file writable upon lock, select Make Writable. To be asked to confirm
branching, select Query User to Branch. To be asked to confirm that you
want the working file to be writable, select Query User to Make Writable.
To cancel the On Lock option, select Cancel. By default, Source Integrity asks
you to confirm the required action each time you check out a member.
Viewing and
Editing a
Member
184
Merge Type (graphical user interface only) specifies the action to be taken when
merging revisions. Select one of the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken when
merging upon check out.
Cancel causes Source Integrity to cancel the operation.
Automatic causes Source Integrity to perform an automatic merge. For more
information on automatic merging, see “Step Two: Merge Branch” on page 345
Manual causes Source Integrity to initiate the MKS Visual Merge tool.
On Conflicts (graphical user interface only) specifies the action to be taken when
merge conflicts occur. Select one of the following options from the list:
Confirm causes Source Integrity to confirm the action to be taken when a
conflict occurs.
Cancel causes Source Integrity to cancel the operation when a conflict
occurs.
Mark For Later Merge causes Source Integrity to mark the files for
merging at another time, allowing you to resolve the conflict first.
Launch Tool causes Source Integrity to initiate the MKS Visual Merge tool.
Highlight Output File causes Source Integrity to highlight conflicts in
the resulting merged revision.
Error causes Source Integrity to display an error message prompt.
You can open a member or a deferred member in your default editor
application.
The default editor is the editor used to display a working file or revision,
for example, Microsoft Windows Notepad or MKS Toolkit’s vi for
Windows editor.
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.
u s e r g u i d e

Performing Member Operations
Changes to member information are automatically displayed in the
Sandbox view. You can also use the Scan for Changes feature to display
changes if the client is offline from the server or if you need to see changes
on your local drive.
To view or edit a member in the graphical user interface
1 With a Sandbox view open, select the member you want to view or
edit.
2 Do one of the following:
Select Member > Working File > Edit.
Click .
Double click the file icon.
The member’s working file is opened in your default editor or in the
editor associated with the file’s extension. To configure your default
editor, see “Setting Preferences” on page 40.
To view a member in the Web interface
1 With a Project view open, select the member you want to view.
2 Select Member > View Member.
The member is opened in a second browser window.
Scanning for Changes
Member information in a Sandbox view is automatically updated
whenever changes are made, for example, if another user locks a member.
You only need to scan for changes if your connection to the Integrity Server
is offline or if you need to see changes to members on your local drive.
To scan a sandbox for changes in the graphical user interface
1 With a Sandbox view open, select the members you want to scan for
changes.
2 Select View > Scan for Changes.
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, ).
185

Chapter 6: Member Operations
Checking In a
Member
186
When you are satisfied with the changes you have made to a member, you
should check in the member to preserve those changes as a new revision in
the member’s 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.
The author name is the name you associate with revisions upon check in. By
default, your author name is your user name.
In the Source Integrity Web interface, because sandboxes do not exist, a
source file (working file) for the member is specified and checked in as the
new revision.
Starting a Branch When Checking In a Member
Source Integrity usually places a new revision at the top of the trunk,
assigning it a two-part revision number, such as 1.15. 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. For information
on branching, see “Branching and Merging Revisions” on page 337.
Divergent lines of development in the same archive are managed through
the use of branches. A branch is an independent revision line that uses an
existing revision as its starting point. Members of a branch revision are
identified by their revision numbers. Whereas revisions on the trunk are
characterized by two-part revision numbers (for example, 1.2 or 3.5),
branch revision numbers are prefixed with the number of the revision they
start from. For example, if a branch revision is started from revision
number 1.2, the members of that branch are numbered
1.2.1.3
1.2.1.2
1.2.1.1
and so on. The first two digits of the number identify the revision where
the branch diverges from the trunk, and the last two represent a position
on the branch.
Assigning Revision Numbers
By default, when you check in a member, Source Integrity 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.
u s e r g u i d e

Performing Member Operations
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
If you check in a revision using an already existing revision number,
Source Integrity attempts to add one to the revision number and check it in
as that revision. If that revision already exists, Source Integrity 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, Source Integrity 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 (Source Integrity
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)
Assigning Revision Descriptions
A revision description is text that becomes a permanent part of the archive’s
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.
187

Chapter 6: Member Operations
188
IMPORTANT
The maximum size for a revision description is 64 KB. If you exceed this size
the member history may become unreadable.
Once a new revision is checked in, its revision description cannot be
changed. You can, however, append new information to a revision
description.
To check in a member in the graphical user interface
NOTE
You cannot check in a member that is associated with a deferred drop
operation.
1 With a Sandbox or Member History view open, select one or more
members to check in.
2 From the Sandbox view, do one of the following:
Select Member > Check In.
Click .
From the Member History view, do one of the following:
Select History > Check In.
Click .
The Check In dialog box is displayed.
TIP
Click the Differences button on the Check In dialog box to view the differences
between your working file and the revision you checked out.
u s e r g u i d e

NOTE
Performing Member Operations
The Change Package options, such as Close Change Package, appear only if
change packages are enabled.
If the member you are checking in had a change package associated with it at
the time of check out, that change package appears by default in the
Change Package field in the Change Package options.
3 In the Revision Description field, enter a comment about the new
revision. For example, you can enter a detailed description of what
you changed, what bug in the software the changes were meant to
correct, or instructions for the next person who works on the member.
IMPORTANT
The maximum size for a revision description is 64 KB. If you exceed this size
the member history may become unreadable.
If your administrator has set the feature for enforced revision
descriptions, you must make an entry in the Revision Description
field. If the field is blank, Source Integrity displays an error message
and the member is not checked in.
4 Under Options, click the desired tab, then modify the check in options.
For more information, see “Check In Options” on page 192.
189

Chapter 6: Member Operations
190
5 To check in the member, click OK. To check in all remaining members,
click OK to All. For information on advanced check in and check out
operations, see “Branching and Merging Revisions” on page 337.
The member is checked in.
If change package reviews are mandatory, a pending revision is
created. For more information, see “Working With Pending
Revisions” on page 335.
To check in a member in the Web interface
NOTE
You cannot check in a member that is associated with a deferred drop
operation.
1 With a Project or Member History view open, select a member to
check in by clicking the corresponding check box.
In the Web interface, you can check in only one member per operation.
Multiple member selections for check in cause an error.
2 From the Project view, do one of the following:
Select Member > Check In.
Click .
From the Member History view, do one of the following:
Select History > Check In.
Click .
The Check In dialog box is displayed.
u s e r g u i d e

NOTE
Performing Member Operations
The Change Package options, such as Close Change Package, appear only if
change packages are enabled.
3 In the Revision Description field, enter a comment about the new
revision. For example, you can enter a detailed description of what
you changed, what bug in the software the changes were meant to
correct, or instructions for the next person who works on the member.
IMPORTANT
The maximum size for a revision description is 64 KB. If you exceed this size
the member history may become unreadable.
If your administrator has set the feature for enforced revision
descriptions, you must make an entry in the Revision Description
field. If the field is blank, Source Integrity displays an error message
and the member is not checked in.
4 Under Options, click the desired tab, then modify the check in options
and click OK. For more information, see “Check In Options” on
page 192.
The Specify Source File dialog box is displayed.
191

Chapter 6: Member Operations
Check In Dialog Box Options
192
5 In the field, enter or browse to the location of the working file for the
member you want to check in.
6 To check in the member, click OK.
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:
Source Integrity confirms if you want to proceed. Click No if you
do not want to check in a source file different from the member.
Click Yes if you want to check in a source file different from the
member.
Source Integrity cancels the check in operation because the file
names do not match.
The member is checked in.
If change package reviews are mandatory, a pending revision is
created. For more information, see “Working With Pending
Revisions” on page 335.
Check In Options
General Specifies the following general check in options:
Label is a unique string that identifies the new revision. Revision labels are
usually assigned during check in, but can be assigned later, for instance, using
the Member > Properties > Add Label command.
Move Existing Label moves the label if it already exists on another revision.
In the Web interface only, select from one of the following options:
Select Yes to move the label.
Select No to not move the label.
Select Confirm to be asked for confirmation of the action to be taken.
Lock Revision causes Source Integrity to check in the working file, then
immediately lock the new revision. This allows you to update the archive while
retaining control of the revision. If this option is not selected, the working file is
checked into the archive unlocked.
u s e r g u i d e

Check In Dialog Box Options
Performing Member Operations
General continued Close Change Package closes the change package associated with the member,
and if the Integrity Manager integration is enabled, updates the issue status in
Integrity Manager.
In the Web interface only, select from one of the following options:
Select Yes to close the associated change package.
Select No to keep the associated change package open.
Select Confirm to be asked for confirmation of the action to be taken.
Defer Check In (graphical user interface only) causes Source Integrity to delay
the check in of the revision. Your lock remains on the revision and
Source Integrity displays the icon and the version information for both the
working and member revisions. Once you submit the check in, your lock is
removed and the member revision moves to the next number in the sequence, as
in the case of a standard check in operation.
Check In if Unchanged checks in the working file even if it has not changed since
it was last checked out.
Update Member Revision makes the new revision the member revision in the
project, replacing the existing member revision.
Different Member/Source File Name (Web interface only) confirms the action to
be taken if the specified source file name and member name are different.
Select Yes to allow the different file names.
Select No to disallow the different file names.
Select Confirm to be asked for confirmation of the action to be taken.
Advanced Specifies the following advanced check in options:
Author is the author name applied to the revision. If necessary, enter a name.
The user name specified in the Add Members command configuration appears
by default.
Update Member Revision Even on Branch causes Source Integrity to update the
member revision upon check in, even when the locked revision is on a different
branch.
In the Web interface only, select from one of the following options:
Select Yes to update the member revision.
Select No to not update the member revision.
Select Confirm to be asked for confirmation of the action to be taken.
Unexpand Keywords replaces literal values with keywords in the new revision.
Retain Working File (graphical user interface only) causes Source Integrity to
check in the working file and immediately resynchronize it. If this option is
cleared, the working file is deleted after it is checked in.
Revision Number specifies the revision number you want to assign to the
revision. By default, Source Integrity creates the next logical revision number, for
example, 1.1 to 1.2. Optionally, you can enter a revision number.
Force Creation of New Branch causes Source Integrity to create a branch off of
the revision you are checking in.
Save Working File Timestamp (graphical user interface only) sets the timestamp
of the revision in the history to the timestamp of the working file, rather than the
time of check in.
193

Chapter 6: Member Operations
Renaming a
Member
194
You can rename individual members while working from a Project or
Sandbox view. When you rename a member, member attributes are copied
from the old member name to the new member name.
The member’s archive remains the same, and points to the old member
name so that change packages, member histories, and project histories
continue to work.
You can defer the renaming of a member by selecting Defer Rename or
the si rename --defer command. For more information deferred
operations, see “Deferring Member Operations” on page 200.
NOTE
Because renaming a member effects a change on other users on the same
development path, the member you want to rename must not be locked by any
other user.
Renaming a locked revision in a variant project moves the lock to the duplicate
revision, even if the lock was generated in the master project.
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, Source Integrity 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), Source Integrity 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, Source Integrity performs the rename
operation and retains your lock. For example, if you rename a locked
revision (1.3), Source Integrity 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, Source Integrity 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, Source Integrity creates a duplicate of that revision along a new
branch and updates the member revision to that branch.
To rename a member in the graphical user interface
1 With a Project or Sandbox view open, select the member you want to
rename.
u s e r g u i d e

2 Select Member > Rename.
Performing Member Operations
The Rename Member dialog box opens, displaying the existing name
of the selected member, as well the name of the project (or sandbox)
the member resides in.
3 In the New Name text field, enter the new name of the member.
4 Under Change Package, select a change package, if applicable, or
create a change package to link to.
NOTE
The requirement for change package information applies only if the integration
with Integrity Manager is enabled.
5 Under Options, click a check box to choose the preferred options for
the rename operation. The available options are:
Rename Working File renames the working file in your sandbox
and preserves any changes made to that file. If not set, the
working file is not renamed and becomes a former member which
will be confirmed for deletion the next time the sandbox is
resynchronized. This setting has no effect if the command is
performed directly from a Project view.
Confirm Rename causes Source Integrity to confirm that you want
to rename the selected member.
Close Change Package closes the specified change package after
performing the rename operation.
195

Chapter 6: Member Operations
Discarding
Changes to a
Member
196
Overwrite Existing File replaces an existing working file in the
sandbox for the new file name.
Defer Rename delays the rename operation in the project until the
deferred operation is submitted. The rename operation in the
sandbox still takes place immediately and Source Integrity
displays the icon.
If the change package reviews are mandatory, select this option to
create a pending entry for this operation at the time of change
package submission. If this option is not enabled, Source Integrity
creates the pending entry at the completion of this procedure. For
more information, see “Change Package Review Process” on
page 240.
6 To complete the rename operation, click OK.
The new member name is displayed in the list of project members.
Source Integrity creates a new, duplicate revision in the archive so that
a change package can be associated with the operation.
If you are sure you do not want to check in a member’s modified working
file, you can revert it to its state before it was checked out.
Reverting a member discards any changes made to a member’s working
file since it was checked out, and then unlocks it.
When you revert a deferred add operation, Source Integrity retains the
working file for the pending member. After the revert operation, the file
becomes a non-member, rather than a former member, because it was
never added to the project.
To discard changes to a member’s working file in the graphical user
interface
1 With a Sandbox, or Member History view open, select one or more
members that are checked out in your name or are modified.
2 From a Sandbox view, do one of the following:
Select Member > Revert.
Click .
From a Member History view, do one of the following:
Select History > Revert.
A confirmation dialog box is displayed if the working file is modified.
u s e r g u i d e

Resyncing
Members
Performing Member Operations
3 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 check out.
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 master 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 ( ) appears next to the
member in the graphical user interface, signaling its status. In the
command line interface, you can use the si viewsandbox command to
display changes to files and archives.
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 203
To resynchronize a member in the graphical user interface
1 With a Sandbox view open, select one or more members that contain
member deltas.
2 Do one of the following:
Select Member > Resynchronize.
Click .
If you have made changes to your working file (without a lock), and
then attempt to check out the member, the Confirm Working File
Update dialog box is displayed. If you want to retain your changes in
the working file, click Yes (Yes to All for multiple members). If you do
not want to retain your changes in the working file, click No (No to All
for multiple members).
If the working file is writable, you will be asked to confirm
overwriting it.
When working in your sandbox, you can also apply the
Resynchronize By CP command. When you select a member and use
Resynchronize By CP, Source Integrity automatically searches the
change package associated with the member you are resynchronizing
and then brings the changes from the project to your sandbox. If the
member you want to resynchronize has more than one change
package associated with it (different change packages can exist for
197

Chapter 6: Member Operations
Locking a
Member
198
each revision of a member), you must apply the Resynchronize By CP
command for each change package associated with the member. For
more information on resynchronizing by change package, see “Using
the Resync By CP Command” on page 436.
3 To resynchronize the member, click Yes (for multiple members, click
Yes to All).
The selected member is updated.
If the working file of the member you are resyncing is modified,
Source Integrity asks you to confirm that you want to merge your
modifications into the working file. For more information on merging
on a resyncing, see “Automatic Merging on Resync” on page 352.
Locking a member prevents more than one user from simultaneously
making changes to the same revision. When a revision is locked, no one
other than the locker can check in changes to that revision.
Normally you lock a member during a check out. 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.
In the graphical user interface, a locked member is denoted with a padlock
symbol ( ), along with the locker’s name, and the date and time the
member was locked.
The person who has a revision locked is referred to as the locker.
NOTE
Locking a member does not affect the working file in any way. Source Integrity
does not make the working file writable if it was read-only, and does not verify
that it corresponds to the revision being locked. Make sure the working file
corresponds to the revision you want to lock.
To lock a member in the graphical user interface and Web interface
1 With a Project or Sandbox view open, select one or more members to
lock.
2 Do one of the following:
Select Member > Lock.
Click .
u s e r g u i d e

Performing Member Operations
If your administrator has enabled the integration with
Integrity Manager and set the option for IMTrackLocksEnabled,
Source Integrity displays the Lock Revision dialog box.
3 Configure the following options as necessary:
Change Package options appear only if change packages are
enabled. Select a change package from the Change Package drop
down list, or click Create to create a new change package.
Force Creation of New Branch causes Source Integrity to create a
branch off of the revision you are locking.
In the Web interface only, select an option from the drop down
list:
Select Yes create a new branch.
Select No to not create a new branch.
Select Confirm to be asked for confirmation of the action to
be taken.
Create Branch if Variant causes Source Integrity to create a branch
off of the revision you are locking, if you are working in a variant
sandbox. This option is available only through the graphical user
interface and command line interface.
To apply the lock with the selected options, click OK. To apply locks to
multiple files, click OK to All.
A padlock symbol appears next to the revision number, and your user
name and the date/time you locked the revision display in the Locked
column.
Depending on your view preferences (see “View Preferences” on
page 61), additional lock information may be available in columns,
199

Chapter 6: Member Operations
Unlocking a
Member
200
such as Lock Timestamp, Locker Development Path, Locker Sandbox,
Locker Project, Locker, or Locker Host.
If the locked member is selected in Sandbox or Project view,
information about the lock is displayed in the Member Information
Pane. Lock information is also available as a ToolTip when pointing to
the lock icon.
To manage your locks, see “Managing Revision Locks” on page 328.
When you no longer need the exclusive ability to change a member, you
can unlock it again. This is normally done by default when you check the
member in. You can unlock a member without checking it in, but your
changes will not be recorded if you choose to do so.
Depending on the permissions your administrator has defined, you may
also be able to unlock a revision that is locked by another user.
To unlock a member in the graphical user interface and Web interface
Do one of the following:
With a Project or Sandbox view open, select one or more locked
members to unlock, then do one of the following:
Select Member > Unlock.
Click .
With the Locks for User window open (see “Locks View” on
page 450), select one or more locked members, then select Locks >
Unlock.
The revision is unlocked and the padlock symbol ( ) is removed.
Deferring Member Operations
For certain operations in Source Integrity, 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 graphical user interface and in the command line interface as
the --defer option.
u s e r g u i d e

You can apply the defer option to the following operations:
“Adding Members to a Project” on page 157
Deferring Member Operations
“Adding Members From Archive to a Project” on page 166
“Dropping Members From a Project” on page 172
“Checking In a Member” on page 186
“Renaming a Member” on page 194
“Importing Members” on page 169
“Updating a Member’s Revision” on page 293
TIP
You can also 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 “Using Filters” on page 86.
A deferred member is a member that is associated with any deferred
operation (add, drop, check in, rename). A deferred member appears 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 Integrity Server until they are submitted to the project. For more
information, see “Submitting Change Packages” on page 238.
With the exception of deferred rename and check in operations,
Source Integrity supports only single deferred operations on a member. If
you try to perform multiple deferred operations on a single member,
Source Integrity reports an error.
NOTE
Once you have specified a deferred operation on a member, Source Integrity
does not allow any further operations that would cause that member to be
modified.
201

Chapter 6: Member Operations
Submitting
Deferred
Operations
202
You can simultaneously defer rename and check in operations on a single
member. When these deferred operations are submitted, Source Integrity
first performs the check in operation followed by the rename 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 Source Integrity 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 Review Process”
on page 240.
IMPORTANT
When adding multiple deferred operations on the same member to a change
package, only combinations of deferred check in and deferred rename
are possible.
To submit, or complete, a deferred operation, you use the Member > Submit
command. Submitting the operation completes the command and makes it
visible in the associated project.
If change package reviews are mandatory, when you submit deferred
operations using the Member > Submit command, pending entries (and if
necessary pending revisions) are created. You must still submit the
associated change package for review before the changes are committed to
the repository. For more information, see “Submitting Change Packages”
on page 238 and “Change Package Review Process” on page 240.
To submit a deferred operation in the graphical user interface
1 From a Sandbox view, select the member with the deferred operation
you want to submit (for example, a deferred check in, add, drop, or
rename operation).
2 From the menu bar, select Member > Submit.
The Submit dialog box opens.
u s e r g u i d e

Cancelling
Deferred
Operations
Resyncing
Members With
Deferred
Operations
Deferring Member Operations
3 Under Options, click to select the options for each item being
submitted:
Use the change package provided when the element was deferred
selects the change package that was originally associated with the
deferred item.
Override the change package to a specified value provides the
means to select (or create) a different change package from the
one that was originally associated with the deferred item.
Close Change Package causes Source Integrity to close the change
package after submitting the item and completing the associated
deferred operation.
4 To complete the submission, click OK.
Source Integrity submits the item and completes the deferred
operation.
Once you have deferred 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 196.
When you revert a deferred add operation, Source Integrity 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.
When you resynchronize a member associated with a deferred operation,
Source Integrity performs the following:
Deferred Add
When resynchronizing a member associated with a deferred add,
Source Integrity does not make any changes to the working file.
203

Chapter 6: Member Operations
Pending
Operations
204
Deferred Drop
When resynchronizing a member associated with a deferred drop,
where the working file is modified, Source Integrity asks you if you
want to overwrite the existing working file.
Deferred Rename
When resynchronizing a member associated with a deferred rename,
Source Integrity asks you if you want to overwrite the existing
working file. If the new working file is missing, Source Integrity
resynchronizes it. The working file with the old name is then deleted
from the sandbox.
Deferred Checkin
When resynchronizing a member associated with a deferred check in,
Source Integrity asks you if you want to overwrite the existing
working file.
Deferred Update Revision
When resynchronizing a member associated with a deferred update
revision, Source Integrity asks you if you want to overwrite the
existing working file.
Deferred Import
When resynchronizing a member associated with a deferred import,
Source Integrity asks you if you want to delete the existing working
file.
For additional information on resyncing members, see “Resyncing
Members” on page 197
If change package reviews are mandatory, then pending operations are
created when deferred operations are submitted either individually, or as
part of a change package (see “Submitting Deferred Operations” on
page 202 and “Submitting Change Packages” on page 238). Pending
operations correspond to pending entries in the associated change
package.
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 Review Process” on
page 240). Pending operations can create pending revisions and members
(see “Working With Pending Revisions” on page 335).
u s e r g u i d e

Resyncing
Pending
Revisions
Comparing Differences
Comparing Differences
When reviews are not mandatory, pending entries are created when the
changes are not successfully committed to the database. Source Integrity
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 like deferred operations, but must
be discarded from the associated change package. For more information,
see “Discarding CP Entries” on page 254.
When checking out a member that has a pending update to a member
revision that was submitted by you, the pending revision is selected by
default in the GUI and Web.
When resynchronizing a member with a pending revision, clicking Yes to
the confirmation message replaces a pending revision with the member
revision; with the working file corresponding to the member revision. For
more information, see “Working With Pending Revisions” on page 335.
After you have made changes to a member’s working file, you usually
check in those changes as a new revision. But you may also decide that
those changes should be discarded. Before you make this decision, you
have to be able to view the changes that you are checking in, or those that
you are discarding if you choose.
Source Integrity Visual Difference allows you to view the differences
between the member’s working file and its member revision. You can also
select two specific revisions and compare them. For information on
comparing revisions, see “Comparing Revisions” on page 331.
You can also compare differences between your checked out working file
and the locked revision through the Check In dialog. For details on viewing
differences through the Check In dialog, see “Checking In a Member” on
page 186.
Source Integrity allows you to use a third party differencing tool, in the
graphical user interface, if you do not want to use Visual Difference. You
can specify a third party difference tool in your preferences. For
information on setting up third party differencing tools, see “Difference
Tool Preferences” on page 69.
205

Chapter 6: Member Operations
206
NOTE
In the Source Integrity Web interface you cannot compare a working file to its
member revision but you can compare revision differences. For information on
comparing revisions, see “Comparing Revisions” on page 331.
For information on merging revisions, see “Merging Revisions” on
page 353 or “Branching and Merging Revisions” on page 337.
To compare a member’s working file to its member revision in the
graphical user interface
1 With a Sandbox view open, select a member that has a modified
working file (indicated by a working file delta ), or a member that
has a new revision available (indicated by a member delta ).
2 Do one of the following:
Select Member > Diff/Merge > Differences.
Click .
Visual Difference launches and displays the member’s working file
and member revision side-by-side, highlighting the differences
between them, or Source Integrity informs you there are no
differences between the files.
u s e r g u i d e

Using Keywords
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.
207

Chapter 6: Member Operations
208
NOTE
Your administrator may define custom keywords for your use. For information
about these keywords, see your administrator or the Integrity Server Installation
and Administration Guide.
The next time you check out the revision, Source Integrity 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: 2002/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:
returns
ident main.c
main.c:
$author: paula_t $
$state: Exp $
The following Source Integrity commands contain keyword expansion
options:
Add Members
Check Out
Check In
Resynchronize
Revert Member
Keyword expansion is configured using the Preferences dialog box in the
graphical user interface or the si setprefs command in the command
line interface. The command line interface settings and dialog boxes in the
u s e r g u i d e

Using Keywords
graphical user interface can override the default settings. For information
on setting command keyword options, see “Command Preferences” on
page 48.
For information on setting the keyword options for individual commands,
see Source Integrity Enterprise Edition CLI Reference Guide or man pages.
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$
Source Integrity, when it encounters this string, automatically adds the
value of the keyword $Revision$ in the format
where
$Revision: value $
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
file’s revision number. The program can then be configured to display this
string when it starts up, automatically presenting the current revision of
the program’s 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.
209

Chapter 6: Member Operations
Locating
Keywords
Table of
Keywords
210
NOTE
Ã
The keyword format of $$ causes Source Integrity to replace
between the first $ and the next $. If you use a keyword in the format
$, Source Integrity continues to replace until it encounters another
$. It is possible that Source Integrity may not encounter another $ until the file
is checked out again. This type of keyword use returns results that are similar
to logging.
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
Source Integrity Enterprise Edition 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.
Source Integrity 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.
$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.
Strings may contain standard escapes like “\n” for new lines, but
must be in ISO-646.
$Date$ The check in date and time of the revision (as assigned at check
in). 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 locker (if locked).
$Id$ The same as $Header$.
$Locker$ The user ID of the user who locked the revision (empty if not
locked).
u s e r g u i d e

Ã
Using Keywords
$Log$ The revision description supplied during check in, preceded by
the archive’s member name, revision number, author, and revision
date.
Repeated check out 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.
$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 Source Integrity. For
example, if the project contains pj set OS=unix, the keyword
$Setting OS$ is expanded to $Setting OS: unix$
$RCSfile$ The archive’s unqualified member name.
$Revision$ The revision number.
$SandboxSetting attribute The current value of the attribute defined in Source Integrity. For
example, if the sandbox contains pj set OS=unix, the keyword
$Setting OS$ is expanded to $Setting OS: unix$
$Setting attribute$ The current value of the attribute defined in Source Integrity. For
example, if the member contains pj set OS=nt, the keyword
$Setting OS$ is expanded to $Setting: nt$.
$Source$ The same as $RCSfile$. The archive’s unqualified member
name.
$State$ The state setting of the revision.
211

Chapter 6: Member Operations
212
u s e r g u i d e

Using Change Packages
and Reviews
7
KEY TERMS: change package, change package ID, submit change package, change
package entry, change package review
When addressing a development issue, work may need to be performed
on several members. Source Integrity provides change packages to group
all of the necessary changes together. When used with lock tracking and
deferred operations, change packages provide an essential tool for
controlling and monitoring development.
This chapter provides details on the following:
“What Are Change Packages?” on page 214
“Why Use Change Packages?” on page 215
“Using Change Packages to Control Development” on page 216
“Creating a Change Package” on page 217
“Adding Entries to a Change Package” on page 219
“Managing Change Packages” on page 220
“Submitting Change Packages” on page 238
“Change Package Review Process” on page 240
“Managing Change Package Entries” on page 252
“Viewing CP Entry Member Differences” on page 255
213

Chapter 7: Using Change Packages and Reviews
What Are Change Packages?
214
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
may add entries to that change package. Change package entries take the
form of operations, both deferred and committed. When reviews are
mandatory, change package entries take the form of pending entries before
they are committed.
For more information on change package entries, see “Change Package
Entry Types” on page 220 and “CP Entry Categories” on page 244
A change package administrator is a user with the permission to discard,
close, and submit change packages that were not created by that user.
The following rules apply when using issues and change packages:
Each change package has a unique change package ID (CP ID). The CP
ID is a colon separated identifier of the following form:
:
NOTE
If Integrity Manager integration is enabled, then the issue ID is used as the
container ID. For more information, see “The Integrity Manager Integration”
on page 371.
A change package acts as a log of both the changes to members that
have already been committed to the repository (server), and as a
record of work in progress, which is only visible to the user on the
desktop and not committed to the repository. It tracks the work in
progress using deferred operations that can be associated with a
change package. When reviews are mandatory, a change package acts
as a control placed on changes to the repository, by making them
pending before they are committed (see “Change Package Review
Process” on page 240).
A traditional change package has the following states: Open, Closed,
Discarded, and CommitFailed. A change package is open, or “in
progress” until you close it, which signifies that work on the change is
completed. If the changes fail to commit to the repository, then the
change package can be submitted again, or opened to continue work.
When reviews are mandatory, a change package has additional states
before it is closed (see “CP States” on page 241).
u s e r g u i d e

Operations That Add Entries to a Change Package
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 reopened by a
change package administrator.
Operations That Add Entries to a
Change Package
Why Use Change Packages?
The following member operations add entries to a change package:
“Checking Out a Member” on page 178
“Renaming a Member” on page 194
“Locking a Member” on page 198
“Adding Members to a Project” on page 157
“Adding Members From Archive to a Project” on page 166
“Dropping Members From a Project” on page 172
“Checking In a Member” on page 186
“Updating a Member’s Revision” on page 293
“Importing Members” on page 169
“Apply CP Procedures” on page 398
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 issue without resyncing the entire project.
215

Chapter 7: Using Change Packages and Reviews
216
Because a change package is stored with each new revision, there is a
relationship between every change in the repository and all of the
other changes made by the author.
Using change packages with the track locks feature, managers can
monitor work in progress.
Groups of changes can be reviewed as a unit. If reviews are
mandatory, changes are reviewed before they are committed to the
server repository.
TIP
You can expand the capabilities of change packages with Integrity Manager to
take advantage of workflow and process management through the use of
issues. The change packages can then be associated with issues. Enabling the
Integrity Manager integration also permits multiple change packages for each
issue. For more information, see “The Integrity Manager Integration” on
page 371.
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 Review Process” on page 240).
1 Open the Manage Change Packages window (see “Managing Change
Packages” on page 220). This is your control center for managing your
development activities.
2 Create a change package (see “Creating a Change Package” on
page 217) for the changes you need to make to address an issue. The
change package acts as a container, grouping together the specific
members (files) that need to be changed to address the issue.
Source Integrity assigns the change package an ID and leaves the
change package in an open state.
You can see the change package listed in the Manage Change
Packages window.
3 View the change package in the Change Package view (see “Viewing
Change Package Details and Entries” on page 226). All operations you
associate with the change package appear in this window.
u s e r g u i d e

Creating a Change Package
4 As part of your development process, identify the members that are
affected by the issue. Associate the members with the change package
(see “Operations That Add Entries to a Change Package” on
page 215).
NOTE
You can only add change package lock entries to a change package through a
check out and member lock if lock tracking is enabled. For more information on
lock tracking, see your administrator.
The operations are listed in the Change Package view.
5 When all of the development to address the issue is completed, submit
the change Package (see “Submitting Change Packages” on page 238).
Any locked members are converted to deferred check in operations,
then checked in.
All of the deferred operations are submitted.
Creating a Change Package
Although you can submit operations individually, or check in a
member without deferring it, submitting all of your operations at one
time ensures that changes are submitted as a group.
If reviews are mandatory, the review process begins here. Do not
continue with the following step. For more information, see “CP
Review Workflow” on page 242.
6 Close the change package when the work to address the issue is
completed. The change package is moved to the Closed state, and the
change package disappears from the Manage Change Packages
window.
To find the change package and view its entries, see “Finding Change
Packages” on page 222).
You can create a change package from Source Integrity views and when
performing member operations.
You can also create change packages from Integrity Manager. For more
information, see the Integrity Manager User Guide.
217

Chapter 7: Using Change Packages and Reviews
218
To create a change package in the graphical user interface
1 Create a change package in one of the following ways:
With a Project, Sandbox, or Member History view open, select
Change Package > Create.
With a Manage Change Packages window open, do one of the
following:
Select Change Package > Create.
Click .
Create a change package when performing a member operation
(see “Operations That Add Entries to a Change Package” on
page 215).
In to the Change Package portion of the panel, click Create.
The Create Change Package dialog box is displayed.
2 In the Summary field, enter a summary of the change package. A value
for this field is mandatory
3 In the Description field, if necessary, enter a detailed description of the
change package.
NOTE
If the Integrity Manager integration is enabled, when you create a change
package you can associate it with an issue. For more information, see “Creating
a Change Package for an Issue” on page 375.
u s e r g u i d e

4 Click OK.
Adding Entries to a Change Package
The change package is created. To view the change package, see
“Viewing Change Package Details and Entries” on page 226.
Adding Entries to a Change Package
Once a change package is created, you can add entries to that change
package when performing member operations (see “Operations That Add
Entries to a Change Package” on page 215).
Refer to the Change Package portion of the panel.
From the change package list, select a change package. The list presents the
Change package ID then the summary, for example, 13:1 Failed
install.
After the operation is completed, the entry is added to the change package.
Depending on the operation, the change package’s ID appears in one of the
member’s CPID (change package ID) columns in the Project or Sandbox
view. Not all CPID columns appear by default. For information on the
possible CPID columns, see “Sandbox View” on page 66.
If the change package contains deferred operations or lock entries, a
icon is displayed beside the change package ID in the Working CPID
column of the Sandbox view.
TIP
You can also add an entry to a change package by dragging the member from a
Sandbox view to a a Change Package view (or change package in the Manage
Change Packages window). The Check Out dialog box is displayed with the
change package selected. For more information, see “Checking Out a Member”
on page 178.
Lock tracking must be enabled for the Lock change package entry to
appear in the Manage Change Packages window when viewed from a
client on another machine.
219

Chapter 7: Using Change Packages and Reviews
220
NOTE
To add change package entries to a change package, the integrity client must be
connected to the server on which the change package resides.
Change Package Entry Types
The following table displays the operation for each change package entry
type.
Change Package Entry
Types
Managing Change Packages
Operation
Add Add Member
AddFromArchive Add Member From Archive
Check In Deferred Check In
Drop Drop Member
Import Import Member
Lock Lock Member, Check Out
Rename Rename Member
Update Check In, Update Member Revision
UpdateRevision Update Member Revision
UpdateArchive Check In (without updating member revision)
Source Integrity provides a central location to manage change packages
you have created that contain entries that have not been committed to the
server repository. From one location, you can view a change package and
its entries, view any issues associated with a change package, submit any
deferred operations for that change package, close a change package, edit a
change package, or create a new change package.
If reviews are mandatory, submitted change packages continue to appear
in the Manage Change Packages window until they are successfully
committed to the repository.
u s e r g u i d e

Managing Change Packages
To manage change packages in the graphical user interface
Do one of the following:
Select Tools > Manage My Change Packages.
Click .
The Manage Change Packages window is displayed.
By default, the Manage Change Packages window displays the following
information:
ID displays the change package ID.
Issue displays the issue ID if Integrity Manager is enabled.
Creator displays the user name of the person who created the change
package.
State displays current state of the change package (see “CP States” on
page 241).
Summary displays the summary statement for the change package.
Additional columns are available in the client preferences. To change the
displayed columns, see the Change Packages View option in the “View
Preferences” on page 61.
TIP
Right-click the column header to hide, show, or sort the available columns.
From the Manage Change Packages window, you can perform the
following tasks using the Change Package menu:
View Change Package entries and information (see “Viewing Change
Package Details and Entries” on page 226)
View Issue associated with the change package (see “Viewing a
Change Package’s Issue” on page 376)
Submit the change package (see “Submitting Change Packages” on
page 238)
221

Chapter 7: Using Change Packages and Reviews
Finding Change
Packages
222
Discard an existing change package (see “Discarding Change
Packages” on page 236)
Open a closed change package (see “Opening Change Packages” on
page 249)
Close a change package (see “Closing a Change Package” on page 235)
Edit an existing change package (see “Editing a Change Package” on
page 233)
Accept casts an accept vote on a change package that is under review
(see “Accepting a Change Package” on page 245
Reject rejects a change package that is under review (see “Rejecting a
Change Package” on page 247).
Create a new change package (see “Creating a Change Package” on
page 217)
For information on the Review Log panel, see “Viewing the CP Review
Log” on page 250.
Source Integrity provides you with a way to search through all of the
change packages created by anyone, including closed change packages.
If the Integrity Manager integration is enabled you can use a query to find
change packages based on complex criteria. See “Finding Change Packages
Using a Query” on page 378 for more information.
To find change packages in the graphical user interface
1 Select Tools > Find > Change Packages.
The Find Change Packages dialog box is displayed with the By Filter
panel displayed.
u s e r g u i d e

Managing Change Packages
If you want to find change packages using a filter, continue. To find a
change package using its ID, go to step 3.
2 You can search for change packages using the following filters:
State finds change packages if they are currently in the specified
state.
Created By finds change packages that were created by a specified
user.
Creation Date finds change packages that were created on a
specified date. The default date is today. Click Change to specify
another date using the Creation Date Filter.
Closed Date finds change packages that were closed on a specified
date. The default date is today. Click Change to specify another
date using the Creation Date Filter.
Member finds change packages that contain a specified member
name.
Project finds change packages whose members belong to a
specified project.
Summary finds change packages that contain specified text in the
change package summary.
223

Chapter 7: Using Change Packages and Reviews
224
Description finds change packages that contain specified text in
the change package description.
Entry Type Modifier finds change packages based on their
category. The categories are Committed and Pending. For more
information, see “CP Entry Categories” on page 244.
Entry Type finds change packages that contain a specified entry
type. For more information, see “Change Package Entry Types”
on page 220.
NOTE
Lock tracking must be enabled to filter by the Lock entry type. The Entry Type
filter only finds locks that were made from a Project view.
Pending Review By finds change packages submitted for review
but not yet been accepted or rejected by a specified reviewer.
Accepted By finds change packages accepted by a specified user.
Rejected By finds change packages rejected by a specified user.
Associated with Issue finds change packages that are associated
with an Integrity Manager issue, if the integration is enabled. For
more information, see “The Integrity Manager Integration” on
page 371.
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
appears. For example, search for change packages that are not
associated with a specified project.
When you are finished, go to step 5.
3 To find a change package by using the change package ID, click the By
ID tab.
The By ID panel is displayed.
u s e r g u i d e

4 Enter one of the following into the ID field:.
Managing Change Packages
A container ID, for example 12. This finds all changes packages
with that container ID. If the Integrity Manager integration is
enabled, the container ID is the same as the issue ID.
The full change package ID, for example 12:1. This finds the single
change package.
To add the ID to the list, click Add.
The ID appears in the list. Add as many IDs to the list as you want.
To remove IDs from the list, select the IDs from the list, then click
Remove.
NOTE
If the Integrity Manager integration is enabled, the By Query panel is available.
For more information, see “Finding Change Packages Using a Query” on
page 378.
5 Click OK.
The results are displayed in the Filtered Change Packages window.
The Filtered Change Packages window displays change packages in
the same way as the Change Packages view does. For more
information, see “Change Packages View” on page 444.
225

Chapter 7: Using Change Packages and Reviews
Viewing Change
Package Details
and Entries
226
To update the search criteria with current data, select View > Refresh.
To refine your search results, from the Filtered Change Packages
window, select View > Filter.
To start a new search, repeat this procedure.
Once you add members to a change package (see “Adding Entries to a
Change Package” on page 219), you can use Source Integrity to view the
change package information for those members or revisions.
NOTE
When working with shared subprojects, Source Integrity uses the actual name
of the subproject in the file system rather than its relative name in the project
hierarchy. Therefore, the change package entries for a shared subproject use
the actual file system name of the subproject. This enhances the portability of
change packages across different projects.
To view change package information and entries in the graphical user
interface
1 Do one of the following:
From a Project or Sandbox view, select View Change Package,
then one of the following:
Working displays the change package associated with a
deferred or a lock operation performed by the current user
from the current sandbox (available only from Sandbox
view).
Member displays the change package associated the
operation that set the member revision.
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 an
import, add member from archive, or set member revision
operation was used.
Locker displays the change package associated with the lock
on the member revision.
Pending displays the change package associated with a
pending operation.
u s e r g u i d e

Do one of the following:
Managing Change Packages
From the Annotated Revision view (see “Viewing an
Annotated Revision” on page 316), select the annotation
block corresponding to the change package you want to
view.
With the Manage Change Packages view open (see
“Managing Change Packages” on page 220), select the
change package you want to view.
Then do one of the following:
Select Change Package > View Change Package.
Click .
Double click the change package name.
The Change Package view is displayed.
2 To view change package information, click the Attributes tab.
The Attributes panel is displayed.
The Attributes panel displays the change package ID, summary,
current change package state, person who created the change package,
date the change package was created, and description (if one was
provided). If applicable, the Attributes panel also displays the closed
date and reolution information.
3 To view change package entries, click the Entries tab.
The Entries panel is displayed.
By default, the Entries panel displays the following information for
each change package entry:
Type is the entry type of the change package entry. For
information on possible entry types, see “Change Package Entry
Types” on page 220.
227

Chapter 7: Using Change Packages and Reviews
228
Member displays name of the member associated with the change
package entry.
When it is a Rename entry type, the member name is displayed in
the form: newname(oldname).
Revision displays the revision number associated with the change
package entry.
Sandbox displays the name of the sandbox where the deferred
operation, check out, or lock took place.
Project displays the name and path of the project that the member
belongs to. If the entry occurred from a shared subproject, the
subproject name and path are displayed.
Variant displays the name of the variant development path (if a
variant was used) the change package entry is derived from.
Date Changed displays the date the entry was made.
Server displays the host name of the server the entry was made
on.
Additional columns are available in the client preferences. To change
the displayed columns, see “View Preferences” on page 61.
TIP
Right click the column header to hide, show, or sort columns.
4 From the Entries panel, you can select a change package entry and
then perform the following tasks from the Change Package Entry
menu:
View Differences for the entry (see “Viewing CP Entry Member
Differences” on page 255).
View Revision that is associated with the entry (see “Viewing a
Member’s Working File or Revision” on page 322). This always
displays the revision stored in the repository.
TIP
Double click a locked member, a deferred check in, or a pending update entry
to display the working file.
View Revision Information associated with the entry (see
“Viewing and Editing Revision Information” on page 314).
u s e r g u i d e

Managing Change Packages
View the Member History associated with the entry (see “Viewing
a Member History” on page 310).
Submit selected deferred entries (see “Submitting Deferred
Operations” on page 202).
Edit Settings for the selected deferred entries (see “Submitting
Deferred Operations” on page 202).
Discard discards the selected entries (see “Discarding CP Entries”
on page 254).
Move moves the selected entries to another change package (see
“Moving CP Entries” on page 252).
Edit Working File that is associated with a entry (see “Viewing a
Member’s Working File or Revision” on page 322).
Check In the selected lock entries (.see “Checking In a Member”
on page 186).
To update the list of change package entries with the most recent
changes, select View > Refresh.
To display or not display uncommitted entries (deferred entries and
lock entries), select View > Show Uncommitted. Repeat to enable or
disable the option.
To display or not display entries that are pending, select View >
Show Pending. Repeat to enable or disable the option.
To display or not display committed entries, select View > Show
Committed. Repeat to enable or disable the option.
To view change package information and entries in the Web interface
1 Do one of the following:
With a Project view open, select the member whose change
package you want to view.
With a Member History view open, select the member revision
whose change package you want to view.
2 Select Change Package > View Change Package.
TIP
Click the change package ID to view the change package.
The Change Package view is displayed.
229

Chapter 7: Using Change Packages and Reviews
230
For more information on the change packages view, see “Change Package
View” on page 443.
To view a member’s change package information in the graphical user
interface
1 With a Project or Sandbox view open, select the member whose
information you want to view.
2 Do one of the following:
Select Member > Properties > Member Information.
Click .
The Member Information dialog box is displayed.
3 Click the Change Package tab.
The Change Package panel appears.
The issue ID and summary are displayed. If the member is not
associated with a change package, No Change Package
Information Available appears in the Change Package panel.
The change package that appears is associated with the operation that
created the member revision.
4 When you are finished viewing the member information, click OK.
u s e r g u i d e

Managing Change Packages
To view a member’s change package information in the Web interface
1 With the Project view open, select the member whose information you
want to view.
2 Select Member > Member Information.
3 Scroll to the Change Package section.
4 The CP ID and summary are displayed. If the member is not
associated with a change package, No Change Package
Information Available appears in the Change Package section.
5 When you have finished viewing the member information, click OK.
To view a revision’s change package information in the graphical user
interface
1 With a Member History view open, select the revision whose
information you want to view.
2 Do one of the following:
Select History > Revision Information.
Click .
The Revision Information dialog box is displayed.
3 Click the Change Package tab.
The Change Package panel appears.
231

Chapter 7: Using Change Packages and Reviews
232
The CP ID and summary are displayed. If the revision is not
associated with a change package, No Change Package
Information Available appears in the Change Package panel.
4 When you are finished viewing the revision information, click OK.
To view a revision’s change package information in the Web interface
1 With a Member History view open, select the revision whose
information you want to view.
2 Do one of the following:
Select History > Revision Information.
Click .
The Revision Information dialog box is displayed.
3 Scroll down to view the change package information.
u s e r g u i d e

Editing a
Change
Package
Managing Change Packages
The CP ID and summary are displayed. If the revision is not
associated with a change package, No Change Package
Information Available appears in the Change Package panel.
4 When you are finished viewing the revision information, click OK.
You can update a change package when necessary. You can update the
summary, state, and description of a change package.
NOTE
You can only edit a change package that you created, unless you have
administrator permissions.
To edit a change package in the graphical user interface
1 Do one of the following:
With the Manage Change Packages view open (see “Managing
Change Packages” on page 220), select the change package you
want to edit.
From a Sandbox view, select the member whose associated
change package you want to edit.
In a Change Package view, display the change package you want
to edit (see “Viewing Change Package Details and Entries” on
page 226).
233

Chapter 7: Using Change Packages and Reviews
234
2 Do one of the following:
Select Change Package > Edit.
Click .
The Edit Change Package dialog box is displayed.
3 Edit the change package as required:
In the Summary field, enter a new summary for the change
package or add to the existing summary.
In the State field, select a state for the change package from the
list (see “CP States” on page 241).
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
Review Process” on page 240.
In the Description field, enter a new description for the change
package or add to the existing description.
4 Click OK to save your changes.
To edit a change package in the Web interface
1 In a Project view, select the member that is associated with the change
package you want to edit.
2 Under the C.P.ID column, click the number link for the change
package.
The Change Package view opens.
3 Do one of the following:
Under the Actions menu, click Edit Change Package.
Click .
u s e r g u i d e

Closing a
Change
Package
The Edit Change Package dialog box is displayed.
4 Edit the change package as required:
Managing Change Packages
In the Summary field, enter a new summary for the change
package or add to the existing summary.
In the State field, select a state for the change package from the
list (see “CP States” on page 241).
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
Review Process” on page 240.
In the Description field, enter a new description for the change
package or add to the existing description.
5 Click OK to save your changes.
Once the necessary changes are made to the members and they are
committed to the repository, the change package can be closed.
In addition to this procedure, you can close a change package in the
graphical user interface when performing member operations (see
“Operations That Add Entries to a Change Package” on page 215).
If the Integrity Manager integration is enabled, closing a change package
allows the issue to move forward in the Integrity Manager workflow. For
more information, see “The Integrity Manager Integration” on page 371.
NOTE
You can only close a change package that you have created unless you have
administrative permissions.
235

Chapter 7: Using Change Packages and Reviews
Discarding
Change
Packages
236
If reviews are mandatory, you cannot close a change package. It must
follow the review process and be closed by the Integrity Server. For more
information, see “Change Package Review Process” on page 240.
To close a change package in the graphical user interface
1 Do one of the following:
With the Manage Change Packages window open (see
“Managing Change Packages” on page 220), select the change
package you want to close.
From a Sandbox view, select the member whose associated
change package you want to close.
In a Change Package view, display the change package you want
to close (see “Viewing Change Package Details and Entries” on
page 226).
2 Do one of the following:
Select Change Package > Close.
Click .
The Confirm Close Change Package dialog box is displayed.
3 To close the change package, click OK.
The change package is closed.
To close a change package when performing an operation in the
graphical user interface
You can close a change package when performing member operations (see
“Operations That Add Entries to a Change Package” on page 215).
To close the change package when performing a member operation: on the
dialog box, enable the Close Change Package option.
After the operation is completed, the change package is closed.
Source Integrity provides a way to remove change packages from active
use when they are not needed by discarding them.
Change packages can only be discarded if they are in the Open or
Rejected states. In order 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.
u s e r g u i d e

TIP
Managing Change Packages
If only specific entries need to be removed from a change package, see
“Discarding CP Entries” on page 254.
When a change package is discarded, the following happens where
applicable:
All uncommitted entries are removed from the change package.
Al deferred operations corresponding to deferred entries are reverted.
All 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).
Note the following about discarded change packages:
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 Change Package filter (see “Finding Change
Packages” on page 222).
If the change package has undergone a review, the review log persists.
Discarded change packages can be opened and used again (see
“Opening Change Packages” on page 249).
To discard change packages in the graphical user interface
1 Do one of the following:
In the Change Package view (see “Viewing Change Package
Details and Entries” on page 226), display the change package
you want to discard.
From the Manage Change Packages view (see “Managing Change
Packages” on page 220), select the change packages to be
discarded.
237

Chapter 7: Using Change Packages and Reviews
238
From the Sandbox view, select member revisions associated with
the change packages to be discarded.
2 Select Change Package > Discard.
The Confirm Discard Change Package dialog box is displayed.
3 To discard the change packages, click Yes.
If the change package contains entries, the Confirm Discard Change
Package Entry dialog box is displayed. To discard all entries in the
change package, click Yes to All .
The change packages are moved to the Discarded state.
To discard a change package in the Web interface
1 Display the change package you want to discard in the Change
Package view. For more information, see “To view change package
information and entries in the Web interface” on page 229.
2 From the Change Package view, select Actions > Discard Change
Package.
The Confirm Discard Change Package dialog box is displayed.
3 To discard the change package, click Yes.
If the change package contains entries, the Confirm Discard Change
Package Entry dialog box is displayed. To discard all entries in the
change package, click Yes to All.
The change package is moved to the Discarded state.
Submitting Change Packages
Although you can submit operations individually, you can ensure that no
operations are missed by submitting a change package that contains
deferred operations. Deferred operations are visible only from the
Source Integrity Client, and are not committed to the repository until they
are submitted. You can submit change packages containing any
combination of deferred, pending, and committed entries.
When reviews are mandatory, submitting a change package begins the
review process (see “Change Package Review Process” on page 240).
u s e r g u i d e

To submit change package in the graphical user interface
1 Do one of the following:
Submitting Change Packages
From the Manage Change Packages view (see “Managing Change
Packages” on page 220), select the change packages you want to
submit.
In the Change Package view (see “Viewing Change Package
Details and Entries” on page 226), display the change package
you want to submit.
From a Sandbox view, select the member whose associated
change package you want to submit.
2 To submit the change package, do one of the following:
Select Change Package > Submit.
Click .
NOTE
Locked members with lock entries in a change package are checked in when
the change package is submitted.
The Submit Change Package Status dialog box is displayed,
containing information on the status of your change package. The
dialog box notifies you if your change package is submitted,
committed, or failed to commit.
IMPORTANT
If when a change package is submitted it only contains pending entries, you are
prompted, and in order to commit those pending entries you must click Yes to
submit the change package even if there are no deferred or lock entries. To set
this option as default, see “Command Preferences” on page 48.
If a review is mandatory for any project that the member
corresponding to a change package entry is associated with, the
Submit Change Package command begins the review process which
must be completed before the changes are committed to the
repository.
If the change package is a resolution change package, by default you
are prompted with the option to apply the change package after it is
submitted. For more information, see “Working With a Resolution
CP” on page 428.
239

Chapter 7: Using Change Packages and Reviews
Change Package Review Process
How the CP
Review Works
240
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.
IMPORTANT
To use change package reviews, you must use Source Integrity 8.6 or later.
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.
A Super Reviewer is a user with permission to vote on change packages that
the user is not a listed reviewer for. 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.
Following is a summary of how the change package review process works:
1 The review starts when a developer (change package creator) submits
a change package containing deferred entries (or any combination of
deferred, pending, or committed entries).
2 Source Integrity creates a pending change package entry for each
deferred entry, and where necessary pending revisions.
3 Change Package Reviewers (possibly a mentor or a senior developer)
accept or reject the change package.
u s e r g u i d e

CP States
Change Package Review Process
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)
For a detailed description of the change package review process, see “CP
Review Workflow” on page 242.
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.
Submit
Change Package
Pending Entries
and Revisions
Change Package Review Overview
ACCEPT or REJECT
Committed
Open and
Work
Server
The following table provides details on change package states. Where
specified, some are only used in the review workflow:
Change Package State Details
Open The only state where work can be performed using a
change package (new entries created).
Submitted The state the change package is in while it is being
reviewed. All operations are pending.
241

Chapter 7: Using Change Packages and Reviews
CP Review
Workflow
242
Change Package State Details
Accepted An intermediate state denoting that the change
package is accepted by all of the reviewers.
Source Integrity automates the state change from
Accepted to Closed if the changes are successfully
committed to the repository.
CommitFailed The state signifying that the pending changes could
not be committed to the repository.
Rejected The state denoting that the change package is
rejected by a reviewer. The 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 The end state for the change package, when
pending changes are successfully committed to the
repository.
A change package under review progresses through states in a workflow.
For a graphical representation of the workflow, see the diagram “Change
Package State Workflow” on page 244.
The following is the change package progression through the workflow:
1 A change package is created, and in the Open state. Entries are added
to the change package by the developer.
2 The developer submits the change package to begin the change
package review process (see “Submitting Change Packages” on
page 238), and Source Integrity moves the change package to the
Submitted state.
An e-mail is sent to notify 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,
Source Integrity sends the reviewers an e-mail notification of the
u s e r g u i d e

Change Package Review Process
accept vote. When all reviewers have voted to accept the change
package, Source Integrity sends each reviewer and the creator an
e-mail notification that the change package is accepted.
Source Integrity then commits the changes to the repository, and
then closes the change package. If Source Integrity fails to commit
the changes to the repository, it moves the 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, Source Integrity 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, Source Integrity 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 335.
The user can also discard the change package if it is no longer
needed for development (thereby discarding entries contained int
he change package). Change packages in the Discarded state can
be moved back to the Open state if they are needed again.
243

Chapter 7: Using Change Packages and Reviews
CP Entry
Categories
244
Change Package State Workflow
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 220.
The following are change package entry type categories and their
descriptions:
deferred entries appear only when the change package is in the Open
state, for deferred operations (see “Deferring Member Operations” on
page 200).
pending entries appear only when the change package is in the Open,
Submitted, Accepted, Rejected, and CommitFailed states, for
operations performed when reviews are mandatory, and when
deferred operations are submitted (see “Submitting Change Packages”
on page 238 and “Submitting Deferred Operations” on page 202).
discarded entries can only be viewed from the review log. For more
information, see “Discarding CP Entries” on page 254 and “Viewing
the CP Review Log” on page 250.
committed entries are entries that are committed to the repository. They
are denoted simply by the change package entry type name, for
example update.
u s e r g u i d e

Reviewing
Changes
Accepting a
Change
Package
NOTE
Change Package Review Process
For change packages that are not under review, only the deferred and
committed entry types are available for use in Source Integrity.
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 406.
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 view the list of reviewers and reviewer groups, see “Viewing the CP
Review Log” on page 250.
NOTE
To accept a change package, the integrity client must be connected to the server
on which the change package resides.
To accept a change package in the graphical user interface and
Web interface
1 Do one of the following:
From the graphical user interface, do one of the following:
From the Change Packages for to review view
(see“Viewing Your Pending Reviews” on page 250), select
the change package you want to accept.
From the Change Packages view, select the change package
you want to accept.
In the Change Package view (see “Viewing Change Package
Details and Entries” on page 226), display the change
package you want to accept.
Select Change Package > Accept or click .
From the Web interface, with a Project or Member History view
open, click the change package ID. The Change Package View is
displayed.
Select Actions > Accept Change Package or click .
245

Chapter 7: Using Change Packages and Reviews
246
The Accept Change Package dialog box is displayed.
The following information is displayed:
ID displays the change package ID number.
Summary displays the summary description of change package.
Creator displays the user name of the user who created the
change package.
Review As displays the user name of the reviewer accepting the
change package.
2 In the Capacity list, select the capacity in which you are the reviewer.
Due to factors determined by your administrator, the options in the
list vary per user for each change package. The possible options are:
Individual casts a vote as an individual reviewer in the
reviewer list.
Member of casts a vote on behalf of the entire group
(only a one user from a group is necessary to vote on behalf of the
entire group).
All Reviewers casts a vote as a specific user and any group to
which the reviewer belongs.
Super Reviewer casts an overriding accept vote that is sufficient
for accepting the change package even if there are additional
reviewers. A super reviewer does is not required to be a listed
reviewer for the change package.
3 Enter comments on the change package elements in the Comments
field if desired.
4 To accept the change package, click OK.
The accept vote is cast and recorded in the review log (see “Viewing
the CP Review Log” on page 250).
If there 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.
u s e r g u i d e

Rejecting a
Change
Package
Change Package Review Process
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 Closed. For more information on
change package states, see “CP Review Workflow” on page 242.
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.
If a reviewer of a change package determines that invalid changes were
made, or additional development must be completed to resolve an issue;
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, see “Viewing the CP
Review Log” on page 250.
To reject a change package in the graphical user interface and
Web interface
1 Do one of the following:
From the graphical user interface, do one of the following:
From the Change Packages for to review view
(see“Viewing Your Pending Reviews” on page 250), select
the change package you want to reject.
From the Change Packages view, select a change package
you want to reject.
In the Change Package view (“Viewing Change Package
Details and Entries” on page 226), display the change
package you want to reject.
Select Change Package > Reject or click .
From the Web interface, with a Project or Member History view
open, click the change package ID. The Change Package View is
displayed.
Select Actions > Reject Change Package or click .
The Reject Change Package dialog box is displayed.
247

Chapter 7: Using Change Packages and Reviews
248
The following information is displayed:
ID is the change package ID number.
Summary is the summary description of change package.
Creator is the user name who created the change package.
Review As is the user name of the reviewer rejecting the change
package.
2 In the Capacity list, select the capacity in which you are the reviewer.
Due to factors determined by your administrator, the options in the
list vary per user for each change package. The possible options are:
Individual casts a vote as an individual reviewer in the
reviewer list.
Member of casts a vote on behalf of the entire group
(only a one user from a group is necessary to vote on behalf of the
entire group).
All Reviewers casts a vote as a specific user and any group to
which the reviewer belongs.
Super Reviewer casts an overriding reject vote that is sufficient
for rejecting the change package even if there are additional
reviewers. A super reviewer does is not required to be a listed
reviewer for the change package.
3 Enter comments on the change package elements in the Comments
field if desired.
4 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 (see “Viewing the CP Review Log” on
page 250). An e-mail notification of the change package’s 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 242.
u s e r g u i d e

Opening
Change
Packages
CP Review
Notifications
Change Package Review Process
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 opened: CommitFailed, Rejected, and Discarded.
CAUTION
Only a Change Package Administrator can open a change package in the
Closed state. Modifying closed change package contents can compromise the
integrity of the server repository.
To open a change package in the graphical user interface and
Web interface
1 Do one of the following:
From the graphical user interface, do one of the following:
From the Manage Change Packages view, select the change
packages to be opened.
Display the change package in the Change Package view
Select Change Package > Open or click .
From the Web interface, with a Project or Member History view
open, click the change package ID. The Change Package View is
displayed.
Select Actions > Open Change Package or click .
The change package is opened.
E-mail notifications are sent out to change package reviewers, watchers,
and the creator at points throughout the change package review process.
For specific information on when each e-mail notification is sent, see the
individual procedures; or for an overview, see “CP Review Workflow” on
page 242.
Each e-mail notification contains a description of the action that prompted
the notification, change package information containing the details and
entries, and Review information containing reviewer and voting
information. Some aspects of e-mail notification may be configured
specifically for your review implementation, including no e-mail
notification. Contact your administrator for more information.
249

Chapter 7: Using Change Packages and Reviews
Viewing Reviews
Viewing Your
Pending
Reviews
Viewing the CP
Review Log
250
Source Integrity provides you with a list of all of the change packages you
are currently listed as a reviewer for. Review information is viewable from
the Change Package view review log.
As a reviewer, you can view all of the change packages you are to review
from one convenient view. A change package only appears in the list after
it is submitted. You can then view all of the review information
individually for each change package.
NOTE
It is possible for you to be a reviewer of a change package you created. Contact
your administrator for more information.
To view your reviews in the graphical user interface
1 Select Tools > My Reviews.
The Change Packages for to review view is displayed.
By default, the following information is displayed:
ID is the change package ID.
Issue is the issue ID if the Integrity Manager integration is
enabled.
Creator is the user name who created the change package.
State is current state of the change package (see “CP States” on
page 241).
Summary is the summary statement for the change package.
The columns are the same as those in the Change Package view. To
modify the columns that appear, see “View Preferences” on page 61.
Source Integrity provides review logs as part of a complete review audit
process. A log consists of individual records for each reviewer vote cast.
Each time the change package is submitted for review, a new log begins.
To view the change package review log in the graphical user interface
and Web interface
From the Change Package view (see “Viewing Change Package Details and
Entries” on page 226), click the Review Log tab.
u s e r g u i d e

The Review Log panel appears.
Viewing Reviews
Each change package review log contains a record of every vote by a
reviewer on the change package. Each review record contains the
following information:
Review State
The possible review states are:
Review Pending the change package is still in a state of Submitted and
there are outstanding votes to be cast by reviewers.
Accepted the change package is in a state of Accepted, and all of the
individual reviewers and a user from each reviewer group have
accepted the change package.
Rejected the change package is in a state of Rejected, and at least one
reviewer has rejected the change package.
Reviewer Type
The possible reviewer types are:
User Reviewer is a user voting in an individual capacity.
Group Reviewer is a user voting in a group capacity on behalf of that
group.
Super Reviewer is a user casting an overriding vote in a super
reviewer capacity, and is not required to be a user on the reviewer list
or in a group on the group reviewer list.
Vote
The possible vote values are:
Pending signifies that the reviewer or group reviewer has not yet cast
a vote.
Accepted signifies that the user has cast an accept vote for the change
package.
Rejected signifies that the user has cast a reject vote for the change
package.
Comments
Displays information that reviewers optionally provide to clarify their
votes.
251

Chapter 7: Using Change Packages and Reviews
252
Changes
Displays in tabular form the changes that were made to members upon
submission of the change package. For information on the columns
displayed, see “Change Package View” on page 443.
Managing Change Package Entries
Moving CP
Entries
Source Integrity provides flexibility for managing change package 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.
Note the following about moving change package entries:
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.
To move change package entries in the graphical user interface
1 From the Entries panel on the Change Package view, select the change
package entries you want to move.
2 Do one of the following:
Select Change Package Entry > Move.
Click .
The Move Change Package Entry dialog box is displayed.
u s e r g u i d e

Managing Change Package Entries
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.
If you want to create a new change package for the entries, click
Create. For more information, see “Creating a Change Package” on
page 217.
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.
4 When you are finished, click OK.
The Confirm Move Change Package dialog box is displayed.
5 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 With a Project or Member History view open, click the change
package ID.
The Change Package view is displayed.
2 Click the Entries tab.
The Entries panel is displayed.
3 Select the change package entries you want to move.
4 Do one of the following:
Select Actions > Move Change Package Entry.
Click .
The Move Change Package Entry dialog box is displayed.
253

Chapter 7: Using Change Packages and Reviews
Discarding CP
Entries
254
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.
If you want to create a new change package for the entries, click
Create. For more information, see “Creating a Change Package” on
page 217.
6 When you are finished, click OK.
The Confirm Move Change Package dialog box is displayed.
7 To move the entry, click Yes. Repeat for additional entries.
The change package entries are moved to the selected change package.
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.
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 and
working file changes are reverted. Source Integrity confirms all
working file overwrites.
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).
Note the following about 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).
To discard change package entries in the graphical user interface
1 From the Entries panel on the Change Package view, select the change
package entries you want to discard.
u s e r g u i d e

Viewing CP
Entry Member
Differences
2 Do one of the following:
Select Change Package Entry > Discard.
Click .
Managing Change Package Entries
The Confirm Discard Change Package Entry dialog box is displayed.
3 To discard each entry presented, click Yes. To discard all entries
without viewing individual prompts, click Yes to All.
The change package entry or entries are discarded.
To discard change package entries in the Web interface
1 With a Project or Member History view open, click the change
package ID.
The Change Package view is displayed.
2 Click the Entries tab.
The Entries panel is displayed.
3 Select the change package entries you want to discard.
4 Do one of the following:
Select Actions > Discard Change Package Entry.
Click .
The Confirm Discard Change Package Entry dialog box is displayed.
5 To discard the entry, click Yes. Repeat for additional entries.
The change package entry or entries are discarded.
From the Change Package view, you can view the member differences of
any change package entry.
For updates, Source Integrity 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, Source Integrity compares revisions 1.3 and 1.2,
displaying them in the Differences window
For lock entries in the graphical user interface, Source Integrity compares
the working file with its immediately preceding revision. You cannot
difference a lock entry that does not have an associated sandbox.
255

Chapter 7: Using Change Packages and Reviews
256
To view change package entry member differences in the Graphical
user interface
1 With the Manage Change Packages window open (see “Managing
Change Packages” on page 220), select the change package that
contains entries that you want to difference.
2 Do one of the following:
Select Change Package > View Change Package.
Double click the change package.
The Change Package view is displayed.
3 Select the change package entry you want to difference
4 Select Change Package Entry > View Differences.
The Differences window appears displaying the two revisions sideby-side,
highlighting the differences between them, or
Source Integrity informs you that there are no differences. For more
information, see “Comparing Differences” on page 205.
To view change package entry member differences in the Web
interface
1 In a Project view, select a member that has a change package
associated with it.
2 Under the C.P.ID column, click the number link for the change
package.
The Change Package view is displayed.
3 Select the change package entry you want to difference.
4 Do one of the following:
Under the Actions menu, click View Member Differences.
Click .
The Differences window appears displaying the two revisions sideby-side,
highlighting the differences between them, or
Source Integrity informs you that there are no differences. For more
information, see “Comparing Differences” on page 205.
u s e r g u i d e

Viewing and Editing
Projects, Sandboxes, and
Members
8
KEY TERMS: project information, project history, label, promote, demote, checkpoint,
attribute, member information, freezing, thawing, member revision
Source Integrity allows you to perform a variety of functions to control
projects, sandboxes, and members during your development cycle. For
example, you can freeze members to prevent changes and thaw them to
allow changes. You can also checkpoint projects to provide a snapshot of
their contents at particular development points, so you can always
reproduce complete project configurations (including the files and the
directory trees they reside in) at any time in the future.
This chapter provides details on the following:
“Controlling Projects” on page 258
“Controlling Sandboxes” on page 280
“Controlling Members” on page 287
“Generating Reports” on page 303
257

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Controlling Projects
Viewing and
Editing Project
Information
258
To help you control your projects, Source Integrity provides functionality
for working with project information such as project histories, labels,
states, development checkpoints, and project revisions.
Source Integrity allows you to view and edit three categories of project
information:
general project information
project attributes
development path information
To view or edit project information in the graphical user interface and
Web interface
1 With a Project or Sandbox view open, select the project or sandbox.
2 In the GUI from a Project view, select Project > Properties > Project
Information.
In the GUI from a Sandbox view, select Sandbox > Properties > Project
Information.
In the Web from a Project view, select Project > Project Information.
The Project Information dialog box is displayed.
3 View or make changes to the project information as required.
u s e r g u i d e

The General tab displays the following project information:
Project Name is the path and name of the project.
Controlling Projects
Shared From appears only if the project you selected is a shared
subproject and displays the path and name of the project where
the shared subproject originated. For information on Shared
Subprojects, see “Adding a Shared Subproject” on page 127.
Server is the Integrity Server name and port number where the
project resides.
Development Path displays the development path name (if a
variant project on a development path, or project contains a
variant subproject on a development path).
Revision is the project’s current revision number.
Last Checkpointed is the last date and time the project was
checkpointed.
Members is the number of members in the project, not including
subprojects.
Subprojects is the number of subprojects in the project.
Description is a free-form text description of the master project.
Edit the existing description, or enter a new description.
For information about the Attributes tab, see “Working With Project
Attribute Information” on page 259. For information about the
Development Paths tab, see “Working With Development Path
Information” on page 261.
4 To accept any changes you have made, click OK.
The project information is saved.
Working With Project Attribute Information
Configuration options in project files are sometimes called attributes.
Within project files, you can set your own attributes as well as those
predefined as options. You can set these attributes from the graphical user
interface or Web interface.
In the graphical user interface, you can view and edit project attribute
information through the Attributes tab. Attributes define local variables or
set options. You can set either master project attributes to apply across an
entire project or sandbox attributes that apply only in your workspace,
sometimes overriding project attributes.
259

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
260
Attributes can have either of the following formats:
variable
variable=value
For more information on project attributes, see the Integrity Server
Installation and Administration Guide.
To view or edit project attribute information in the graphical user
interface
1 Select the target project.
2 Select Project > Properties > Project Information.
The Project Information dialog box is displayed.
3 Click the Attributes tab.
The Attributes panel appears.
4 In the Variable field, enter a variable, for example, OS.
NOTE
The variable name cannot include the “=” character.
5 In the Value field, enter a value, for example, Win32.
6 To add the attribute, click Add. To remove attributes, select them, then
click Remove.
The attributes appear in the attributes list.
u s e r g u i d e

7 To accept any changes you have made, click OK.
The project information is saved.
Controlling Projects
To view or edit project attribute information in the Web interface
1 Open the target project by selecting File > Open Project.
2 Select Project > Project Information.
The Project Information dialog box opens.
3 Scroll to the Attributes section.
4 In the Variable field, enter a variable, for example, OS.
5 In the Value field, enter a value, for example, Win32.
6 To add the attribute, click Add.
The attributes appear in the attributes list.
To remove attributes, select them, then click Remove.
7 To accept any changes you have made, click OK.
The project information is saved.
Working With Development Path Information
A development path is an identifier given to a new direction of file
development. Changes made through the new development path are kept
separate from the main development trunk unless you later choose to
merge them.
261

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
262
In the graphical user interface, the Development Paths tab shows a
selectable list of any development paths created from the current project. A
development path is identified by name, with the revision number (on
which the development path is based) in brackets, for example,
Aurora_Beta_Variant (1.1).
CAUTION
If you remove a development path that is referenced by a variant sandbox, you
can no longer open that variant sandbox.
To view or edit project development path information in the graphical
user interface
1 Select the target project.
2 Select Project > Properties > Project Information.
The Project Information dialog box is displayed.
3 Click the Development Paths tab.
The Development Paths panel appears.
4 To delete a development path, select one from the list.
5 Click Delete.
The development path is deleted from the list.
6 To accept any changes you have made, click OK.
The project information is saved.
u s e r g u i d e

Viewing a
Project History
TIP
Controlling Projects
To create a development path, see “Creating a Development Path” on page 147.
To view development path information in the Web interface
1 Open the target project by selecting File > Project.
2 Select Project > Project Information.
The Project Information dialog box opens.
3 Scroll to the Development Paths section.
4 Review the development path information presented in the text field.
When you want to view the history of a project, you can open its project
history. Opening the project history of a sandbox is the same as viewing
the project history of its master project.
The Project History view is a window that displays the revision history of a
project, including details on the revision number, author, date, labels, and
promotion state of the project.
To view a project history in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select the project or sandbox.
2 From a Project view, select Project > View Project History.
From a Sandbox view, select Sandbox > View Project History.
The Project History view is displayed.
In the graphical user interface, you can toggle between the Graphical
History view and the List view in the Project History view. For more
information on toggling views, see “Changing Views (GUI)” on
page 449.
263

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
264
Project History Filters
Like the filters in the Project and Sandbox views, the Project History filters
allow you to view and manipulate a predefined subset of project revisions
that are grouped according to their properties.
You can apply filters to a Project History in either the Graphical History
view or the List view. Project History filters are located in the View menu.
Choose one of the following filters, and your view is filtered accordingly:
All Revisions shows all the revisions in the project.
You cannot use the All Revisions filter in combination with other
filters. Selecting the All Revisions filter deactivates other filters. A
bullet next to the All Revisions filter indicates that it is active.
Development Paths shows all the revisions with a development path.
Labeled shows all revisions that have labels.
You can use the Development Paths filter and Labeled filter in
combination to show all the revisions with a current development
path and a label. A check mark next to the filter indicates the active
filter.
u s e r g u i d e

Opening a Build
Project
Adding Project
Labels
Controlling Projects
Once a filter is applied, operations performed on project members
apply only to those members shown as a result of the filter. For
example, if you apply the filter for Labeled and then perform a History
> Lock operation for that project, the lock operation applies only to
those members shown by the Labeled filter.
A Build project is a static project based upon a specific revision of the
master project. It is used for building or testing the project, but not for
further development.
To open a build project in the graphical user interface
1 With a Project History view open, select the revision you want to open
as a Build project.
2 Select History > Open Build Project.
The Build project appears in a new Project view.
To open a build project in the Web interface
1 From the File menu, select Open Build Project.
The Select Build Project dialog box opens.
2 Select the project you want to open from the Project list, and specify
the project revision (if necessary) in the Project Revision list.
The Build project appears in a Project view.
As with project members, you can add labels to project revisions. 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 revision of the project. Labels appear in
alphabetical order.
To add a label to a project in the graphical user interface and Web
interface
1 With a Project History view open, select the revision you want to label.
2 Do one of the following:
Select History > Add Label.
Click .
The Add Project Label dialog box is displayed.
265

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Deleting Project
Labels
266
TIP
In the Source Integrity Web interface, you can also add a project label from the
Project view by selecting Project > Add Label.
3 In the Label field, enter a label for the project, for example, Bug Fixes.
Labels cannot contain colons (:), square brackets ([ ]), or leading
spaces. Additionally they cannot have the same format as a valid
revision number.
4 In the graphical user interface, to move an existing label to another
revision, select the Move Existing Label option.
In the Web interface select one of the following options from the list:
Select Yes to move an existing label to another revision.
Select No to maintain the label location.
Select Confirm to be asked for confirmation about the action to be
taken.
5 To accept the new label, click OK.
The project revision is labeled.
As with project members, 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.
To delete a project label in the graphical user interface and Web
interface
1 With a Project History view open, do one of the following:
Select History > Delete Label.
Click .
The Delete Project Label dialog box is displayed.
u s e r g u i d e

Promoting a
Project
TIP
Controlling Projects
In the Source Integrity Web interface, you can also delete a project label from
the Project view by selecting Project > Delete Label.
2 From the Label list, select a label to delete from the project, for
example, Bug Fixes.
3 To confirm the deletion, click OK.
The project label is deleted.
As with a project member, you can promote the project itself (or change its
state). Controlling a project’s state helps in managing the entire project
through the development cycle, especially if the promotion function is
restricted to key project personnel.
Promotion is the process of managing data as it moves through a
structured development cycle. Any project (whether it is software
development, document production, or any other type of data
management) goes through recognizable phases: from inception, through
development, testing, quality assurance, and completion.
Typically, you promote a project (or set its state) when you checkpoint it,
but you can do so at any time.
The available promotion states are defined by your administrator.
When you promote a project, only the project (.pj) file is affected.
Individual members of the project are not changed.
To promote a project in the graphical user interface and Web interface
1 With a Project History view open, select the revision you want to
promote.
267

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Demoting a
Project
268
2 Do one of the following:
Select History > Promote.
Click .
The Promote Project dialog box is displayed.
TIP
In the Source Integrity Web interface, you can also promote a project from the
Project view by selecting Project > Promote.
3 Select a new state from the Promote to State list, for example, Beta.
4 To accept the new state, click OK.
The project is promoted.
As with a project member, you can demote the project itself (or change its
state). Typically, you demote a project (or set its state) when you
checkpoint it, but you can do so at any time.
NOTE
When you demote a project, only the project file (.pj) is affected. Individual
members of the project are not changed.
To demote a project in the graphical user interface and Web interface
1 With a Project History view open, select the revision you want to
demote.
2 Do one of the following:
Select History > Demote.
Click .
The Demote Project dialog box is displayed.
u s e r g u i d e

Checkpointing
a Project
TIP
Controlling Projects
In the Source Integrity Web interface, you can also demote a project from the
Project view by selecting Project > Demote.
3 Select a state from the Demote to State list, for example, Exp.
4 To accept the new state, click OK.
Just as you check in a source file to preserve the changes made to it from
one revision to another, you can also track the evolution of an entire
project. In Source Integrity, this process is called checkpointing.
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 at any time in the
future. The saved information includes the project structure and the list of
members with their revision numbers.
A checkpoint saves a copy of the project in the project’s history as a
revision, including the list of members along with their revision numbers,
and project and member attributes.
You can use the project’s revision number to keep track of your projects,
but to simplify post-release 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.
NOTE
Checkpointing a project affects the project only; it does not check in every
member of the project.
If you are working in a sandbox, issuing a checkpoint command
checkpoints the sandbox’s master project.
269

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
270
If you want to create a variant or build sandbox, you must first checkpoint
the project.
To checkpoint a project in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select the project or sandbox.
2 From a Project view, do one of the following:
Select Project > Checkpoint Project.
Click .
From a Sandbox view, do one of the following:
Select Sandbox > Checkpoint Project.
Click .
The Checkpoint dialog box is displayed.
3 Click an option tab, if necessary, then modify the checkpoint options.
The General tab specifies general checkpoint options:
Label is a unique text string assigned by you to identify a new
project revision, for example, Beta. Labels cannot contain colons
(:), square brackets ([ ]), or leading spaces. Additionally they
cannot have the same format as a valid revision number. To add
labels to a project from a Project or Sandbox view, see “Adding
Labels to Members” on page 297.
u s e r g u i d e

Restoring a
Project
NOTE
Controlling Projects
If you specify a label that contains the same name as one used for another
project revision in the history, and have the MoveProjectLabel permission,
the label from the earlier project revision is moved to the new revision. For
more information, contact your administrator.
Apply Label to All Members applies the checkpoint label to all
project members.
Notify when Complete (graphical user interface) causes
Source Integrity to confirm that the checkpoint operation has
finished.
State is a one-word description of a new revision’s status. Select a
state from the State list, for example, Exp.
Apply State to All Members applies the checkpoint state to all
project members.
The Advanced tab specifies advanced checkpoint options:
Recurse into Subprojects recursively checkpoints subprojects.
This option must be selected for the entire project to be
checkpointed.
If a subproject is a build project, the checkpoint references the
subproject and identifies it as being of build type, but does not
checkpoint it.
Author is the author name applied to the checkpoint. Your user
name appears by default.
4 In the Checkpoint Description field, enter a description of the
checkpoint, for example, Ready for peer review.
5 To accept the checkpoint, click OK.
The Restore Project command allows you to restore a project to a
previously checkpointed revision. When you apply the Restore Project
command, Source Integrity modifies the selected project to reflect the
member list of the target project revision. Any further development then
proceeds from the restored project revision.
271

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
272
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. Restoring a project is not an option when the goal is to test a
particular version.
IMPORTANT
Do not use the Restore Project command to create a new development branch
from a previously checkpointed project revision. For new development paths,
you should instead create a development path (see “Creating Variant
Sandboxes and Development Paths” on page 146).
Source Integrity 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.6 final checkpoint
1.5 pre-checkpoint
You would then continue your project development work from revision
1.6.
You can effectively undo the Restore Project command by restoring the
project to the pre-checkpointed revision. Build projects cannot be restored
using the Restore Project command.
You can restore any registered project or subproject through the graphical
user interface, using either a Project or Sandbox view, or through the
command line interface. When you work through a sandbox or
subsandbox, the corresponding master project is referenced. The Restore
Project command can be applied to both normal and variant projects.
To restore a project or subproject in the graphical user interface
1 With a Project or Sandbox view open, select the project or sandbox.
2 From a Project view, select Project > Restore Project.
From a Sandbox view, select Sandbox > Restore Project.
The Restore Project dialog box is displayed.
u s e r g u i d e

Controlling Projects
By default, Source Integrity selects the head revision as the project
revision to restore.
3 Click an option tab, and then modify the options for restoring the
project:
The Selection tab provides two methods for selecting the project
revision you want to restore.
Pre-Defined Revision that is, by default, the Head revision of the
project. The Head revision represents the latest revision on the
default branch of development (or on the trunk, if no default is
specified).
The Trunk Tip represents the latest revision in the main branch
of development, independent of the default branch settings.
To select a pre-defined project revision, choose the desired
revision from the list.
Specific Revision that is, by default, the most recently
checkpointed project revision.
To change the specific revision, select the Revisions tab or the
Labels tab.
The Revisions tab allows you to select a specific project revision by
number from the list of existing project revisions (in other words, from
all previously checkpointed versions of the project).
273

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
274
The Labels tab allows you to select a specific project revision by label
from the list of existing project revisions (in other words, from all
previously checkpointed versions of the project).
4 In the Reason For Restore field, enter a description of the reason for
restoring the project.
5 To complete the restore operation, click OK.
The selected version of the project is restored.
In the member information pane of your Sandbox view,
Source Integrity displays information on the corresponding working
file and available revision.
u s e r g u i d e

Viewing Project
Differences
Controlling Projects
6 To update the working file to the member revision number of the
target project, highlight the member and resynchronize it by choosing
Member > Resynchronize.
Source Integrity updates the working files to the member revision
number of the target project. All restored members are returned to the
initial state (by default, this is EXP).
Typically, the next time you check in the restored members, the
member revision number is incremented to the next sequential level.
Source Integrity allows you to view a summary of the changes that have
occurred between two versions of a project. In the graphical user interface
and Web interface, this functionality is provided through View Project
Differences. In the command line interface, you can access this
functionality through the si mods command.
Information is provided on any change packages that have been applied
between two revisions of the project. This information is extremely useful
for confirming the specific content of a project.
For more information on checkpointing, see “Checkpointing a Project” on
page 269.
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.
Source Integrity can also checkpoint subprojects if a project is
checkpointed recursively.
The changes to a project and its members are not tracked as they happen,
but rather the View Project Differences command takes two checkpoints (or
a checkpoint and the current version) of the project and then compares
them.
The View Project Differences command can compare the following:
two specified revisions of the project
the current revision of the project with a specified revision
the current version of the project with the last checkpointed revision
275

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
276
Change package information displayed on the By Change Package panel is
drawn from the modifications calculated from the checkpoint comparison.
For more information, see “Project Differences View” on page 462.
Viewing Differences Between Two Specified
Revisions of the Project
To view differences between two specified revisions of a project, you select
the individual revisions so that Source Integrity can compare them.
To view project revision differences in the graphical user interface
If you select more than two project revisions, the View Project Differences
command is disabled. You can only view project differences for one project
or between two versions of a project.
1 With a Project or Sandbox view open, select the project whose
differences you want to view.
2 From a Project view, select Project > View Project History.
From a Sandbox view, select Sandbox > View Project History.
The Project History view is displayed.
3 From the Project History view, select the two revisions of the project
you want to compare. Use CTRL when clicking to select or clear a
selection.
u s e r g u i d e

4 With the required versions selected, do one of the following:
Select History > View Project Differences.
Click .
Controlling Projects
The Project Differences view opens, displaying the list of project
differences.
For information about the view, see “Project Differences View” on
page 462.
To perform further comparisons, close the Project Differences view
and return to the Project History view.
To return to the Project History view, select Window from the
Source Integrity menu and choose Project History from the list.
To view project revision differences in the Web interface
If you select more than two project revisions, the View Project Differences
command is disabled. You can only view project differences for one project
or between two versions of a project.
1 Select the project whose differences you want to view.
2 From a Project view, click Project > View Project History.
The Project History view is displayed.
3 From the Project History view, click the check boxes of the project
versions you want to compare.
4 With the required versions selected, do one of the following:
Click History > View Project Differences.
Click .
The Changes Since view opens, displaying the list of project
differences.
277

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
278
Using a Project view in the Web interface, you can also compare the
current version of the project with the last checkpointed revision by
clicking Project > View Project Differences.
Viewing Differences Between the Current Revision
of the Project With a Specified Revision
To compare the current revision of a project with a specified revision, you
select the individual revision and Source Integrity compares it to the
current revision.
In the graphical user interface, from the Project History view (in either the
List view or the Graphical History view), select one version of the project.
Then select History > View Project Differences, Source Integrity compares
the current project revision with the specified revision.
The Project Differences view opens, displaying the list of project
differences. For information, see “Project Differences View” on page 462.
In the Web interface, from the Project History view, select one version of
the project. Then select History > View Project Differences, Source Integrity
compares the current project revision with the specified revision.
The Changes Since view opens, displaying the list of project differences.
u s e r g u i d e

Controlling Projects
Viewing Differences Between the Current Version of
the Project With the Last Checkpointed Revision
When no specific version of the project is selected, Source Integrity
compares the current revision of the project with the last checkpointed
revision. This comparison shows all of the changes to the project since it
was created or since the last time it was checkpointed.
In the graphical user interface (in the List view or the Graphical History
view), no project is selected so that Source Integrity compares the current
revision of the project with the last checkpointed revision. This comparison
shows all of the changes to the project since it was created or since the last
time it was checkpointed. For information about the view, see “Project
Differences View” on page 462.
In the Web interface, no project is selected so that Source Integrity
compares the current revision of the project with the last checkpointed
revision. This comparison shows all of the changes to the project since it
was created or since the last time it was checkpointed.
Using a Project view in the Web interface, you can also compare the
current version of the project with the last checkpointed revision by
clicking Project > View Project Differences.
279

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Controlling Sandboxes
Viewing
General
Sandbox
Information
280
To help you manage your individual sandboxes, Source Integrity allows
you to view two categories of sandbox information:
general sandbox information
project attributes
sandbox attributes
General sandbox information includes the name you have given the
sandbox and the project it points to, together with the host name and port
number of the Integrity Server where the project resides, the current
revision of the project, the last checkpointed revision, and the number of
members and subsandboxes in the sandbox.
To view sandbox information in the graphical user interface
1 Do one of the following:
From the Registered Sandboxes view, select the sandbox. Then
click Information.
With a Sandbox view open, select the sandbox. Then select
Sandbox > Properties > Sandbox Information.
The Sandbox Information dialog box is displayed.
u s e r g u i d e

Viewing Project
Attributes From
a Sandbox
Controlling Sandboxes
The General tab displays the following general sandbox information:
Sandbox Name is the path and name of the sandbox.
Project Name is the path and name of the master project.
Server is the Integrity Server name and port number where the
master project resides.
Revision is the master project’s current revision number.
Last Checkpointed is the last date and time the master project was
checkpointed.
Members is the number of members in the sandbox.
Subsandboxes is the number of subsandboxes in the sandbox.
Sparse setting determines if the selected sandbox is a sparse
sandbox.
Shared setting determines if the selected sandbox is a shared
sandbox.
Line Terminator setting determines the type of ASCII character
Source Integrity recognizes as the end of a line of text: Native (or
automatic, the default setting), LF (or line feed, primarily for
UNIX applications), or CR/LF.
Project Description is a description of the master project.
Working from your sandbox, you can view project attribute information
through the graphical user interface. These are the attributes that apply
across the entire project. To modify project attributes, see “Working With
Project Attribute Information” on page 259.
Attributes can have either of the following formats:
variable
variable=value
To view project attributes in the graphical user interface
1 Do one of the following:
From the Registered Sandboxes view, select the sandbox. Then
click Information.
With a Sandbox view open, select the sandbox. Then select
Sandbox > Properties > Sandbox Information.
The Sandbox Information dialog box is displayed.
281

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Viewing
Sandbox
Attributes
282
2 Click the Project Attributes tab.
The Project Attributes panel appears.
The project attributes are displayed view-only.
3 To close the Sandbox Information dialog box, click OK.
Working from your sandbox, you can view and edit sandbox attribute
information through the graphical user interface. These are sandbox
attributes that apply to your workspace.
Attributes can have either of the following formats:
variable
variable=value
To view or edit sandbox attribute information in the graphical user
interface
1 Do one of the following:
From the Registered Sandboxes view, select the sandbox. Then
click Information.
With a Sandbox view open, select the sandbox. Then select
Sandbox > Properties > Sandbox Information.
The Sandbox Information dialog box is displayed.
2 Click the Attributes tab.
The Attributes panel appears.
u s e r g u i d e

Taking Sandbox
Snapshots
3 In the Variable field, enter a variable, for example, OS.
NOTE
The variable name cannot include the “=” character.
4 In the Value field, enter a value, for example, Win32.
Controlling Sandboxes
5 To add the attribute, click Add. To remove attributes, select them, then
click Remove.
The attributes appear in the attributes list.
6 To accept any changes you have made, click OK.
The sandbox information is saved.
A snapshot is a capture of 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 Integrity Server. The sandbox snapshot creates a
standard project revision from which a build sandbox can be created and a
development path assigned. The project revision number takes the form of
a branched revision in the project history. For example, if the head revision
of the project is 1.1, then the project revision created by the snapshot will
be 1.1.1.1.
The set of sandbox elements includes the following:
sandbox members identified with an archive and working revisions
from which the archive was created
former members that were dropped but are still present in your
sandbox
subsandboxes, identified by project name and type
former subsandboxes that were dropped but are still present in your
sandbox
Note the following about sandbox snapshots:
To be included in the snapshot, there must be no 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 with no 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.
283

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
284
Former subprojects that are still in the sandbox view appear as
subprojects in the snapshot.
Source Integrity 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.
Differencing can be performed between a project revision created by a
snapshot and another project revision (including revisions created by
a snapshot) in the project history, but the revision cannot be
differenced with the sandbox contents.
In order to specify an existing development path when taking a
sandbox snapshot, you must use the CLI. For more information, see
The Source Integrity Enterprise Edition CLI Reference Guide.
Members of a sandbox need to be associated with a corresponding
archive on the Integrity Server.
When recursing into subsandboxes, 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 snapshot a sandbox recursively that contains
subsandboxes, for those subsandboxes the snapshot creates a
branched project revision based on the revision of the subproject
captured in the last checkpoint of the master project (if one exists), not
the current revision of the subproject in your sandbox. Member
revisions are unaffected.
When you snapshot a sandbox non-recursively the subproject
elements refer to the exact type they were in the sandbox at the time
the snapshot is performed, so configured subprojects remain
configured. For more information, see “Configuring a Subproject” on
page 131.
The following is the recommended scenario for when to take a sandbox
snapshot in a development environment:
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 Snapshot the sandbox.
u s e r g u i d e

Controlling Sandboxes
4 Create a development path from the project revision that corresponds
to the snapshot (see “Creating a Development Path” on page 147).
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 Source Integrity Enterprise
Edition CLI Reference Guide.
The following is the recommended scenario for when to take a sandbox
snapshot in a build environment:
1 Checkpoint the project.
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 Perform a resynchronize of the required revisions to fix the build (you
can use resync cp).
5 Snapshot the sandbox, and use the project revision created by the
snapshot to recreate the build in the future using a build sandbox,
instead of using the original project checkpoint.
To take a snapshot of a sandbox in the graphical user interface
1 From a Sandbox view, select Sandbox > Snapshot Sandbox.
The Snapshot Sandbox dialog box is displayed.
285

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
286
2 Click an option tab, if necessary, then modify the snapshot. options.
The General tab specifies general snapshot options:
Label is a unique text string assigned by you to identify the
project revision created by the snapshot. Labels cannot contain
colons (:), square brackets ([ ]), or leading spaces. Additionally
they cannot have the same format as a valid revision number.
TIP
When creating a build sandbox, labels to identify the project revision created
by the snapshot.
Apply Label to All Members applies the snapshot label to all
sandbox members.
Notify when Complete causes Source Integrity to confirm that the
snapshot operation has finished. The notification message
displays the name and path of the sandbox, and revision number
of the project revision created by the snapshot.
u s e r g u i d e

Controlling Members
State is a one-word description of the snapshot revision’s status.
Select a state from the State list, for example, Exp.
Apply State to All Members applies the revision state to all project
members.
The Advanced tab specifies advanced snapshot options:
Recurse into Sub-sandboxes recursively snapshots the sandbox.
This option must be selected to snapshot the entire sandbox, and
is by default, selected.
Author is the author name applied to the snapshot. Your user
name appears by default.
3 If desired, in the Snapshot Description field, enter a description for the
snapshot.
4 When you are finished, to snapshot the sandbox, click OK.
The sandbox snapshot is taken and appears as a branched project
revision in the project history. To see the revision in the history, see
“Viewing a Project History” on page 263.
NOTE
Controlling Members
Viewing and
Editing Member
Information
If working files are missing from the sandbox, a warning appears 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), then perform
the snapshot.
To help you control your project members, Source Integrity provides
functionality for working with member information such as member
revisions, labels, development states, and information states.
Source Integrity allows you to view and edit four types of member
information:
general
attributes
labels
change package
287

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
288
To view or edit member information in the graphical user interface
and Web interface
1 With a Project or Sandbox view open, select the member whose
information you want to view or edit.
2 From the GUI, do one of the following:
Select Member > Properties > Member Information.
Click .
From the Web, do one of the following:
Select Member > Member Information.
Click .
The Member Information dialog box is displayed.
3 View or make changes to the member information as required.
The Member Information dialog box presents the following
information on the General panel:
Member Name is the path and name of the member.
Project/Sandbox Name is the path and name of the member’s
project or sandbox.
u s e r g u i d e

NOTE
Controlling Members
As part of the Change Package review process, if the member has a pending
operation against it or one of its revisions, the information appears in a note,
for example, This member has a pending update to member
revision 1.2 by devans.
Member Revision is the displayed member revision. To select
another member revision, choose a revision from the Member
Revision list.
Created By is the name of the user who created the revision and
the date and time it was created.
Locked By is the name of the user who locked the revision, and
the date and time it was locked.
Locked In is the sandbox location and host name of the computer
where the lock on the revision was made.
State is the state assigned to the revision. To change the state of
the revision, choose a state from the State list. For more
information on states, see “Promoting Members” on page 299.
Revision Description is a brief description of the revision. You
cannot change an existing revision description from this dialog
box, but you can append additional comments to it. To do so,
enter any supplemental information in the Revision Description
field below the present information (indicated by a line if an
existing description is present).
For information on the Attributes tab, see “To view or edit member
attributes in the graphical user interface” on page 290. For information
on the Labels tab, see “To view or edit member labels in the graphical
user interface” on page 292. For information on the Change Package
tab, see “To view a member’s change package information in the
graphical user interface” on page 230.
4 When you are finished viewing or editing the member information,
click OK to accept the changes.
The member information is saved.
289

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
290
Working With Member Attributes
You can add or delete member attributes that allow you to categorize
members, and then perform operations on them as a group. For example,
in the graphical user interface, you could use the Select command to
highlight only those members with the attribute sys=dos and then check
them out as a group.
Every project member can have any number of attribute statements that
define variables for the member. Attributes can have either of the
following formats:
variable
variable=value
To view or edit member attributes in the graphical user interface
1 Select the target member.
2 Select Member > Properties > Member Information.
The Member Information dialog box is displayed.
3 Click the Attributes tab.
The Attributes panel appears.
4 In the Variable field, enter a variable, for example, os.
u s e r g u i d e

NOTE
The variable cannot include the “=” character.
5 In the Value field, enter a value, for example, dos.
6 To add the attribute, click Add.
The attributes appear in the attributes list.
To remove an attribute, select it, then click Remove.
7 To accept the changes, click OK.
Controlling Members
To view or edit member attribute information in the Web interface
1 With the Project view open, select the member whose information you
want to view or edit.
2 Select Member > Member Information.
The Member Information dialog box opens.
3 Scroll to the Attributes section.
4 In the Variable field, enter a variable for example, os.
5 In the Value field, enter a value, for example, win32.
6 To add the attribute, click Add.
The attributes appear in the attributes list.
To remove attributes, select them, then click Remove.
7 To accept any changes you have made, click OK.
The member information is saved.
Working With Member Labels
Labels are unique text that describe and refer to a revision of a member.
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.
Although you generally assign a label to a new revision upon check in, you
may sometimes want to add an additional label or change the label
assigned to a revision.
Labels appear in alphabetical order.
291

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
292
To view or edit member labels in the graphical user interface
1 Select the target member.
2 Right click and select Member Information.
The Member Information dialog box is displayed.
3 Click the Labels tab.
The Labels panel appears.
4 In the Label field, enter a label for the member revision, for example,
Draft1.
5 To add the label, click Add.
6 To remove an existing label, select it from the list of labels, then click
Remove.
7 To accept the changes, click OK.
To view or edit member label information in the Web interface
1 With the Project view open, select the member whose information you
want to view or edit.
2 Select Member > Member Information.
The Member Information dialog box opens.
3 Scroll to the Labels section.
4 In the Label field, enter a variable for example, Draft1.
5 To add the label, click Add.
u s e r g u i d e

Updating a
Member’s
Revision
Controlling Members
6 To remove an existing label, select it from the list of Labels, then click
Remove.
The attributes appear in the attributes list.
7 To accept the changes, click OK.
The member information is saved.
Within the graphical user interface, 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 member’s history.
For example, if the current project member is revision 2.7 of an archived
file, but a newer revision (revision 2.8) has been added to the member’s
history, you can update the member to the new revision.
You can also update the member revision by using the Update Revision
command.
NOTE
You cannot update a frozen member’s revision. You must first thaw the
member and then update it. For information on thawing members, see
“Thawing Members” on page 302.
To update a member’s revision in the graphical user interface
1 With a Project or Sandbox view open, select one or more members to
update.
2 Select Member > Properties > Update Revision.
The Set Member Revision dialog box is displayed.
293

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
294
3 Click an option tab, if necessary, then modify the set member revision
options.
The Selection tab allows you to select a revision to update to.
NOTE
If Promotion is enabled by your administrator, the Last revision with State
option appears. This option allows you to update the revision by a specific
state.
To check out a revision by state, click Latest revision with State, then select a
state from the list. The options in the list depend on the states configured by
your administrator. For more information on the available states, see your
administrator.
A pre-defined revision is a symbolic revision that represents a location
in the development path. To select a pre-defined revision to update
the member to, click Pre-Defined Revision, then choose a pre-defined
revision from the list. The available pre-defined revisions are:
Working updates the member revision to the version of the
working file.
Head updates the member revision to the member’s head
revision.
Trunk Tip updates the member revision to the latest revision in
the trunk, independent of the default branch settings.
u s e r g u i d e

Controlling Members
Member Branch Tip updates the member revision to the latest
revision along the member’s current branch of development.
Saved Revision Rule updates the member revision to a saved
revision. The revision is one that was saved in the CLI using
--save option with the si updaterevision command, and can
be a specified revision or any symbolic revision. For more
information, see the Source Integrity Enterprise Edition CLI
Reference Guide.
To select a specific revision, click Specific Revision, then click the
Revisions, Labels, or Project tab to choose a revision.
The Revisions tab allows you to select a specific revision to make
the member revision.
The Labels tab allows you to make a specific labeled revision the
member revision.
The Project tab allows you set the member revision for the
following options:
Member revision on Variant allows you to make a specific
variant revision the member revision.
Member revision on a Project Build allows you to make a
specific build revision or label the member revision.
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 more information, see “Creating a Change Package” on page 217.
5 Under Options, you can specify the following information:
6 To commit the operation later, select Defer Update Revision.
If the change package reviews are mandatory, select this option to
create a pending entry for this operation at the time of change package
submission. If this option is not enabled, Source Integrity creates the
pending entry at the completion of this procedure. For more
information, see “Change Package Review Process” on page 240.
7 To close the change package when the operation is complete, select
Close Change Package.
8 To set the member revision, click OK (for multiple members, click OK
to All).
The member is updated to the specified revision.
295

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
296
To update a member’s revision in the Web interface
1 With a Project view open, select one or more members to update.
2 Select Member > Update Revision.
The Update Member Revision dialog box is displayed.
3 Click an option tab, if necessary, then modify the set member revision
options.
The Selection tab allows you to select a revision to update to.
To select a pre-defined revision to update, click Pre-Defined Revision,
then choose a pre-defined revision from the list. The available predefined
revisions are:
Head updates the member revision to the member’s head
revision.
Trunk Tip updates the member revision to the latest revision in
the trunk, independent of the default branch settings.
Member Branch Tip updates the member revision to the latest
revision along the member’s current branch of development.
Working updates the member revision to the version of the
working file.
Saved Revision Rule updates the member revision to a saved
revision. The revision is one that was saved in the CLI using
--save option with the si updaterevision command, and can
u s e r g u i d e

Adding Labels
to Members
Controlling Members
be a specified revision or any symbolic revision. For more
information, see the Source Integrity Enterprise Edition CLI
Reference Guide.
To select a specific revision, click Specific Revision, then click the
Revisions or Labels tab to choose a revision.
The Revisions tab allows you to select a specific revision to make
the member revision.
The Labels tab allows you to make a specific labeled revision the
member revision.
4 To add the operation to a change package, from the Change Package
list, select a change package.
5 In the field for Close Change Package, select one of the following
options:
Yes causes Source Integrity to close the associated change
package.
No causes Source Integrity to keep the associated change package
open.
Confirm causes Source Integrity to ask you for confirmation on
the action to be taken.
6 To set the member revision, click OK (for multiple members, click OK
to All).
The member is updated to the specified revision.
Labels are unique text that describe and refer to a revision. 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.
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.
In the Web interface, Source Integrity displays up to three member labels
in the Labels column of the Project view. If a member has more than three
labels, Source Integrity displays a link ( ) that you can click to view all
the member labels.
Labels appear in alphabetical order in selection lists.
297

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Deleting
Member Labels
298
To add a label to a member in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select one or more members to
label.
2 In the GUI, select Member > Properties > Add Label.
3 In the Web, select Member > Add Label.
The Add Label dialog box is displayed.
:member appears in the Revision field indicating the label will be
applied to the member revision.
4 In the Label field, enter a label for the member, for example, Draft1.
Labels cannot contain colons (:), square brackets ([ ]), or leading
spaces. Additionally they cannot have the same format as a valid
revision number.
TIP
You can also add labels to the member in the Member Information dialog box.
5 To move the label, if it already exists on another revision, select the
Move Existing Label option.
6 To accept the new label, click OK (for multiple members, click OK to
All).
The member is labeled.
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.
u s e r g u i d e

Promoting
Members
Controlling Members
To delete a member label in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select one or more members to
delete labels from.
2 In the GUI, select Member > Properties > Delete Label.
In the Web, select Member > Delete Label.
The Delete Label dialog box is displayed.
3 Select a label to delete from the Label list.
TIP
You can also delete a member’s labels in the Member Information dialog box.
4 To accept the deletion, click OK (for multiple members, click OK to
All).
The member label is deleted.
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.
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.
299

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Demoting
Members
300
To promote a member in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select one or more members to
promote.
2 In the GUI, select Member > Properties > Promote.
In the Web, select Member > Promote.
The Promote Member dialog box is displayed.
:member appears in the Revision field indicating the member revision
will be promoted.
3 Select a new state from the Promote to State list, for example, Test.
4 To accept the new promotion state, click OK (for multiple members,
click OK to All).
The member is promoted.
Project members can also be demoted to a predefined lower state of
development.
To demote a member in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select one or more members to
demote.
2 In the GUI, select Member > Properties > Demote.
In the Web, select Member > Demote.
The Demote Member dialog box is displayed.
u s e r g u i d e

Freezing
Members
Controlling Members
:member appears in the Revision field indicating the member revision
will be demoted.
3 Select a new state from the Demote to State list, for example,
Development.
4 To accept the new state, click OK (for multiple members, click OK to
All).
The member is demoted.
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 member’s archive, Source Integrity does not
update the project’s member revision.
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.
301

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Thawing
Members
302
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 302).
If a member is frozen, Source Integrity reports the availability of new
revisions when anyone checks them into the archive. Source Integrity 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.
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 appears beside utility.dll, revision 1.2 in
the Apex.pj Project view. (The snowflake symbol appears 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.
To freeze a member in the graphical user interface and Web interface
1 With a Project or Sandbox view open, select the member you want to
freeze.
2 In the GUI, select Member > Properties > Freeze.
In the Web, select Member > Freeze.
A snowflake symbol ( ) appears beside the selected member.
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.
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.
u s e r g u i d e

Generating Reports
About the
Report
Information
Generating Reports
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.
Source Integrity notifies that a newer revision of utility.dll
(version 1.3) is available to the project.
Once the developer’s 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. Source Integrity 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.
To thaw a member in the graphical user interface and Web interface
1 With a Project or Sandbox view open, select the member you want to
thaw. The member is one that is marked with a snowflake symbol
( ).
2 In the GUI, select Member > Properties > Thaw.
In the Web, select Member > Thaw.
The snowflake symbol beside the selected member disappears.
In the graphical user interface, Source Integrity Reporter analyzes projects,
their members, or individual archives, and allows you to generate a variety
of reports and graphs based on its findings. Reports and graphs can be
printed or viewed on the screen. To use Reporter, you must have a default
printer installed.
Reporter calculates a summary of the changes to a project or archive, then
displays or prints the summary as text or, for some reports, as a graph.
Customized reports, created using Microsoft Access, can also be
produced.
303

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
About Graphs
Report Types
304
Reporter’s data files (containing the results of its project or archive
analysis) can be saved as text files that can be read by most database
applications.
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
Whenever graphs are available in Reporter, you are given the option of
displaying the report in a text version (the default) or as a graph. If you
display a report as a graph, you can define how you want it to look. Using
graphs, you can give reports a custom look to suit your preferences or for
quick, project-specific identification.
Reporter allows you to generate different types of reports based on the
information Source Integrity maintains about project members and
revisions in the archives. Reporter can generate the following report types:
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 Fred and Ethel made changes
to several members, the report would include two sections, one for Fred
and one for Ethel. 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.
u s e r g u i d e

Changes Grouped by Author (Summary)
Generating Reports
This type of report shows a brief summary of changes made by each user.
Each type of project member (Text, Binary, Auto-Detect) appears 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
date of the newer revisions
revision description for each newer revision
Changes From Member Revision to Label
This report lists all revisions in a member’s 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
305

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
306
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:
name of the member
revision number
person who has it locked
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
u s e r g u i d e

Creating a Report
Project Member History
Generating Reports
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.
Source Integrity provides you with the ability to create reports.
Reports are summaries of the data in your project. Reports are based on the
standard and custom fields of issue types. Reports can be customized to
include images, fonts, hyperlinks, and can be saved as HTML files for
viewing on the Web.
To create a report in the graphical user interface
1 With a Project or Sandbox view open, select the project or sandbox
you want to report on.
2 From a Project view, select Project > Reports.
From a Sandbox view, select Sandbox > Reports.
The Select Report Type dialog box is displayed.
3 To save the results of the Reporter’s analysis to data files that can be
read by most database applications, select the Save Data Files option.
307

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
308
4 If you have created customized reports with Microsoft Access that you
want to use with Reporter, select the Show Customized Reports
option, then specify the report name with the Custom Reports selector.
5 From the Report Type list, select a report type to generate, as described
in “Report Types” on page 304.
6 Click OK.
If the report type requires additional information (for example, a
range of revisions), a second dialog box is displayed to collect it.
Reports appear in plain text format by default. Some report types,
however, allow you to display the information graphically.
7 To display a report as a report, click Report.
To display a report as a graph, click Graph.
8 If necessary, type in any additional information.
9 Click OK.
The report or graph appears in a scrollable, scalable window.
u s e r g u i d e

Viewing and Editing
Member Histories and
Revisions
9
KEY TERMS: member history, archive information, revision information, working file,
locking, unlocking, branching, merging
While sandboxes and projects allow you to manage and access project
members and the contents of individual members—the history of changes
are saved in member histories.
Source Integrity lets you save and recreate every stage (or revision) in the
development of each member you use.
When you make changes to a project member and check it back in, your
changes are automatically added to the member history. If you ever need
to see that version of the member again, check out the appropriate revision,
and Source Integrity rebuilds an exact copy for you.
This chapter provides details on the following:
“Viewing a Member History” on page 310
“Viewing and Editing Archive Information” on page 312 and
“Viewing and Editing Revision Information” on page 314
“Viewing an Annotated Revision” on page 316
“Viewing and Editing Revision Labels” on page 319
“Viewing a Member’s Working File or Revision” on page 322
“Promoting Revisions” on page 323 and “Demoting Revisions” on
page 324
“Locking Revisions” on page 324, “Unlocking Revisions” on page 326,
“Locking Multiple Revisions” on page 327, and “Managing Revision
Locks” on page 328
“Setting the Member Revision” on page 330, “Deleting Revisions” on
page 331, and “Comparing Revisions” on page 331
309

Chapter 9: Viewing and Editing Member Histories and Revisions
Viewing a Member History
310
You can view the entire history of a member, including information about
who modified individual revisions, revision labels, and revision
descriptions.
To view a member history in the graphical user interface and Web
interface
1 With a Project or Sandbox view open, select the member whose
history you want to view.
NOTE
In the Source Integrity Web interface, application functionality is not available
through the shortcut menu.
2 Do one of the following:
Select Member > View Member History.
Click .
The member history appears in a Member History view.
u s e r g u i d e

NOTE
Viewing a Member History
If there is an pending add operation for a member, you cannot view the
member history for that member because it has not yet been added to the actual
project.
You can toggle between the Graphical History view and List view in
the Member History view. For more information on toggling views,
see “Changing Views (GUI)” on page 449.
IMPORTANT
If you choose a project and select the View Member History command,
Source Integrity opens the member history for each member of the project. For
larger projects, this action requires a long execution time.
Member History Filters
Like the filters in the Project and Sandbox views, the Member History
filters allow you to view and manipulate a predefined subset of project
members that are grouped according to their properties.
311

Chapter 9: Viewing and Editing Member Histories and Revisions
312
You can apply filters to a Member History in either the Graphical History
view or the List view. Member History filters are located in the View menu.
Choose one of the following filters, and your view is filtered accordingly:
All Revisions shows all the revisions of the selected member.
You cannot use the All Revisions filter in combination with other
filters. Selecting the All Revisions filter deactivates other filters. A
bullet next to the All Revisions filter indicates that it is active.
Branched shows all the revisions that are branched.
Labeled shows all revisions with a label.
Locked shows all the revisions locked by any user.
Member shows the member revision, and shows the revision with the
working file (if it is different than the member revision).
Pending shows all pending revisions.
You can use filters in combination (except the All Revisions filter) to show
all the revisions on the current development path with a label. A check
mark next to the filter indicates the active filter.
Once a filter is applied, operations performed on project members apply
only to those members shown as a result of the filter.
Viewing and Editing Archive Information
Just as it maintains information about each project member,
Source Integrity also maintains historical information about each member
archive 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 strict-locking applies to the archive, and a
description of the archive.
The default branch is the branch Source Integrity tries to check in files to. If
unspecified during a check in, files are checked in to the trunk.
u s e r g u i d e

Viewing and Editing Archive Information
To view or edit archive information in the graphical user interface and
Web interface
1 With a Member History view open, do one of the following:
Select History > Archive Information.
Click .
The Archive Information dialog box is displayed.
2 Click an option tab, if necessary, then view or modify the archive
information:
The General tab specifies general archive information options.
Member Name is the path and name of the member that the
archive is for.
Project/Sandbox Name is the path and name of the member’s
project or sandbox.
Archive Name is the path and name of the displayed archive.
Archive Type displays the type of data stored in the archive.
Default Branch specifies the starting point of the default branch.
To specify a default branch, enter a branch number in the Default
Branch field, for example, 2.1.1.
313

Chapter 9: Viewing and Editing Member Histories and Revisions
314
Strict Locking specifies if a strict locking policy is in effect for the
archive. With strict locking on, a user must have a revision locked
before checking in any changes. To enable strict locking, select the
Strict Locking option.
Compressed specifies if the archive is compressed. To compress
the archive, select the Compressed option.
Store by Reference causes each revision to be saved to a separate
file, instead of saving all revisions to one file. This feature
improves performance for archives that contain large binary files.
To store the archive by reference, select the Store by Reference
option.
Archive Description describes the archive. If necessary, enter or
edit a description.
The Labels panel displays a list of revision labels in the archive, for
example, Draft1 1.1.
The Locks panel displays a list of users who have locks on revisions in
the archive, for example, sholmes 1.2.
3 To save your changes, click OK.
The archive information is saved.
Viewing and Editing Revision Information
Source Integrity maintains detailed information about each member
revision in a member history. In the graphical user interface, this revision
information displays in columns in the Member History view.
Each revision is assigned a unique revision number used to identify a
revision in a history. Revisions on the trunk 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.
The revision can also be viewed and modified with the Revision
Information command.
The Labels tab displays the labels assigned to the selected revision and also
allows you to add or remove labels. For more information on viewing and
editing revision labels, see “Viewing and Editing Revision Labels” on
page 319.
u s e r g u i d e

Viewing and Editing Revision Information
The Change Package tab provides information on change packages
associated with the revision. The Change Package tab only appears if
change packages are enabled.
To view or edit general revision information in the graphical user
interface and Web interface
1 With a Member History view open, select the revision whose
information you want to view or edit.
2 Do one of the following:
Select History > Revision Information.
Click .
The Revision Information dialog box is displayed.
3 View or make changes to the member information as allowed.
The General tab displays the following information:
Member Name is the path and name of the member.
Project/Sandbox Name is the path and name of the member’s
project or sandbox.
Revision is the revision corresponding to the displayed
information. If the revision is pending, then pending appears in
parenthesis (see “Working With Pending Revisions” on
page 335).
Created By is the name of the user who created the revision, and
the date and time it was created.
315

Chapter 9: Viewing and Editing Member Histories and Revisions
316
Locked By is the name of the user who locked the revision, and
the date and time it was locked.
Locked In is the sandbox location and host name of the computer
where the lock on the revision was made.
State is the state assigned to the member. To apply a different
state to the member, choose a state from the State list.
Revision Description is a brief description of the revision. You
cannot change an existing revision description from this dialog
box, but you can append additional comments to it. To do so,
enter any supplemental information in the Revision Description
field below the present information (indicated by a line if an
existing description is present).
4 To accept the changes, click OK.
The revision information is saved.
Viewing an Annotated Revision
Source Integrity provides an annotated revision view for member
revisions. Use it when you want to investigate the reason and
circumstances a revision was introduced or changed. 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 revisions in an annotated
list.
In annotation blocks, each line of the revision is displayed, with information
about the last modification made to each line of the revision’s contents. By
default, the annotated revision list includes the revision number, author,
date, line number, and revision contents.
You can view annotated revision information from the Project, Sandbox, or
Member History views.
When using the Annotated view:
you can only view 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 is
displayed, not deleted content
u s e r g u i d e

NOTE
Viewing an Annotated Revision
The annotated view can only be displayed for members of text format.
To view annotated revisions in the graphical user interface and Web
interface
1 With a Project, Sandbox, or Member History view open, select the
revision you want to view.
2 From a Project or Sandbox view, select Member > View Annotated
Member.
From a Member History view, do one of the following:
Select History > View Annotated Revision.
Click .
The Annotated Revision view is displayed.
The Annotated Revision view displays the following information:
Revision displays the revision number for each annotated block.
If the revision is pending, then pending appears in parenthesis
(see “Working With Pending Revisions” on page 335).
Author displays the author of the revision.
317

Chapter 9: Viewing and Editing Member Histories and Revisions
318
Date displays the date each member revision was created.
Line displays the line number for each line of text in the revision.
Revision Contents displays the text contained in each annotation
block.
C.P. ID displays the change package ID for the annotation block.
In the Web interface, the Revision Information for the specified
revision is displayed in the bottom frame.
To customize the fields displayed in the Annotated Revision view, see
“View Preferences” on page 61.
From the View menu, you can 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 appears.
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 is displayed in the center of the pane if it exists in a scrolling
region.
3 Select an annotation block, then from the History menu, select one of
the following:
Revision Information, see “Viewing and Editing Revision
Information” on page 314.
View Revision, see “Viewing a Member’s Working File or
Revision” on page 322.
View Member History, see “Viewing a Member History” on
page 310.
From the Change Package menu, select one of the following:
View Change Package, see “Using Change Packages and
Reviews” on page 213.
View Issue, see “Viewing a Change Package’s Issue” on page 376.
u s e r g u i d e

TIP
Viewing and Editing Revision Labels
From the graphical user interface, right click the annotation block and then
select an option.
Viewing and Editing Revision Labels
Although you generally assign a label to a new revision upon check in,
there may be times you want to add an additional label or change the label
assigned to a revision.
A revision label is a textual name that describes and refers to revisions in a
history. When a file is checked in, you are given the option of assigning it a
revision label. Revisions in a history can be displayed and selected either
by revision number or revision label.
To view or edit revision labels in the graphical user interface
1 With a Member History view open, select the revision whose
information you want to view or edit.
2 Do one of the following:
Select History > Revision Information.
Click .
The Revision Information dialog box is displayed.
3 Click the Labels tab.
The Labels panel appears.
4 In the Label field, enter a label for the revision, for example, Beta
Fixes. Labels cannot contain colons (:), square brackets ([ ]), or
leading spaces. Additionally they cannot have the same format as a
valid revision number.
319

Chapter 9: Viewing and Editing Member Histories and Revisions
Adding
Revision Labels
320
5 To add the label, click Add.
6 To remove an existing label, select it from the list, then click Remove.
7 To accept the changes, click OK.
The revision information is saved.
Although you generally assign 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 that is already assigned to a revision.
In the Web interface, Source Integrity displays up to three revision labels in
the Labels column of the Project view. If a revision has more than three
labels, Source Integrity displays a link ( ) that you can click to view all
the revision labels.
To add a label to a revision in the graphical user interface and Web
interface
1 With a Member History view open, select the revision you want to
label.
2 Do one of the following:
Select History > Add Label.
Click .
u s e r g u i d e

Deleting
Revision Labels
TIP
Viewing and Editing Revision Labels
You can also add a label using the Revision Information dialog box, as
described in “Viewing and Editing Revision Information” on page 314.
The Add Label dialog box is displayed.
3 In the Label field, enter a label for the revision, for example, Draft1.
Labels cannot contain colons (:), square brackets ([ ]), or leading
spaces. Additionally they cannot have the same format as a valid
revision number.
4 To move an existing label from the revision, select the Move Existing
Label option.
5 To add a label, if it already exists, to another revision, click OK (for
multiple members, click OK to All).
The revision label is added.
If you have assigned the wrong label to a revision, you can delete that label
either through the graphical user interface or the command line interface.
To delete a revision label from a revision in the graphical user
interface and Web interface
1 With a Member History view open, do one of the following:
Select History > Delete Label.
Click .
TIP
You can also delete a label using the Revision Information dialog box, as
described in “Viewing and Editing Revision Information” on page 314.
321

Chapter 9: Viewing and Editing Member Histories and Revisions
322
The Delete Label dialog box is displayed.
2 From the Label list, select a label to delete, for example, Draft1.
3 To accept the deleted label, click OK (for multiple members, click OK
to All).
The revision label is deleted.
Viewing a Member’s Working File or
Revision
When you view a revision, Source Integrity copies the revision to a readonly
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.
Although it can be used to show the contents of any revision in an archive,
this command is typically used with the working file, since it provides a
mechanism to open the member without leaving the Source Integrity
application environment.
A working file is a file that contains a working copy of a checked out
revision. Users edit and change the working file, not the revision itself.
Changes to the working file are added to the history (as a new revision)
when the working file is checked in.
To view a member’s working file or revision in the graphical user
interface or Web interface
1 With a Member History view open, select the working file or revision
you want to view.
u s e r g u i d e

2 Do one of the following:
Select History > View Revision.
Click .
Promoting Revisions
Promoting Revisions
The member’s working file or revision is opened in your default editor
or in the editor associated with the file’s extension.
Normally, you promote a member’s revision (set its state) when you
checkpoint its master project, but you can do so at any time.
To promote a revision in the graphical user interface and Web
interface
1 With a Member History view open, select a revision to promote.
2 Do one of the following:
Select History > Promote.
Click .
The Promote Member dialog box is displayed.
3 Select a new state from the Promote to State list, for example, Beta.
The next highest state appears in the Promote to State list.
4 To accept the new state, click OK (for multiple members, click OK to
All).
The revision is promoted.
323

Chapter 9: Viewing and Editing Member Histories and Revisions
Demoting Revisions
Locking Revisions
324
You can demote a revision by changing its promotion state setting from a
higher level to a lower one.
To demote a revision in the graphical user interface and Web interface
1 With a Member History view open, select a revision to demote.
2 Do one of the following:
Select History > Demote.
Click .
The Demote Member dialog box is displayed.
3 Select a new state from the Demote to State list.
By default, the next lowest state appears in the Demote to State list.
4 To accept the new state, click OK (for multiple members, click OK to
All).
The revision is demoted.
Revisions are normally locked at checkout time, but you can lock a revision
without checking it out of the archive. Locking a revision ensures that no
one else can modify that revision.
u s e r g u i d e

Locking Revisions
To lock a revision in the graphical user interface and Web interface
1 With a Member History view open, select a revision to lock.
2 Do one of the following:
Select History > Lock.
Click .
If your administrator has enabled the integration with Integrity
Manager and set the IMTrackLocksEnabled option, Source Integrity
opens the Lock Revision dialog box.
3 Configure the following options as necessary:
Change Package options appear only if change packages are
enabled. Select a change package from the Change Package drop
down list, or click Create to create a new change package.
Force Creation of New Branch causes Source Integrity to create a
branch off of the revision you are locking.
In the Web interface only, select an option from the list:
Select Yes to create a new branch.
Select No to not create a new branch.
Select Confirm to be asked for confirmation of the action to
be taken if branch creation is required.
Create Branch if Variant causes Source Integrity to create a branch
off of the revision you are locking, if you are working in a variant
sandbox. This option is available only through the graphical user
interface and command line interface.
To apply the lock with the selected options, click OK. To apply locks to
multiple files, click OK to All.
325

Chapter 9: Viewing and Editing Member Histories and Revisions
Unlocking Revisions
326
A padlock symbol appears next to the revision number, and your user
name and the date/time you locked the revision display in the Locked
column.
You can unlock a revision without checking it back into the archive.
Unlocking a revision does not discard any changes you have made;
however, resynchronizing or reverting the member would discard those
changes.
If you attempt to unlock a revision that is locked by another user, a
message warns you that you are about to break someone else’s lock.
NOTE
Although you may not be prohibited from breaking someone else’s lock, you
should be cautious about doing so, because it can result in confusion and
duplication of effort in shared working environments. For information on
permissions, see the Integrity Server Installation and Administration Guide.
To unlock a revision in the graphical user interface and Web interface
Do one of the following:
With a Member History view open, select a revision to unlock
(denoted by a padlock symbol), then do one of the following:
Select History > Unlock.
Click .
With the Locks for User window open (see “Locks View” on
page 450), select one or more locked revisions, then select Locks >
Unlock.
If the lock is not held by you, you are asked to confirm breaking the lock.
To confirm that you want to break the lock, click Yes.
The padlock symbol and the name of the user who had the revision locked
both disappear.
u s e r g u i d e

Locking Multiple Revisions
Locking Multiple Revisions
Locking a revision ensures that no one else can modify that revision. In
some cases locking more than one revision in a member history at the same
time is required.
Cases where you may require multiple locking include:
You are working on both the main branch of development (where new
development is occurring) and in a variant sandbox (where fixes are
occurring)
You are working in two variant sandboxes and need to modify a
different revision in the same member history in each sandbox
You are sharing the member history across many projects and need to
modify a different revision in the same member history in each
particular project
Locking multiple revisions triggers variant branching when necessary. For
example, if you are working in a variant sandbox that does not already
have its own branch, Source Integrity prompts you to create the branch.
Source Integrity then moves the variant and the variant member revision
to that branch. For information on working with variant sandboxes, see
“Creating Variant Sandboxes and Development Paths” on page 146.
NOTE
Your administrator must explicitly set the locking policy to allow locking
multiple revisions. See your administrator to find out if your system is
configured for multiple locking.
Multiple Lock Procedures
There are several ways to lock multiple revisions. The following sections
outline the procedures you can use.
To lock multiple revisions in the graphical user interface
From the Member History view:
Follow the procedure for Locking a Revision (see “Locking Revisions”
on page 324). Repeat to lock other revisions.
Follow the procedure for Checking Out a Member (see “Checking Out
a Member” on page 178) by specifying the revision number (Member
History view via the Sandbox view only). Repeat to check out and lock
other revisions.
327

Chapter 9: Viewing and Editing Member Histories and Revisions
Managing Revision Locks
328
From the Sandbox view, follow the procedure for Checking Out a Member
(see “Checking Out a Member” on page 178) by specifying the revision
number. Repeat to check out and lock other revisions.
To lock multiple revisions in the Web interface
From the Member History view:
Follow the procedure for Locking a Revision (see “Locking Revisions”
on page 324). Repeat to lock other revisions.
Follow the procedure for Checking Out a Member (see “Checking Out
a Member” on page 178) by specifying the revision number. Repeat to
check out and lock other revisions.
From the Project view, follow the procedure for Checking Out a Member
(see “Checking Out a Member” on page 178) by specifying the revision
number. Repeat to check out and lock other revisions.
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.
To manage revision locks in the graphical user interface and Web
interface
1 Select Tools > Manage My Locks.
The Locks for User window is displayed.
The Locks for User window displays the following information:
Project displays the name and path of the project where the
member revision was locked from. If the member revision was
locked from a shared subproject, it is the subproject name and
path that are displayed.
u s e r g u i d e

Managing Revision Locks
Member Name displays the member name for the locked revision.
Revision displays the locked revision number.
Time displays the time the revision was locked
You can also display other columns such as Archive Name, Host, User,
C.P. ID, Sandbox, Development Path. For more information, see “View
Preferences” on page 61.
You can perform the following tasks:
To delete a lock or locks, select a list item, then select Locks >
Unlock.
The revision is unlocked.
To refresh the list of locked revisions, select View > Refresh.
The list is updated.
To change the user (GUI only) whose locks are displayed, select
Locks > Change User.
The Retrieve All Locks for a User dialog box is displayed.
From the Locker list, select the name of the user whose locks you
want to view, then click OK.
The user’s locks are displayed in the Locks for User window.
NOTE
You may only view other users’ locks on revisions in archives that are in
projects you have permission to view. You can always view your locks for any
project regardless of project permissions.
From the Locks for User window, you cannot remove another user’s lock on a
member that was locked from a shared subproject.
Finding Locks
Source Integrity can display all of the locks for a specified user.
To find locks in the graphical user interface
1 Select Tools > Find > Locks.
The Retrieve All Locks for a User dialog box is displayed.
329

Chapter 9: Viewing and Editing Member Histories and Revisions
Setting the Member Revision
330
2 From the Locker list, select the name of the user whose locks you want
to view, then click OK.
The user’s locks are displayed in the Locks for User window.
NOTE
Although you may not be prohibited from breaking someone else’s lock, you
should be cautious about doing so, because it can result in confusion and
duplication of effort in shared working environments. For information on
permissions, see the Integrity Server Installation and Administration Guide.
You can specify a particular revision as the member revision for a project.
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.
To set the member revision from the member history in the graphical
user interface and Web interface
1 With a Member History view open, select the revision you want to
make the member revision.
2 Do one of the following:
Select History > Set Member Revision.
Click .
The selected revision becomes the member revision, indicated by a
member revision icon ( ).
u s e r g u i d e

Deleting Revisions
Comparing Revisions
Deleting Revisions
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. For more information, see
“Working With Pending Revisions” on page 335 and “Change Package
Review Process” on page 240.
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 graphical user interface
1 With a Member History view open, select the revision you want to
delete.
You can only delete one revision at a time in the graphical user
interface.
2 Do one of the following:
Select History > Delete Revision.
Click .
Source Integrity asks you to confirm the deletion.
NOTE
Any existing locks on revisions are removed when those revisions are deleted.
3 To delete the selected revision, click Yes. To keep the selected revision,
click No.
Source Integrity deletes the revision.
When you are working with an evolving body of source files, you can
compare two revisions to see what changes you made from one revision to
the next, or any two specific revisions.
331

Chapter 9: Viewing and Editing Member Histories and Revisions
332
With Source Integrity you can compare:
any two text-based revisions in a history
a text-based revision and its associated working file in a sandbox
any two text files
The commands discussed in this section for the graphical user interface use
MKS Visual Difference, a standalone application that compares and
merges members and revisions.
MKS Visual Difference calculates the differences between working files or
revisions and displays them side by side in their own panes, along with a
summary of the differences between the files. Using MKS Visual
Difference, you can also interactively merge two members or revisions. For
information on merging in MKS Visual Difference, see “Merging Two
Revisions” on page 356.
In the Web interface, the Differences window displays the revisions sideby-side
in the same pane. For more information on the MKS Visual
Difference interface, see “MKS Visual Difference Interface” on page 100.
Source Integrity allows you to use a third party differencing tool, in the
graphical user interface, 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 “Difference
Tool Preferences” on page 69.
To compare two revisions in the graphical user interface
1 With a Member History view open, select two revisions to compare, or
a revision and the working file.
To select two revisions in the graphical user interface, select the first
revision, then hold down CTRL and click the second revision.
2 Do one of the following:
Select History > Differences.
Click .
NOTE
In the Source Integrity Web interface, application functionality is not available
through the shortcut menu.
The MKS Visual Difference window is displayed.
u s e r g u i d e

Comparing Revisions
Both revisions and a summary of the differences between them are
displayed in the MKS Visual Difference window.
To compare two revisions in the Web interface
1 With a Member History view open, select two revisions to compare, or
a revision and the working file.
2 Do one of the following:
Select History > Differences.
Click .
The Differences window opens.
Both revisions and a summary of the differences between them are
shown in the Differences window.
333

Chapter 9: Viewing and Editing Member Histories and Revisions
334
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.
u s e r g u i d e

Working With Pending Revisions
Working With Pending Revisions
Pending revisions are created by Source Integrity when a change package
containing deferred operations is submitted. Pending revisions are also
created when reviews are mandatory and an operation that creates a new
revision is performed without deferral (see the documentation for the
desired operation for more information).
When reviews are mandatory, the pending revisions persist until the
change package is accepted and the changes are successfully committed to
the repository (and then become committed entries). If the change package
is rejected, the creator of the change package can edit pending revisions by
checking them out.
When reviews are not mandatory, you only see pending revisions under
the one of following circumstances:
Deferred operations, which when committed create a new member
revision, are submitted but fail to commit to the database.
A change package that contains deferred operations, which when
committed create a new member revision, is submitted but fails to
commit to the database.
If the changes fail to commit to the repository, Source Integrity moves the
change package to a state of CommitFailed. You can submit the operation
or change package again (the pending revisions are then changed to
member revisions), or open the change package and continue development
and then submit the change package. For more information, see
“Submitting Deferred Operations” on page 202 and “Change Package
Review Process” on page 240.
Pending revisions are denoted with pending in parenthesis in all views
that display revision numbers, for example 1.2 (pending).
Reviewing a Pending Revision
To review a pending revision created by the action of another user, obtain
a working file for the revision by checking out the revision by its number
(you cannot obtain a lock on the pending revision).
You can view the working file for the pending change package entry from
the Change Package view by selecting Entries > Edit Working File (See
“Viewing Change Package Details and Entries” on page 226).
Resyncing a pending revision from your sandbox, replaces the working file
(corresponding to the pending revision) with the member revision.
335

Chapter 9: Viewing and Editing Member Histories and Revisions
336
Pending members
A pending member, is a member that is associated with a pending operation
that adds it to the project. The pending member is denoted by a pending
icon displayed in the Name column of the Sandbox and Project views.
The following are commands that create pending members: Import, Add,
Add From Archive, Rename To.
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.
Pending Revision Caveats
Except for the following information, all commands that involve revisions
can be performed on pending revisions.
Note that 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
Information about pending revisions is can be viewed in the Revision
Information dialog box (see “Viewing and Editing Revision Information”
on page 314 and “Viewing and Editing Member Information” on
page 287).
u s e r g u i d e

Branching and Merging
Revisions
KEY TERMS: branching, merging, merge result file
10
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. Source Integrity allows you to merge two
revisions and the corresponding working file into a single merged revision
with the MKS Visual Merge tool.
This chapter explains the branching and merging tasks and the different
ways you can complete them.
Specific topics covered in this chapter include:
“Branching Revisions” on page 338
“Making Locked Members Writable” on page 340
“Merging Branched Revisions” on page 343
“Merging Revisions” on page 353
“Resolving Merges” on page 367
337

Chapter 10: Branching and Merging Revisions
Branching Revisions
338
A branch is a revision path that diverges from the main line of development
(or trunk) in a member or project history. A branch is typically created by
checking in a file to a revision other than the head revision. The most
recent revision of a branch in a history is called the tip revision. When you
branch a member the working revision number is appended to indicate the
branch. For example, the member features.txt at revision 1.2 is
branched and appears with the working revision number 1.2.1.1.
The branching on check out option allows multiple users to share locks on
the same revision by creating new branches automatically. You can use this
option to check out a file that is locked by another user. When you apply
the branching on check out option, Source Integrity provides you with a
locked working revision on new branch where you can proceed with
development.
You can merge revisions when development is complete, or check in your
revisions to the new branch without merging. For more details on checking
in and merging, see “Merging on Check In” on page 343.
To branch a member upon check out in the graphical user interface
and Web interface
1 With a Project or Sandbox view open, select one or more locked
members to check out.
2 Do one of the following:
Select Member > Check Out.
Click .
The Check Out dialog box is displayed.
u s e r g u i d e

Branching Revisions
3 Click the desired tab, then modify the check out options. For details on
check out options, see “Checking Out a Member” on page 178.
4 To check out a single selected member, click OK. To check out all
selected members, click OK to All.
The Resolve Lock Conflict dialog box is displayed.
5 Select the Create a new branch with a lock option.
6 To check out and branch a single selected member, click OK.
To check out and branch all selected members, click OK to All.
To cancel the check out and branch without checking out the member,
select the Cancel this operation option, and click OK.
339

Chapter 10: Branching and Merging Revisions
340
NOTE
If you have made changes to your working file (without a lock), and then
attempt to check out the member, the Confirm Working File Update dialog box
is displayed. If you want to retain your changes in the working file, click Yes
(Yes to All for multiple members). If you do not want to retain your changes in
the working file, click No (No to All for multiple members).
The member is checked out for editing on a new branch, indicated by a
lock icon, and a new working revision number. A member delta
symbol also appears indicating that the working file corresponds to
the new branch revision.
Making Locked Members Writable
If you want to edit a locked file without creating a branch, Source Integrity
provides an alternate method. You can make the working file in your
sandbox writable so that you can continue with development while
waiting for the lock to be released. When the lock is released, you can then
check out the member with a lock and check in your changes.
In the graphical user interface, you can make your working file writable
during the check out process, or from a Sandbox view.
In the Web interface, you can make your working file writable during the
check out process.
To make a member writable in the graphical user interface
1 With a Sandbox view open, select one or more locked members to
make writable.
2 Select Member > Working File > Make Writable.
The working file in your sandbox is made writable for editing. The
member revision number and working revision number are not
affected.
IMPORTANT
The changes you make to the working file in your sandbox are not part of the
project history until you check out the member locked, and then check the
member back in.
u s e r g u i d e

Making Locked Members Writable
To make a member writable upon check out in the graphical user
interface
1 With a Project or Sandbox view open, select one or more locked
members to make writable.
2 Do one of the following:
Select Member > Check Out.
Click .
The Check Out dialog box is displayed.
3 Click the desired tab, then modify the check out options. For details on
check out options, see “Checking Out a Member” on page 178.
4 To make a single selected member writable, click OK. To make all
selected members writable, click OK to All.
The Resolve Lock Conflict dialog box is displayed.
5 Select the Make your working file writable option.
6 To make a single selected member writable, click OK. To make all
selected members writable, click OK to All.
The working file in your project or sandbox is made writable for
editing. The member revision number and working revision number
are not affected.
IMPORTANT
The changes you make to the working file in your sandbox are not part of the
project history until you check out the member locked, and then check the
member back in.
341

Chapter 10: Branching and Merging Revisions
342
To make a member writable in the Web interface upon check out
1 From a Project view, select one or more locked member to make
writable.
2 Do one of the following:
Select Member > Check Out.
Click .
The Check Out dialog box is displayed.
3 Click the desired tab, then modify the check out options. For details on
check out options, see “Checking Out a Member” on page 178.
4 To make a single selected member writable, click OK. To make all
selected members writable, click OK to All.
The Resolve Lock Conflict dialog box is displayed.
5 Select the Ignore and continue without a lock option.
6 To make a single selected member writable, click OK. To make all
selected members writable, click OK to All.
The revision in your project is made writable for editing. The member
revision number is not affected.
IMPORTANT
The changes you make to the working file in your project are not part of the
project history until you check out the member locked, and then check the
member back in.
u s e r g u i d e

Merging Branched Revisions
Merging on
Check In
Merging Branched Revisions
When you want to combine the development occurring on different
branches, you can merge the branched revisions into a single revision.
Source Integrity recognizes cases where a previous merge has occurred,
(whether by merging the branch, automatic merging, or using the MKS
Visual Merge and MKS Visual Difference tools), and merges only changes
since the last merge operation. Thus, the first merge branch operation
occurring on a given branch merges all changes throughout the branch.
Any subsequent merge branch operations will merge only changes since
the previous merge operation.
Merging operations are available only in the graphical user interface and
command line interface.
Merging on check in is a two step process that allows users sharing locks
on a revision to update the member revision and then merge changes from
a branch if necessary.
Step One: Check In
In the first step, you can check in a revision from a branch when the
member revision is locked with the option of updating the member
revision in the project. For more details on updating the member revision,
see “Updating a Member’s Revision” on page 293.
To check in and update the member revision using the graphical user
interface
1 With a Sandbox view open, select one or more members to check in.
2 Do one of the following:
Select Member > Check In.
Click .
The Check In dialog box is displayed.
NOTE
The Change Package options, such as Close Change Package, appear only if
change packages are enabled.
If the member you are checking in had a change package associated with it at
the time of check out, that change package appears by default in the Change
Package field in the Change Package options.
343

Chapter 10: Branching and Merging Revisions
344
3 In the Revision Description field, enter a comment about the new
revision. For example, you can enter a detailed description of what
you changed, what bug in the software the changes were meant to
correct, or instructions for the next person who works on the member.
NOTE
If your administrator has set the feature for enforced revision descriptions, you
must make an entry in the Revision Description field. If the field is blank,
Source Integrity displays an error message and the member is not checked in.
4 Under Options, click the desired tab, then modify the check in options.
For details on check in options, see “Checking In a Member” on
page 186.
5 To check in the member, click OK. To check in all remaining members,
click OK to All.
The Confirm Update Of Member Revision dialog box is displayed.
u s e r g u i d e

Merging Branched Revisions
6 To check in and update a single selected member, click Yes. To check
in and update all selected members, click Yes to All.
The member is checked in. The new revision becomes the member
revision in the project, and the member revision number increments
accordingly.
To check in a single member without updating, click No. To check in
all remaining members without updating, click No to All.
NOTE
Source Integrity confirms the action to be taken if the working file you want to
check in has unresolved merge conflicts. For information on resolving merges,
see “Resolving Merges” on page 367.
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.
To cancel the check in and update without checking in the member,
click Cancel.
Step Two: Merge Branch
In the second step, you can merge the changes between revisions on
branches, making the merged revision the member revision for the project.
For more details on merging, see “Merging Revisions” on page 353.
To merge revisions in the graphical user interface
1 With a Sandbox or Member History view open, select one or more
members 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 From the Sandbox view, select Member > Diff/Merge > Merge Branch.
From the Member History view, select History > Merge Branch.
The Merge Branch dialog box is displayed.
345

Chapter 10: Branching and Merging Revisions
346
3 Specify the Target revision that the working revision is merged into.
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 Specify the Branch revision you want to merge 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 Under Options complete the following as required:
Select Lock target revision to lock the merged revision when the
merge is complete.
Select Force Creation of New Branch to automatically create a
branch for the merged revision.
Select Create Branch if Variant to automatically create a branch for
the merged revision if you are working in a variant sandbox.
Configure the Merge Type option to specify the method you want
to use for merging. Select one of the following from the list:
Confirm causes Source Integrity to prompt you for the action
to be taken.
u s e r g u i d e

Merging Branched Revisions
Cancel causes Source Integrity to cancel the merge
operation.
Automatic causes Source Integrity to automatically merge
the files.
Manual causes Source Integrity to launch the MKS Visual
Merge tool.
Configure the On Conflicts option to specify how you want
Source Integrity to handle any conflicts that occur during
merging. Select one of the following from the list:
Confirm causes Source Integrity to prompt you for the action
to be taken.
Cancel causes Source Integrity to cancel the merge operation
when a conflict occurs.
Mark For Later Merge causes Source Integrity to exit the
merge operation and mark the working file with an
unresolved merge icon.
Launch Tool causes Source Integrity to launch the MKS
Visual Merge tool.
Highlight Output File causes Source Integrity to
complete the merge automatically and highlight the output
file where any conflicts occurred.
Error causes Source Integrity to display an error message
prompt.
6 Under Change Package, select a change package to associate with the
merged file from the Change Package list.
Click Create to create a new change package for the file.
NOTE
The Change Package options only appear if change packages are enabled.
7 To merge the revision, click OK. To merge revisions of more than one
member, click OK to All.
Source Integrity 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.
347

Chapter 10: Branching and Merging Revisions
Merging
Revisions by
Dragging
348
You can merge revisions in the Graphical History view by dragging. The
drag-and-drop action initiates the Merge Branch command.
For more information on the Graphical History view, see “Graphical
History View (GUI)” on page 445.
For more information on Dragging, see “Dragging in the Graphical History
View (GUI)” on page 448.
To merge revisions in the graphical user interface Graphical History
view by dragging
1 Select the branch revision you want to merge.
2 Drag the branch revision onto the target revision (the revision you
want to merge into).
The Merge Branch dialog box is displayed.
3 Specify the Target revision that the working revision is merged into.
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.
u s e r g u i d e

Merging Branched Revisions
4 Specify the Branch revision you want to merge 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 Under Options complete the following as required:
Select Lock target revision to lock the merged revision when the
merge is complete.
Select Force Creation of New Branch to automatically create a
branch for the merged revision.
Select Create Branch if Variant to automatically create a branch for
the merged revision if you are working in a variant sandbox.
Configure the Merge Type option to specify the method you want
to use for merging. Select one of the following from the list:
Confirm causes Source Integrity to prompt you for the action
to be taken.
Cancel causes Source Integrity to cancel the merge
operation.
Automatic causes Source Integrity to automatically merge
the files.
Manual causes Source Integrity to launch the MKS Visual
Merge tool.
Configure the On Conflicts option to specify how you want
Source Integrity to handle any conflicts that occur during
merging. Select one of the following from the list:
Confirm causes Source Integrity to prompt you for the action
to be taken.
Cancel causes Source Integrity to cancel the merge operation
when a conflict occurs.
Mark For Later Merge causes Source Integrity to exit the
merge operation and mark the working file with an
unresolved merge icon.
Launch Tool causes Source Integrity to launch the MKS
Visual Merge tool.
349

Chapter 10: Branching and Merging Revisions
Automatic
Merging on
Check Out
350
Highlight Output File causes Source Integrity to
complete the merge automatically and highlight the output
file where any conflicts occurred.
Error causes Source Integrity to display an error message
prompt.
6 Under Change Package, select a change package to associate with the
merged file from the Change Package list.
Click Create to create a new change package for the file.
NOTE
The Change Package options only appear if the Integrity Manager integration
is enabled.
7 To merge the revision, click OK. To merge revisions of more than one
member, click OK to All.
Source Integrity 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.
The Automatic Merging on Check Out option allows you to merge a
member revision, if it is modified, with your working file upon check out.
This option allows you to have the most complete working file available.
For more details on merging, see “Merging Revisions” on page 353.
To merge revisions automatically on check out in the graphical user
interface
1 With a Sandbox view open, select one or more members to check out.
2 Do one of the following:
Select Member > Check Out.
Click .
The Check Out dialog box is displayed.
u s e r g u i d e

Merging Branched Revisions
3 Under Options, click the Advanced tab, then click the Merge Working
File if Changed check box.
4 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 (without a lock), and
then attempt to check out the member, the Confirm Working File
Update dialog box is displayed. If you want to retain your changes in
the working file, click Yes (Yes to All for multiple members). If you do
not want to retain your changes in the working file, click No (No to All
for multiple members).
Depending on the preferences you have set for the check out
command (see “Command Preferences” on page 48), Source Integrity
takes one of the following actions when a conflict occurs:
Source Integrity asks you to confirm the action to be taken.
Source Integrity cancels the operation.
351

Chapter 10: Branching and Merging Revisions
Automatic
Merging on
Resync
352
Source Integrity exits the merge operation and marks the working
file with an unresolved merge icon. For information on resolving
merges, see “Resolving Merges” on page 367.
Source Integrity automatically launches the MKS Visual Merge
tool. For information on the MKS Visual Merge tool, see
“Working With MKS Visual Merge” on page 361.
Any changes to the working file are merged and the member is
checked out for editing, indicated by a lock icon, who locked the
revision, and when it was locked.
The Automatic Merging on Resync option allows you to merge a member
revision, if it is modified, with your working file upon resyncing. This
option provides you with the most complete working file available. For
more details on merging, see “Merging Revisions” on page 353. For more
information on resyncing members, see “Resyncing Members” on
page 197.
To merge revisions automatically on resynchronization in the
graphical user interface
1 With a Sandbox view open, select one or more members that contain
member deltas that denote that both the working file is modified and a
new member revision available.
u s e r g u i d e

Merging Revisions
2 Do one of the following:
Select Member > Resynchronize.
Click .
The Confirm Working File Merge dialog appears.
Merging Revisions
3 To merge and resynchronize the member, click Yes (for multiple
members, click Yes to All). To cancel the merging and resynchronizing
the member, click No (for multiple members, click No to All).
Depending on the preferences you have set for the resynchronize
command (see “Command Preferences” on page 48), Source Integrity
takes one of the following actions when a conflict occurs:
Source Integrity asks you to confirm the action to be taken.
Source Integrity cancels the operation.
Source Integrity exits the merge operation and marks the working
file with an unresolved merge icon. For information on resolving
merges, see “Resolving Merges” on page 367.
Source Integrity automatically launches the MKS Visual Merge
tool. For information on the MKS Visual Merge tool, see
“Working With MKS Visual Merge” on page 361.
The selected member is updated and merged.
Source Integrity offers a number of different methods to merge revisions.
This section describes the methods of merging revisions automatically or
by using the MKS Visual Difference and MKS Visual Merge tools. These
tools are available through the graphical user interface only, but can be
launched from the command line interface. Command line interface
procedures are also included in this section.
For more information on MKS Visual Difference, see “MKS Visual
Difference Interface” on page 100.
353

Chapter 10: Branching and Merging Revisions
Merging
Revisions
Automatically
354
For more information on MKS Visual Merge, see “MKS Visual Merge
Interface” on page 107.
For more information on the command line interface, see “Command Line
Interface” on page 98.
IMPORTANT
Members must be checked out before you can merge them.
If you do not want to use MKS Visual Difference or MKS Visual Merge to
merge revisions in the graphical user interface, you can merge revisions
automatically.
To merge revisions automatically in the graphical user interface
1 From a Sandbox or Member History view, select the revisions you
want to merge.
2 Do one of the following:
From the Sandbox view, select Member > Diff/Merge > Merge.
From the Member History view, select History > Merge.
The Merge dialog box is displayed.
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.
u s e r g u i d e

4 Click OK to continue.
Merging Revisions
The Merge dialog box is displayed (if your preferences are set to
confirm the action to be taken, see “Command Preferences” on
page 48)
5 Select Automatically and click OK.
The revisions are merged.
If Source Integrity encounters a conflict, depending on your
preferences (see “Command Preferences” on page 48), the Conflict
resolution dialog box is displayed.
The merge operation may be canceled, the MKS Visual Merge tool
may be launched, the output file may be highlighted, or the revisions
may be marked for merging later.
Select an option, then Click OK. Source Integrity provides a message
indicating why the merge was canceled.
6 Check in the merged revision.
355

Chapter 10: Branching and Merging Revisions
Working With
MKS Visual
Difference
356
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.
Merging Two Revisions
You can use MKS Visual Difference to merge differences between two
revisions selected from a member history or the member revision and
working file. The graphical user interface and command line interface
allow you to merge differences between two revisions.
To merge two revisions in the graphical user interface
1 Compare two revisions whose differences you want to merge, as
described in “Comparing Revisions” on page 331.
2 In Visual Difference, do one of the following:
Select File > Merge.
Click .
The Reassign Merge Roles dialog box is displayed.
3 Specify which of the selected revisions you want as the Merge From
revision and the Merge To revision by selecting it from the list.
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 “View Panes”
on page 103.
u s e r g u i d e

5 Complete the required changes by doing one of the following:
Merging Blocks (see “Merging Blocks” on page 358)
Merging Revisions
Editing Merge Results (see “Editing Merge Results” on page 363)
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 is displayed.
357

Chapter 10: Branching and Merging Revisions
358
7 Enter the file name you want to save your merge result as. By default,
Source Integrity selects the file name corresponding to the member
name.
8 Click Save to save the Merge Result.
The Merge Result is saved.
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 360.
u s e r g u i d e

Editing Merge Results
Merging Revisions
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:
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
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.
To revert merge results in the graphical user interface
1 Do one of the following:
Select Edit > Revert Merge Result File.
Click .
The merge result file is reverted to its last saved state.
359

Chapter 10: Branching and Merging Revisions
360
To revert merge results by block in the graphical user interface
1 Select the block you want to revert in the merge result file.
2 Select Edit > Revert Block.
The block is replaced with the adjacent block in the Merge To.
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, Source Integrity does not
recognize any changes to the member.
To save merge results in the graphical user interface
1 Select File > Save As.
The Save merge result dialog box is displayed.
2 Enter the file name you want to save your merge result as. By default,
if the working file is involved in the comparison, Source Integrity
selects the file name corresponding to the member name.
3 Click Save to complete the operation.
The merge result file is saved.
NOTE
If you save the merge result to your working file, MKS Visual Difference
automatically recalculates the differences when it is saved.
u s e r g u i d e

Working With
MKS Visual
Merge
Merging Revisions
Once you have selected a file name and saved the merge result file, as you
continue to make changes you can do one of the following to save it:
Select File > Save.
Click .
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 Revisions
Automatically” on page 354).
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
( ) buttons to navigate through the revisions and view all the conflicts.
361

Chapter 10: Branching and Merging Revisions
362
Merging by Nonconflicting Blocks
Merging by 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 revisions by nonconflicting blocks in MKS Visual Merge
1 Do one of the following:
Select Edit > Merge All Nonconflicting Blocks.
Click .
All nonconflicting difference blocks are applied to the merge result
file.
u s e r g u i d e

Merging Revisions
2 Save the merge result file to retain the changes as described in “Saving
Merge Results” on page 364.
Merging by Blocks
If you do not want to merge entire revisions you can merge by difference
blocks or lines. Difference blocks are highlighted within each revision and
may be insertions, deletions, changes, or conflicts.
The merging by 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 appears 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 364.
Editing Merge Results
While you are working in MKS Visual Merge you can directly edit the
merge result if necessary.
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
363

Chapter 10: Branching and Merging Revisions
364
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
Do one of the following:
Select Edit > Revert Merge Result File.
Click .
The merge result file is reverted to its last saved state.
To revert merge results by block in MKS Visual Merge
1 Select the block or line you want to revert in the merge result file.
2 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, Source Integrity does not
recognize any changes to the member.
To save merge results in MKS Visual Merge
1 Select File > Save As.
The Save merge result dialog box is displayed.
u s e r g u i d e

Merging Revisions
2 Enter the file name you want to save your merge result as. By default,
Source Integrity selects the file name corresponding to the member
name.
3 Click Save to complete the operation.
The merge result file is saved.
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 do one of the following to save it:
Select File > Save.
Click .
Click the Save button on the status bar.
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.
365

Chapter 10: Branching and Merging Revisions
Merging in the
Command Line
Interface
366
To suspend merges in MKS Visual Merge
1 In MKS Visual Merge, click the Close button on the status bar.
The Mark for Later Merge dialog box is displayed.
2 Click Yes to mark the revision 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
Source Integrity indicates that resolution is required.
To resolve a suspended merge, see “Resolving Merges” on page 367.
In the command line interface, you can merge two revisions using the si
merge command. Merging in the command line interface operates as the
graphical user interface where two revisions and a working file are
compared and merged.
You can also launch the MKS Visual Merge and MKS Visual Difference
tools from the command line interface by using the -g option with the
merge command.
To merge two revisions in the command line interface
Use the si merge command:
si merge -r value -r value member --sandbox=value
where
-r value -r value specifies the revisions you want to merge, for
example, -r1.1 -r1.2.
member specifies the member whose revisions you want to merge, for
example, demoapp.c.
--sandbox=value specifies the sandbox containing the member whose
revisions you want to merge, for example, c:/sandboxdemo/
project.pj.
Depending on the preferences you have set for the Merge command (see
“Command Preferences” on page 48), Source Integrity may ask one or both
of the following questions:
u s e r g u i d e

Resolving Merges
How would you like to perform the merge?
Select an option from the list provided.
How would you like to handle conflicts?
Select an option from the list provided.
Resolving Merges
Source Integrity merges the differences between the two revisions and
saves them to the member’s working file.
Check in the merged revision.
For a complete list of options for the si merge command, see the
Source Integrity Enterprise Edition CLI Reference Guide.
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.
To resolve a merge in the graphical user interface
1 In a Sandbox view, select a member with an unresolved merge
symbol.
2 Select Member > Diff/Merge > Resolve Merge.
The Merge dialog box is displayed (if your preferences are set to
confirm the action to be taken, see “Command Preferences” on
page 48).
367

Chapter 10: Branching and Merging Revisions
368
3 Select either 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. A delta, visible in the Sandbox view,
appears indicating that the merge is complete.
If Source Integrity encounters a conflict, depending on your
preferences (see “Command Preferences” on page 48), 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 the
MKS Visual Merge tool. The MKS Visual Merge tool appears in a
new window displaying the revisions you want to merge. In MKS
Visual Merge perform merging and editing as required. Complete
steps 4 through 7.
For information on using the MKS Visual Merge tool, see “MKS Visual
Merge Interface” on page 107, and “Working With MKS Visual
Merge” on page 361.
4 In the MKS Visual Merge window, click File > Save As.
The Save merge result dialog box is displayed.
u s e r g u i d e

Resolving Merges
5 Enter the file name you want to save your merge result as. By default,
Source Integrity selects the file name corresponding to the Merge To
revision.
6 Click Save to merge the revisions.
The revisions are merged.
7 To close MKS Visual Merge, click Close.
In your Sandbox view, a delta appears indicating that the merge is
complete.
369

Chapter 10: Branching and Merging Revisions
370
u s e r g u i d e

The Integrity Manager
Integration
KEY TERMS: Integrity Manager, change package, issue, change package ID
11
Integrity Manager extends the concept of defect tracking to include
support for managing components, tasks, and a complex workflow. This is
particularly important when your organization has implemented a
Software Configuration Management (SCM) process for the proposal,
review, and approval of all software changes. Source Integrity supports the
managing of components and tasks in change packages. For more
information on change packages, see “Using Change Packages and
Reviews” on page 213.
As part of the complete MKS Integrity Solution, Integrity Manager allows
you to associate issues with Source Integrity change packages. Your
administrator configures Source Integrity to allow change packages,
enables the Integrity Manager integration, and then defines the issue types
that can use change packages.
This chapter discusses the following:
“Integrating With Integrity Manager” on page 372
“How the Integration Works” on page 372
“Creating a Change Package for an Issue” on page 375
“Adding Entries to an Issue’s Change Package” on page 376
“Viewing a Change Package’s Issue” on page 376
“Finding Change Packages Using a Query” on page 378
371

Chapter 11: The Integrity Manager Integration
Integrating With Integrity Manager
How the Integration Works
372
As part of the integration with Integrity Manager, you can associate
change packages with Integrity Manager issues. Issues provide more
detailed information on the issue that needs to be addressed, and control
the workflow of development and testing, known as the software
development cycle.
Issues track changes in the software development cycle. For example, your
administrator can configure Integrity Manager in a way that a problem
issue may be associated with a solution issue for easy tracking and
monitoring of both issues. Each issue has an audit trail, which may be used
to evaluate internal processes for the effectiveness of the problem
resolution process. In effect, issues track all aspects of any engineering
endeavor.
Integrating with Integrity Manager allows you to specify groups of
developers who are affected by an issue, who can then be notified using email
notification rules.
Administrators define what issue types can use change packages and
configure Source Integrity to integrate with Integrity Manager.
Change packages can be grouped together using an issue to create a larger
logical grouping of changes. Each change package in an issue can be
created by a different user for team development of an issue.
For detailed information on Integrity Manager operations, see the
Integrity Manager User Guide.
Before reading about how the integration works, you should note the
following rules that apply when using issues and change packages:
Multiple change packages can be created for a single issue. If the
resolution of an issue 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 issue.
If an issue type does not allow open change packages, you cannot
create and associate new change packages with that issue. Check with
your administrator to find out which issue types allow open change
packages.
u s e r g u i d e

How the Integration Works
Only issue states specified by your administrator allow open change
packages. When attempting to advance to a state that does not allow
open change packages, Integrity Manager instructs you to first close
the issue’s change package.
Typically, an issue cannot advance to the final state in an
Integrity Manager workflow until all change packages are closed. See
your administrator for more information.
Users can view change package information from both
Integrity Manager and Source Integrity, reducing the need to work in
both applications to use the integration features.
When the Integrity Manager integration is enabled, the change
package ID is a colon-separated identifier of the form:
:
NOTE
When working with shared subprojects, Source Integrity uses the actual name
of the subproject in the file system rather than its relative name in the project
hierarchy. Therefore, the change package entries for a shared subproject use
the actual file system name of the subproject. This enhances the portability of
change packages across different projects.
The following is an example of the recommended way to use change
packages with Integrity Manager to control development:
1 In Integrity Manager, submit an issue that needs to be addressed. For
more information, see the Integrity Manager User Guide.
2 In Source Integrity, open the Manage Change Packages window (see
“Managing Change Packages” on page 220). This is your control
center for managing your grouping of tasks.
3 Create a change package (see “Creating a Change Package” on
page 217) to use for the group of tasks you need to perform to address
an issue. The change package acts as a container, grouping together
the specific members (files) that need to be changed to address the
issue. When creating the change package, associate it with the issue
you created in Integrity Manager.
Source Integrity assigns the change package an ID and leaves the
change package in the Open state.
You can see the change package listed in the Manage Change
Packages window.
373

Chapter 11: The Integrity Manager Integration
374
4 View the change package in the Change Package view (see “Viewing
Change Package Details and Entries” on page 226). All operations you
do to address the issue appear in this window.
5 As part of your development process, identify the members that are
affected by the issue. Add the members to the change package (see
“Operations That Add Entries to a Change Package” on page 215).
NOTE
You can only see change package lock entries in a change package from
Integrity Manager if lock tracking is enabled. For more information on lock
tracking, see your administrator.
The operations are listed in the Change Package view.
6 When all of the development to address the issue is completed, submit
the change Package (see “Submitting Change Packages” on page 238).
All deferred operations are submitted.
Any locked members are converted to deferred check in operations,
then checked in.
Although you can submit operations individually, or check in a
member without deferring it, submitting all of your operations at one
time ensures that no operations miss the development build.
If reviews are mandatory, the review begins here, and the following
numbered steps are not completed. For more information, see “CP
Review Workflow” on page 242.
7 Close the change package to signify that the work to address the issue
is completed. The change package disappears from the Manage
Change Packages window.
To find the change package and view its entries, see “Finding Change
Packages” on page 222 or “Finding Change Packages Using a Query”
on page 378.
8 In Integrity Manager, advance the issue through the workflow. At this
point, the verification phase begins. If it is determined that more work
needs to be performed to address the issue, the user moves the issue to
an earlier state in the workflow, then you (or another developer)
create an additional change package. The process is repeated until the
issue is sufficiently addressed.
u s e r g u i d e

Creating a Change Package for an Issue
Creating a Change Package for an Issue
You can create a change package and associate it with an issue from the
menu bar, when checking out, checking in, adding, dropping, locking, or
renaming a member.
To create a change package for an issue in the graphical user
interface
1 Create a change package in one of the following ways:
With a Project, Sandbox, Manage Change Packages, or Member
History view open, select Change Package > Create.
Create a change package when performing member operations
(see “Operations That Add Entries to a Change Package” on
page 215).
In the Change Package portion of the panel, Click Create.
Create performs a query for all issues assigned to you that can be
associated with a change package. The qualifying criteria are set by the
administrator as part of the workflow in Integrity Manager.
The Create Change Package dialog box is displayed.
2 From the Choose Issue list, select the issue you want to associate with
the change package.
Integrity Manager supplies the issues for the Choose Issue list. This
list displays issues assigned to you that are in a state that allows open
change packages. For more information on issues, see the
Integrity Manager User Guide.
375

Chapter 11: The Integrity Manager Integration
376
Depending on how your administrator has configured
Integrity Manager, you may be able to select , and the change
package appears on an issue of “SI Change Package” type in Integrity
Manager.
3 In the Summary field, type a summary of the change package.
By default, the issue summary appears in the change package
Summary field.
4 In the Description field, if necessary, type a detailed description of the
change package.
5 Click OK.
Adding Entries to an Issue’s
Change Package
The change package is created. To view the change package, see
“Viewing Change Package Details and Entries” on page 226.
Once a change package is created and associated with an issue, you can
add entries to that change package when performing member operations
(see “Operations That Add Entries to a Change Package” on page 215).
Refer to the Change Package portion of the panel.
From the change package list, select a change package. The list presents the
Change package ID then the summary, for example, 13:1 Failed
Install.
After the operation is completed, the entry is added to the change package.
The change package’s ID appears in one of the change package ID columns
of the Project or Sandbox view.
Viewing a Change Package’s Issue
As part of the Integrity Manager integration, you can launch
Integrity Manager from Source Integrity to view issues that are associated
with change packages.
u s e r g u i d e

Viewing a Change Package’s Issue
To view a change package’s issue in the graphical user interface
1 Do one of the following:
From the Manage Change Packages window (see “Managing
Change Packages” on page 220), select a change package.
Open the Change Package view (see “Viewing Change Package
Details and Entries” on page 226).
With the Annotate Revision view open (see “Viewing an
Annotated Revision” on page 316), select an annotation block.
2 Do one of the following:
Select Change Package > View Issue.
Click .
The Integrity Manager graphical user interface opens, displaying the
associated issue. For more information on Integrity Manager, see the
Integrity Manager User Guide.
To view a change package’s issue from the Project or Sandbox view
in the graphical user interface
With a Project or Sandbox view open, select a member that has a change
package associated with it.
Select Change Package, then one of the following:
Working displays the issue for the change package associated with a
deferred or a lock operation performed by the current user from the
current sandbox.
Member displays the issue for the change package associated the
operation that set the member revision.
Creation displays the issue for the change package that created the
revision that is currently the member revision. This revision may be
different from the Member CPID if an import, add member from
archive, or set member revision operation was used.
Locker displays the issue for the change package associated with the
lock on the member revision.
Pending displays the issue for the change package associated with a
pending operation.
The Integrity Manager graphical user interface opens, displaying the
associated issue. For more information on Integrity Manager, see the
Integrity Manager User Guide.
377

Chapter 11: The Integrity Manager Integration
378
To view a change package’s issue in the Web interface
1 In a Project view, select a member that has a change package
associated with it.
2 Select Change package > View Issue.
The issue is displayed in the Integrity Manager Web interface.
Finding Change Packages Using a Query
You can create issue queries in Integrity Manager, and then use them in
Source Integrity to find change packages. This is useful for change
packages that are closed, because they no longer appear in the Manage
Change Packages window.
To find a change package using an Integrity Manager query in the
graphical user interface
1 Select Tools > Find > Change Packages.
The Find Change Packages dialog box is displayed.
2 Click the By Query tab.
The By Query panel is displayed.
u s e r g u i d e

Finding Change Packages Using a Query
By Query uses an existing Integrity Manager query to find and display
the change packages.
For information on searching for change packages using the By Filter
or By ID panel, see “Finding Change Packages” on page 222.
3 Select the desired query from the list. For more information on
creating queries, see the Integrity Manager User Guide.
4 Click OK.
The results are displayed in the Filter Change Packages window. The
Filtered Change Packages window displays change packages in the
same way as the Manage Change Packages window does. For more
information, see “Managing Change Packages” on page 220.
To update the search results with current data, select View > Refresh.
To create a new search from the Change Packages view, select View >
Filter.
379

Chapter 11: The Integrity Manager Integration
380
u s e r g u i d e

Advanced Change Package
Operations
12
KEY TERMS: issue, change package entries, change package, apply change
package, resynchronize change package, backfill list, resynchronize by
change package, resolution change package
Apply Change Package (Apply CP) and Resynchronize Change Package
(Resync CP) represent two of the most powerful features of the
Integrity Solution. 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 changes—whether from the master project to a variant, or
from a variant to the master project.
Apply CP and Resync CP rely on the use of change packages to track
individual changes that modify project content or create new content.
The chapter includes the following topics:
“Change Package Feature Overview” on page 382
“Using the Apply CP Command” on page 387
“Using the Resync CP Command” on page 406
“Working With a Resolution CP” on page 428
“Using the Resync By CP Command” on page 436
381

Chapter 12: Advanced Change Package Operations
Change Package Feature Overview
Change
Package
Methodology
382
A change package is a group of changes made by a single user which can be
considered a logical unit of work. Only the creator of a change package
may add entries to that change package. Change packages entries take the
form of operations, both deferred and committed. Apply CP and Resync
CP only apply to committed change packages entries.
Both Apply CP and Resync CP rely on the use of change packages to track
individual changes that modify project content or create new content. If a
development team is using change packages consistently, Source Integrity
can isolate all changes related to a specific issue because this information is
recorded as part of the change package. Once the dependencies are
calculated, the operation completes and the change packages are applied in
the project.
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 issue. To build the project, it would then be
necessary to add and drop files, update file revisions, merge around
unwanted revisions, merge in required changes, and merge out any
unwanted changes.
Using the functionality of Apply CP and Resync CP, this complicated
process becomes largely automated. In Source Integrity, the Apply CP
operation adds and drops files, and updates file revisions as required to
create the desired change. 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 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.
When used across a development project, Apply CP and Resync CP are
powerful tools for managing changes and new content. However, the
effectiveness of the functionality ultimately relies on the following factors:
accurate and consistent use of change packages for logging issues
associating related changes into a single change package that
ultimately addresses the issue in question
Because issues, and their associated change packages, follow a workflow
progression, it is critical that each member of the development team record
and track all changes as they are made, from the initial phase to the
u s e r g u i d e

Change
Package
Commands
Change Package Feature Overview
completion phase in which the associated problem is addressed. All
changes relating to a given issue must then be associated with the correct
change package. Once the problem is addressed, or the feature added, that
change package can be closed.
It is equally important that issues are clearly delineated so that each change
package addresses only one problem area or feature. Certainly, one
problem area or feature may require many files to address it, but if you
create a change package that is too wide in scope, it becomes difficult to
extract specific changes later on.
With accurate and consistent logging, Source Integrity can clearly identify
the specific member revisions (or files) that address the identified problem
or complete the required feature. Without this type of tracking, applying a
change package may not have the desired results and manual reviews may
become necessary.
Consider the following scenario at abcBusiness: A major customer
purchased version 2.0 of abcBusiness’ Aurora software. The customer now
wants a new feature—data compression—that they can use with Aurora
2.0. The development team at abcBusiness has already completed work on
a data compression feature, but the feature has been engineered only as
part of the upcoming Aurora 3.0 release.
To address the customer’s needs, abcBusiness would normally have to
assign a separate development team to create the new feature for Aurora
2.0. But how can abcBusiness take advantage of the work already
completed on the data compression feature and provide it to the customer?
If the development team has been using change packages, they can isolate
the files that relate to the new data compression feature. However, without
the functionality of Apply CP and Resync 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
and drop 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 and Resync CP, this complicated
process becomes largely automated. In Source Integrity, the Apply CP
operation works directly in the project to add and drop files, and update
file revisions as required to create the desired change. Source Integrity
presents you with a list—the backfill list—including all change packages
required to capture the issue. In the Apply CP operation, you must either
383

Chapter 12: Advanced Change Package Operations
384
accept or decline this list—you cannot make selections. If you accept the
list, the Apply CP command completes the changes directly in 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 then
run the Resync CP command. Resync CP works in your sandbox and
allows you to make selections from the backfill list. Source Integrity then
merges around unwanted changes and uses differencing to merge files.
Consider once again, the abcBusiness development team. Because the team
has been tracking all of their changes through the use of change packages,
they can target the main trunk of development and use Apply CP and
Resync CP functionality to extract only those files that relate to the new
data compression feature. Those specific change packages can then be
applied to a variant project of Aurora 2.0 and testing carried out within a
new project designed specifically for the customer.
The functionality allows you to maximize existing development work,
while being more responsive to both internal and external stakeholders.
Apply CP and Resync CP are especially effective in any environment
where there are large numbers of files to deal with—whether these are
code files for a software project or Web pages for a complex Web site.
CAUTION
The Apply CP operation works directly on the project and cannot be undone.
Exercise caution when working with the Apply CP command and ensure that
you have checkpointed your project before starting the command. When using
the Resync CP command in your sandbox, you should also confirm all changes
before checking in the files.
Apply CP Command
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 change package, or set of issues, that isolates the
feature from other features.
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
u s e r g u i d e

Change Package Feature Overview
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
change package, the Apply CP command can be used to transfer the
feature to the earlier, stable release.
The buildmaster at abcBusiness would:
Create a variant project off of 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 package to the variant project. The
change package contains 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.
Resync CP and Resync By CP Commands
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 developer’s sandbox.
The development team at abcBusiness is working on the next release,
which contains hundreds of files that span many Source Integrity 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.
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
and Resync By CP commands.
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
385

Chapter 12: Advanced Change Package Operations
Resolving
Conflicts
386
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 and Resync By CP
also merge 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 and Resync By CP commands also allow a developer to
remove a bug fix or feature that is incomplete or not working.
The basic process for resolving conflicts is to apply the target change
package using the Apply CP command. If the Apply CP operation fails
because of a merge conflict, you can do one of the following:
use the Resync CP command to create a resolution change package. A
resolution change package is a specialized change package that
records all applied change packages, resolved conflicts, checked in
modified files, and conflicts resolved by merging.
use the MKS Visual Merge tool to resolve conflicts and perform
merges. Depending on your preferences, Visual Merge may appear by
default for conflict resolution. For information on using Visual Merge
for conflict resolution, see “Working With MKS Visual Merge” on
page 361. For information on the MKS Visual Merge tool, see “MKS
Visual Merge Interface” on page 107.
The newly created resolution change package is then applied to the project
using the Apply CP command. The process involves the following key
steps:
Use the Apply CP command to apply a change package to the main
trunk of development.
If no merges are required and the Apply CP operation succeeds, the
changes are made in the project.
If Apply CP fails due to a required merge, use the Resync CP
command on the same change package and create a resolution change
package. Resync CP places the required files, locked, in your sandbox.
Verify the merges to ensure they are correct.
In your sandbox, check in the members, making sure to associate them
with the newly created resolution change package.
Close the resolution change package.
u s e r g u i d e

Apply that resolution change package to the project.
Using the Apply CP Command
The Apply CP command works directly in the project, adding and
dropping files, and updating file revisions as required to apply the
resolution change package and update the project.
It is important to note that while Resync CP can be used to apply a
resolution 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.
NOTE
Using the Apply CP Command
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.
Apply CP relies on the use of change packages to track individual changes
that modify project content or create new content. The Apply CP operation
presents you with a backfill list that includes all of the change packages
required for the identified issue. If you accept the backfill list, the operation
then adds and drops files, and updates file revisions as required to create
the feature, content, or bug fix you are looking for.
How Does Apply CP Work?
The Apply CP operation applies change packages through a revision
process. By applying a change package, you can incorporate only those
changes that you want to include in the project.
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
(si updaterevision). The Apply CP operation may also require that
files be added or dropped. This function of the command is an automated
process of the Add Member command (si add) and the Drop Member
command (si drop).
387

Chapter 12: Advanced Change Package Operations
Key Apply CP
Concepts
388
When Should I Use the Apply CP Command?
You should use the Apply CP command when you need to update a
project to include changes listed in a change package. The updating
process updates member revisions, and may also involve adding and
dropping files. The Apply CP command is most useful for building
software.
Are There Any Limitations When Using Apply CP?
The Apply CP operation adds and drops files, and updates file revisions.
Apply CP only operates on closed change packages and cannot perform
merging. The operation is carried out in relation to the project. If you run
the Apply CP command from a sandbox, the sandbox acts as a redirector to
the project.
The next four sections describe how the Apply CP command works and
how you can use it in your development environment. The topics covered
are:
“Key Apply CP Concepts” on page 388
“How Apply CP Works” on page 389
Procedures for the graphical user interface
the Apply CP backfill list, (“Apply CP Backfill List” on page 391)
The following outlines the key concepts associated with the Apply CP
command:
The Apply CP operation occurs in the project (whereas the Resync CP
operation occurs only in the sandbox). You can perform the Apply CP
operation from a sandbox, but this only acts as a redirector to the
project.
In principle, change packages are applied through a revision process.
By applying a change package, you can incorporate only those
changes that you want to include in the project.
Apply CP cannot address changes that require merging. Apply CP can
only make changes based on complete files—it can only add files,
drop files, and update a file revision. For more information on
resolving merge questions, see “Using the Resync CP Command” on
page 406.
Apply CP only works with closed change packages; therefore, you
must close the change package before you apply it. The Apply CP
operation is committing changes directly to a project and, for this
u s e r g u i d e

How Apply CP
Works
Using the Apply CP Command
reason, it is important that the entire change package is treated as a
single, indivisible change. If a change package is not closed, it may not
stand alone and may break the build.
Source Integrity allows you to run the Apply CP command first and
then, if required, run the Resync CP command to perform any
required merge operations.
If an Apply CP operation is not successfully completed,
Source Integrity tells you what you need to do to apply the change
package successfully.
The Apply CP backfill list presents you with all the change packages
that the selected change packages depend on. To run the command,
you must accept the entire list.
The changes made by an Apply CP operation can be recorded in a
change package for auditing purposes.
If reviews are mandatory, the changes made by an Apply CP
operation must be recorded as pending entries in a change package.
The change package must then be submitted, which starts the review
process (see “Change Package Review Process” on page 240).
The Apply CP operation adds and drops files, and updates file revisions to
include specific content in a project. For example, consider a simplified
application of the command in the main trunk of development for the
Aurora project (Aurora_Project.pj). The project member, main.c,
includes a bug fix that allows the printing of version information. Issue 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.
389

Chapter 12: Advanced Change Package Operations
390
Before applying a change package (simple case)
To get the bug fix for the variant project (Aurora_Variant_1_0.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
main.c
Aurora_Project
1.2
CP 21:1
***The following set of operations will be performed:
Project: f:/Aurora_Project/
project.pj[Aurora_Variant_1_0]
main.c
Member main.c: update member revision to Revision
1.2
Are you sure you wish to proceed? [yn]: y
u s e r g u i d e
Aurora_Variant_1_0
1.1
CP 21:1 addresses Issue 21 - “Modify the Main class
so that it prints version information.”
Archive for main.c
1.2
1.1
CP 21:1
CP 20:1

Apply CP
Backfill List
main.c
Aurora_Project
1.2
CP 21:1
Applying CP 21:1 updates main.c revision 1.1 to revision 1.2
to include the fix for printing version information.
Archive for main.c
1.2
1.1
CP 21:1
CP 20:1
main.c
After applying a change package (simple case)
Using the Apply CP Command
Aurora_Variant_1_0
1.2 CP 21:1
In this case, 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.
The following provides an example of the backfill list and how it works in
the Apply CP command. The main project, Aurora_Project.pj, now
includes an additional bug fix for project member, main.c. Issue 22
addresses that 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 bug fix and
apply these to a variant project, Aurora_Variant_1_0. In the variant
project, main.c is at revision 1.1.
391

Chapter 12: Advanced Change Package Operations
392
main.c
Aurora_Project
1.3
CP 22:1
CP 22:1 addresses Issue 22 -
“Add About information to the Main tool.”
Archive for main.c
Before applying a change package that requires backfilling
1.3
1.2
1.1
CP 22:1
CP 21:1
CP 20:1
main.c
Again, 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
u s e r g u i d e
Aurora_Variant_1_0
1.1

main.c
Aurora_Project
1.3
CP 22:1
Using the Apply CP Command
Applying CP 22:1 updates main.c from revision 1.1 to revision 1.3 in the variant
project to include the bug fix for About information. The backfill list included
CP 21:1.
Archive for main.c
1.3
1.2
CP 22:1
CP 21:1
1.1 CP 20:1
main.c
Aurora_Variant_1_0
After the backfill list is accepted, the Apply CP operation updates
main.c in the variant project from revision 1.1 to revision 1.3
1.3
CP 22:1
393

Chapter 12: Advanced Change Package Operations
394
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
In this case, 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 member
history in the variant project because it was accepted as part of the backfill
list (CP 21:1).
Apply CP Backfill Options
The Apply CP command operates recursively. To apply a change package,
Source Integrity searches the specified change packages for revision
changes between the current revision and the target revision.
Backfill
Option (GUI)
Entire Change
Packages
Backfill
Option (CLI)
Function
cp Selected by default for the Apply CP
command. Recursively finds all historic
revisions required by the specified change
packages and applies them. It does not ask
the user to confirm the backfill list.
u s e r g u i d e

Backfill
Option (GUI)
Back
Revisions Only
Backfill
Option (CLI)
Function
Using the Apply CP Command
revision Processes only the changes in the specified
change package(s). Any change packages
associated with intermediate revisions are
not picked up.
Note: Processing by revision reduces the
total number of changes you bring into the
variant; however, this option may result in
broken builds because indirectly associated
files are not picked up.
Error error Results in an error if other change packages
are required but not specified.
Skip Revisions skip Results in an error if any backfill revisions are
specified during the Apply CP operation.
Ask to Specify ask Displays the backfill list. To complete the
Apply CP operation, you must accept the
entire list. If you decline the list, the Apply CP
operation fails.
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 406.
The next example illustrates how Apply CP handles a more complex
change package—one 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.
395

Chapter 12: Advanced Change Package Operations
396
Aurora_Project
main.c
1.3
Archive for main.c
1.3
1.2
CP 23:1
CP 22:1
1.1 CP 21:1
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.
u s e r g u i d e
Aurora_Variant_1_0
main.h 1.1
main.c 1.1
Archive for main.h
1.1 CP 22:1
CP 21:1 Add main.c revision 1.1 to Aurora_Project
CP 22:1 Update main.c to revision 1.2 in Aurora_Project
Add main.h revision 1.1 to Aurora_Project
CP 23:1
Update main.c to revision 1.3 in Aurora_Project
Before applying a change package that contains an associated file

CP 21:1
CP 22:1
CP 23:1
Aurora_Project
main.c 1.3
main.h 1.1
Archive for main.h
1.1 CP 22:1
Archive for main.c
1.3
1.2
CP 23:1
CP 22:1
1.1 CP 21:1
Using the Apply CP Command
Aurora_Variant_1_0
main.c
Apply CP 23:1 updates main.c to revision 1.3 and
adds main.h revision 1.1 in Aurora_Variant_1_0
Add main.c revision 1.1 to Aurora_Project
Update main.c to revision 1.2 in Aurora_Project
Add main.h revision 1.1 to Aurora_Project
Update main.c to revision 1.3 in Aurora_Project
After applying a change package that contains an associated file
In this case, if the buildmaster selects the default backfill option—backfill
by Entire Change Packages—the variant is updated to include all the
contents of CP 22:1 (that is, main.c at revision 1.3 and main.h at revision
1.1.) However, if the buildmaster instead chooses to backfill by Back
Revisions Only, the build is broken because any intermediate change
packages are only filled by revision. In this case, the result is to place only
revision 1.3 of main.c in the variant. The associated file (main.h)
contained in the CP 22:1 is not added.
The preceding examples illustrated how to bring changes from the main
trunk of development to a variant project. You can also take changes that
are created on a branch or variant—for example, for an older release—and
1.3
main.h
1.1
397

Chapter 12: Advanced Change Package Operations
Apply CP
Procedures
398
bring them to the main trunk that may already include new feature
development. For more information on performing this operation using
Resync CP, see “Working on a Variant” on page 413.
This section describes the step-by-step procedures required to perform the
Apply CP command in both the graphical user interface and command line
interface.
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 269. For more information on restoring a project, see “Restoring a Project”
on page 271.
To apply a change package in the graphical user interface
1 From a Sandbox or Project view, select the project you want to apply
change packages to.
2 Select Change Package > Apply Change Package.
The Apply Change Packages wizard opens, displaying the Apply List
panel.
u s e r g u i d e

3 To add change packages to the Apply List, click Add.
Using the Apply CP Command
If you know the ID number of the change package(s) or issue(s) you
want to add, you can also enter that number in the Change Package ID
field and then click Insert. For multiple numbers, include a space
between each change package ID.
The Find Change Package Panel appears.
4 Select filter criteria for the change package, or if Integrity Manager is
enabled, select a query. For more information, see “Finding Change
Packages” on page 222 and “Finding Change Packages Using a
Query” on page 378.
5 After you specify the filter criteria or query, click OK.
The Select Change Package(s) dialog appears. The Change Packages
tab is populated with the filter or query results.
399

Chapter 12: Advanced Change Package Operations
400
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 406.
Available information is displayed in the panel as follows:
Tab Table Columns
Change Packages C.P. ID is the identification number of the change package
(in the form x:y, where x is the container ID (if
Integrity Manager is enabled it is also the issue ID), and y
is the change package index number).
State is the state of the change package (see “CP States”
on page 241).
Summary is the summary description of the issue
associated with the change package.
u s e r g u i d e

Tab Table Columns
Change Package
Entries
Using the Apply CP Command
Type lists the type of operation that was used to manipulate
the listed member. For more information, see “Change
Package Entry Types” on page 220.
Project lists the file path of the project.
Member lists the name of the member file.
Revision lists the revision number of the member file.
Development Path lists the development path, or variant,
that the change came from.
Server is the name of the Integrity Server the project
resides on.
Member History Displays the following information for each revision in the
member history:
Revision is the revision number of the selected member.
Author is the user ID of the individual who checked in the
member revision.
Date is the date the member revision was checked in.
Labels are the labels, if any, assigned to the revision in the
history.
State is the workflow state of the member.
C.P. ID is the change package identification number of the
revision.
6 To view the information for change package entries, select a change
package ID under the Change Packages tab and then click the Change
Package Entries tab.
The Change Package Entries tab is populated with information on the
associated change package entries.
Under the Change Package Entries tab detailed information is
displayed for each entry in the change package. For more information,
see “Change Package Entry Types” on page 220.
To view the information for a member history, select a member under
the Change Package Entries tab, then click the Member History tab.
401

Chapter 12: Advanced Change Package Operations
402
Once you select a member, the Member History tab is populated with
information on the associated member history.
NOTE
Under the Member History tab, you can highlight a member revision, and use
the shortcut menu to select View Revision or Revision Information. To perform
differencing between revisions, use CTRL+click to select two revisions and then
use the shortcut menu to select Differences.
7 To add change packages selected, click OK.
TIP
You can also double click to view a revision.
The added change packages are displayed in the Apply List.
u s e r g u i d e

Apply CP
General Command Option
Using the Apply CP Command
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.
8 To select the options you want Source Integrity to use when applying
the change packages, click Next.
The Options panel opens.
9 Select the command options you want Source Integrity to use when
carrying out the Apply CP operation:
Function
Confirm Actions Causes Source Integrity to confirm all operations with you before starting them.
(This option is enabled by default.)
Apply CP
Advanced Command Options
Function
Verbose Provides additional information to track the status of the command.
Other Project is Error Terminates the command if the member is not in the project you are applying to,
or in its variant.
Span Projects Applies the command to any member specified in the change package, even if
this involves a different project than the one you initially targeted.
Caution: This is the only command option that has the potential to affect other
projects.
403

Chapter 12: Advanced Change Package Operations
Apply CP
Advanced Command Options
Ignore Cross-Branch Entries Causes Source Integrity to use the most recent revision when it encounters two
revisions of the same member on different branches.
Close Change Package Closes the change package when the operation is complete.
Already in Project is Error Causes Source Integrity to terminate the operation if the member being applied is
already in the project.
If this setting is negated, then the information is displayed as a warning.
Ignore Server in Change
Package
404
Function
Causes Source Integrity to perform the Apply CP operation even if the change
package members reside on different servers.
Note: You must set the Other Project is Error option in order for the Ignore
Server in Change Package option to work. This additional setting is required
because projects are defined by their server and path.
Create Variants Causes Source Integrity to create new variant subprojects within the variant
project as required to apply the change package members. If the main project
contains required files that reside in a subproject, the Create Variants option
creates variant subprojects for these files to be placed into.
Backfill Determines how Source Integrity treats historic revisions required by the
specified change packages. For the Apply CP command, the backfill option is set
to Entire Change Packages by default.
You can select from the following options:
Entire Change Packages chooses all historic revisions required by the specified
change packages and applies them by updating member revisions, adding files,
or dropping files. The user is not prompted to confirm the backfill list.
Back Revisions Only processes only the specified change package(s) and
chooses only directly-associated revisions. It does not process any change
packages that are associated with intermediate revisions.
Error terminates the operation if other change packages are required but are not
specified.
Skip Revisions causes Source Integrity to merge around specified backfill
revisions. Because the Apply CP command does not perform merging, this is
treated as an error.
Ask to Specify allows you to select the specific change packages you want to
include. For the Apply CP operation, a list of additional change packages is
displayed. The presented list of change packages cannot be manipulated. You
must either accept the entire list or the operation fails.
Change Package Add the operation to a change package. From the Change Package list, select a
change package. To create a change package, click Create. For more
information, see “Creating a Change Package” on page 217.
Ignore Update Revision Entries Ignores update revision entries in a change package. There is no user prompt.
10 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 is displayed.
u s e r g u i d e

Using the Apply CP Command
11 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 406.
The Confirm Change Package Application dialog box is displayed
indicating the operations to be performed.
12 To complete the operation(s) and apply the selected change
package(s), click Yes.
Source Integrity completes the operation or returns information on
errors and warnings if the operation cannot be successfully completed.
405

Chapter 12: Advanced Change Package Operations
406
NOTE
Using the Resync CP Command
To see any change packages that have been applied between two revisions of a
project, use View Project Differences and, under Preferences, select the option
for Show Applied Change Packages. For more information on viewing project
modifications, see “Viewing Project Differences” on page 275.
While Apply CP works to either add, drop, or update member revisions,
you must accept the entire list of backfill entries or the command fails. In
the Resync CP operation, you are able to select the individual change
packages you want to exclude from the backfill operation and then
Source Integrity performs the required merges. Therefore, if you need to
merge files to create your solution, you must use the Resync CP command.
The Resync CP operation allows you to resynchronize revisions and carry
out merges entirely within a sandbox. When you are prompted to backfill
historical revisions (the Resync CP backfill list), you can select the change
packages you want to include. Resync CP automatically performs merging
and notifies you of unresolved conflicts that must be addressed manually
after the command completes.
How Does Resync CP Work?
To perform the operation, Source Integrity checks out all the files listed in
the selected change package(s) and places them in your sandbox. At the
same time, Source Integrity displays information on any conflicts, as well
as information on changes (or deltas).
Once the dependencies are calculated, and you have performed the
required merges, the operation completes and Source Integrity presents all
the files required for the new feature or content in your sandbox.
When Should I Use Resync CP?
You should use the Resync CP command when the Apply CP operation
has failed because there were conflicts to be resolved through merging.
Resync CP is most useful for developing software features and for
applying bug fixes during the software development process.
u s e r g u i d e

Key Resync CP
Concepts
NOTE
Using the Resync CP Command
When working in your sandbox, you can also use the Resynchronize By CP
command. When you select a member and use Resynchronize By CP,
Source Integrity automatically searches the change package associated with the
member and resynchronizes the selected member and all other member files
contained in that change package. For more information, see “Using the Resync
By CP Command” on page 436.
If the issues you are looking at have numerous associated change
packages, you can also use a single change package—a resolution change
package— that contains all the associated change packages, to resolve it.
The Resync CP command includes a process for creating resolution change
packages that can be used for this purpose. For more information on
resolution change packages, see “Working With a Resolution CP” on
page 428.
The next four sections describe how the Resync CP command works and
on how you can use it in your development environment. The topics
covered are:
“Key Resync CP Concepts” on page 407
“How Resync CP Works” on page 408
“Resync CP Backfill List” on page 409
Procedures for the graphical user interface
The following outlines the key concepts associated with the Resync CP
command:
The Resync CP operation takes place in a sandbox rather than directly
in the project. Resync CP does not drop members or update member
revisions in the project, but works only in your sandbox. Resync CP
also performs merges and adds required members to your sandbox.
If you need to merge files to create your solution, you must use Resync
CP rather than Apply CP. Resync CP performs three-way merging
and can therefore only merge around a consecutive range of revisions.
Resync CP allows you to work with open change packages.
Resync CP provides additional options beyond those available for
Apply CP, including options for Restore Revision Timestamp, Allow
Open Change Packages, Keyword, and certain merge options.
407

Chapter 12: Advanced Change Package Operations
How Resync CP
Works
408
Source Integrity allows you to run the Apply CP command first and
then, if required, run the Resync CP command to perform any
required merge operations.
The Resync CP backfill list allows you to quickly select those change
packages that you want to operate on. In the graphical user interface,
you select the change packages you want to include in the resync
operation. In the command line interface, you enter the numbers for
the change packages you want to exclude from the resync operation.
The Resync CP operation adds and drops files, and updates file revisions
to include specific content in a sandbox. Fundamentally, the Resync CP
works similarly to the Apply CP command, but rather than touching the
project directly, makes the changes in a sandbox.
For example, consider a simplified application in the main trunk of
development for the Aurora project (Aurora_Project.pj). The project
member, tool.c, includes a bug fix for Issue 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 developer’s 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:
-------------------
The change package(s)
20:1 -- tool.c(1.3)
21:1 -- tool.c(1.4)
22:1 -- tool.c(1.5)
23:1 -- 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).
--------------------
u s e r g u i d e

Resync CP
Backfill List
Using the Resync CP Command
*** 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]: y
In this case, Resync CP 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.
The following provides an example of the backfill list and how it works in
the Resync CP command. The main project, Aurora_Project.pj, now
includes an additional bug fix for project member, tool.c. Issue 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 developer’s sandbox, tool.c is at revision
1.2.
409

Chapter 12: Advanced Change Package Operations
410
tool.c
Aurora_Project
1.6
CP 23:1
CP 23:1 addresses Issue 23 -
“Add internationalization code to the tool.”
Archive for tool.c
1.6 CP 23:1
1.5
1.4
1.2
1.1
CP 22:1
CP 21:1
1.3 CP 20:1
CP 19:1
CP 18:1
tool.c
Picking up a specific change using the Resync CP command
u s e r g u i d e
Aurora_Sandbox
1.2

Using the Resync CP Command
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|#...] ?
411

Chapter 12: Advanced Change Package Operations
412
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 resolution 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
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
In this case, 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.5 and 1.6. The intermediate revisions are not added
to the sandbox because the skip option was selected. Because the resync
operation does not involve a resolution change package, the merged
member is not locked.
u s e r g u i d e

Working on a
Variant
Resync CP Backfill Options
Backfill
Option (GUI)
Entire
Change
Packages
Back
Revisions
Only
Backfill
Option (CLI)
Function
Using the Resync CP Command
cp Selected by default for the Resync CP
command. Recursively finds all historic
revisions required by the specified change
packages and applies them. It does not ask
you to confirm the backfill list.
revision Processes only the changes in the specified
change package(s). Any change packages
associated with intermediate revisions are not
picked up.
Note: Processing by revision may result in
broken builds because indirectly associated
files are not picked up.
Error error Results in an error if other change packages
are required but not specified.
Skip
Revisions
Ask to
Specify
skip Causes Source Integrity to merge around
specified backfill revisions.
ask Displays the backfill list and asks you to
specify how you want Source Integrity to treat
the change packages.
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.c—has 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.
413

Chapter 12: Advanced Change Package Operations
414
utility.c
Master Project
1.4
Archive for utility.c
1.4
1.3
1.2.1.2
1.2.1.1
1.2
1.1
CP 5:1
utility.c
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. Apply CP would not be successful in
this case because merging is required. Similarly, because the master project
contains further new development, updating the head revision of
utility.c from 1.4 to 1.2.1.2 would not be appropriate. Updating the
head revision would cause the new development work in revisions 1.3 and
1.4 to be lost.
The Resync CP command should be used in this case. However, if the
correct options are not selected, the default Resync CP operation checks
out utility.c and overwrites revision 1.4 in your sandbox with
utility.c revision 1.2.1.2 from the variant project.
1.2
u s e r g u i d e
Variant Project
1.2.1.2
1.2.1.1

utility.c
Master Project
1.4
utility.c
Sandbox to Master
1.4
1.2.1.2
The default Resync CP operation
Using the Merge On Branch Option
Using the Resync CP Command
Variant Project
1.2.1.2
1.2 1.2.1.1
utility.c
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 Source Integrity 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.
415

Chapter 12: Advanced Change Package Operations
416
utility.c
Master Project
1.4
utility.c
Sandbox to Master
1.4
Archive for utility.c
1.4
1.3
1.2.1.2
1.2.1.1
1.2
1.1
CP 5:1
Using Resync CP with the Merge On Branch option
Using the Ignore Branches Option
utility.c
Another situation that warrants special consideration is the case where two
change packages must be applied. Unless the correct options are selected,
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. To pick up all the
required changes, both CP 9:1 and CP 10:1 must be selected.
u s e r g u i d e
Variant Project
1.2.1.2
1.2 1.2.1.1
Differences between 1.2 and
1.2.1.2 merged into 1.4.
Result placed in sandbox.
To finalize changes in the
project, file must be checked in.

Archive for patch.c
Using the Resync CP Command
Performing a Resync CP operation on two change packages using the
Ignore Branches option
Running the Resync CP for two change packages requires more than a
three-way merge and therefore fails. Using the Ignore Branches option
(--ignoreBranches) Resync CP can successfully complete, but with a
restriction. The restriction is that Source Integrity searches both change
packages, takes the highest revision it finds, and uses this revision to
overwrite the working file in your sandbox.
In our example, the Resync CP operation would take patch.c at revision
1.3.1.2 and check it out to the sandbox, overwriting revision 1.4.
NOTE
1.4
1.3.1.2 CP 10:1
1.3.1.1
1.3
1.2
1.1
1.2.1.2 CP 9:1
1.2.1.1
patch.c
patch.c
patch.c
Project
Variant Project 1
1.3.1.2
Rapid Development
creates a bug fix
Buildmaster is
rolling out a fix
for a patch
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.
The Ignore Branches option can also be used to accommodate the case
where one developer has created the same fixes for both the project and the
variant, and associated with the same change package.
1.4
Variant Project 2
1.2.1.2
Product team needs
all the changes for
the master project
417

Chapter 12: Advanced Change Package Operations
Resync CP
Procedures
418
CP 10:1
Using Ignore Branches to apply two fixes in the same change package
In this case, because the single change package applies to both the project
and the variant, the highest revision is the only one the buildmaster needs.
The Ignore Branches option therefore allows Source Integrity to apply the
highest revision to the buildmaster’s variant project.
Combining Options
patch.c 1.5 Master Project
patch.c 1.3.1.2 Variant Project
Applying CP 10:1 and selecting the Ignore Branches
option allows Source Integrity to choose the highest
available revision, 1.5.
Following the same example, you can also apply both the Merge On Branch
and Ignore Branches options. Selecting both options allows
Source Integrity to perform a differencing between revisions 1.3 and the
highest revision found, revision 1.3.1.2, and merge the result into revision
1.4.
This section describes the step-by-step procedures required to perform the
Resync CP command in both the graphical user interface and command
line interface.
To resynchronize a change package in the graphical user interface
1 From a Sandbox view, select the project you want the Resync CP
command to operate on.
2 Select Change Package > Resynchronize Change Package.
The Resynchronize Change Packages wizard opens, displaying the
Apply List panel.
u s e r g u i d e
patch.c
patch.c
Master Project
1.5 CP 10:1
Variant Project
1.3.1.2 CP 10:1

3 To add change packages to the Apply List, click Add.
Using the Resync CP Command
If you know the ID number of the change package(s) or issue(s) you
want to add, you can also enter that number in the Change Package ID
field and then click Insert. For multiple numbers, include a space
between each change package ID.
The Find Change Package Panel appears.
4 Select filter criteria for the change package, or if Integrity Manager is
enabled, select a query. For more information, see “Finding Change
Packages” on page 222 and “Finding Change Packages Using a
Query” on page 378.
The Select Change Package(s) panel appears. The Change Packages
tab is populated with the filter or query results.
419

Chapter 12: Advanced Change Package Operations
420
NOTE
Open change packages are allowed when resynchronizing change packages.
The option for Allow Open Change Packages is enabled by default. You can
disable this option by clearing the check box.
Available information is displayed in the panel as follows:
Tab Table Columns
Change Packages C.P. ID is the identification number of the change package
(in the form x:y, where x is the container ID (if the
Integrity Manager integration is enabled, it is also the issue
ID, and y is the change package index number).
State is the state of the change package, whether open or
closed.
Summary is the summary description of the issue
associated with the change package.
Change Package
Entries
Type lists the type of operation that was used to
manipulate the listed member. For more information, see
“Change Package Entry Types” on page 220.
Project lists the file path of the project.
Member lists the name of the member file.
Revision lists the revision number of the member file.
Development Path lists the development path, or variant,
that the change came from.
Server is the name of the Integrity Server the project
resides on.
u s e r g u i d e

Tab Table Columns
Using the Resync CP Command
Member History Displays the following information for each revision in the
member history:
Revision is the revision number of the selected member.
Author is the user ID of the individual who checked in the
member revision.
Date is the date the member revision was checked in.
Labels are the labels, if any, assigned to the revision in the
history.
State is the workflow state of the member.
C.P. ID is the change package identification number of the
revision.
5 To view the information for change package entries, select a change
package under the Change Packages tab and then click the Change
Package Entries tab. Detailed information is displayed for each entry
in the change package. For more information, see “Change Package
Entry Types” on page 220.
Once you select a change package ID, the Change Package Entries tab
is populated with information on the associated change package
entries.
To view the information for a member history, select a member under
the Change Package Entries tab and then click the Member History tab.
Once you select a member, the Member History tab is populated with
information on the associated member history.
NOTE
Under the Member History tab, you can highlight a member revision, and use
the shortcut menu to select View Revision or Revision Information. To perform
differencing between revisions, use CTRL+click to select two revisions and
then use the shortcut menu to select Differences.
421

Chapter 12: Advanced Change Package Operations
422
6 To add the change packages to the Apply List and return to the Apply
List panel, click OK.
The list of change packages is displayed in the Apply List panel.
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.
u s e r g u i d e

Resync CP
General Command Options
Using the Resync CP Command
7 To select the change packages or Issues you want Source Integrity to
use during the Resync CP operation, click Next.
The Options panel opens.
8 Select the command options you want Source Integrity to use when
carrying out the Resync CP operation:
Function
Use Master Causes Source Integrity to operate on the top-level sandbox. When the selected
change package is associated with a member in a subsandbox, specifying Use
Master causes the command to operate on the top-level sandbox for that
subsandbox.
Overwrite Working File if
Changed
Perform Merges Enables merging
Overwrites the working file even if the file has changed since it was last checked
in.
Confirm Actions Causes Source Integrity to confirm all operations with you before starting them.
(This option is enabled by default.)
423

Chapter 12: Advanced Change Package Operations
Resync CP
Advanced Command Options
424
Function
Verbose Provides additional information to track the status of the command.
Already in Project is Error Causes Source Integrity to terminate the operation if the member being applied is
already in the project.
If this setting is negated, then the information is displayed as a warning.
Ignore Server in Change
Package
Causes Source Integrity to perform the Resync CP operation even if the change
package members reside on different servers.
Span Projects Applies the command to any project specified in the change package, even if this
involves a project that is not the one you initially targeted.
In a Resync CP operation, this option allows Source Integrity to search across
local sandboxes for all the entries contained in the selected change package(s).
Ignore Cross-Branch Entries Causes Source Integrity to use the most recent revision when it encounters two
revisions of the same member on different branches.
Restore Revision Timestamp Sets the timestamp of the working file to the date and time of the revision in the
history. If this option is not set, the working file’s timestamp is set to the current
date and time.
Other Project is Error Terminates the command if the member is not in the project you are applying to,
or in its variant.
Allow Open Change Packages Allows Source Integrity to work with open change packages. This facilitates the
application of a resolution change package.
Create Variants Causes Source Integrity to create new variant subprojects within the variant
project as required to apply the change package members. If the main project
contains required files that reside in a subproject, the Create Variants option
creates variant subprojects for these files to be placed into.
Merge On Branch Causes Source Integrity to perform a merge if the target revision is on a branch.
Source Integrity differences the two file revisions and merges any changes into
the working file without modifying its revision number. You must then check in the
working file to advance the revision to the next available revision number.
Keyword Allows you to select keyword expansion options that apply when a member is
checked out.
Expand replaces keywords in the revision with literal values in the working file.
Unexpand takes literal values in the working file and unexpands them.
Do Not Expand leaves the keywords unexpanded.
u s e r g u i d e

Resync CP
Advanced Command Options
Function
Using the Resync CP Command
Backfill Determines how Source Integrity treats historic revisions required by the
specified change packages. For the Resync CP command, the backfill option is
set to Entire Change Packages by default.
You can select from the following options:
Entire Change Packages chooses all historic revisions required by the
specified change packages and applies them by updating member revisions,
adding files, or dropping files. The user is not prompted to confirm the backfill
list.
Back Revisions Only processes only the specified change package(s) and
chooses only directly-associated revisions. It does not process any change
packages that are associated with intermediate revisions.
Error terminates the operation if other change packages are required but are
not specified.
Skip Revisions causes Source Integrity to merge around specified backfill
revisions.
Ask to Specify allows you to select the specific change packages you want
to include.
Ignore Update Revision Entries Ignores update revision entries in a change package. There is no user prompt.
9 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 is displayed.
425

Chapter 12: Advanced Change Package Operations
426
10 Select the change package(s) you want to include in the resync
operation and then click OK.
NOTE
At this time, the Resync CP command can only merge around a consecutive
range of revisions.
The Confirm Change Package Application dialog box is displayed.
Under the Query tab, information is provided on the operations to be
performed.
u s e r g u i d e

Using the Resync CP Command
Under the Warnings tab, information is provided on the change
packages associated with intermediate revisions.
427

Chapter 12: Advanced Change Package Operations
428
11 To complete the Resync CP operation, click Yes.
Source Integrity completes the Resync CP operation or returns
information on errors and warnings if the command cannot be
successfully completed.
NOTE
Working With a Resolution CP
To see any change packages that have been applied between two revisions of a
project, use View Project Differences. For more information on viewing project
modifications, see “Viewing Project Differences” on page 275.
There are instances when the Apply CP command does not work on a set
of change packages because merging is required. When this happens, the
Resync CP command must be used to automate the required merging.
Once the Resync CP operation is completed, the modified files that result
from those merges are transferred to your sandbox. To apply the changes,
you must then check in those modified files.
For a development team using the change package methodology, the check
in of the modified files requires an associated issue and change package.
Once the issue has been created, the files can then be checked into the
associated change package and the development path updated with the
merged files.
If other developers want to apply the same set of change packages, how
can they be certain that the changes made relate only to the target feature
and that no other changes have been checked in? To be absolutely certain,
they would have to repeat the original Resync CP operation—a significant
duplication of effort. Otherwise, they would have to resynchronize using
the original set of change packages and possibly accept additional,
unwanted changes that were selected during the first Resync CP operation.
To avoid this uncertainty and duplication of effort, there is a mechanism
for recording all change packages that have been applied, including the
merge conflicts that have been resolved. The resolution change package is
the mechanism for recording these changes.
A resolution change package is a specialized change package that records
all applied change packages, resolved conflicts, checked in modified files,
and conflicts resolved by merging. A resolution change package is applied
u s e r g u i d e

Working With a Resolution CP
when an Apply CP operation has failed due to unresolved conflicts that
require merging. Resolution change packages are created through the
Resync CP operation and cannot be manually created by the user.
In addition, you can only apply one resolution change package during
each Apply CP operation, and if you select a resolution change package,
you cannot apply any other change packages during that operation.
Therefore, the applied changes are strictly limited and defined. Anyone
wanting a specific set of changes can then select the associated resolution
change package, run the Apply CP command, and obtain the same results.
What Is a Resolution Change Package?
A resolution change package is similar to a normal change package except
that it contains additional information on:
change packages that are to be applied
modified files that have been checked in
conflicts that have been addressed by merging
When Should I Use a Resolution Change Package?
You need to use a resolution change package if an Apply CP operation has
failed because merging is required and you want to record all merge
operations required to address the issue. To record accurately the results of
the required merge operations, you should use a resolution change
package.
Resolution change packages are particularly useful for assisting
buildmasters to complete their work. When an Apply CP operation has
failed, developers can identify the dependencies and required merges, and
include all the necessary changes in a single resolution change package.
The buildmaster can then redo the Apply CP operation using that
resolution change package. This reduces the amount of decision-making
required of the buildmaster and allows developers to resolve the conflicts
in their own files.
How Is a Resolution Change Package Created?
A resolution change package is created only through the Resync CP
operation. Using the graphical user interface, you can select an existing
change package—or create a new one—and then ask Source Integrity to
use this as a resolution change package. The only requirement is that the
change package must be in the Open state.
The change package you ask Source Integrity to use may or may not
contain entries (that is, files), but for the greatest level of control in isolating
a feature or issue, it is preferable to start with an empty change package.
429

Chapter 12: Advanced Change Package Operations
Key Resolution
CP Concepts
430
The process for creating a resolution change package is as follows:
1 You create a normal change package and, during a Resync CP
operation, you ask Source Integrity to use it as a resolution change
package for recording all conflicts.
Source Integrity takes the specified change package and adds a
resolution list, thereby making it into a resolution change package.
2 Once all the merge conflicts are addressed, you can do one of the
following:
You submit the resolution change package and Source Integrity
applies the changes.
You submit the resolution change package without updating
member revisions; then the Buildmaster applies the resolution
change package at the time the software is built.
Submitting the resolution change package causes Source Integrity to
apply the change package. If reviews are mandatory, the apply CP
command records the applied changes in another change package that
then follows the review process (see “Change Package Review
Process” on page 240).
Are There Any Limitations When Using a Resolution CP?
To avoid the problem of overlaps and conflicts during the Apply CP
operation, you can only apply one resolution change package per
operation.
The next three sections describe how to work with a resolution change
package. The topics covered are:
key concepts (see “Key Resolution CP Concepts” on page 430)
an example (see “How Resolution CPs Work” on page 431)
procedures for the graphical user interface (“To create a resolution
change package in the graphical user interface” on page 434)
The following lists the key concepts associated with resolution change
packages:
A resolution change package records all the required changes needed
to address the conflicts (or required merging) found when the Apply
CP command fails. All conflicts identified by Source Integrity are
represented in the change package as deferred Update entries
(representing a deferred check in).
u s e r g u i d e

How Resolution
CPs Work
Working With a Resolution CP
A resolution change package works by stating that entries in the
resolution change package supersede corresponding entries found in
change packages on the resolution list. Thus, if you perform a merge
from a branch and check the result into a resolution change package,
the resulting revision supersedes any entries in the listed change
packages that might be on branches.
A resolution change package is created through the Resync CP
operation. There is no way to manually create a resolution change
package.
You can select an existing change package—or create a new one—and
then ask Source Integrity to use it as a resolution change package. The
only requirement is that the change package must be in the Open state.
For the greatest level of control in isolating a feature or issue, it is
preferable to start with an empty resolution change package. When
the resolution change package contains no previous entries, the only
additions will be those that specifically relate to the issue in question.
If the resolution change package contains other change package
entries, Source Integrity will also process those entries.
To avoid the problem of overlaps and conflicts during the Apply CP
operation, you can only apply one resolution change package per
operation.
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 newlyreleased
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. If the Integrity Manager integration is enabled, an
issue is created and then associated with a created change package.
An MDT developer is assigned to fix the problem.
431

Chapter 12: Advanced Change Package Operations
Using a
Resolution CP
432
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, what
is the best method for transferring the MDT bug fix work back to the main
development path so that it can be incorporated into the next product
release? The Resync CP command is the best option for applying the new
fix.
A PT developer can now create a second change package, 1204:2 for the
same issue. The second change package would include the summary
“Applied fix to main development path”. The PT developer would start
the Resync CP command, select the main development sandbox, and the
first change package—1204:1—in this issue. The second change package—
1204:2—would be used as a resolution change package.
Once all merges have been resolved, the developer submits the resolution
and Source Integrity 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.
The basic process for resolving conflicts is to apply the target change
package using the Apply CP command. If the Apply CP operation fails
because of a merge conflict, you must then use the Resync CP command to
create a resolution change package. That resolution change package is then
submitted, and Source Integrity applies the changes to the project.
The process involves the following key steps:
Use the Apply CP command to apply a change package to the main
trunk of development.
If Apply CP fails due to a required merge, use the Resync CP
command on the same change package and create a new resolution
change package. Resync CP places the required files, locked, in your
sandbox.
Verify the merges to ensure they are correct.
In your sandbox, check in the members, making sure to associate them
with the newly created resolution change package.
u s e r g u i d e

Working With a Resolution CP
Submit that resolution change package, thereby applying the changes
to the project.
The Apply CP command works directly in the project, adding and
dropping files, and updating file revisions as required to apply the
resolution change package and update the project.
It is important to note that while Resync CP can be used to apply a
resolution 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.
Resolving Binary Conflicts
When a conflict between two revisions of a binary file is encountered,
Source Integrity replaces the sandbox working file for that member with
the destination revision and marks it as a conflict. The destination revision
appears in the resolution change package as a deferred Check In entry
(representing a deferred check in 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 appears as a deferred
Check In entry in the resolution 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 resolution change package, thereby
checking in the destination revision for the binary member (or
manually submit the deferred check in of the destination revision).
Perform Manual Binary Merge
Using a third-party tool outside of Source Integrity, perform a binary
merge on the affected member. Then submit the changes in the
resolution change package (or manually submit the deferred check in
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
433

Chapter 12: Advanced Change Package Operations
Resolution CP
Procedures
434
deferred Update Revision operation that specifies the desired
revision.
This section outlines the procedures required to work with resolution
change packages in both the graphical user interface and command line
interface.
To create a resolution change package in the graphical user interface
1 Create an empty change package. Ensure that the empty change
package is in the Open state.
If the Integrity Manager integration is enabled, you can create an issue
that clearly identifies the feature, content, or bug fix you want to
isolate, and then associate it with a created change package. For more
information on creating an issue in Integrity Manager, see the
Integrity Manager User Guide.
2 Follow steps 1 through 6 of the procedure for resynchronizing a
change package (“To resynchronize a change package in the graphical
user interface” on page 418).
3 To select the options you want Source Integrity to use during the
Resync CP operation, click Next.
The Options panel opens.
u s e r g u i d e

Working With a Resolution CP
4 Select the check box for Create Resolution Change Package option.
5 From the Change Package list, select the change package you created
in step 2.
IMPORTANT
The change package must be in the Open state to select it as a resolution change
package. For the greatest level of control in isolating a feature or issue, it is
recommended that you start with an empty resolution change package. When
the resolution change package contains no previous entries, the only additions
will be those that specifically relate to the issue in question.
6 Select the command options you want Source Integrity to use when
carrying out the Resync CP operation. For more information on
command options, refer to the command options tables (see “Resync
CP General Command Options” on page 423).
435

Chapter 12: Advanced Change Package Operations
436
7 To run the Resync CP command and create the resolution change
package using the selected options, click Finish.
Source Integrity completes the Resync CP operation or returns
information on errors and warnings if the command cannot be
successfully completed.
Merged results are checked out and locked in your sandbox.
8 Review the results, then defer check in of the files and associate them
with the resolution change package ID. This resolution change
package appears by default as the selected change package.
9 Use the Submit Change Package command to submit your deferred
changes in the resolution change package (see “Submitting Change
Packages” on page 238).
Source Integrity runs the Apply CP command on the resolution change
package, reconciling and then applying the changes from both the
specified change packages in the resolution change package and the
new changes in the resolution change package to the project.
NOTE
If reviews are mandatory, Source Integrity runs the Apply CP command after
the change package is accepted.
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.
u s e r g u i d e

Using the Resync By CP Command
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.
NOTE
Do not use the Resync By CP command on a resolution change package
containing deferred entries.
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 Tools > Preferences. This includes the way
in which the backfill list operates. For example, if you specify ask, a backfill
list is displayed. For more information on options for Resync CP, see
“Using the Resync CP Command” on page 406.
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 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 Tools > Preferences. The Resync By CP operation
always sets the backfill list to Entire Change Packages (cp).
Resync By CP Example
Consider a case where a developer makes a change to a 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.
437

Chapter 12: Advanced Change Package Operations
438
Sandbox - Developer 1
main.c
Project
main.c
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
1.1
CP 21:1
1.1 CP 21:1 main.c
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
u s e r g u i d e
Sandbox - Developer 2
1.1 CP 21:1

Sandbox - Developer 1
main.c
1.1 CP 21:1
1.2 CP 22:1
main.h 1.1 CP 22:1
Project
main.c 1.1 CP 21:1
1.2 CP 22:1
main.h 1.1 CP 22:1
Using the Resync By CP Command
Sandbox - Developer 2
main.c
1.1 CP 21:1
CP 22:1
main.h 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. To complete the update,
Developer 2 can check the files into his sandbox.
IMPORTANT
If the working file of the member you are resyncing is modified,
Source Integrity asks you to confirm that you want to merge your
modifications into the working file. For more information on merging on a
resync, see “Automatic Merging on Resync” on page 352.
To resynchronize by change package in the graphical user interface
1 With a Sandbox view open, select one or more members that contain
member deltas.
439

Chapter 12: Advanced Change Package Operations
440
2 Select Member > Resynchronize By Change Package.
If the working file is writable, you are asked to confirm overwriting it.
3 To resynchronize the member, click Yes. For multiple members, click
Yes to All.
The selected member is updated.
NOTE
When using the Resync By CP command on a change package with entries that
add members to a project, after the command completes you must resync each
added member to obtain a working file.
u s e r g u i d e

$ 3 3 ( 1 ' , ;
Views
Annotated
Revision View
A
This appendix provides additional information about the views that are
available in the Source Integrity graphical user interface and Web
Interface.
The Annotated Revision view displays the following information:
Revision displays the revision number for each annotated block.
Author displays the author of the revision.
Date displays the date each member revision was created.
Line displays the line number for each line of text in the revision.
Revision Contents displays the text contained in each annotation
block.
To customize the fields displayed in the Annotated Revision view
(graphical user interface only), see “View Preferences” on page 61.
Select an annotation block, then from the History menu, select one of the
following:
Revision Information, see “Viewing and Editing Revision Information”
on page 314.
View Revision, see “Viewing a Member’s Working File or Revision” on
page 322.
View Member History, see “Viewing a Member History” on page 310.
From the Change Package menu, select one of the following:
View Change Package, see “Using Change Packages and Reviews” on
page 213.
View Issue, see “Viewing a Change Package’s Issue” on page 376.
441

Appendix A: Views
Archive
Information
View
442
The Archive Information displays information for a specified member
archive.
The General panel specifies general archive information options.
Member Name is the path and name of the member that the archive is
for.
Project/Sandbox Name is the path and name of the member’s project
or sandbox.
Archive Name is the path and name of the displayed archive.
Archive Type displays the type of data stored in the archive.
Default Branch specifies the starting point of the default branch. To
specify a default branch, enter a branch number in the Default Branch
field, for example, 2.1.1.
Strict Locking specifies if a strict locking policy is in effect for the
archive. With strict locking on, a user must have a revision locked
before checking in any changes. To enable strict locking, select the
Strict Locking option.
Compressed specifies if the archive is compressed. To compress the
archive, select the Compressed option.
Store by Reference causes each revision to be saved to a separate file,
instead of saving all revisions to one file. This feature improves
performance for archives that contain large binary files. To store the
archive by reference, select the Store by Reference option.
u s e r g u i d e

Change
Package View
Change Package View
Archive Description describes the archive. If necessary, enter or edit a
description.
The Labels panel displays a list of revision labels in the archive, for
example, Draft1 1.1.
The Locks panel displays a list of users who have locks on revisions in the
archive, for example, sholmes 1.2.
Source Integrity provides a way to view change package details and
entries from one view in both the graphical user interface and Web
interface.
The Change Package view has the following three tabs:
The Attributes panel displays the change package ID, summary, the
current change package state, person who created the change package,
date the change package was created, and description (if one was
provided).
By default, the Entries panel displays the following information for
each change package entry:
Type is the entry type of the change package entry. For
information on possible entry types, see “Change Package Entry
Types” on page 220.
Member displays name of the member in the change package
entry.
When it is a Rename entry type, the member name is displayed
with the form: newname(oldname).
Revision displays the number of the revision in the change
package entry.
Sandbox displays the name of the sandbox where the deferred
operation or check out took place.
443

Appendix A: Views
Change
Packages View
444
Project displays the name and path of the project that the member
belongs to. If the entry occurred from a shared subproject, it is the
subproject name and path that are displayed.
Variant displays the name of the variant development path (if a
variant was used) the change package entry occurred on.
Date Changed displays the date the entry was made.
Server displays the host name of the server the entry was made
on.
In the GUI, additional columns are available in the client preferences.
To change the displayed columns, see “View Preferences” on page 61.
If reviews are mandatory, the Review Log panel displays review
information. For more information, see “Viewing the CP Review Log”
on page 250.
The Change Packages view and Manage Change Packages window display
information in the same way. The Manage Change Packages window only
displays change your open change packages (see “Managing Change
Packages” on page 220), whereas the Change Packages view displays all
change packages queried (see “Finding Change Packages” on page 222).
By default, the Change Packages view displays the following information:
ID displays the change package ID.
Issue displays the issue ID if Integrity Manager is enabled.
Creator displays the username of the person who created the change
package.
State displays current state of the change package, which can be Open
or Closed.
Summary displays the summary statement for the change package.
Additional columns are available in the client preferences. To change the
displayed columns, see “View Preferences” on page 61.
From the Change Packages view, you can perform the following tasks
using the Change Package menu:
View Change Package entries and information (see “Viewing Change
Package Details and Entries” on page 226)
View Issue that is associated with the change package (see “Viewing a
Change Package’s Issue” on page 376)
Submit the change package (see “Submitting Change Packages” on
page 238)
u s e r g u i d e

Graphical
History View
(GUI)
Graphical History View (GUI)
Close a Change Package (see “Closing a Change Package” on
page 235)
Edit an existing Change Package (see “Editing a Change Package” on
page 233)
Discard an existing change package (see “Discarding Change
Packages” on page 236)
Accept casts an accept vote on a change package that is under review
(see “Accepting a Change Package” on page 245
Reject rejects a change package that is under review (see “Rejecting a
Change Package” on page 247).
Create a new Change Package (see “Creating a Change Package” on
page 217)
Source Integrity’s Graphical History view provides a comprehensive
picture of the evolution of a project or member from the Project History or
Member History view. The view is designed to clearly display the path of
development from revision to revision, including branches, variants, and
merge lines.
Like the List view, information such as author, state, date, description,
locker, and change package (if one exists) is presented in the Graphical
History view. These details display in a ToolTip when you place the mouse
pointer on a specific revision. Labels appear to the right of the revision,
while icons, like the locked icon, or the working file icon, appear to the left
of the revision.
445

Appendix A: Views
446
Examples of Project History and Member History in the Graphical
History view
Member Histories and Project Histories, whether displayed in the
Graphical History view or List view, can be manipulated with the same
operations, and with a new set of filters specific to the Member History and
Project History views.
For more information on Member History view filters, see “Member
History Filters” on page 311, and on Project History view filters, see
“Project History Filters” on page 264.
u s e r g u i d e

Graphical History View (GUI)
Selecting Revisions in the Graphical History View
(GUI)
Although revisions in the Graphical History view are presented as objects,
you can select them in order to perform operations, just as you would in
the List view.
When you click a revision, a blue outline appears around the object to
indicate that it is selected. You can use SHIFT+click or CTRL+click to select
multiple revisions.
The following tables outline operations available in the Member History
and Project History views, including where you can find the
corresponding procedures.
Member History Operations
For Operation ... See …
Check Out “Checking Out a Member” on page 178
Check In “Checking In a Member” on page 186
Revert “Discarding Changes to a Member” on page 196
View Revision “Viewing a Member’s Working File or Revision” on
page 322
View Annotated
Revision
“Viewing an Annotated Revision” on page 316
Differences “Comparing Revisions” on page 331
Lock “Locking a Member” on page 198
Unlock “Unlocking a Member” on page 200
Add Label “Adding Labels to Members” on page 297
Delete Label “Deleting Member Labels” on page 298
Promote “Promoting Members” on page 299
Demote “Demoting Members” on page 300
Set Member Revision “Setting the Member Revision” on page 330
Archive Information “Viewing and Editing Archive Information” on
page 312
Revision Information “Viewing and Editing Revision Information” on
page 314
Delete Revision “Deleting Revisions” on page 331
447

Appendix A: Views
448
For Operation ... See …
Merge “Merging Revisions” on page 353
View Change Package “Viewing Change Package Details and Entries” on
page 226
Merge Branch “Step Two: Merge Branch” on page 345
Project History Operations
For Operation ... See …
Add Label “Adding Project Labels” on page 265
Delete Label “Deleting Project Labels” on page 266
Promote “Promoting a Project” on page 267
Demote “Demoting a Project” on page 268
View Project Differences “Viewing Project Differences” on page 275
Open Build Project “Opening a Build Project” on page 265
Create Development Path “Creating a Development Path” on page 147
Remove Development Path “Removing a Development Path” on page 149
Dragging in the Graphical History View (GUI)
Dragging is a unique function of the graphical history view, available only
through the Member History view.
In the graphical history view of the Member History view, you can use the
drag method to merge branched revisions. For more information on
branching and merging, see “Step Two: Merge Branch” on page 345.
View Options (GUI)
You can alter the display of information in the graphical history view by
modifying the view options. View options allow you to decide to show
labels, show the legend, and adjust the zoom to suit your needs.
The legend and labels display by default, and the default zoom is set at 100
percent.
To hide labels in the Graphical History view
With a Member History or Project History view open, select View > Show
Labels. The labels disappear from the Graphical History view.
u s e r g u i d e

Graphical History View (GUI)
A check mark next to Show Labels indicates that the Graphical History
view is displaying labels. If a check mark does not appear next to Show
Labels, then the labels are already hidden.
To display the labels, select View > Show Labels. The labels reappear in the
Graphical History view.
To hide the legend in the Graphical History view
With a Member History or Project History view open, select View > Show
Legend. The legend disappears from the Graphical History view.
A check mark next to Show Legend indicates that the Graphical History
view is displaying the legend. If a check mark does not appear next to
Show Legend, then the legend is already hidden.
To display the legend, select View > Show Legend. The legend reappears in
the Graphical History view.
To adjust the zoom in the Graphical History view
With a Member History or Project History view open, from the View menu,
select one of the following:
Zoom 100%
Zoom 75%
Zoom 50%
Zoom to Fit
A bullet next to the zoom indicates the current zoom setting.
To show metadata in the Graphical History view
With a Member History or Project History view open, select View > Show
Metadata.
A box containing truncated metadata appears beside each revision. Point
to the box to display a tooltip that contains the full metadata for the
revision.
Changing Views (GUI)
The Graphical History view is the default view in the Member History and
Project History views. If you prefer to view information in these views in
tabular form, you can toggle to the List view.
If you prefer to always view a Member History or Project History in the
List view first, you can change the default view setting in Preferences.
449

Appendix A: Views
Locks View
450
For information on setting the default view in the Member History or
Project History views, see “View Preferences” on page 61.
To view a Member History or Project History in List view
With a Member History or Project History view open, select View > List.
A bullet next to the view menu item (Graphical or List) indicates the
current view.
The Member History or Project History appears as a list.
To view a Member History or Project History in the Graphical History
view
With a Member History or Project History view open, select View >
Graphical.
A bullet next to the View menu item (Graphical or List) indicates the
current view.
The Member History or Project History appears in the Graphical History
view.
The Locks view displays the following information:
Project displays the name and path of the project where the member
revision was locked from. If the member revision was locked from a
shared subproject, it is the subproject name and path that are
displayed.
Member Name displays the member name for the locked revision.
Revision displays the locked revision number.
Time displays the time the revision was locked
You can also display other columns such as Archive Name, Host, User, C.P.
ID, Sandbox, Development Path. For more information, see “View
Preferences” on page 61.
You can perform the following tasks:
To delete a lock or locks, select a list item and then select Locks >
Unlock.
The revision is unlocked.
To refresh the list of locked revisions, select Locks > Refresh.
The list is updated.
u s e r g u i d e

Member History
View
Member History View
To change the user (GUI only) whose locks are displayed, select Locks
> Change User.
The Retrieve All Locks for a User dialog box is displayed.
From the Locker list, select the name of the user whose locks you want
to view, then click OK.
The user’s locks are displayed in the Locks for User window.
NOTE
From the Locks view, you cannot remove another user’s lock on a member that
was locked from a shared subproject.
Member History View (GUI)
When you open a member history, Source Integrity displays its contents in
a Member History view. The default view for the Member History view is
the Graphical History view, but you can toggle to the List view as well. For
more information on using the Graphical History view, see “Graphical
History View (GUI)” on page 445.
In the Member History view title bar, the name of the member you are
viewing is listed. To see the project that the member belongs to, in the
Graphical History view, point to the first revision. In the List view, point to
the revision icon ( ). A ToolTip appears displaying the project name and
path.
You can apply filters in the Member History view to view and manipulate
a subset of revisions. For information on applying filters in the Member
History view, see “Member History Filters” on page 311.
For information on toggling between the Graphical History view and the
List view in the Member History view, see “Changing Views (GUI)” on
page 449.
The information in the List view of the Member History view displays in
columns with headings and icons. For information on how to configure the
column set, see “Configuring the Source Integrity Column Set” on page 80.
Depending on your view preferences, your Member History view displays
may be different than the default preferences described here. For more
information on View Preferences, see “View Preferences” on page 61.
The following outlines the default column set and what they display:
451

Appendix A: Views
452
The member’s path and name, for example, c:\sandboxdemo\
demoap.c, appears in the first row underneath the columns. If the
working file can be edited, the entry is preceded by a document and
pencil icon ( ). If the working file is read-only, the document and
pencil icon is crossed out with a red line ( ).
Revision displays the following information:
the revision that the working file corresponds to, indicated by
a white document icon
the member’s revision, indicated by a blue striped document
icon
a list of the revisions in the member history, for example, 1.1,
1.2, 1.3, and so on
Author is the user who checked in the revision.
Date is the date and timestamp of the revision. The date and
timestamp can be either the check in time and date or the date and
time the file was last modified, depending on how the user checks in
the file.
Locked displays a revision’s lock status with a padlock and the
date and time the lock occurred and the name of the user who locked
the revision.
Labels are the labels attached to the revision, for example, Draft1.
State is the revision’s state, for example, Beta.
C.P. ID displays the revision’s associated change package ID, for
example, 8230:3. For more information on change packages, see
“Using Change Packages and Reviews” on page 213.
When Track Locks are enabled, the C.P.ID column displays a lock
change package ID assigned during any lock procedure. In all other
cases, the C.P.ID column displays the member revision change
package ID. For more information on Track Locks, see your
administrator.
Revision Description displays the comments that were assigned to the
revision when it was checked in.
Select a revision by clicking it or moving the selector bar to it with the
cursor keys.
A box below the list of revisions displays the revision description for the
currently selected revision. As you move the selector bar from one revision
to another, the description changes to reflect the currently selected
revision.
u s e r g u i d e

Member History View
The Member History view can be resized within the Source Integrity
application window’s workspace or reduced to an icon in the application
window.
The Member History view also supports standard shortcut menus.
Selecting and right clicking a revision in a Member History view displays a
menu of actions you can perform on the selected revision.
Member History View (Web)
When you open a member history, Source Integrity displays its contents in
a Member History view.
To view the Member History view, do one of the following:
select Member > View Member History
click the member name link in the Project view
The information in a Member History view displays in columns with the
following headings and icons:
The member’s path and name, for example:
readme.txt in Project: c:/Libra_Program/project.pj
Revision displays the following information:
the member’s revision, indicated by a blue striped document
icon
a list of the revisions in the member history, for example, 1.1,
1.2, 1.3, and so on
Author is the user who checked in the revision.
453

Appendix A: Views
Member
Information
View
454
Date is the date and timestamp of the revision. The date and
timestamp can be either the check in time and date or the date and
time the file was last modified, depending on how the user checks in
the file.
Locked displays a revision’s lock status with a padlock and the
date and time the lock occurred and the name of the user who locked
the revision.
Labels are the labels attached to the revision, for example, Draft1.
State is the revision’s state, for example, Development.
C.P. ID displays the revision’s associated change package ID, for
example, 19:1. The change package ID is displayed as a hyperlink
that opens the change package. For more information on change
packages, see “Using Change Packages and Reviews” on page 213.
Source Integrity displays a lock change package ID (a change package
assigned during a checkout) in priority over the member revision
change package ID (the change package assigned during a check in)
when Track Locks are enabled. For more information on Track Locks,
see your administrator.
The Member Information view displays information about a specified
member.
The Member Information dialog box presents the following information on
the General panel:
Member Name is the path and name of the member.
u s e r g u i d e

Non-Members
View
Non-Members View
Project/Sandbox Name is the path and name of the member’s project
or sandbox.
NOTE
As part of the Change Package review process, if the member has a pending
operation against it or one of its revisions, the information appears in a note,
for example, This member has a pending update to member
revision 1.2 by devans.
Member Revision is the displayed member revision. To select another
member revision, choose a revision from the Member Revision list.
Created By is the name of the user who created the revision and the
date and time it was created.
Locked By is the name of the user who locked the revision, and the
date and time it was locked.
Locked In is the sandbox location and host name of the computer
where the lock on the revision was made.
State is the state assigned to the revision. To change the state of the
revision, choose a state from the State list. For more information on
states, see “Promoting Members” on page 299.
Revision Description is a brief description of the revision. You cannot
change an existing revision description from this dialog box, but you
can append additional comments to it. To do so, enter any
supplemental information in the Revision Description field below the
present information (indicated by a line if an existing description is
present).
For information on the Attributes tab, see “To view or edit member
attributes in the graphical user interface” on page 290. For information on
the Labels tab, see “To view or edit member labels in the graphical user
interface” on page 292. For information on the Change Package tab, see
“To view a member’s change package information in the graphical user
interface” on page 230.
The Non-Members view displays the following information:
Closest Project displays the project or subproject, with file path,
corresponding to the sandbox that is closest to the directory
containing the file.
Closest Sandbox displays the sandbox or subsandbox, with file path,
that is closest to the directory containing the file.
455

Appendix A: Views
456
Member ID displays the default member name for the file as it would
appear if it was added to the nearest project. In the case where the
nearest project is subproject, the relative path is displayed with the
member name.
Absolute Path displays the absolute file path of the file.
Size displays the size of the file in bytes.
Last Modified displays the date that the file was last modified.
You can modify which columns appear in the Non-Members view by
changing the Non-Members view preferences. For more information, see
“View Preferences” on page 61.
From the Non-Members view, the following operations can be performed:
To add non-member files to the project, select the member in the list,
then do one of the following:
Select Non-Member > Add.
Click .
For more information, see “Adding Members to a Project” on
page 157.
To delete non-member files from the sandbox directory, select the
members in the list, then do one of the following:
Select Non-Member > Delete.
Click .
To edit non-member files, select the members in the list, then do the
following:
Select Non-Member > Edit.
Click .
To change the filter criteria, do one of the following:
Select View > Filters.
Click .
For more information, see “Filtering Non-Member Files” on page 156.
To refresh the contents of the view, select View > Refresh.
u s e r g u i d e

Project View Project Views (GUI)
TIP
Project View
To add non-member files to a project or subproject, drag the files from the
Non-Members view to the sandbox or subsandbox that corresponds to that
project or subproject in a Sandbox view.
When you open a project, Source Integrity displays its contents in a Project
view.
A project is any group of files that, taken together, forms a single body of
work. Projects are presented in Project views, which list the members of the
project and provide access to them.
Source Integrity 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.
The Project view displays project members and subprojects in a tree
structure. You can expand and collapse a project or subproject tree using
one of the following options:
Double click the project or subproject.
Click the plus or minus icons in the directory list.
Right click the project or subproject, then select Expand All.
Select View > Expand All or View > Collapse All.
Select a member by clicking it or by moving the selector bar to it with the
cursor control keys. Use the up and down arrows to move through the
project hierarchy. Use the right arrow to open a project, revealing its
members. Use the left arrow to close a project.
457

Appendix A: Views
458
A box below the list of members displays all delta information: working
file deltas, new revision (member) deltas, and revision sync deltas. For
example, if the working file has been updated but not checked in, a
message tells you that the working file has been changed.
The information in Project view displays in columns with headings and
icons. For information on how to configure the column set, see
“Configuring the Source Integrity Column Set” on page 80.
Depending on your view preferences, the columns displayed may be
different than the default preferences described here. For more information
on View Preferences, see “View Preferences” on page 61.
The following list outlines the default column set and what they display:
Name displays the following information:
project or subprojects, for example, project.pj
project members, for example, demoapp.c
pending members (or rename to)
pending dropped members (or rename from)
shared subprojects
build configured subprojects
variant configured subprojects
The working revision number displays when the working file revision
is different from the member revision number.
Working Rev. displays the checked out revision number
corresponding to the member’s working file, for example, 1.2.
Member Rev. displays the member’s revision number, or in the case of
a subproject, the subproject revision number (if any), for example,
1.3.
In the column, a delta symbol with a white document icon
( )means your working file has changed. It also appears when no
working file exists for the member. A description of the changes is
shown at the bottom of the window.
In the column, a delta symbol with a blue striped document
icon indicates that the working revision does not match the member
revision. A description of the changes is shown at the bottom of the
window.
In the column, a snowflake icon means the member is frozen.
When the member is thawed, the snowflake icon disappears.
u s e r g u i d e

Project View
Locked displays a member’s lock status with a padlock and the
date and time the lock occurred and the name of the user who locked
the member.
Labels displays any labels assigned to the member revision, for
example, Draft1.
State displays the state of the member revision, for example, Beta.
Member CPID displays the member’s associated change package ID,
for example, 8230:3. For more information on change packages, see
“Using Change Packages and Reviews” on page 213.
Project View (Web)
When you open a project using the Source Integrity Web interface,
Source Integrity displays its contents in a Project view.
The Project view displays subprojects and project members. You can open
a project or subproject using either of the following options:
Click the project or subproject link.
From the File menu, click Open Project. From the list, select the project
you want to open, and click OK. The list displayed contains only
master projects, subprojects are not accessible by this procedure.
To return to the project, click the project link displayed in the title bar, for
example, Project: c:/Aurora_Program/project.pj.
The information in the Project view displays in columns with the following
headings and icons by default:
459

Appendix A: Views
Project History
View
460
Name displays the following information:
project or subprojects, for example, project.pj
project members, for example, demoapp.c
pending members (or rename to)
pending dropped members (or rename from)
Member Rev. displays the member’s revision number, or in the case of
a subproject, the subproject revision number (if any), for example,
1.3.
In the column, a snowflake icon means the member is frozen.
When the member is thawed, the snowflake icon disappears.
Locked displays a member’s lock status with a padlock and the
date and time the lock occurred and the name of the user who locked
the member.
Labels displays any labels assigned to the member revision, for
example, Draft1.
State displays the state of the member revision, for example, Beta.
C.P. ID displays the member’s associated change package ID, for
example, 8230:3. The change package ID is displayed as a hyperlink
that displays the change package. For more information on change
packages, see “Using Change Packages and Reviews” on page 213.
Source Integrity displays a lock change package ID (a change package
assigned during a checkout) in priority over the member revision
change package ID (the change package assigned during a check in)
when Track Locks are enabled. For more information on Track Locks,
see your administrator.
Project History View (GUI)
When you open a project history, Source Integrity displays its contents in a
Project History view. The default view for the Project History view is the
Graphical History view, but you can toggle to the List view as well.
For more information on using the Graphical view, see “Graphical History
View (GUI)” on page 445.
You can apply filters in the Project History view to view and manipulate a
subset of revisions. For information on applying filters in the Project
History view, see “Project History Filters” on page 264.
u s e r g u i d e

Project History View
For information on toggling between the Graphical History view and the
List view in the Project History view, see “Changing Views (GUI)” on
page 449.
The information in the List view of the Project History view displays in
columns with headings. For information on how to configure the column
set, see “Configuring the Source Integrity Column Set” on page 80.
Depending on your view preferences, your Project History view displays
may be different than the default preferences described here. For more
information on View Preferences, see “View Preferences” on page 61.
The following outlines the default column set and what they display:
Revision is the revision number.
Author is the user who made a checkpoint of the project revision.
Date is the date and time the project revision was checkpointed.
Labels are the labels attached to the revision, for example, Bug Fixes.
State is the revision’s state, for example, Beta.
Select a revision by clicking it or moving the selector bar to it with the
cursor keys.
A box below the list of revisions displays the revision description for the
currently selected revision. As you move the selector bar from one revision
to another, the description changes to reflect the currently selected
revision.
461

Appendix A: Views
Project
Differences
View
462
The Project History view can be resized within the Source Integrity
application window’s workspace or reduced to an icon in the application
window.
The Project History view also supports standard shortcut menus. Selecting
and right clicking an archive revision in a Project History view displays a
menu of actions you can perform on the selected item.
Project History View (Web)
When you open a project history, the Source Integrity Web interface
displays its contents in a Project History view.
The information in a Project History view displays in columns.
The column headings are as follows:
Revision is the revision number of the member.
Author is the user who checkpointed the project revision.
Date is the date and time the project revision was checkpointed.
Labels are the labels attached to the revision, for example, Bug Fixes.
State is the revision’s state, for example, Beta.
The Project Differences view displays project differences between
checkpoints of project. The changes to a project and its members are not
tracked as they happen, but rather the View Project Differences command
takes two checkpoints (or one checkpoint and the current version) of the
project and then compares them.
u s e r g u i d e

Project Differences View
The View Project Differences command can compare the following:
two specified revisions of the project
the current revision of the project with a specified revision
the current version of the project with the last checkpointed revision
For more information, see “Viewing Project Differences” on page 275.
By Member Panel
The By Member panel displays the following information:
Name displays name of the project, subproject, or member changed.
Change displays the operation performed on the member or
subproject, and the resulting revision number.
Selecting a member entry displays the following information:
Revision displays the member’s revision number.
Author displays the author of the revision.
Date displays the date each revision in the history was created.
Labels displays revision labels.
State displays the state of the member revision.
C.P. ID displays the revision’s associated change package ID.
NOTE
Members that were checked in between the two checkpoints without updating
the revision number do not appear in the Project Differences view, and do not
display change package information in the By Change Package panel.
463

Appendix A: Views
Project
Information
View
464
By Change Package Panel
Change package information displayed on the By Change Package panel is
drawn from the modifications calculated from the checkpoint comparison.
The By Change Package panel displays the following information:
ID displays the change package ID for change packages that contain
entries with member changes between project revisions
Summary displays the change package summary for change packages
that contain entries with member changes between project revisions.
Modifications that are not associated with a change package (unresolved)
are displayed in the bottom frame of the By Change Package panel. Where
possible, the member or project name is displayed with full path
information.
The following are reasons why modifications can appear in the bottom
frame:
The change package entry is missing; either because one was not
recorded for the member operation, or the entry was discarded.
The operation that made the modification cannot use a change
package, for example, adding a subproject.
The project state captures compared are from different development
paths.
Pending change package entries do not appear in the By Change Package
panel.
The Project Information view displays information for a specified project.
u s e r g u i d e

Registered
Projects View
The General tab displays the following project information:
Project Name is the path and name of the project.
Registered Projects View
Shared From appears only if the project you selected is a shared
subproject and displays the path and name of the project where the
shared subproject originated. For information on Shared Subprojects,
see “Adding a Shared Subproject” on page 127.
Server is the Integrity Server name and port number where the project
resides.
Development Path displays the development path name (if a variant
project on a development path, or project contains a variant subproject
on a development path).
Revision is the project’s current revision number.
Last Checkpointed is the last date and time the project was
checkpointed.
Members is the number of members in the project, not including
subprojects.
Subprojects is the number of subprojects in the project.
Description is a free-form text description of the master project. Edit
the existing description, or enter a new description.
For information about the Attributes tab, see “Working With Project
Attribute Information” on page 259. For information about the
Development Paths tab, see “Working With Development Path
Information” on page 261.
Registered Projects View (GUI)
From the Registered Projects view you can open, create, import, and drop
projects.
When you switch views from a Registered Projects view to another dialog
box or window, the Registered Projects view is no longer visible, but it is
still accessible from the taskbar.
The Registered Projects view contains one tab, Regular, that displays
projects used for regular development.
465

Appendix A: Views
466
The Registered Projects view supports standard shortcut menus. To
display the menu of actions you can perform, select a project or sandbox
and right click. Source Integrity displays the applicable shortcut menu.
Registered Projects View (Web)
The Registered Projects view allows you to view the projects and project
histories that are available on the Integrity Server.
The Registered Projects view displays all regular projects used for
development.
To view the Registered Projects view, select Tools > Manage Projects or
click .
u s e r g u i d e

Registered
Sandboxes
View
Registered Sandboxes View
From the Registered Sandboxes view you can open, create, import, and
drop sandboxes.
When you switch views from a Registered Sandboxes view to another
dialog box or window, the Registered Sandboxes view is no longer visible,
but it is still accessible from the taskbar.
The Registered Sandboxes view contains three tabs that display the
following different types of sandboxes:
Regular is a sandbox used for normal or main project development.
Variant is a sandbox used for branching off the main development
path of a project.
Build is a sandbox based upon a specific revision of a project, typically
used as a reference for building or testing the project. It is not suitable
for further development due to limited project modification abilities.
NOTE
Sandboxes based on configured subprojects do not appear with a configuration
icon in the Registered Sandboxes view. For more information on configured
subprojects, see “Configuring a Subproject” on page 131.
The Registered Sandboxes view supports standard shortcut menus. To
display the menu of actions you can perform, select a project or sandbox
and right click. Source Integrity displays the applicable shortcut menu.
467

Appendix A: Views
Revisions
Information
View
468
The Revision Information view displays information for a specified
revision.
The General tab displays the following information:
Member Name is the path and name of the member.
Project/Sandbox Name is the path and name of the member’s project
or sandbox.
Revision is the revision corresponding to the displayed information. If
the revision is pending, then pending appears in parenthesis (see
“Working With Pending Revisions” on page 335).
Created By is the name of the user who created the revision, and the
date and time it was created.
Locked By is the name of the user who locked the revision, and the
date and time it was locked.
Locked In is the sandbox location and host name of the computer
where the lock on the revision was made.
State is the state assigned to the member. To apply a different state to
the member, choose a state from the State list.
Revision Description is a brief description of the revision. You cannot
change an existing revision description from this dialog box, but you
can append additional comments to it. To do so, enter any
supplemental information in the Revision Description field below the
present information (indicated by a line if an existing description is
present).
u s e r g u i d e

Sandbox View
Sandbox View
For information on the Labels tab, see “To view or edit member labels in
the graphical user interface” on page 292. For information on the
Change Package tab, see “To view a member’s change package
information in the graphical user interface” on page 230.
When you open a sandbox, Source Integrity displays its contents in a
Sandbox view.
Sandboxes can reside on the client machines and allow you to work locally
in your own workspace, without interfering with the work of others. You
can think of the sandbox as a local pointer to the project residing on the
Integrity Server. A sandbox is a mirror image of a Source Integrity project.
Although it looks and acts like the project it mirrors, it is actually a
collection of pointers to its real-life counterparts in the master project.
The Sandbox view displays project members, and subsandboxes in a tree
structure. You can expand and collapse a project, sandbox, and
subsandbox tree using one of the following options:
Double click the sandbox or subsandbox.
Click the plus or minus icons in the directory list.
Right click the sandbox or subsandbox and select Expand All.
Select View > Expand All or View > Collapse All.
Select a member by clicking it or by moving the selector bar to it with the
cursor control keys. Use the up and down arrows to move through the
project or sandbox hierarchy. Use the right arrow to open a project or
sandbox, revealing its members. Use the left arrow to close a project or
sandbox.
A box below the list of members displays all delta information: working
file deltas, new revision (member) deltas, and revision sync deltas. For
example, if the working file has been updated but not checked in, a
message tells you that the working file has been changed.
469

Appendix A: Views
470
The information in Sandbox views is displayed in columns with headings
and icons. For information on how to configure the column set, see
“Configuring the Source Integrity Column Set” on page 80.
Depending on your view preferences, the columns displayed may be
different than the default preferences described here. For more
information, see “View Preferences” on page 61.
The following list outlines the default column set and what they display:
Name displays the following information:
sandbox or subsandboxes, for example, project.pj
sandbox members, for example, demoapp.c
deferred members
deferred dropped members
pending members (or rename to)
pending dropped members (or rename from)
shared subprojects
build configured subprojects
variant configured subprojects
The working revision number displays when the working file revision
is different from the member revision number.
Working Rev. displays the checked out revision number
corresponding to the member’s working file, for example, 1.2. If it is a
pending revision, pending appears in parenthesis, for example,
1.2 (pending).
Member Rev. displays the member’s revision number, or in the case of
a subproject, the subproject revision number (if any), for example,
1.3.
In the column, a delta symbol with a white document icon
( )means your working file has changed. It also appears when no
working file exists for the member. A description of the changes is
shown at the bottom of the window.
In the column, a delta symbol with a blue striped document
icon indicates that the working revision does not match the member
revision. A description of the changes is shown at the bottom of the
window.
In the column, a snowflake icon means the member is frozen.
When the member is thawed, the snowflake icon disappears.
u s e r g u i d e

Sandbox
Information
View
Sandbox Information View
Locked displays a member’s lock status with a padlock and the
date and time the lock occurred and the name of the user who locked
the member.
Labels displays any labels assigned to the member revision, for
example, Draft1.
State displays the state of the member revision, for example, Beta.
Working CPID (sandbox only) displays the change package associated
with a deferred or a lock operation performed by the current user
from the current sandbox. A icon is displayed beside the change
package ID.
Member CPID displays the member’s associated change package ID,
for example, 8230:3. For more information on change packages, see
“Using Change Packages and Reviews” on page 213.
The Sandbox Information dialog box is displayed.
The General tab displays the following general sandbox information:
Sandbox Name is the path and name of the sandbox.
Project Name is the path and name of the master project.
Server is the Integrity Server name and port number where the master
project resides.
Revision is the master project’s current revision number.
Last Checkpointed is the last date and time the master project was
checkpointed.
471

Appendix A: Views
472
Members is the number of members in the sandbox.
Subsandboxes is the number of subsandboxes in the sandbox.
Sparse setting determines if the selected sandbox is a sparse sandbox.
Shared setting determines if the selected sandbox is a shared sandbox.
Line Terminator setting determines the type of ASCII character
Source Integrity recognizes as the end of a line of text: Native (or
automatic, the default setting), LF (or line feed, primarily for UNIX
applications), or CR/LF.
Project Description is a description of the master project.
For information on the Project Attributes tab, see “Viewing Project
Attributes From a Sandbox” on page 281. For information on the Sandbox
Attributes tab, see “Viewing Sandbox Attributes” on page 282.
u s e r g u i d e

$ 3 3 ( 1 ' , ;
Glossary of Terms
B
A project is any group of files that, taken together, forms a single body of
work. Projects are presented in Project views, which list the members of the
project and provide access to them.
Access Control List See ACL.
ACL An Access Control List (ACL) is a collection of entries that permits
or limits entry to the functionality of a software program or server. The
Access Control List allows the administrator to manage user access by
requiring authentication of the user’s identity or membership in a
predefined group. Access is then granted according to the assigned
permissions. See principals, permissions.
administrator The administrator installs Source Integrity; defines and
customizes projects and policies; and creates and manages user accounts,
allowing users to access the program.
annotated revision Source Integrity provides an annotated revision view
for member revisions. Use it when you want to investigate the reason and
circumstances a revision was introduced or changed. 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 revisions in an annotated list.
archive description The archive description contains text that describes
the purpose of an archive. Each time you create an archive, you can assign
to it a description.
archive information Just as it maintains information about each project
member, Source Integrity also maintains historical information about each
member archive 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 strict-locking applies to the archive, and
a description of the archive.
archive 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, Source Integrity can reconstruct
any previous version of the member. The archive is sometimes referred to
as the RCS file, for historical reasons.
473

Appendix B: Glossary of Terms
474
author name The author name is the name you associate with revisions
upon check in. By default, your author name is your user name.
binary file A binary file contains unprintable characters, or lines too long
to be handled by text editors.
branch A branch is a revision path that diverges from the main line of
development (or trunk) in a member or project history. A branch is typically
created by checking in a file to a revision other than the head revision. The
most recent revision of a branch in a history is called the tip revision. When
you branch a member the working revision number is appended to indicate
the branch. For example, the member features.txt at revision 1.2 is
branched and appears with the working revision number 1.2.1.1.
build project A Build project is a static project based upon a specific
revision of the master project. It is used for building or testing the project,
but not for further development.
change package review A change package review is a review of changes
by specified reviewers before the changes are committed to the server
repository.
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.
change package watcher 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 A change package is a group of changes made by a single
user which can be considered a logical unit of work. Only the creator of a
change package may add entries to that change package. Change package
entries take the form of operations, both deferred and committed. When
reviews are mandatory, change package entries take the form of pending
entries before they are committed.
check in 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.
checkpointing 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 at
any time in the future. The saved information includes the project structure
and the list of members with their revision numbers.
u s e r g u i d e

Glossary of Terms
command line interface The command line interface, or CLI, is a program
that allows a user to enter keywords as instructions to a computer or device
to perform specific tasks. (The MS-DOS® Command Prompt is an example
of a CLI.) Results are typically outputted as simple text to the user’s
terminal.
default editor The default editor is the editor used to display a working
file or revision, for example, Microsoft Windows Notepad or MKS Toolkit’s
vi for Windows editor.
deferred member A deferred member is a member that is associated with
any deferred operation (add, drop, check in, rename). A deferred member
appears in the sandbox, but the deferred operation is not shown in the
project until the deferred operation is submitted.
delta The set of differences (stored in a history) between one revision and
its immediate ancestor, is known as a delta. Using deltas, the program can
reconstruct the exact contents of any revision without having to store
complete copies. Known also as reverse delta storage, it is the standard RCS
format for archives.
demoting You can demote a revision by changing its promotion state
setting from a higher level to a lower one.
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.
drop (a project or sandbox) To drop a project or sandbox means that the
project or sandbox is no longer registered with the Integrity Server. Once a
project or sandbox is dropped, it cannot be accessed with Source Integrity.
However, if the project or sandbox is not deleted and you can import it
again if you want it to be accessible in Source Integrity.
Federated Server Architecture MKS Federated Server Architecture is an
implementation of the Integrity Server structured to serve client requests
through a proxy. The proxy provides access to project members residing on
the Integrity Server by retrieving information from its local cache or, if
changes are detected, directly from the server.
former member A former member is one dropped from the project.
Source Integrity retains the member history for former members as part of
the project. Depending on the options you select when dropping the
member, Source Integrity can also delete the member’s working file and
close any associated change package.
freezing (a member) 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.
475

Appendix B: Glossary of Terms
476
graphical user interface (GUI) The graphical user interface, or GUI, is a
program interface that uses a number of visual components (such as icons,
pointers, and pull-down menus) to execute commands. Working in a GUI
allows the user to give instructions to the computer without having to learn
a specific command language.
Head revision The head revision is the tip revision on the default branch,
or the trunk, if no default branch is defined.
importing (a project, sandbox, or member) Importing a project, sandbox,
or member registers it with the Integrity Server. Once a project, sandbox, or
member is imported, Source Integrity commands can be performed upon it.
Integrated Development Environment (IDE) An Integrated
Development Environment, or IDE, is a supported development
application, such as Sybase PowerBuilder, that allows you to access
Source Integrity functionality by installing the appropriate extension.
issues Issues track changes in the software development cycle. For
example, your administrator can configure Integrity Manager in a way that
a problem issue may be associated with a solution issue for easy tracking
and monitoring of both issues. Each issue has an audit trail, which may be
used to evaluate internal processes for the effectiveness of the problem
resolution process. In effect, issues track all aspects of any engineering
endeavor.
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.
keyword 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.
locker The person who has a revision locked is referred to as the locker.
locking Locking a member prevents more than one user from
simultaneously making changes to the same revision. When a revision is
locked, no one other than the locker can check in changes to that revision.
metadata Metadata is composed of all of the information about a revision
or archive, as opposed to the information that is part of the object. For
example, a revision’s Revision Description is metadata since it is
information about the revision, while the contents of the revision is part of
the revision itself and, hence, is not metadata.
pending member A pending member, is a member that is associated with
a pending operation that adds it to the project. The pending member is
denoted by a pending icon displayed in the Name column of the Sandbox
and Project views. The following are commands that create pending
members: Import, Add, Add From Archive, Rename To.
u s e r g u i d e

Glossary of Terms
pending operations Pending operations are operations whose proposed
changes reside on the server, but have not been committed to the repository.
pending revision Pending revisions are created by Source Integrity when
a change package containing deferred operations is submitted. Pending
revisions are also created when reviews are mandatory and an operation
that creates a new revision is performed without deferral (see the
documentation for the desired operation for more information).
permissions Permissions are a collection of pre-defined functionality and
operations that can be assigned to users, granting access to certain
Source Integrity tasks. The set of assigned permissions determines each
user’s access to the various functions of Source Integrity. If a user is not
granted the permission, that user is not able to complete the task. For
example, checking out files in Source Integrity requires the
FetchRevision and Lock permissions.
Project History view The Project History view is a window that displays
the revision history of a project, including details on the revision number,
author, date, labels, and promotion state of the project.
project member A project member is any file that is included in a project.
Project members are displayed in the Project view.
Project view The Project view displays the members and subprojects of a
project.
project A project is any group of files that, taken together, forms a single
body of work. Projects are presented in Project views, which list the
members of the project and provide access to them.
promoting Promotion is the process of managing data as it moves
through a structured development cycle. Any project (whether it is software
development, document production, or any other type of data
management) goes through recognizable phases: from inception, through
development, testing, quality assurance, and completion.
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.
Reports Reports are summaries of the data in your project. Reports are
based on the standard and custom fields of issue types. Reports can be
customized to include images, fonts, hyperlinks, and can be saved as HTML
files for viewing on the Web.
477

Appendix B: Glossary of Terms
478
Resolution change package A resolution change package is a specialized
change package that records all applied change packages, resolved
conflicts, checked in modified files, and conflicts resolved by merging. A
resolution change package is applied when an Apply CP operation has
failed due to unresolved conflicts that require merging. Resolution change
packages are created through the Resync CP operation and cannot be
manually created by the user.
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 member’s
working file since it was checked out, and then unlocks it.
revision description A revision description is text that becomes a
permanent part of the archive’s 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 label A revision label is a textual name that describes and refers
to revisions in a history. When a file is checked in, you are given the option
of assigning it a revision label. Revisions in a history can be displayed and
selected either by revision number or revision label.
revision number Each revision is assigned a unique revision number
used to identify a revision in a history. Revisions on the trunk 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 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.
Sandbox view The Sandbox view displays the members and
subsandboxes of a single sandbox.
sandbox Sandboxes can reside on the client machines and allow you to
work locally in your own workspace, without interfering with the work of
others. You can think of the sandbox as a local pointer to the project residing
on the Integrity Server. A sandbox is a mirror image of a Source Integrity
project. Although it looks and acts like the project it mirrors, it is actually a
collection of pointers to its real-life counterparts in the master project.
Sandboxes can reside on the client machines and allow you to work locally
in your own workspace, without interfering with the work of others. You
can think of the sandbox as a local pointer to the project residing on the
Integrity Server. A sandbox is a mirror image of a Source Integrity project.
Although it looks and acts like the project it mirrors, it is actually a
collection of pointers to its real-life counterparts in the master project.
u s e r g u i d e

Glossary of Terms
shared sandbox Source Integrity 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.
shared subproject A shared subproject is a subproject that is a member of
more than one project. Source Integrity 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.
snapshot A snapshot is a capture of 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 Integrity Server. The sandbox snapshot creates a
standard project revision from which a build sandbox can be created and a
development path assigned. The project revision number takes the form of
a branched revision in the project history. For example, if the head revision
of the project is 1.1, then the project revision created by the snapshot will be
1.1.1.1.
sparse sandbox A sandbox with no working files. A sparse sandbox does
not retain working files even when a member is checked in, and continues
to function this way throughout its use.
state 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.
strict locking Strict locking is a policy that enforces users to have a lock on
a revision to perform a check in operation.
subproject Source Integrity allows you to create large projects composed
of smaller component projects. These smaller projects are known as
subprojects. Subprojects behave in the same way as projects, and can be
accessed with most project and sandbox commands.
subsandbox A subsandbox is a sandbox within a sandbox. Subsandboxes
are typically smaller components of a sandbox, such as documentation or
graphic files.
Super Reviewer A Super Reviewer is a user with permission to vote on
change packages that the user is not a listed reviewer for. 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.
thawing 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.
479

Appendix B: Glossary of Terms
480
tip revision The tip revision is the most recent revision on a branch in a
history.
trunk The trunk is the primary line of a file’s change history in a history.
The first member of the trunk is always the original file checked into the
archive.
type (project member) Project members may be one of following types of
files: archived (files under Source Integrity revision control), or subproject
(another Source Integrity project).
updating a member revision Within the graphical user interface, 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 member’s history.
user A user is anyone who needs to work with Source Integrity projects.
variant sandbox While a regular sandbox is based on the current state of
the project, a variant sandbox is based on a previously checkpointed
revision of the project. When you create a variant sandbox, you choose a
checkpoint (snapshot) of your project and use it as the starting point for a
new branch of development. Source Integrity allows you to do this by
defining a new development path.
Web interface The Web interface is a program interface that appears in a
Web browser, such as Netscape Navigator and Microsoft Internet Explorer.
Working in a Web interface offers the familiar functionality of a Web
browser with no client installation required.
working file A working file is a file that contains a working copy of a
checked out revision. Users edit and change the working file, not the
revision itself. Changes to the working file are added to the history (as a
new revision) when the working file is checked in.
u s e r g u i d e

Index
A
access control list
described 31
understanding ACLs 31
access keys
graphical user interface 79
access permission 30
ACL
See access control list
adding
change package entries 219
label
to member 297
to project 265
to revision 320
member
deferred 158
to project 157
to project from archive 166
subproject 125
administrator
described 1
all members
filter 87, 97
annotated revision 316
any member delta
filter 87
application window
graphical user interface 76
Web interface 95
applying change package 381
backfill list 391
backfill option 394
command option 403
GUI command 398
key concept 388
overview 383
process 389
architecture
server 13
archive
information
editing 312
viewing 312
archive description
described 160
assigning
revision description 187
revision number 186
attribute
project 259
Author keyword 210
B
backfill list
Apply CP 391
Apply CP option 394
Resync CP 409
Resync CP option 413
before starting
access control lists 31
access permission 30
Source Integrity 30
binary file 18
comparing 18
described 18
branch
described 338
ignore 416
merge on 415
merging 345
by dragging 348
on check in 343
on check out 350
on resync 352
renaming member on branch 194
starting during check in 186
branching
on check out 338
browser requirements 24
481

Index
build project
opening 265
build sandbox
creating 135
described 150
C
canceling deferred operation 203
change
scanning sandbox for 185
change package
accepting 245
adding entries 219
to an issue 376
Apply CP process 389
applying 381
command option 403
GUI command 398
key concept 388
closing 235
creating 217
for an issue 375
discarding 236
editing 233
entries
differences 255
discarding 254
moving 252
types 220
explained 214
finding 222
using query 378
managing 220
methodology 382
opening 249
rejecting 247
resolution
creating 434
GUI command 434
key concepts 430
process 431
using 432
Resync CP process 408
resynchronizing 406
by CP 436
command option 423
example 437
GUI command 418
key concept 407
submitting 238
482
using to control development 216
viewing 226
associated issue 376
viewing reviews 250
why to use 215
workflow 242
check in 14, 18
check out 14, 17
checking in
member 186
merging on check in 343
checking out
automatic merging on check out 350
branching 338
member 178
checkpointing 19
project 19, 269
CLI
described 98
using graphical user interface 98
closing
change package 235
client 73
client session 72
columns
configuring 80
command
ident 210
option
Apply CP 403
Resync CP 423
preferences 48
syntax 99
viewing 98
command prompts
described 99
CompanyInfo keyword 210
comparing
project 20
revision 331
working file to member revision 205
concept
checkpointing project 19
delta 18
development path 21
file and object history 15
integrated development environment
project 14
project member 17
sandbox 14
Source Integrity 13
variant 21
u s e r g u i d e

configuration management 14
configuration options 19
configuring
client environment variable 29
graphical user interface
main toolbar 82
Source Integrity 40
subproject 131
conflict
viewing in Visual Merge 361
connecting
preferences 43
to multiple servers 39
to server 36
content
reconstructing revision 18
creating
build sandbox 135
change package 217
for an issue 375
development path 147
project 116
report 307
sandbox 135
shared subproject 127
subproject 124
variant sandbox 135
customer support
getting help 8
D
Date keyword 210
deferred item
filter 89
deferred member
described 201
deferred operation 200
adding member 157
adding member from archive 168
canceling 196, 203
checking in member 186
dropping member 172
import 172
renaming member 194
resynchronizing 197, 203
reverting 196, 203
submitting 202
updating a member’s revision 295
deleting
member label 298
project label 266
revision 331
delta
described 18
storing 18
demoting
project 268
revision 324
development
integrated environment 22
object 17
path 21
creating 147
described 146
editing 261
removing 149
viewing 261
difference
project 20, 275
differencing
change package entries 255
third party differencing tool 69
tool preferences 69
Visual Difference 100
editing merge results 359
merging 356
mode 104
panes 103
preferences 105
reverting merge results 359
saving merge results 360
working with 356
discarding
change to working file 196
disconnecting
from multiple servers 40
from server 72
documentation
format
man 4
online help 4
PDF 4
print 4
related 4
dropping
member 172
project 119
described 119
sandbox 143
described 143
subproject 133
Index
483

Index
E
editing
archive information 312
change package 233
development path information 261
member 184
attribute 290
information 287
label 291
merge results in Visual Difference 359
merge results in Visual Merge 363
project
attribute 259
information 258
revision
information 314
label 319
environment variable 92
UNIX client 29
F
file
binary 18
comparing 18
history 15
text 18
working 17
file and object history
filter
15
all members 87, 97
any member delta 87
deferred item 89
existing working files 87
frozen member
list
88, 97
graphical user interface 78
Web interface 96
locked member 88, 97
member at label 88, 97
member at state
member history
88, 97
all revisions 311
branched 311
labeled 311
locked 311
member 311
member locked by me 88, 97
member on branch 88, 97
member with attribute 88, 97
member with label 88, 97
484
member with name 88
missing working file 87
modified working file 87
new member 87
new revision available 87
non-members 156
out of sync member 87
pending item 88
project history
all revisions 264
development path 264
labeled 264
regular expression 89
Unresolved Merges 87
using 86
Web interface 97
Work in Progress 88
working file on branch 87
working file size delta 87
finding
change package
using query 378
change packages 222
former member
described 172
freezing
member 301
frozen member
filter 88, 97
G
general
preferences 42
graph
Reporter 304
graphical history view 445
changing views 449
dragging and dropping 448
member history view 445
project history view 445
selecting revision 447
view options 448
graphical user interface
access keys 79
application window 76
columns
configuring 80
described 76
environment variable 92
filter list 78
u s e r g u i d e

graphical history view 445
member history view 451
member information pane 78
menu bar 76
project history view 460
project view 77, 457
registered project 465
registered sandboxes 467
sandbox view 77, 469
shortcut keys 80
shortcut menu 77
status bar 78
title bar 76
toolbar 77
configuring 82
using in CLI 98
workspace 78
groups
viewing 34
H
Header keyword 210
help
customer support 8
history
file 15
object 15
I
Id keyword 210
IDE
See integrated development environment
ident command 210
ignore branch 416
importing
a project 117
member 169
sandbox 138
installing
Integrity Client 24
UNIX post-install 29
integrated development environment 22
integrations
for Solution
described 372
Integrity Client
installing 24
post-installation on UNIX 29
uninstalling 29
Integrity Manager
integration 372
how works 372
issue
adding entries to a change
package 376
creating a change package for 375
viewing 376
using query 378
Integrity Server
registering project with 14
interface 75
K
keyword
Author 210
CompanyInfo 210
Date 210
Header 210
Id 210
locating 210
Locker 210
Log 211
Name 211
ProjectName 211
ProjectRevision 211
ProjectSetting 211
RCSfile 211
Revision 211
SandboxSetting 211
Setting 211
Source 211
State 211
using 207
keywords
table 210
L
label
deleting from revision 321
labeling
member 297
revision 320
launching
Source Integrity 34
line terminator 136, 281, 472
list, backfill
Apply CP 391
Apply CP option 394
Index
485

Index
Resync CP 409
Resync CP option 413
locating keyword 210
locked member
filter 88, 97
making locked member writable 340
managing revision locks 328
view sandbox that locked member 145
Locker keyword 210
locking
member 198
multiple revisions 327
revision 324
Log keyword 211
logging in 36
logging out 72
M
manage projects
graphical user interface 465
Web interface 466
manage sandboxes
graphical user interface 467
managing change packages 220
member
adding label to 297
adding to project 157
attribute
editing 290
viewing 290
checking in 186
checking out 178
deferring operation 200
deleting label 298
demoting 300
dropping 172
editing 184
freezing 301
history 17
reference format 18
viewing 310
importing 169
information
editing 287
viewing 287
label
editing 291
viewing 291
location 15
locking 198
486
making locked member writable 340
managing locks 328
name 15
permission 31
project 17
promoting 299
removing from project 172
renaming 194
tip revision 194
resynchronizing 197, 293
reverting 196
revision 17
number 15
setting 330
updating 293
selecting 176
thawing 302
type 15
unlocking 200
updating 197
viewing 184
member at label
filter 88, 97
member at state
filter 88, 97
member history view
filter 311
graphical history view 445
graphical user interface 451
Web interface 453
member information pane
graphical user interface 78
member locked by me
filter 88, 97
member name argument
described 99
member on branch
filter 88, 97
member with attribute
filter 88, 97
member with label
filter 88, 97
member with name
filter 88
menu bar
graphical user interface 76
Web interface 95
merge
automatic merging on check out 350
automatic merging on resync 352
on branch 415
merge results
u s e r g u i d e

editing in Visual Merge 363
reverting in Visual Merge 364
saving in Visual Merge 364
merging
branch 345
by dragging 348
in Visual Difference 356
on check in 343
resolving merges 367
revision 353
automatically 354
in Visual Merge 362
revision in CLI 366
revision in Visual Difference 356
revision in Visual Merge 361
suspending in Visual Merge 365
metadata 15
methodology
change package 382
missing working file
filter 87
MKS Visual Difference
See Visual Difference
MKS Visual Merge
See Visual Merge
modified working file
filter 87
N
Name keyword 211
new member
filter 87
new revision available
filter 87
non-members
displaying 154
filtering 156
O
object
control 17
history 15
opening
member history 310
project 121
sandbox 144
option
configuration 19
out of sync member
filter 87
P
pending item
filter 88
pending member 200
permission 31
preferences
command 48
connection 43
difference tool 69
general 42
setting 40
view 61
printing lists and views 78
process
Apply CP command 389
resolution change package 431
Resync CP command 408
project 14, 17
adding member 157
attribute 259
editing 259
viewing 259, 281
checkpointing 19, 269
comparing 20
content 15
creating 116
deleting label 266
demoting 268
difference 20, 275
comparing current to last
checkpointed 279
comparing current to specified
revision 278
comparing two specified
revisions 276
dropping 119
history
viewing 263
importing 117
information
editing 258
viewing 258
member 17
metadata 15
modification
viewing 276
opening 121
Index
487

Index
permission 31
promoting 267
registering with Integrity Server 14
removing member 172
restoring 271
in GUI 272
viewing 121
differences 275
project history view
filter 264
graphical history view 445
graphical user interface 460
Web interface 462
project view
graphical user interface 77, 457
Web interface 96, 459
ProjectName keyword 211
ProjectRevision keyword 211
ProjectSetting keyword 211
project-specific configuration 15
promoting
a project 267
member 299
revision 323
proxy
configuring 45
Q
quick access keys
access keys 79
graphical user interface shortcut keys 80
quitting
session 72
R
RCSfile keyword 211
reconstructing revision 18
reference format
member history 18
registered projects
graphical user interface 465
Web interface 466
registered sandboxes
graphical user interface 467
regular expression
filter 89
related documentation 4
488
removing
development path 149
member 172
renaming
member 194
on a branch 194
tip revision 194
report
creating 307
information 303
type 304
by author 304
by author (summary) 305
member revision to label 305
member revision to revision 306
newer revision 305
project member history 307
revision locked 306
revision with label 306
revision with state 306
Reporter
described 303
graph 304
resolution change package
creating 434
GUI command 434
key concepts 430
process 431
using 432
restoring project 271
in GUI 272
resynchronizing
automatic merging on resync 352
by CP 197, 436
example 437
deferred operation 197, 203
member 197, 293
resynchronizing change package 406
backfill list 409
backfill option 413
binary conflicts 433
command option 423
GUI command 418
ignore branch option 416
key concept 407
merge on branch option 415
overview 383
process 408
reverting
deferred operation 196, 203
member 196
u s e r g u i d e

merge results in Visual Difference 359
merge results in Visual Merge 364
revision 15
adding label to 320
annotated 316
comparing 331
deleting 331
deleting label 321
demoting 324
description
assigning 187
in member history 18
information
editing 314
viewing 314
label
editing 319
viewing 319
locking 324
locking multiple revisions 327
merging 353
automatically 354
in CLI 366
in Visual Difference 356
in Visual Merge 361, 362
number 15
assigning 186
valid 186
promoting 323
reconstructing 18
unlocking 326
viewing 322
viewing locks 328
Revision keyword 211
S
sandbox 14
build 150
creating 135
described 14
dropping 143
importing 138
information
general 280
project attribute 281
viewing 280
opening 144
scanning for change 185
sharing 139
snapshot 283
type 137
variant 21
view sandbox that locked member 145
viewing 144
sandbox view
graphical user interface 77, 469
SandboxSetting keyword 211
saving
merge results in Visual Difference 360
merge results in Visual Merge 364
scanning sandbox
for change 185
selecting
member 176
server
configuring multiple servers 46
connecting 36
disconnecting 72
session
closing client 73
quitting 72
shutting down client 74
setting
member revision 330
preferences 40
Setting keyword 211
shared subproject
creating 127
sharing a sandbox 139
shortcut keys
graphical user interface 80
shortcut menu
graphical user interface 77
shutting down
client 74
snapshot a sandbox 283
Solution integration 372
Source Integrity
before starting 30
concept 13
configuring 40
graphical history view 445
graphical user interface 76
integration with Integrity Manager 372
rules 372
viewing associated issue 376
starting 34
understanding 13
Web interface 94
Source Integrity interfaces 75
Source keyword 211
Index
489

Index
starting
a session 36
branch during check in 186
Source Integrity 34
State keyword 211
status bar
graphical user interface 78
Web interface 96
storing delta 18
submit 202
change packages 238
deferred operation 202
subproject
adding 125
configuring 131
creating 124
creating shared subproject 127
dropping 133
suspending
merges in Visual Merge 365
system requirements
Web browser 24
T
table
keyword 210
text file 18
thawing
member 302
third party difference tool 69
tip revision
renaming 194
title bar
graphical user interface 76
Web interface 95
toolbar buttons
graphical user interface 77
Web interface 96
type
report 304
sandbox 137
U
uninstalling
Integrity Client 29
UNIX
client environment variable 29
490
unlocking
member 200
revision 326
Unresolved Merges
filter 87
updating
member 197
member revision 293
user
described 1
using
filter 86
keyword 207
V
variant sandbox 21
creating 135
described 146
viewing
archive information 312
change package
associated issue 376
details and entries 226
entry member differences 255
multiple 220
command 98
conflict in Visual Merge 361
development path information 261
general sandbox information 280
group membership 34
member 184
member attribute 290
member difference 255
member history 310
member information 287
member label 291
preferences 61
project 121
information 258
project attribute 259, 281
project attribute information 281
project differences 275
project history
opening 263
revision 322
revision information 314
revision label 319
sandbox 144
sandbox information 280
working file 322
u s e r g u i d e

Visual Difference 100
editing merge results 359
merging 356
mode 104
panes 103
preferences 105
reverting merge results 359
saving merge results 360
working with 356
Visual Merge 107
editing merge results 363
merging revision 362
panes 110
preferences 111
reverting merge results 364
saving merge results 364
suspending merges 365
viewing conflict 361
working with 361
W
Web browser
system requirements 24
Web interface 94
application window 95
filter 97
filter list 96
member history view
described 453
menu bar 95
project history view
described 462
project view 96
described 459
registered project 466
status bar 96
title bar 95
toolbar buttons
described 96
Work in Progress
filter 88
working file 17
comparing to member revision 205
discarding change 196
viewing 322
working file on branch
filter 87
working file size delta
filter 87
working file, existing
filter 87
working with project 14
workspace
graphical user interface 78
writable
making locked member writable 340
Index
491

Index
492
u s e r g u i d e