User Guide - MKS

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

MKS Source Integrity® Enterprise Edition 8.4
User Guide
Copyright © 2001–2003 MKS Inc. and MKS Inc. (Delaware). All rights reserved.
MKS and design, MKS Change Integrity, MKS Code Integrity, MKS Engineer Integrity, MKS Federated Server, MKS
Integrity Manager, MKS Integrity Solution, MKS Source Integrity, MKS Toolkit, AlertCentre, CodeRover, DISCOVER,
Implementer, NuTCRACKER, Sandbox, SDM, and Build Better Software are trademarks or registered trademarks of
MKS Inc. All other trademarks acknowledged.
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.
Contains embedded database © Copyright PointBase Inc. All rights reserved.
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.3CNOE-051603
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Your Feedback Is Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Where To Go From Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
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
Integrated Development Environment 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 Into Source Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Connecting to Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
i

Table of Contents
ii
Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
General Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Connection Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Command Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
View Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Difference Tool Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Managing Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Quitting a Source Integrity Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Logging Out of Source Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Closing the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Shutting Down the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4 Source Integrity Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 71
Source Integrity Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . 72
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Printing Lists and Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Quick Access Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configuring the Source Integrity Column Set . . . . . . . . . . . . . . 76
Configuring the Source Integrity Toolbars . . . . . . . . . . . . . . . . 78
Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Source Integrity Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Viewing Available CLI Commands . . . . . . . . . . . . . . . . . . . . . . . 93
Using the Graphical User Interface From the CLI . . . . . . . . . . . 93
Command Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Member Name Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
MKS Visual Difference Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
MKS Visual Merge Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Application Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5 Project and Sandbox Operations . . . . . . . . . . . . . . . . . . 109
Working With Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Creating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Importing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Dropping a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Opening or Viewing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
u s e r g u i d e

Table of Contents
Working With Subprojects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Creating a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Adding a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Creating a Shared Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Configuring a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Dropping a Subproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Working With Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Creating a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Importing a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Dropping a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Opening or Viewing a Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . 138
Viewing Which Sandbox Locked a Member . . . . . . . . . . . . . . 139
Creating Variant Sandboxes and Development Paths . . . . . . 139
Removing a Development Path . . . . . . . . . . . . . . . . . . . . . . . . . 143
Using Build Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6 Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Managing Project Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Adding Members to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Importing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Dropping Members From a Project . . . . . . . . . . . . . . . . . . . . . . 158
Performing Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Selecting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Checking Out a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Viewing and Editing a Member . . . . . . . . . . . . . . . . . . . . . . . . . 170
Checking In a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Renaming a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Discarding Changes to a Member . . . . . . . . . . . . . . . . . . . . . . . 183
Resyncing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Locking a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Unlocking a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Deferring Member Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Submitting Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . 190
Cancelling Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . 191
Resyncing Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . 191
Comparing Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Using Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Locating Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Table of Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
7 Using Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . 199
What Are Change Packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Why Use Change Packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Using Change Packages to Control Development . . . . . . . . . . . . . . 202
Creating a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
iii

Table of Contents
iv
Adding Entries to a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . 205
Managing Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Finding Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Viewing Change Package Details and Entries . . . . . . . . . . . . . 211
Editing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Closing a Change Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Submitting Change Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Viewing Change Package Entry Member Differences . . . . . . . . . . 222
8 Viewing and Editing Projects, Sandboxes,
and Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Controlling Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Viewing and Editing Project Information . . . . . . . . . . . . . . . . . 226
Viewing a Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Opening a Build Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Adding Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Deleting Project Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Promoting a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Demoting a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Checkpointing a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Restoring a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Viewing Project Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Comparing Project Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Controlling Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Viewing General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Viewing Project Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Taking Sandbox Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Controlling Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Viewing and Editing Member Information . . . . . . . . . . . . . . . 257
Updating a Member’s Revision . . . . . . . . . . . . . . . . . . . . . . . . . 263
Adding Labels to Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Deleting Member Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Promoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Demoting Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Freezing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Thawing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
About the Report Information . . . . . . . . . . . . . . . . . . . . . . . . . . 273
About Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Creating a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
u s e r g u i d e

Table of Contents
9 Viewing and Editing Member Histories and Revisions . 279
Viewing a Member History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Viewing and Editing Archive Information . . . . . . . . . . . . . . . . . . . . 282
Viewing and Editing Revision Information . . . . . . . . . . . . . . . . . . . 284
Viewing an Annotated Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Viewing and Editing Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . 288
Adding Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Deleting Revision Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Viewing a Member’s Working File or Revision . . . . . . . . . . . . . . . . 291
Promoting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Demoting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Locking Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Unlocking Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Locking Multiple Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Managing Revision Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Setting the Member Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Deleting Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Comparing Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
10 Branching and Merging Revisions . . . . . . . . . . . . . . . . . 305
Branching Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Making Locked Members Writable . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Merging Branched Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Merging on Check In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Merging Revisions by Dragging . . . . . . . . . . . . . . . . . . . . . . . . . 316
Automatic Merging on Check Out . . . . . . . . . . . . . . . . . . . . . . . 319
Automatic Merging on Resync . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Merging Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Merging Revisions Automatically . . . . . . . . . . . . . . . . . . . . . . . 322
Working With MKS Visual Difference . . . . . . . . . . . . . . . . . . . 324
Working With MKS Visual Merge . . . . . . . . . . . . . . . . . . . . . . . 330
Merging in the Command Line Interface . . . . . . . . . . . . . . . . . 335
Resolving Merges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
11 The Integrity Manager Integration . . . . . . . . . . . . . . . . . . 339
Integrating With Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 340
How the Integration Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Creating a Change Package for an Issue . . . . . . . . . . . . . . . . . . . . . . 343
Adding Entries to an Issue’s Change Package . . . . . . . . . . . . . . . . . 345
Viewing a Change Package’s Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Finding Change Packages Using a Query . . . . . . . . . . . . . . . . . . . . . 347
v

Table of Contents
vi
12 Advanced Change Package Operations. . . . . . . . . . . . . 349
Change Package Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Change Package Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Change Package Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Resolving Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Using the Apply CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Key Apply CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
How Apply CP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Apply CP Backfill List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Apply CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Using the Resync CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Key Resync CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
How Resync CP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Resync CP Backfill List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Working on a Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Resync CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Working With a Resolution CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Key Resolution CP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
How Resolution CPs Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Using a Resolution CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Resolution CP Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Using the Resync By CP Command . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Appendixes A Views, Windows, and Dialog Boxes . . . . . . . . . . . . . . . . 409
Project and Sandbox Windows (GUI) . . . . . . . . . . . . . . . . . . . . 410
Project Window (Web) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Project History Window (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Project History Window (Web) . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Member History Window (GUI) . . . . . . . . . . . . . . . . . . . . . . . . 416
Member History Window (Web) . . . . . . . . . . . . . . . . . . . . . . . . 419
Graphical History View (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Change Package View (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Change Package View (Web) . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Change Packages View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Annotated Revision View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Locks View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Registered Projects and Sandboxes Dialog Boxes (GUI) . . . . . 429
Registered Projects Window (Web) . . . . . . . . . . . . . . . . . . . . . . 430
B Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
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: “Source Integrity Interfaces” on page 71
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 4: “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 5: “Project and Sandbox Operations” on page 109
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: “Viewing and Editing Projects, Sandboxes, and
Members” on page 225
Describes how to manage projects, sandboxes, and members, for
example, viewing and editing project information, adding labels to
projects, and freezing members.
Chapter 7: “Viewing and Editing Member Histories and Revisions”
on page 279
Describes how to manage member histories and revisions, for
example, viewing and editing revision information, deleting revisions,
and promoting revisions.
u s e r g u i d e

Related Documentation
Related Documentation
Chapter 8: “Branching and Merging Revisions” on page 305
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 9: “The Integrity Manager Integration” on page 339
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 10: “Advanced Change Package Operations” on page 349
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, Windows, and Dialog Boxes” on page 409
Describes the views that are available in Source Integrity.
Appendix B: “Glossary of Terms” on page 433
Provides a glossary of common terms and definitions for
Source Integrity.
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
Administration CLI
Reference Guide
Integrity Server Installation
and Administration Guide
Source Integrity Enterprise
Edition CLI Reference
Guide
Source Integrity Enterprise
Edition User Guide
No Yes Yes Yes
Yes Yes AA, IM a
No
No Yes Yes Yes
No Yes Yes No
3

Chapter 1: Welcome to Source Integrity Enterprise Edition
4
Documentation Print PDF Online Man
Source Integrity Enterprise
Edition IDE Integrations
Guide
Integrity Manager CLI
Reference Guide
Integrity Manager User
Guide
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
have installed the reader, whenever you open a PDF file the reader starts
automatically.
NOTE
No Yes Yes No
No Yes Yes Yes
No Yes Yes No
Using MKS Make No Yes No No
Release Notes No No Yes No
a
For Authorization Administration graphical user interface and Integrity Manager
only.
To print PDFs, Adobe Acrobat Reader 4.0 or greater is required. Adobe
Acrobat Reader is provided on the product CD (located in the
\support\acrobat subdirectory).
In addition to the Source Integrity Enterprise Edition User Guide, the other
documentation included in this release is as follows:
Integrity Server Administration CLI Reference Guide provides details on
the command line utilities used for administration tasks.
Integrity Server Installation and Administration Guide gives you the
information you need to build a basic understanding of the Integrity
Solution, and to install and configure the solution in your
organization. It also provides information on post-installation tasks:
configuring and administering the Integrity Server at your site, and
how to configure and set up Integrity Manager and Source Integrity
Enterprise Edition.
Source Integrity Enterprise Edition CLI Reference Guide gives details on
the command line utilities included with Source Integrity.
u s e r g u i d e

Typographical Conventions
Typographical Conventions
Source Integrity Enterprise Edition IDE Integrations Guide describes how
to access the functionality of Source Integrity while working within
your favorite integrated development environment (IDE), such as IBM
WebSphere Studio, Microsoft Visual Studio .NET, and Borland
JBuilder.
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.
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 re-compiles 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 as HTML
documents in a Web browser.
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:
5

Chapter 1: Welcome to Source Integrity Enterprise Edition
6
Items in documentation Appear as
Environment variables TMPDIR
Path names c:\srcint\work
New terms appear in italics the first time
Keyboard keys appear in caps, for example: ENTER;
CTRL; ALT, F, S
Procedures for the graphical user
interface, command line interface, and
Web interface
NOTE
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.
u s e r g u i d e

What’s New in This Release
Assumptions
What’s New in This Release
For more detailed information on the following features, see the
SourceIntegrityWhatsNews.pdf located in the \documentation\pdf
subdirectory of the distribution CD.
improved administration
SIEE Native Change Packages
improved distribution of client-side patches
improved authentication support
print support for SIEE GUI Views
annotated view of file history
improved usability of SIEE GUI
client side event triggers
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)
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)
7

Chapter 1: Welcome to Source Integrity Enterprise Edition
Getting Help
8
MKS Global Customer Care is ready to assist you with product solutions.
You can choose the online system or telephone a MKS Technical Support
Representative.
NOTE
If contacting Global Customer Care, you will require your product serial
number. The serial number appears on the product box and on the CD sleeve.
You can also get the product serial number from your site administrator.
For online support, browse to www.mks.com/support. There you will find
Frequently Asked Questions (FAQs), information about current releases,
solution downloads, and Knowledge Base articles that can help you find
the answers you need quickly.
In addition, you can browse to www.mks.com/support/productinfo/sie
to view and download white papers that cover best practices and more indepth
applications of Source Integrity.
Online Web www.mks.com/support
E-mail support@mks.com
Telephone Toll Free North America 800 219 4842
Outside North America 800 2194 8424
Direct North America 519 884 2270
UK +44 (0) 1483 733910
Germany +49 711 351 775 51
Fax North America 630 495 4855
UK +44 (0) 1483 733901
Germany +49 711 351 775 11
The hours of operation for Global Customer Care are as follows:
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)
u s e r g u i d e

Professional Services
Professional Services
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
For more information on MKS professional services:
Online Web Global www.mks.com/services
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
9

Chapter 1: Welcome to Source Integrity Enterprise Edition
Your Feedback Is Welcome
10
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
Where To Go From Here
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).
To Do This … See …
Install the Integrity Client. “Installing the Integrity Client” on
page 24
Log in to Source Integrity. “Logging Into Source Integrity” on
page 36
Set Source Integrity preferences. “Setting Preferences” on page 40
Create a project. “Creating a Project” on page 110
Create a sandbox. “Creating a Sandbox” on page 131
Add members to a Source Integrity
project.
u s e r g u i d e
“Adding Members to a Project” on
page 146
Check out a member. “Checking Out a Member” on
page 163
Check in a member. “Checking In a Member” on page 172

To Do This … See …
Where To Go From Here
Create a change package “Creating a Change Package” on
page 203
View a project history. “Viewing a Project History” on
page 231
View a member history. “Viewing a Member History” on
page 280
Use Integrity Manager with
Source Integrity.
“Integrating With Integrity Manager” on
page 340
Learn Source Integrity terms. “Glossary of Terms” on page 433
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 Windows, 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.
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
Integrated Development Environment
Support
22
Source Integrity supports the following IDEs:
IDE Versions
Borland Delphi 6.0 and 7.0
Borland JBuilder 6.0 Enterprise, 7.0 Enterprise, and 8.0
Enterprise
Eclipse (open source) 1.0.0, 2.0.2
IBM VisualAge for Java Enterprise Editions 3.5.3 and 4.0
IBM WebSphere Studio Classic Advanced Edition 4.0
IBM WebSphere Studio Application
Developer
(utilizing the IBM WebSphere Studio
Workbench technology, based upon
the Eclipse open source initiative)
IBM WebSphere Studio Site
Developer
(utilizing the IBM WebSphere Studio
Workbench technology, based upon
the Eclipse open source initiative)
4.0.x, 5.0
4.0.x
Mercury Interactive TestDirector 7.6
Microsoft eMbedded Visual C++ 3.0
Microsoft Visual Basic 6.0
Microsoft Visual C++ 6.0
Microsoft Visual J++ 6.0
Microsoft Visual Studio .NET
Microsoft Windows Explorer Windows 98 Second Edition, ME,
2000 Server SP2+, 2000 Professional
SP2+, NT 4.0 SP6.a, XP Professional
Rational Rose Enterprise Edition 2000e
Starbase CodeWright 7.0c
Sybase PowerBuilder 7.0, 8.0.3
TogetherSoft Together ControlCenter 6.0
Source Integrity documents the changes made to your files, and also tracks
who made them, when they were made, and the reasons why.
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 Into Source Integrity” on page 36
“Connecting to Multiple Servers” on page 39
“Setting Preferences” on page 40
“Managing Integrations” on page 67
“Quitting a Source Integrity Session” on page 69
23

Chapter 3: Getting Started Using Source Integrity
Installing the Integrity Client
Browser
Support
24
IMPORTANT
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.
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.0.
To install the integrity client from the CD
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:
View Release Notes allows you to view the release notes for the
Integrity Client components.
Install Integrity Client allows you to install Integrity Manager,
Source Integrity, or both.
View Documentation launches your default Web browser and
allows you to view the user documentation in Adobe Acrobat
format.
About ... links display descriptions of the MKS Integrity Solution
and other MKS products.
2 To start the installation process, do one of the following:
From the Integrity Client CD browser, select Install Integrity
Client.
A page appears allowing you to start the installation program for
your particular platform.
For Windows, click the link.
u s e r g u i d e

NOTE
For UNIX, follow the written instructions.
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 appears 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
25

Chapter 3: Getting Started Using Source Integrity
26
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.
TIP
The installation program allows you to return to a previous panel without
having to exit the program. To return to the last panel, click Previous.
If you accept the license agreement, the Select Integrity Client
Components panel appears.
5 Depending on the product components you are licensed to use, select
Integrity Manager, Source Integrity, Administration Client, or a
combination of your choice.
6 To continue, click Next.
The Integrity Client Installation Location panel appears.
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.
u s e r g u i d e

Installing the Integrity Client
8 In step 5, if you chose to install more than one product, the Specify
Server Connection Default panel appears. 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 appears, 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.
The Specify Integrity Server Connections panel appears.
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 appears.
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 appears 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 appears 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 appears 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 appears.
10 To continue, click Next.
The System Environment Changed panel appears, 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 appears. The uninstall program
removes all installed components, except any files or folders created
after the installation.
29

Chapter 3: Getting Started Using Source Integrity
30
2 To run the uninstall program, click Uninstall.
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 appears. 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.
u s e r g u i d e

Understanding
Access Control
Lists
Before You Start the Integrity Client
Depending on your permissions, you can view the permissions assigned
for both projects and project members, but only your administrator can
modify the permissions.
To view project permissions in the graphical user interface
Do one of the following:
From a Project window, select Project > Properties > Project
Permissions.
From a Sandbox window, 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 window, 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 69.
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
31

Chapter 3: Getting Started Using Source Integrity
32
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.
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 a Source Integrity window, do one of the following:
Select Tools > Manage Projects.
Select Tools > Manage Sandboxes.
A list of the registered projects or sandboxes appears in the Registered
Projects or Registered Sandboxes dialog box.
2 Choose the project or sandbox you want to view ACLs for.
TIP
The Registered Projects dialog box 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.
u s e r g u i d e

3 Click Permissions.
Before You Start the Integrity Client
The ACL dialog box opens and displays the ACLs for the selected
project or sandbox.
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. 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 69.
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 appears.
35

Chapter 3: Getting Started Using Source Integrity
36
4 Type your user ID and password, and press ENTER.
Logging Into Source Integrity
The Source Integrity Web interface opens in a new browser window.
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.
u s e r g u i d e

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 appears.
Logging Into Source Integrity
NOTE
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, 1.2.34.56.
3 In the Port Number field, type the port number, for example, 7001.
4 To accept the server information, click OK.
The Enter Credentials dialog box appears.
5 In the User Name field, type your user name, for example, mkern.
Your user name appears by default in the User Name field.
6 In the Password field, type your password, for example, sesame.
37

Chapter 3: Getting Started Using Source Integrity
38
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.
IMPORTANT
In the Server Connection menu, the active connection appears 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, such as Netscape Navigator or Microsoft
Internet Explorer.
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 appears in the form:
http://server_name:port_#/
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
u s e r g u i d e

The MKS Integrity Server home page appears.
3 Click Start Source Integrity Enterprise Web Interface.
Connecting to Multiple Servers
A browser password dialog box appears, prompting you for your
Source Integrity user name and password.
4 In the User Name field, enter your user name, for example, mkern.
5 In the Password field, enter your password, for example, docsteam.
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.
7 To accept the log in information, click OK.
Source Integrity validates your login information, then the
Source Integrity Web interface appears.
Connecting to Multiple Servers
When you point to the Source Integrity icon ( ) a ToolTip appears
showing your user name, server, and port number for the session. This
information also appears in the status bar at the bottom of the browser
window, for example, mkern@dev_nt:7001.
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 Into 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
39

Chapter 3: Getting Started Using Source Integrity
Setting Preferences
40
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 138.
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.
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 appears 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.
Preferences allow you to customize your Source Integrity client session.
You can configure general preferences, connection preferences,
commands, views, and select the program you want to use to view
differences.
u s e r g u i d e

General
Preferences
Setting Preferences
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 Into 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.
Under the General tab, you can set your preferences for the following:
look and feel of the graphical user interface
preferred editor for your files
time delay for pop-up windows
option to restore active windows when you restart Source Integrity
To set general preferences in the graphical user interface
1 Do one of the following:
Select Tools > Preferences.
Click .
The Preferences dialog box appears.
41

Chapter 3: Getting Started Using Source Integrity
42
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 70.
3 To select an editor for editing files, click an option under Editor. The
available options are:
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.
u s e r g u i d e

Connection
Preferences
Setting Preferences
4 To set the time in milliseconds (ms) before a command’s status
appears 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 appears
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.
5 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.
The Restore Desktop option remembers which Sandbox, Project,
Project History, and Member History 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.
The Connection tab in the Preferences dialog box contains default settings
for server and proxy connections. You can also override the default
settings when connecting to the Integrity Server.
The Connection panel includes two tabs, General and Proxy. The General
tab contains settings for the default server, while the Proxy tab contains
advanced settings for improved performance through the use of a proxy.
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.
43

Chapter 3: Getting Started Using Source Integrity
44
For a detailed discussion about using a proxy, see “Implementing
Federated Server Architecture” in the Integrity Server Installation and
Administration Guide.
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.
To set connection preferences in the graphical user interface
1 From the Preferences dialog box, click the Connection tab.
The Connection panel appears with two tabs, General and Proxy.
2 On the General panel 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, for example, 9001.
u s e r g u i d e

Setting Preferences
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:
NOTE
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.
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.
Optionally, under SOCKS, you can specify a network proxy you
want to connect to. In the Host Name field type the name of the
server, for example, sockshost, or the numerical IP address, for
example, 1.2.34.67. In the Port field, type the port number, for
example, 7761.
3 Do one of the following:
Click OK to save your connection preferences without specifying
any advanced proxy server settings. Your connection preferences
are saved.
Click the Proxy tab to specify advanced proxy server settings. The
Proxy panel appears.
CAUTION
Do not change proxy settings when the client is connected to the
Integrity Server.
45

Chapter 3: Getting Started Using Source Integrity
46
4 On the Proxy panel 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 successfully connect to a proxy.
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,
Source Integrity prompts you for your user name and password
again.
For information about the authentication schemes used, contact
your administrator.
u s e r g u i d e

Setting Preferences
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 the Add button. The Add new server connection dialog
box appears.
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.
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 panel. 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
panel. The server appears 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.
47

Chapter 3: Getting Started Using Source Integrity
Command
Preferences
48
TIP
To edit a previously configured server, select it from the Server list and click
Edit. The Edit server connection dialog box appears. 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.
The Commands tab 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 dialog box, click the Commands tab.
The Commands panel appears.
u s e r g u i d e

Command Options
Setting Preferences
2 From the Command list, 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 are local settings configured by you.
3 If necessary, select a command’s option check box.
4 To restore a command’s default options, click Clear Local Settings.
Modify options for commands as listed in the following table:
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.
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.
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.
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.
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.
52
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.
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 has been 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 313
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.
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.
Create Sandboxes Populate Sandbox causes Source Integrity to add working files to the sandbox.
Recurse Into Subprojects creates subsandboxes recursively from subprojects.
Make Sandbox Sparse creates a sandbox with no working files.
View Sandbox After Creation displays the sandbox after it is created.
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.
53

Chapter 3: Getting Started Using Source Integrity
Command Options
54
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.
Disconnect From Server Confirm Disconnect causes Source Integrity to confirm you will be disconnected from
the Integrity Server.
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.
Import Members Author allows you to specify the author of the member.
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.
Unexpand Keywords replaces literal values in the revision with keywords.
u s e r g u i d e

Command Options
Setting Preferences
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 has been 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 313
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.
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 322.
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 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.
Promote Recurse Into Subprojects promotes all members in subprojects.
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 window.
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.
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.
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.
Recurse into Subprojects recursively resynchronizes members in subprojects.
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.
u s e r g u i d e

Command Options
Setting Preferences
Resynchronize 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 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 313
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.
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.
57

Chapter 3: Getting Started Using Source Integrity
Command Options
Resynchronize Change
Package continued
58
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.
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.
u s e r g u i d e

Command Options
View
Preferences
Setting Preferences
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.
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 causes Source Integrity to confirm 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.
Submit Change Package Close Change Package causes Source Integrity to close the change package after
submitting the item and completing the associated deferred operation.
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.
The Views tab in the Preferences 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 dialog box. For
more information on configuring toolbars, see “Configuring the Source
Integrity Toolbars” on page 78.
59

Chapter 3: Getting Started Using Source Integrity
60
View Options
To set view preferences in the graphical user interface
1 From the Preferences dialog box, click the Views tab.
The Views panel appears.
2 From the View list, select a view to configure. The available views and
their options are discussed in detail in the proceeding table.
3 If necessary, select a view’s option check box.
4 To restore a view’s default options, click Clear Local Settings.
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.
u s e r g u i d e

View Options
Setting Preferences
Change Package View Show Committed displays entries that contain changes that have been
committed to the repository.
Show Uncommitted displays deferred entries that have not been submitted and
therefore committed to the repository. Also displays lock entries if TrackLocks is
enabled.
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. The possible types are Add,
Drop, Lock, Rename, Update, Deferred Add, Deferred Check In,
Deferred Rename.
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.
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.
61

Chapter 3: Getting Started Using Source Integrity
View Options
62
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.
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.
u s e r g u i d e

View Options
Setting Preferences
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.
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 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. 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.
C.P. ID displays the member’s associated change package ID.
Lock Timestamp displays the date and time a member 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. Timestamp displays the date and time the member revision is set.
63

Chapter 3: Getting Started Using Source Integrity
View Options
64
Project View continued 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 Host displays the host name of the computer that locked the member.
Member Rev. displays the member’s revision number.
Name displays the project, subproject, and the project members by file name.
Type displays the type of each project, and project member.
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.
Project Modifications View Member Attribute Changes displays all modifications of member attributes
between two project revisions.
Show Revision Description displays the content of the revision description.
Show Applied Change Packages displays all the change packages applied
between two project revisions.
Show Revision Changes displays all modifications to each revision.
Recurse into Subprojects displays the hierarchy of subprojects.
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).
u s e r g u i d e

View Options
Setting Preferences
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 Host displays the host name of the computer that locked the member.
Member Rev. displays the member’s revision number.
Name displays the sandbox, subsandbox, and the sandbox members by file
name.
State displays the state of the member revision.
Working Rev. displays the checked out revision number that corresponds to the
member’s working file.
C.P. ID displays the member’s associated change package ID.
Labels displays member labels.
Locker displays who has a member locked.
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. 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.
Type displays the type of each sandbox, and sandbox member.
Deferred displays a icon to indicate that an operation on a member has
been deferred.
Lock Timestamp displays the date and time a member 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. Timestamp displays the date and time the member revision is set.
Revision Sync Delta displays a delta icon to indicate that your working revision
does not match the member revision (usually due to branching).
Working File Delta displays a delta icon to indicate that your working file has
changed.
Sandbox Information View Show Project Attributes displays project attributes.
65

Chapter 3: Getting Started Using Source Integrity
Difference Tool
Preferences
66
The Diff Tool tab in the Preferences dialog box contains default settings for
a Visual Difference Tool. The Visual Difference Tool is a graphical
application that allows you to compare two or more revisions side-by-side
with differences between the revisions highlighted for you. You can choose
to use MKS Visual Difference, a third party tool, or a specific application.
To set difference tool preferences in the graphical user interface
1 From the Preferences dialog box, click the Diff Tool tab.
The Diff Tool panel appears.
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 95.
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
u s e r g u i d e

Managing Integrations
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.
To save preferences in the graphical user interface
In the Preferences dialog box, click OK.
The preferences are saved.
Managing Integrations
Source Integrity includes functionality for enabling and disabling
supported IDE integrations. Using the Integrations command, you can
select from a list of available IDE integrations and enable or disable them
as required to work with your preferred IDE. There is no requirement to
re-install the Integrity Client.
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.
NOTE
Using the Enable/Disable Integrations dialog box or the command:
si integrations --action=enable
you can always restore an available IDE integration at a later date.
You can have only one of the following versions of Sybase PowerBuilder
installed: 7.0, or 8.0.3.
For complete information on using third party integrations with
Source Integrity, see the Source Integrity Enterprise Edition IDE Integrations
Guide.
To enable IDE integrations for the Integrity Client using the graphical
user interface
1 Start the Integrity Client.
67

Chapter 3: Getting Started Using Source Integrity
68
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 IDE 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 IDE 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 >
Manage Integrations.
The Enable/Disable Integrations dialog box opens.
3 In the Enabled Integrations list, select the Source Integrity IDE
integration(s) that you want to disable.
TIP
You can select multiple integrations by using CTRL + click.
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.
u s e r g u i d e

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
Quitting a Source Integrity Session
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 appears 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
windows.
The server connection is disconnected.
To log in again, see “Logging Into Source Integrity” on page 36.
69

Chapter 3: Getting Started Using Source Integrity
Closing the
Client
Shutting Down
the Client
70
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).
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
Select File > Shutdown.
The Source Integrity graphical user interface closes, the connection to the
server is disconnected, then the Source Integrity client shuts down.
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.
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 72
“Source Integrity Web Interface” on page 88
“Command Line Interface” on page 92
“MKS Visual Difference Interface” on page 95
“MKS Visual Merge Interface” on page 101
71

Chapter 4: Source Integrity Interfaces
Source Integrity Graphical User Interface
Application
Window
72
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 windows.
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).
u s e r g u i d e

Source Integrity Graphical User Interface
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.
Toolbar
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 78.
Most toolbar buttons only become available when an item is selected in a
certain window. For example, selecting a project in a Project window
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 Window
Project and Sandbox windows display the project members and hierarchy
for projects registered with the Integrity Server.
The Project window gives you access to project-level functions and a
limited number of member-level functions. The Sandbox window 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 windows, see “Project and
Sandbox Windows (GUI)” on page 410.
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 window
a revision in a Project or Member History window
73

Chapter 4: Source Integrity Interfaces
74
a project in the Registered Projects dialog box
a sandbox in the Registered Sandboxes dialog box
Source Integrity displays the applicable shortcut menu.
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 window 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 window
is active.
For more information on filters, see “Using Filters” on page 83.
u s e r g u i d e

Printing Lists
and Views
Source Integrity Graphical User Interface
You can print the information from 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.
2 With the desired information displayed in the window, do one of the
following:
Select File > Print.
Click .
The Print dialog box appears.
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.
75

Chapter 4: Source Integrity Interfaces
Quick Access
Keys
Configuring the
Source Integrity
Column Set
76
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 window.
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 window:
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 appears 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.
u s e r g u i d e

To sort a column in the graphical user interface
Do one of the following:
Click the column heading.
Source Integrity Graphical User Interface
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
window.
To add a column in the 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 appears in the window.
Right click a column heading and select Columns.
The Columns dialog appears 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 appears 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 appears 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.
77

Chapter 4: Source Integrity Interfaces
Configuring the
Source Integrity
Toolbars
78
To change the column order in the graphical user interface
1 Right click a column heading and select Columns.
The Columns dialog appears
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.
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 82.
u s e r g u i d e

Source Integrity Graphical User Interface
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 .
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.
79

Chapter 4: Source Integrity Interfaces
80
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.
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 79.
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.
u s e r g u i d e

Enter the following information into the text fields:
Source Integrity Graphical User Interface
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.
To select the icon file, do one of the following:
Enter the path to the icon file.
Click Browse to select the icon file.
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 86.
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 79.
81

Chapter 4: Source Integrity Interfaces
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 80.
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 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 79.
u s e r g u i d e

Using Filters
Source Integrity Graphical User 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.
NOTE
The list of built-in filters only displays if a Project or Sandbox window 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 windows, filters
appear in the Filter list located on the toolbar.
Filters for the Project History and Member History windows are also
available. For information on applying filters in the Project History
window, see “Project History Filters” on page 232. For information on
applying filters in the Member History window, see “Member History
Filters” on page 281.
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.
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
has been modified.
Out of Sync Members shows only members where the sandbox
revision is not the same as the member revision in the corresponding
project.
83

Chapter 4: Source Integrity Interfaces
84
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.
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 259.
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.
u s e r g u i d e

Source Integrity Graphical User Interface
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 268.
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.
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.
85

Chapter 4: Source Integrity Interfaces
Environment
Variables
86
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.
87

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_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
88
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 window 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.
89

Chapter 4: Source Integrity Interfaces
90
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).
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 window
displays project command toolbar buttons.
Project Window
The Source Integrity Web interface provides access to the Project window.
The Project window displays the project members and hierarchy for
projects registered with the Integrity Server.
The Project window 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.
u s e r g u i d e

Using Filters
Filter List
Source Integrity Web Interface
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.
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 259.
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 268.
Under Specify a State, enter the state name in the field, then click OK.
91

Chapter 4: Source Integrity Interfaces
Command Line Interface
92
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.
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.
u s e r g u i d e

Viewing
Available CLI
Commands
Using the
Graphical User
Interface From
the CLI
Command
Prompts
Member Name
Arguments
Command Line Interface
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.
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.
93

Chapter 4: Source Integrity Interfaces
94
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.
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.
u s e r g u i d e

MKS Visual Difference Interface
Application
Window
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.
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.
95

Chapter 4: Source Integrity Interfaces
96
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).
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 98.
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.
u s e r g u i d e

NOTE
Under the View menu, the following controls are also available:
MKS Visual Difference Interface
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 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.
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 324.
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.
97

Chapter 4: Source Integrity Interfaces
Modes
98
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 98
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 appears. This dialog box allows you to
specify which revision you want as the Merge From and Merge To.
A bullet appears 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 appears.
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 79.
NOTE
The toolbar buttons available for configuration varies depending on which
mode you are working in.
99

Chapter 4: Source Integrity Interfaces
100
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 appears.
2 Click the Fonts & Colors tab.
The Fonts & Colors panel appears.
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 appears.
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 appears.
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 appears.
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.
101

Chapter 4: Source Integrity Interfaces
Application
Window
102
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 appears.
Ignore Whitespace ignores tab and white space throughout the lines in
the revisions.
Ignore Case ignores the type case when comparing the revisions.
103

Chapter 4: Source Integrity Interfaces
104
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.
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.
Scrolling in the view panes is synchronized.
u s e r g u i d e

Preferences
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 appears.
105

Chapter 4: Source Integrity Interfaces
106
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 79.
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 appears.
2 Click the Fonts & Colors tab.
The Fonts & Colors panel appears.
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 appears.
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 appears 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 appears.
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.
107

Chapter 4: Source Integrity Interfaces
108
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 appears.
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 110
“Working With Subprojects” on page 118
“Working With Sandboxes” on page 130
109

Chapter 5: Project and Sandbox Operations
Working With Projects
Creating a
Project
110
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
opening or viewing a project
creating a subproject
creating shared subprojects
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 dialog box. With the
Registered Projects dialog box open, click Create (or select Create from the
shortcut menu), and the Specify Project to Create dialog box appears.
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 window.
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 .
u s e r g u i d e

The Specify the Project to Create dialog box appears.
Working With Projects
2 Select a location, where you want to create the project, from the Look
in list.
This step is applicable only when your administrator has specified
multiple server roots. 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.
111

Chapter 5: Project and Sandbox Operations
Importing a
Project
112
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 window.
You can now create a sandbox, then add members to the sandbox. For
more information, see “Working With Sandboxes” on page 130.
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.
Importing a project registers it with the Integrity Server. Once a project is
imported, Source Integrity commands can be performed upon it.
To import a project in the graphical user interface
1 Do one of the following:
Select Tools > Manage Projects.
Click .
The Registered Projects dialog box appears.
u s e r g u i d e

TIP
Working With Projects
The Registered Projects dialog box 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 appears.
3 Browse to the project file on the server.
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.
IMPORTANT
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 dialog box.
113

Chapter 5: Project and Sandbox Operations
Dropping a
Project
114
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, the project is not deleted and you can import it
again if you want it to be accessible in Source Integrity.
To drop a project in the graphical user interface
1 Do one of the following:
Select Tools > Manage Projects.
Click .
The Registered Projects dialog box appears.
TIP
The Registered Projects dialog box 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 Select the project you want to drop.
3 Click Drop.
The Confirm Project Drop dialog appears.
u s e r g u i d e

Opening or
Viewing a
Project
4 To drop the selected project click Yes.
The project is removed from the list of registered projects.
5 Close the Registered Projects dialog box.
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 window 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.
115

Chapter 5: Project and Sandbox Operations
116
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 141.
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 dialog box. With the
Registered Projects dialog box open, select the project you want to open and
click Open, or select Open from the shortcut menu. The project appears in a
Project window.
5 To accept the options, click Finish. To modify the options, click Back.
The project opens in a Project window.
To open a project in the Web interface
1 Select File > Open Project.
The Select Project dialog box appears.
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 window 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.
117

Chapter 5: Project and Sandbox Operations
Working With Subprojects
Creating a
Subproject
118
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.
You can also use the Subproject > Create command to re-add a subproject
that was dropped for the purposes of scripts and backwards compatibility
with previous versions of Source Integrity.
To create a subproject in the graphical user interface
1 With a Project or Sandbox window open, select the project or sandbox
to add the subproject to.
2 From a Project window, select Project > Subproject > Create.
From a Sandbox window, select Sandbox > Subproject > Create.
The Specify the Subproject to Create on localhost:portnumber dialog
box appears.
u s e r g u i d e

Adding a
Subproject
Working With Subprojects
3 Select the subproject to create, or enter the name for the subproject, for
example, applications.pj.
4 Click OK.
The subproject appears in a Project or Sandbox window.
You can now add members to the subproject as you would with a project.
When a subproject has been 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 window open, select the project or sandbox
you want to add the subproject to.
2 From a Project window, select Project > Subproject > Add.
From a Sandbox window, select Project > Subproject > Add.
The Add Subproject Wizard appears.
119

Chapter 5: Project and Sandbox Operations
120
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.
u s e r g u i d e

Working With Subprojects
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 141.
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 window.
121

Chapter 5: Project and Sandbox Operations
Creating a
Shared
Subproject
122
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.
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.
u s e r g u i d e

Working With Subprojects
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 create a shared subproject in the graphical user interface
1 With a Project or Sandbox window open, select the project or sandbox
you want to add the shared subproject to.
2 From a Project window, select Project > Subproject > Add Shared.
From a Sandbox window, select Sandbox > Subproject > Add Shared.
The Add Shared Subproject Wizard appears.
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.
123

Chapter 5: Project and Sandbox Operations
124
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.
u s e r g u i d e

Working With Subprojects
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 141.
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, for example, 1.1.
Select Label, and from the list select a project label.
125

Chapter 5: Project and Sandbox Operations
Configuring a
Subproject
126
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 window with
a shared icon (Project window: or Sandbox window: ).
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 window. 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.
u s e r g u i d e

Working With Subprojects
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.
To configure a subproject in the graphical user interface or the Web
interface
1 With a Project or Sandbox window open, select the subproject you
want to configure.
2 In the GUI, from a Project window, select Project > Subproject >
Configure.
In the GUI, from a Sandbox window, select Sandbox > Subproject >
Configure.
In the Web, from a Project window, select Project > Configure
Subproject.
The Configure Subproject dialog box appears.
127

Chapter 5: Project and Sandbox Operations
128
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 141.
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, for example, 1.1.
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 window: or Sandbox window: ), 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 window: or Sandbox window: ), and the
u s e r g u i d e

Dropping a
Subproject
Working With Subprojects
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 window or through a Sandbox window. For
more details on removing a subproject through a Sandbox window, see
“Dropping Members From a Project” on page 158.
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.
To drop a subproject in the graphical user interface
1 With the Manage Projects dialog box, or a Project or Sandbox window
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 window, select Project > Drop Members.
From the Sandbox window, select Sandbox > Drop Members.
The Drop Subproject dialog box appears.
129

Chapter 5: Project and Sandbox Operations
130
3 Under Options, select Confirm Drop to have Source Integrity prompt
you to confirm the operation.
The Confirm Drop message appears.
Working With Sandboxes
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).
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.
u s e r g u i d e

Creating a
Sandbox
Working With Sandboxes
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 window open, the project path and name appears
in the Project Name field. If you click Select, the Select One or More
Projects dialog box appears.
131

Chapter 5: Project and Sandbox Operations
132
3 Select a project.
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.
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 184).
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.
u s e r g u i d e

Working With Sandboxes
View Sandbox After Creation displays the sandbox after it is
created.
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.
7 Click Next.
If the directory you specify does not exist, a Confirm Create Sandbox
Location dialog box appears 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.
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 139.
133

Chapter 5: Project and Sandbox Operations
134
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 141.
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 144.
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 window.
To modify the options, click Back.
You can also create a sandbox from the Registered Sandboxes dialog box.
With the Registered Sandboxes dialog box open, click Create (or select
Create from the shortcut menu). 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.
u s e r g u i d e

Importing a
Sandbox
Working With Sandboxes
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.
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 dialog box appears.
TIP
The Registered Sandboxes dialog box 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 appears.
135

Chapter 5: Project and Sandbox Operations
Dropping a
Sandbox
136
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 Select a Project dialog box appears.
5 Select the corresponding master project from the list of projects.
6 Click OK.
The sandbox is added to the Registered Sandboxes dialog box.
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 dialog box appears.
u s e r g u i d e

TIP
Working With Sandboxes
The Registered Sandboxes dialog box 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 appears.
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 dialog box.
137

Chapter 5: Project and Sandbox Operations
Opening or
Viewing a
Sandbox
138
Opening a sandbox in the graphical user interface allows you to view and
work with the sandbox and its members.
The Sandbox window 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 appears.
2 To select a sandbox type, click a sandbox type tab.
Regular is a sandbox used for regular development.
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 window.
u s e r g u i d e

Viewing Which
Sandbox
Locked a
Member
Creating Variant
Sandboxes and
Development
Paths
Working With Sandboxes
You can also open a sandbox from the Registered Sandboxes dialog box.
With the Registered Sandboxes dialog box open, select the sandbox you
want to open, and click Open, or select Open from the shortcut menu. The
sandbox appears in a sandbox window.
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 59.
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.
139

Chapter 5: Project and Sandbox Operations
140
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.
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
u s e r g u i d e

Working With Sandboxes
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.
To create a development path in the graphical user interface and Web
interface
1 With a Project, Project History, or Sandbox window 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 131. from. For more information on
working with subprojects, see “Working With Subprojects” on
page 118.
NOTE
You cannot create a development path based on a variant subproject or build
subproject.
2 In the GUI, from a Project window, select Project > Development Path
> Create.
141

Chapter 5: Project and Sandbox Operations
142
3 In the Web, from a Project window, select Project > Create
Development Path.
From a Project History window, select History > Create Development
Path.
From a Sandbox window, select Sandbox > Development Path >
Create.
The Create Development Path dialog box appears.
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.
u s e r g u i d e

Removing a
Development
Path
Working With Sandboxes
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 window open, select the
project.
2 In the GUI, from a Project window, select Project > Development Path
> Remove.
In the Web, from a Project window, select Project > Remove
Development Path.
From a Project History window, select History > Remove Development
Path.
From a Sandbox window, select Sandbox > Development Path >
Remove.
The Remove Development Path dialog box appears.
3 From the Development Path list, select a development path to remove.
For more information, see “Controlling Projects” on page 226.
4 To remove the development path, click OK.
The development path is removed.
143

Chapter 5: Project and Sandbox Operations
Using Build
Sandboxes
144
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 131. To view
a build project, see “Opening or Viewing a Project” on page 115.
Within a build sandbox, you can:
change labels and states
resynchronize your sandbox
compare a member revision in the build sandbox to another revision
merge a member revision in the build sandbox with another revision
(of course, you cannot check a merged file back into the build
sandbox)
check for differences between 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.
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 146
“Performing Member Operations” on page 161
“Deferring Member Operations” on page 189
“Comparing Differences” on page 192
“Using Keywords” on page 194
145

Chapter 6: Member Operations
Managing Project Members
Adding
Members to a
Project
146
You can manage project members by adding them to a project, importing
them into Source Integrity, or dropping them from a project.
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 window.
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.
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 155.
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 189.
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.
u s e r g u i d e

To add members in the graphical user interface
Managing Project Members
1 With a Sandbox window open, select the sandbox or subsandbox you
want to add members to.
2 Do one of the following:
Select Sandbox > Add Members.
Click .
The Add Members Wizard appears.
3 To add a list of files to the project, click Add File.
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
appears.
5 Select one or more files from the displayed file list, navigating to the
desired directory if necessary.
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.
147

Chapter 6: Member Operations
148
6 Click Open.
The files are added to the members list. To remove files, select the files,
then click Remove.
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 appears.
10 Modify the following Create Archive options as necessary:
In the Archive Description field, enter a description 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 to it a
description.
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.
NOTE
If specifying a revision number, 0.0 and 0.1 are acceptable revision numbers.
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.
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. The operation in the sandbox still takes
place immediately and Source Integrity displays the icon.
149

Chapter 6: Member Operations
150
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 re-adding a dropped member and the member’s archive still
exists, the Existing archive detected dialog box appears 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.
u s e r g u i d e

Managing Project Members
The newly added members appear in your Sandbox window.
To add members in the Web interface
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 appears.
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 appears.
151

Chapter 6: Member Operations
152
4 Modify the following Create Archive options as necessary:
In the Archive Description field, enter a description of the
member.
IMPORTANT
The à 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.
NOTE
If specifying a revision number, 0.0 and 0.1 are acceptable revision numbers.
u s e r g u i d e

Managing Project Members
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.
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 appears.
153

Chapter 6: Member Operations
154
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 appears 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.
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 window.
u s e r g u i d e

Importing
Members
Managing Project Members
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 “Creating a Shared Subproject” on page 122.
To import a member in the graphical user interface
1 With a Project window open, select Project > Import Members.
The Import Members Wizard appears.
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
appears.
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.
155

Chapter 6: Member Operations
156
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

6 Under Options, you can specify the following information:
Managing Project Members
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 replace literal values in the revision with keywords, select the
Unexpand Keywords option.
To recursively import members that exist in the specified
directory location, select the Recurse into Directories option.
157

Chapter 6: Member Operations
Dropping
Members From
a Project
158
7 To complete the operation, click Finish.
To make changes, click Back.
The members appear in the Project window.
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 window, or through a Project window. For more details on
removing members through a Project window, see “Dropping a
Subproject” on page 129.
In the Web interface, because sandboxes do not exist, you can remove
members through the Project window 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 has been 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.
NOTE
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 window open, select one or more members
to remove from the project or sandbox.
2 From a Project window, do one of the following:
Select Project > Drop Members.
Click .
From a Sandbox window, do one of the following:
Select Sandbox > Drop Members.
Click .
The Drop Member dialog box appears.
u s e r g u i d e

Managing Project Members
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.
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. The operation in the sandbox
still takes place immediately and Source Integrity displays the
icon.
Close Change Package closes any associated change package.
For information on the Integrity Manager integration see, “The
Integrity Manager Integration” on page 339.
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 appears.
The project or sandbox is updated to reflect the removed member, and
the member is removed from the project.
159

Chapter 6: Member Operations
160
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 184.
To drop a member in the Web interface
1 From a Project window, 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 appears.
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.
u s e r g u i d e

Performing Member Operations
4 To drop the selected member, click OK. To drop multiple members,
click OK to All.
Performing Member Operations
Selecting
Members
If you selected the Confirm Drop option in step 3, the Confirm Drop
dialog box appears.
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 appears. For information on the Integrity Manager
integration see, “The Integrity Manager Integration” on page 339.
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 window open, do one of the following:
Select View > Select.
Click .
The Select Members dialog box appears.
161

Chapter 6: Member Operations
162
2 Choose the selection criteria you want to use by selecting a check box.
The available options are:
All Members selects all visible members.
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.
u s e r g u i d e

Checking Out a
Member
Performing Member Operations
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
pending. 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.
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 window.
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.
163

Chapter 6: Member Operations
164
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 appears. 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.
To check out a member in the graphical user interface
1 With a Sandbox or Member History window open, select one or more
members to check out.
2 From the Sandbox window, do one of the following:
Select Member > Check Out.
Click .
From the Member History window, do one of the following:
Select History > Check Out.
Click .
The Check Out dialog box appears.
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 168.
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 305.
165

Chapter 6: Member Operations
166
To check out a member in the Web interface
1 With a Project or Member History window 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 window, do one of the following:
Select Member > Check Out
Click .
From the Member History window, do one of the following:
Select History > Check Out.
Click .
The Check Out dialog box appears.
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 168.
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 appears.
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 has been 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.
167

Chapter 6: Member Operations
168
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 appears. 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 appears. 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 window (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.
u s e r g u i d e

Check Out Dialog Box Tab Revision to Check Out Options
Performing Member Operations
Labels Allows you to select a revision to check out by label. Select a label from the label
list.
Project 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.
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 has been 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.
169

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
170
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 313
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.
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 window. You can also use the Scan for Changes feature to display
changes if the client has been 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 window 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 window 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 window 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
has been 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 window open, select the members you want to scan
for changes.
2 Select View > Scan for Changes.
The sandbox window 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, ).
171

Chapter 6: Member Operations
Checking In a
Member
172
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 305.
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),
u s e r g u i d e

Performing Member Operations
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.
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)
173

Chapter 6: Member Operations
174
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.
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 has been 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 window open, select one or more
members to check in.
2 From the Sandbox window, do one of the following:
Select Member > Check In.
Click .
From the Member History window, do one of the following:
Select History > Check In.
Click .
The Check In dialog box appears.
u s e r g u i d e

TIP
Performing Member Operations
Click the Differences button on the Check In dialog box to view the differences
between your working file and the revision you checked out.
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.
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.
175

Chapter 6: Member Operations
176
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 179.
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 305.
The member is checked in.
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 window 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 window, do one of the following:
Select Member > Check In.
Click .
From the Member History window, do one of the following:
Select History > Check In.
Click .
The Check In dialog box appears.
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.
177

Chapter 6: Member Operations
178
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 179.
The Specify Source File dialog box appears.
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.
u s e r g u i d e

Check In Dialog Box Options
Check In Options
General Specifies the following general check in options:
Performing Member Operations
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.
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.
179

Chapter 6: Member Operations
Check In Dialog Box Options
Advanced Specifies the following advanced check in options:
Renaming a
Member
180
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.
You can rename individual members while working from a Project or
Sandbox window. 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 189.
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.
u s e r g u i d e

Renaming a Member That Is the Tip Revision
Performing Member Operations
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 window open, select the member you want
to rename.
2 Select Member > Rename.
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.
181

Chapter 6: Member Operations
182
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 window.
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 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.
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.
u s e r g u i d e

Discarding
Changes to a
Member
Performing Member Operations
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 window open, select one or more
members that are checked out in your name and/or have been
modified.
2 From a Sandbox window, do one of the following:
Select Member > Revert.
Click .
From a Member History window, do one of the following:
Select History > Revert.
A confirmation dialog box appears if the working file has been
modified.
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.
183

Chapter 6: Member Operations
Resyncing
Members
184
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.
Resyncing Deferred Operations
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.
Deferred Drop
When resynchronizing a member associated with a deferred drop,
where the working file has been 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.
u s e r g u i d e

Performing Member Operations
To resynchronize a member in the graphical user interface
1 With a Sandbox window 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 appears. 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
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 405.
185

Chapter 6: Member Operations
Locking a
Member
186
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 has been
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 320.
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 window open, select one or more members
to lock.
2 Do one of the following:
Select Member > Lock.
Click .
If your administrator has enabled the integration with
Integrity Manager and set the option for IMTrackLocksEnabled,
Source Integrity opens the Lock Revision dialog box.
u s e r g u i d e

3 Configure the following options as necessary:
Performing Member Operations
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 59), additional lock information may be available in columns,
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 window,
information about the lock is displayed in the Member Information
187

Chapter 6: Member Operations
Unlocking a
Member
188
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 298.
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 window 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 428), select one or more locked members, then select Locks >
Unlock.
The revision is unlocked and the padlock symbol ( ) is removed.
u s e r g u i d e

Deferring Member Operations
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.
You can apply the defer option to the following operations:
adding a project member
dropping a project member
checking in a member
renaming a member
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 83.
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 have been 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 have been submitted to the project. For
more information, see “Submitting Change Packages” on page 221.
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.
189

Chapter 6: Member Operations
Submitting
Deferred
Operations
190
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.
To submit, or complete, a deferred operation, you use the Member > Submit
function. Submitting the operation completes the command and makes it
visible in the associated project.
To submit a deferred operation in the graphical user interface
1 From a sandbox window, 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.
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 allows you to
select 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.
u s e r g u i d e

Cancelling
Deferred
Operations
Resyncing
Deferred
Operations
4 To complete the submission, click OK.
Deferring Member Operations
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 183.
When you revert a deferred add operation, Source Integrity retains the
working file for the pending member.
A pending member is a member that is associated with a deferred add
operation and will be added to the project at a future time when the
operation is submitted. The member is shown as a deferred add in the
sandbox, but not yet shown in the project. A pending member is also
known as a 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.
Deferred Drop
When resynchronizing a member associated with a deferred drop,
where the working file has been 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.
191

Chapter 6: Member Operations
Comparing Differences
192
After you have made changes to a member’s working file, you usually
check those changes back into the member history 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 301.
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 172.
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 66.
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 301.
For information on merging revisions, see “Merging Revisions” on
page 322 or “Branching and Merging Revisions” on page 305.
To compare a member’s working file to its member revision in the
graphical user interface
1 With a Sandbox window 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 .
u s e r g u i d e

Comparing Differences
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.
193

Chapter 6: Member Operations
Using Keywords
194
A keyword is a placeholder that can be inserted into text-based working
files. This placeholder is a special variable (for example, $Date$,
$Author$, $State$) used to represent textual information in a working
file. Keywords can be expanded (that is, replaced with their literal values)
when a revision is checked out.
To use a keyword, simply include it in a working file, surrounded by
dollar signs (for example, $Date$) and check the file back into its archive.
NOTE
Your administrator may define custom keywords for your use. For information
about these keywords, see your administrator or the 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 $
u s e r g u i d e

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

Chapter 6: Member Operations
Locating
Keywords
Table of
Keywords
196
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 have been made to the member over
time.
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.
u s e r g u i d e

Using Keywords
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).
$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.
$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.
$RCSfile$ The archive’s unqualified member name.
$Revision$ The revision number.
$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: unix$ is expanded to $Setting: $.
$Source$ The same as $RCSfile$. The archive’s
unqualified member name.
$State$ The state setting of the revision.
197

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

Using Change Packages
7
KEY TERMS: change package, change package ID, submit change package, change
package entry
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 200
“Why Use Change Packages?” on page 201
“Using Change Packages to Control Development” on page 202
“Creating a Change Package” on page 203
“Adding Entries to a Change Package” on page 205
“Managing Change Packages” on page 206
“Viewing Change Package Entry Member Differences” on page 222
199

Chapter 7: Using Change Packages
What Are Change Packages?
200
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.
Note the following rules that 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 339.
A change package acts as a log of both the changes to members which
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.
A change package has two states, open and closed. A change
package is open, or “in progress’ until you close it which signifies that
work on the change has been completed.
Only the creator of a change package or an administrator can close a
change package
Once a change package is closed, it cannot be reopened.
u s e r g u i d e

Why Use Change Packages?
Change packages provide the following advantages:
Why Use Change Packages?
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.
Since a change package is stored with each new revision, there is a link
between every change in the repository to the related changes made
by the author. If Integrity Manager is enabled, there is also a link back
to the issue that provides the context for why the particular change
was made.
Using change packages with the track locks feature, managers are able
to monitor work in progress.
Groups of changes can be reviewed as a unit.
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 339.
201

Chapter 7: Using Change Packages
Using Change Packages to Control
Development
202
The following is an example of the recommended way to use change
packages to control development:
1 Open the Manage Change Packages window (see “Managing Change
Packages” on page 206). This is your control centre for managing your
development activities.
2 Create a change package (see “Creating a Change Package” on
page 203) 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 window (see
“Viewing Change Package Details and Entries” on page 211). All
operations you associate with the change package will appear in this
window.
4 As part of your development process, identify the members that are
affected by the issue. Add the members to the change package during
one of the following operations:
Check Out
Rename
Lock
Add Member
Drop Member
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 window.
u s e r g u i d e

Creating a Change Package
5 When all of the development to address the issue is completed, submit
the change Package (see “Submitting Change Packages” on page 221).
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.
6 Close the change package when the work to address the issue has been
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 207).
TIP
If the Integrity Manager integration is enabled, change packages can also be
associated with issues in Integrity Manager to control advancement through a
workflow. For more information, see “The Integrity Manager Integration” on
page 339.
You can create a change package in one of the following ways: from the
Change Package menu, when checking out or checking in a member, when
renaming a member, when locking a member, and when adding or
dropping a member.
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, Member History view window open,
select Change Package > Create.
With a Manage Change Packages window open, do one of the
following:
Select Change Package > Create.
Click .
203

Chapter 7: Using Change Packages
204
Create a change package when performing any one of the
following operations:
“Checking Out a Member” on page 163
“Checking In a Member” on page 172
“Renaming a Member” on page 180
“Locking a Member” on page 186
“Adding Members to a Project” on page 146
“Dropping Members From a Project” on page 158
Refer to the Change Package portion of the panel.
Click Create.
The Create Change Package dialog box appears.
2 In the Summary field, enter a summary of the change package, for
example, Failed install. 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 343.
u s e r g u i d e

4 Click OK.
Adding Entries to a Change Package
5 The change package is created. To view the change package, see
“Viewing Change Package Details and Entries” on page 211.
Adding Entries to a Change Package
Once a change package has been created, you can add entries to that
change package upon any one of the following operations:
“Checking Out a Member” on page 163
“Checking In a Member” on page 172
“Renaming a Member” on page 180
“Locking a Member” on page 186
“Adding Members to a Project” on page 146
“Dropping Members From a Project” on page 158
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 the member’s C.P. ID (Change Package
ID) column of a Project or Sandbox window.
If the change package contains deferred operations or lock entries, a
icon is displayed beside the change package ID in the C.P. ID column.
TIP
You can also add a member to a change package by dragging the member from
a sandbox window to a a change package window (or change package in the
Manage Change Packages window). The Check Out dialog box appears with
the change package selected. For more information, see “Checking Out a
Member” on page 163.
205

Chapter 7: Using Change Packages
206
If the Integrity Manager integration is enabled and the change package is
associated with an issue, the change package ID is displayed as a hyperlink
in the C.P. ID column. When clicked, Integrity Manager opens the
associated issue. For more information on the integration, see “The
Integrity Manager Integration” on page 339.
NOTE
Managing Change Packages
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.
Source Integrity provides a central location to manage open change
packages you have created. From one location, you can view change
package 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.
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 appears.
By default, the Manage Change Packages window displays the following
information:
ID displays the change package ID.
Issue displays the issue ID if change packages are enabled.
Creator displays the username who created the change package.
u s e r g u i d e

Finding Change
Packages
Managing Change Packages
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 the Change Packages View option in the “View
Preferences” on page 59.
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 211)
View Issue that is associated with the change package (see “Viewing a
Change Package’s Issue” on page 346)
Submit the change package (see “Submitting Change Packages” on
page 221)
Close a Change Package (see “Closing a Change Package” on
page 219)
Edit an existing Change Package (see “Editing a Change Package” on
page 217)
Create a new Change Package (see “Creating a Change Package” on
page 203)
While the Manage Change Packages window only displays open change
packages that were created by you, Source Integrity provides you with a
way to search through all of the change packages that have been 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 347 for more information.
To find change packages in the graphical user interface
1 Select Tools > Find > Change Packages.
The Find Change Packages dialog box appears with the By Filer panel
displayed.
207

Chapter 7: Using Change Packages
208
If you want to find change packages using a filter, continue. To find a
query using its ID, go to step 3.
2 You can search for change packages using the following filters:
Closed finds change packages that are in a closed state.
Open finds change packages that are in an open 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.
u s e r g u i d e

Managing Change Packages
Description finds change packages that contain specified text in
the change package description.
Entry Type finds change packages that contain a specified entry
type. The possible types are Add, Drop, Lock, RenameFrom,
RenameTo, Update.
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 window.
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 339.
To combine filters, select the desired filters, then select Logical
AND or Logical OR to specify their relationship.
To invert a filter (for example, search for change packages that do not
have a project name), click the filter a second time and the ! symbol
appears.
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.
209

Chapter 7: Using Change Packages
210
4 Enter one of the following into the ID field:.
The 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 the ID appears in the list. Add as many IDs to the list as you
desire.
To remove IDs from the list, select the IDs from in the list, then click
Remove.
TIP
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 347.
5 Click OK.
The results are displayed in the Filtered Change Packages window.
The Filtered Change Packages window displays change packages in
u s e r g u i d e

Viewing Change
Package Details
and Entries
Managing Change Packages
the same way as the Manage Change Packages window does. For
more information, see “Managing Change Packages” on page 206.
To update the search results with current data, select View > Refresh.
To 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 205), 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 With the Manage Change Packages window open (see “Managing
Change Packages” on page 206), select the change package you want
to view.
2 Do one of the following:
Select Change Package > View Change Package.
Click .
Double click the change package name.
The Change Package window appears.
211

Chapter 7: Using Change Packages
212
The Change Package window displays the change package ID, person
who created the change package, description (if one was provided),
summary, date the change package was created, and the current
change package state.
By default, the Change Package window displays the following
information for each change package entry:
Type is the entry type of the change package entry. The possible
types are Add, Drop, Lock, Rename, Update, Deferred Add,
Deferred Drop, Deferred Check In, Deferred Rename.
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.
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.
Additional columns are available in the client preferences. To change
the displayed columns, see “View Preferences” on page 59.
u s e r g u i d e

Managing Change Packages
3 From the Change Package window, 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 Change Package
Entry Member Differences” on page 222)
View Revision that is associated with the entry (see “Viewing a
Member’s Working File or Revision” on page 291). This always
displays the revision stored on the repository.
TIP
Double click locked member or deferred check in entries to display the
working file.
View Revision Information associated with the entry (see
“Viewing and Editing Revision Information” on page 284)
View the Member History associated with the entry (see “Viewing
a Member History” on page 280)
Submit selected deferred entries (see “Submitting Deferred
Operations” on page 190)
Edit Settings for the selected deferred entries (see “Submitting
Deferred Operations” on page 190)
Revert the selected deferred entries (see “Cancelling Deferred
Operations” on page 191)
Edit Working File that is associated with a entry (see “Viewing a
Member’s Working File or Revision” on page 291)
Check In the selected lock entries (see “Checking In a Member” on
page 172)
Unlock the selected lock entries (see “Unlocking a Member” on
page 188 or “Locking Revisions” on page 294)
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 have been committed, select
View > Show Committed. Repeat to enable or disable the option.
213

Chapter 7: Using Change Packages
214
To view change package information and entries in the Web interface
With a Project or Member History window open, click the change package
ID.
The Change Package View window is displayed.
For more information on the change packages view, see “Change Package
View (Web)” on page 426.
To view a member’s change package information in the graphical
user interface
1 With a Project or Sandbox window 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 appears.
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.
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 window 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 window 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 appears.
3 Click the Change Package tab.
The Change Package panel appears.
215

Chapter 7: Using Change Packages
216
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 window 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 appears.
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 an open change package when necessary. You can update
the following change package information: Summary, State, and
Description.
NOTE
You can only edit a change package that you have created unless you have
administrative permissions.
To edit 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 206), select the change
package you want to edit.
From a Sandbox window, select the member whose associated
change package you want to edit.
View the details of the change package you want to edit (see
“Viewing Change Package Details and Entries” on page 211).
217

Chapter 7: Using Change Packages
218
2 Select Change Package > Edit.
The Edit Change Package dialog box appears.
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. An Open change package is active and allows you to track
modifications within it. A Closed change package indicates that
modifications within it are complete, and it cannot be opened
again.
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 window, 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 .
The Edit Change Package dialog box appears.
u s e r g u i d e

Closing a
Change
Package
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. An Open change package is active and allows you to track
modifications within it. A Closed change package indicates that
modifications within it are complete, and it cannot be opened
again.
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 have been made to the members and they are
checked in, the change package can be closed.
In addition to this procedure, you can close a change package in the
graphical user interface when you check in a member, when you add or
drop a member, and when you rename a member.
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 339.
NOTE
You can only close a change package that you have created unless you have
administrative permissions.
219

Chapter 7: Using Change Packages
220
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 206), select the change
package you want to close.
From a Sandbox window, select the member whose associated
change package you want to close.
View the details of the change package you want to close (see
“Viewing Change Package Details and Entries” on page 211).
2 Do one of the following:
Select Change Package > Close.
Click .
The Confirm Close Change Package dialog box appears.
3 To close the change package, click OK.
The change package appears closed in the State column of the Manage
Change Packages window (see “Managing Change Packages” on
page 206).
To close a change package when performing an operation in the
graphical user interface
You can close a change package when performing any one of the following
operations:
“Checking In a Member” on page 172
“Renaming a Member” on page 180
“Dropping Members From a Project” on page 158
“Adding Members to a Project” on page 146
To close the change package when performing one of the above operations;
on the dialog box, enable the Close Change Package option.
After the operation is completed, the change package appears closed in the
State column of the Manage Change Packages window (see “Managing
Change Packages” on page 206).
u s e r g u i d e

Submitting Change Packages
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.
To submit change package in the graphical user interface
1 Do one of the following:
From the Manage Change Packages window (see “Managing
Change Packages” on page 206), select the change packages you
want to submit.
Display the desired change package in the Change Package
window (see “Viewing Change Package Details and Entries” on
page 211).
From a Sandbox window, 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.
3 All of the deferred operations in the change package are submitted.
Individual confirmations for each operation appear. To avoid repeated
confirmation, where possible click OK to All.
221

Chapter 7: Using Change Packages
Viewing Change Package Entry Member
Differences
222
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 GUI, Source Integrity compares the working file
with it’s immediately preceeding revision. You cannot difference a lock
entry that does not have an associated sandbox.
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 206), 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 entry.
The Change Package window appears.
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 192.
To view change package entry member differences in the Web
interface
1 In a Project window, 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 appears.
u s e r g u i d e

Viewing Change Package Entry Member Differences
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 192.
223

Chapter 7: Using Change Packages
224
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 226
“Controlling Sandboxes” on page 251
“Controlling Members” on page 257
“Generating Reports” on page 273
225

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Controlling Projects
Viewing and
Editing Project
Information
226
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 window open, select the project or sandbox.
2 In the GUI from a Project window, select Project > Properties > Project
Information.
In the GUI from a Sandbox window, select Sandbox > Properties >
Project Information.
In the Web from a Project window, select Project > Project Information.
The Project Information dialog box appears.
u s e r g u i d e

TIP
Controlling Projects
In the Source Integrity Web interface, you can also work with project
information by selecting Tools > Manage to open the Registered Projects
window, and then by selecting Project > Project Information.
3 View or make changes to the project information as required.
The General tab displays the following project information:
Project Name is the path and name of the project.
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 “Creating a Shared Subproject” on page 122.
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 Attribute
Information” on page 228. For information about the Development
Paths tab, see “Working With Development Path Information” on
page 230.
4 To accept any changes you have made, click OK.
The project information is saved.
227

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
228
Working With 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.
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 appears.
3 Click the Attributes tab.
The Attributes panel appears.
u s e r g u i d e

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.
Controlling Projects
6 To add the attribute, click Add. To remove attributes, select them, then
click Remove.
The attributes appear in the attributes list.
7 To accept any changes you have made, click OK.
The project information is saved.
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.
229

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
230
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.
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 appears.
3 Click the Development Paths tab.
The Development Paths panel appears.
4 To delete a development path, select one from the list.
u s e r g u i d e

Viewing a
Project History
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.
TIP
Controlling Projects
To create a development path, see “Creating a Development Path” on page 141.
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 window 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.
231

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
232
To view a project history in the graphical user interface and Web
interface
1 With a Project or Sandbox window open, select the project or sandbox.
2 From a Project window, select Project > View Project History.
From a Sandbox window, select Sandbox > View Project History.
The Project History window appears.
In the graphical user interface, you can toggle between the Graphical
History view and the List view in the Project History window. For
more information on toggling views, see “Changing Views (GUI)” on
page 424.
Project History Filters
Like the filters in the Project and Sandbox windows, 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:
u s e r g u i d e

Opening a Build
Project
Adding Project
Labels
All Revisions shows all the revisions in the project.
Controlling Projects
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.
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 window 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 window.
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 window.
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.
233

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
234
To add a label to a project in the graphical user interface and Web
interface
1 With a Project History window 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 appears.
TIP
In the Source Integrity Web interface, you can also add a project label from the
Project window 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.
u s e r g u i d e

Deleting Project
Labels
Promoting a
Project
Controlling Projects
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 has been applied.
To delete a project label in the graphical user interface and Web
interface
1 With a Project History window open, do one of the following:
Select History > Delete Label.
Click .
The Delete Project Label dialog box appears.
TIP
In the Source Integrity Web interface, you can also delete a project label from
the Project window 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.
235

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Demoting a
Project
236
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 window open, select the revision you want to
promote.
2 Do one of the following:
Select History > Promote.
Click .
The Promote Project dialog box appears.
TIP
In the Source Integrity Web interface, you can also promote a project from the
Project window 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 window open, select the revision you want to
demote.
u s e r g u i d e

Checkpointing
a Project
2 Do one of the following:
Select History > Demote.
Click .
The Demote Project dialog box appears.
Controlling Projects
TIP
In the Source Integrity Web interface, you can also demote a project from the
Project window 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.
237

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
238
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.
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 window open, select the project or sandbox.
2 From a Project window, do one of the following:
Select Project > Checkpoint Project.
Click .
From a Sandbox window, do one of the following:
Select Sandbox > Checkpoint Project.
Click .
The Checkpoint dialog box appears.
u s e r g u i d e

Controlling Projects
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 window, see
“Adding Labels to Members” on page 266.
NOTE
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.
239

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Restoring a
Project
240
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.
Revision Number is the revision number of the project. If you
choose to specify a revision number, the number you supply must
be higher than the head revision number (if you are
checkpointing the main project) or the tip revision number (if you
are checkpointing a variant project).
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.
u s e r g u i d e

Controlling Projects
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 139).
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 window, 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 window open, select the project or sandbox.
2 From a Project window, select Project > Restore Project.
From a Sandbox window, select Sandbox > Restore Project.
The Restore Project dialog box appears.
241

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
242
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).
u s e r g u i d e

Controlling Projects
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 window,
Source Integrity displays information on the corresponding working
file and available revision.
243

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Viewing Project
Differences
244
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.
If you have installed the full Integrity Solution Integration,
Source Integrity also provides information 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 change packages, see “The Integrity Manager Integration”
on page 339.
When you checkpoint a project, Source Integrity is actually saving a
revision of the project file itself (that is, the .pj file). The project file
contains information that can help you understand and manage the
development of your projects. This information includes:
the revision number of the current project
the names and locations of all project members
revision numbers of all project members
any project attributes
member attributes
For more information on checkpointing, see “Checkpointing a Project” on
page 237.
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.
u s e r g u i d e

Comparing
Project
Revisions
Project members may be added or deleted.
Project attributes may be added or deleted.
Controlling Projects
Source Integrity can also checkpoint subprojects when a project is
checkpointed. To checkpoint subprojects, open the Checkpoint dialog box,
click the Advanced tab, and select the option for Recurse into Subprojects.
There are three methods for comparing project revisions. Source Integrity
can compare:
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 detailed procedures on comparing project revisions in the graphical
user interface, see “To view project differences in the graphical user
interface” on page 249. For the Web interface, see “To view project
differences in the Web interface” on page 250.
Comparing 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.
In the graphical user interface, you use the Project History window to
select two versions of the project (in either the List view or Graphical
History view). When you select History > View Project Differences,
Source Integrity compares the two specified revisions of the project.
An example of two revisions selected for comparison in the Project
History List view.
245

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
246
TIP
To select two revisions in the graphical user interface, hold CTRL and then click
the left mouse button while highlighting each revision number.
In the Web interface, you use the Project History window to select two
versions of the project. When you select History > View Project Differences,
Source Integrity compares the two specified revisions of the project.
Comparing 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, you use the Project History window (in
either the List view or the Graphical History view) to select one version of
the project. When you select History > View Project Differences,
Source Integrity compares the current project revision with the specified
revision.
u s e r g u i d e

Controlling Projects
An example of a project revision selected for comparison in the Project
History List view.
In the Web interface, you use the Project History window to select one
version of the project. When you select History > View Project Differences,
Source Integrity compares the current project revision with the specified
revision.
247

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
248
Comparing 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.
TIP
An example of the Project History window in the List view.
To deselect a revision that is already highlighted, move the pointer to the
highlight, hold CTRL, and then click the left mouse button.
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 window 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.
u s e r g u i d e

To view project differences in the graphical user interface
Controlling Projects
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 window open, select the project whose
differences you want to view.
2 From a Project window, select Project > View Project History.
From a Sandbox window, select Sandbox > View Project History.
The Project History window appears.
From the Project History window, choose the versions of the project
you want to compare.
To select more than one revision of the project, hold CTRL and click the
left mouse button while highlighting each revision. To deselect a
revision that is already highlighted, move the pointer to the highlight,
hold CTRL, and click the left mouse button.
3 With the required versions selected, do one of the following:
Select History > View Project Differences.
Click .
The Changes to Project window opens, displaying the list of project
differences.
249

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
250
If no project members have been modified since the last checkpoint, no
information displays in the Changes to Project window.
4 To perform further comparisons, close the Changes to Project window
and return to the Project History window.
To return to the Project History window, select Window from the
Source Integrity menu and choose Project History from the list.
To view project 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 window, click Project > View Project History.
The Project History window appears.
3 From the Project History window, 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 to Project window opens, displaying the list of project
differences.
u s e r g u i d e

Controlling Sandboxes
Viewing
General
Information
Controlling Sandboxes
If no project members have been modified since the last checkpoint, no
information displays in the Changes to Project window.
Using a Project window 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.
To help you manage your individual sandboxes, Source Integrity allows
you to view two categories of sandbox information:
general sandbox information
project 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 With a Sandbox window open, select the sandbox.
2 Select Sandbox > Properties > Sandbox Information.
The Sandbox Information dialog box appears.
251

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Viewing Project
Attributes
252
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.
Sparse appears when the selected sandbox is a sparse sandbox.
Members is the number of members in the sandbox.
Subsandboxes is the number of subsandboxes in the sandbox.
Project Description is a description of the master project.
Working from your sandbox, you can only view project attribute
information through the graphical user interface. These are the attributes
that apply across the entire project, as well as any sandbox attributes you
have applied for your workspace.
Attributes can have either of the following formats:
variable
variable=value
u s e r g u i d e

Taking Sandbox
Snapshots
To view project attributes in the graphical user interface
1 Select the target sandbox.
2 Select Sandbox > Properties > Sandbox Information.
The Sandbox Information dialog box appears.
3 Click the Project Attributes tab.
The Project Attributes panel appears.
The project attributes are displayed view-only.
4 To close the Sandbox Information dialog box, click OK.
Controlling Sandboxes
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
253

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
254
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.
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
u s e r g u i d e

Controlling Sandboxes
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 126.
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 have been 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.
4 Create a development path from the project revision that corresponds
to the snapshot (see “Creating a Development Path” on page 141).
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.
255

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
256
To take a snapshot of a sandbox in the graphical user interface
1 From a Sandbox window, select Sandbox > Snapshot Sandbox.
The Snapshot Sandbox dialog box appears.
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.
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.
u s e r g u i d e

The Advanced tab specifies advanced snapshot options:
Controlling Members
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 231.
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
257

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
258
To view or edit member information in the graphical user interface
and Web interface
1 With a Project or Sandbox window 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 appears.
3 View or make changes to the member information as required.
The Member Information dialog box presents 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.
Member Revision is the displayed member revision. To select
another member revision, choose a revision from the Member
Revision list.
u s e r g u i d e

Controlling Members
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 268.
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 260. For information
on the Labels tab, see “To view or edit member labels in the graphical
user interface” on page 262.
4 When you are finished viewing or editing the member information,
click OK to accept the changes.
The member information is saved.
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
259

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
260
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 appears.
3 Click the Attributes tab.
The Attributes panel appears.
4 In the Variable field, enter a variable, for example, os.
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.
To view or edit member attribute information in the Web interface
1 With the Project window open, select the member whose information
you want to view or edit.
u s e r g u i d e

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.
Controlling Members
261

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
262
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.
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 appears.
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.
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.
7 To accept the changes, click OK.
To view or edit member label information in the Web interface
1 With the Project window 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.
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 272.
263

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
264
To update a member’s revision in the graphical user interface
1 With a Project or Sandbox window open, select one or more members
to update.
2 Select Member > Properties > Update Revision.
The Set Member Revision dialog box appears.
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 has been 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.
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.
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.
Working updates the member revision to the version of the
working file.
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 set the member revision, click OK (for multiple members, click OK
to All).
The member is updated to the specified revision.
To update a member’s revision in the Web interface
1 With a Project window open, select one or more members to update.
2 Select Member > Update Revision.
The Update Member Revision dialog box appears.
265

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Adding Labels
to Members
266
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.
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 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 window. 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.
u s e r g u i d e

Deleting
Member Labels
Controlling Members
To add a label to a member in the graphical user interface and Web
interface
1 With a Project or Sandbox window 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 appears.
: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.
267

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Promoting
Members
268
To delete a member label in the graphical user interface and Web
interface
1 With a Project or Sandbox window 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 appears.
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.
u s e r g u i d e

Demoting
Members
Controlling Members
To promote a member in the graphical user interface and Web
interface
1 With a Project or Sandbox window 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 appears.
: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 window 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 appears.
269

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Freezing
Members
270
: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.
u s e r g u i d e

Controlling Members
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 272).
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 window. (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 window 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.
271

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
Thawing
Members
272
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.
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 window open, select the member you want
to thaw. The member is one that is marked with a snowflake symbol
( ).
u s e r g u i d e

Generating Reports
About the
Report
Information
2 In the GUI, select Member > Properties > Thaw.
In the Web, select Member > Thaw.
Generating Reports
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.
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
273

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
About Graphs
Report Types
274
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.
Changes Grouped by Author (Summary)
This type of report shows a brief summary of changes made by each user.
Each type of project member (Text, Binary, Auto-Detect) 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
u s e r g u i d e

This report type offers two additional options:
The report can be on a single, specified author, or all authors.
Generating Reports
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
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
275

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
276
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
Project Member History
This report displays all the revisions of a specified project member. For
each revision, it shows:
revision number
revision date
revision description
When you choose the member to report on, you can specify that the
information should be sorted according to Revision Number or Revision
Date, in either ascending or descending order.
u s e r g u i d e

Creating a Report
Source Integrity provides you with the ability to create reports.
Generating 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 window open, select the project or sandbox
you want to report on.
2 From a Project window, select Project > Reports.
From a Sandbox window, select Sandbox > Reports.
The Select Report Type dialog box appears.
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.
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 274.
6 Click OK.
If the report type requires additional information (for example, a
range of revisions), a second dialog box appears to collect it.
Reports appear in plain text format by default. Some report types,
however, allow you to display the information graphically.
277

Chapter 8: Viewing and Editing Projects, Sandboxes, and Members
278
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 280
“Viewing and Editing Archive Information” on page 282, and
“Viewing and Editing Revision Information” on page 284
“Viewing an Annotated Revision” on page 286
“Viewing and Editing Revision Labels” on page 288
“Viewing a Member’s Working File or Revision” on page 291
“Promoting Revisions” on page 292, and “Demoting Revisions” on
page 293
“Locking Revisions” on page 294, “Unlocking Revisions” on
page 295, “Locking Multiple Revisions” on page 296, and “Managing
Revision Locks” on page 298
“Setting the Member Revision” on page 300, “Deleting Revisions” on
page 301, and “Comparing Revisions” on page 301
279

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

NOTE
Viewing a Member History
If there is an add operation pending 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 window. For more information on toggling
views, see “Changing Views (GUI)” on page 424.
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 windows, the Member History
filters allow you to view and manipulate a predefined subset of project
members that are grouped according to their properties.
281

Chapter 9: Viewing and Editing Member Histories and Revisions
282
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.
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).
Branched shows all the revisions that have been, or are branched.
Labeled shows all revisions with a label.
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.
To view or edit archive information in the graphical user interface and
Web interface
1 With a Member History window open, do one of the following:
Select History > Archive Information.
Click .
The Archive Information dialog box appears.
u s e r g u i d e

NOTE
Viewing and Editing Archive Information
In the Source Integrity Web interface, you cannot edit archive information.
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.
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.
283

Chapter 9: Viewing and Editing Member Histories and Revisions
284
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 tab displays a list of revision labels in the archive, for
example, Draft1 1.1.
The Locks tab 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 window.
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 288.
The Change Package tab provides information on change packages
associated with the revision. The Change Package tab only appears if
change packages are enabled.
u s e r g u i d e

Viewing and Editing Revision Information
To view or edit general revision information in the graphical user
interface and Web interface
1 With a Member History window 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 appears.
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.
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.
285

Chapter 9: Viewing and Editing Member Histories and Revisions
286
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
History windows.
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
NOTE
The annotated view can only be displayed for members of text format.
u s e r g u i d e

Viewing an Annotated Revision
To view annotated revisions in the graphical user interface and Web
interface
1 With a Project, Sandbox, or Member History window open, select the
revision you want to view.
2 From a Project or Sandbox window, select Member > View Annotated
Member.
From a Member History window, do one of the following:
Select History > View Annotated Revision.
Click .
The Annotated Revision window appears.
The Annotated Revision window 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.
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.
287

Chapter 9: Viewing and Editing Member Histories and Revisions
288
To customize the fields displayed in the Annotated Revision window,
see “View Preferences” on page 59.
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.
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 284.
View Revision, see “Viewing a Member’s Working File or
Revision” on page 291.
View Member History, see “Viewing a Member History” on
page 280.
View Issue, see the Integrity Manager User Guide.
View Change Package, see “Using Change Packages” on page 199.
TIP
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.
u s e r g u i d e

Viewing and Editing Revision Labels
To view or edit revision labels in the graphical user interface
1 With a Member History window 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 appears.
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.
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.
289

Chapter 9: Viewing and Editing Member Histories and Revisions
Adding
Revision Labels
290
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 window. 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 window open, select the revision you want to
label.
2 Do one of the following:
Select History > Add Label.
Click .
TIP
You can also add a label using the Revision Information dialog box, as
described in “Viewing and Editing Revision Information” on page 284.
The Add Label dialog box appears.
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.
u s e r g u i d e

Deleting
Revision Labels
Viewing a Member’s Working File or Revision
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 window 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 284.
The Delete Label dialog box appears.
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.
291

Chapter 9: Viewing and Editing Member Histories and Revisions
292
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 window open, select the working file or
revision you want to view.
2 Do one of the following:
Select History > View Revision.
Click .
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 window open, select a revision to promote.
2 Do one of the following:
Select History > Promote.
Click .
The Promote Member dialog box appears.
u s e r g u i d e

Demoting Revisions
Demoting Revisions
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.
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 window open, select a revision to demote.
2 Do one of the following:
Select History > Demote.
Click .
The Demote Member dialog box appears.
293

Chapter 9: Viewing and Editing Member Histories and Revisions
Locking Revisions
294
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.
To lock a revision in the graphical user interface and Web interface
1 With a Member History window 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.
u s e r g u i d e

Unlocking Revisions
3 Configure the following options as necessary:
Unlocking Revisions
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.
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.
295

Chapter 9: Viewing and Editing Member Histories and Revisions
296
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 window open, select a revision to unlock
(denoted by a padlock symbol), then do one of the following:
Select History > Unlock.
Click .
Locking Multiple Revisions
With the Locks for User window open (see “Locks View” on
page 428), 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.
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
u s e r g u i d e

Locking Multiple Revisions
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 139.
NOTE
Your administrator must explicitly set the locking policy to allow locking
multiple revisions. See your administrator to find out if your system has been
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 window:
Follow the procedure for Locking a Revision (see “Locking Revisions”
on page 294). Repeat to lock other revisions.
Follow the procedure for Checking Out a Member (see “Checking Out
a Member” on page 163) by specifying the revision number (Member
History window via the Sandbox window only). Repeat to check out
and lock other revisions.
From the Sandbox window, follow the procedure for Checking Out a
Member (see “Checking Out a Member” on page 163) 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 window:
Follow the procedure for Locking a Revision (see “Locking Revisions”
on page 294). Repeat to lock other revisions.
Follow the procedure for Checking Out a Member (see “Checking Out
a Member” on page 163) by specifying the revision number. Repeat to
check out and lock other revisions.
297

Chapter 9: Viewing and Editing Member Histories and Revisions
Managing Revision Locks
298
From the Project window, follow the procedure for Checking Out a
Member (see “Checking Out a Member” on page 163) 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 appears.
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.
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,
Change Package ID, Sandbox, Development Path. For more
information, see “View Preferences” on page 59.
u s e r g u i d e

You can perform the following tasks:
Managing Revision Locks
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 appears.
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.
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 appears.
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.
299

Chapter 9: Viewing and Editing Member Histories and Revisions
300
NOTE
Setting the Member Revision
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 window 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
If you know you will never use a revision again, you can delete it.
CAUTION
Deleting Revisions
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 window 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 .
Comparing Revisions
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.
301

Chapter 9: Viewing and Editing Member Histories and Revisions
302
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 324.
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 95.
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 66.
To compare two revisions in the graphical user interface
1 With a Member History window 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.
u s e r g u i d e

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

Chapter 9: Viewing and Editing Member Histories and Revisions
304
The Differences window opens.
Both revisions and a summary of the differences between them are
shown in the Differences window.
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

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 306
“Making Locked Members Writable” on page 308
“Merging Branched Revisions” on page 311
“Merging Revisions” on page 322
“Resolving Merges” on page 336
305

Chapter 10: Branching and Merging Revisions
Branching Revisions
306
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 311.
To branch a member upon check out in the graphical user interface
and Web interface
1 With a Project or Sandbox window 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 appears.
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 163.
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 appears.
5 Select the Create a new branch with a lock option.
307

Chapter 10: Branching and Merging Revisions
308
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.
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
appears. 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 window.
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 window open, select one or more locked members to
make writable.
u s e r g u i d e

2 Select Member > Working File > Make Writable.
Making Locked Members 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.
To make a member writable upon check out in the graphical user
interface
1 With a Project or Sandbox window 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 appears.
3 Click the desired tab, then modify the check out options. For details on
check out options, see “Checking Out a Member” on page 163.
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 appears.
5 Select the Make your working file writable option.
309

Chapter 10: Branching and Merging Revisions
310
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.
To make a member writable in the Web interface upon check out
1 From a Project window, 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 appears.
3 Click the desired tab, then modify the check out options. For details on
check out options, see “Checking Out a Member” on page 163.
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 appears.
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.
u s e r g u i d e

Merging Branched Revisions
Merging on
Check In
Merging Branched Revisions
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.
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 263.
To check in and update the member revision using the graphical user
interface
1 With a Sandbox window open, select one or more members to check
in.
311

Chapter 10: Branching and Merging Revisions
312
2 Do one of the following:
Select Member > Check In.
Click .
The Check In dialog box appears.
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.
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.
u s e r g u i d e

NOTE
Merging Branched Revisions
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 172.
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 appears.
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 336.
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 322.
313

Chapter 10: Branching and Merging Revisions
314
To merge revisions in the graphical user interface
1 With a Sandbox or Member History window open, select one or more
members to merge.
IMPORTANT
Revisions must be checked in prior to merging. An error occurs if the working
file has been modified and not checked in.
2 From the Sandbox window, select Member > Diff/Merge > Merge
Branch.
From the Member History window, select History > Merge Branch.
The Merge Branch dialog box appears.
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.
u s e r g u i d e

5 Under Options complete the following as required:
Merging Branched Revisions
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.
Highlight Output File causes Source Integrity to
complete the merge automatically and highlight the output
file where any conflicts occurred.
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.
315

Chapter 10: Branching and Merging Revisions
Merging
Revisions by
Dragging
316
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.
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 420.
For more information on Dragging, see “Dragging in the Graphical History
View (GUI)” on page 423.
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 appears.
u s e r g u i d e

Merging Branched Revisions
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.
317

Chapter 10: Branching and Merging Revisions
318
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.
Highlight Output File causes Source Integrity to
complete the merge automatically and highlight the output
file where any conflicts occurred.
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.
u s e r g u i d e

Automatic
Merging on
Check Out
Merging Branched Revisions
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 has been 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 322.
To merge revisions automatically on check out in the graphical user
interface
1 With a Sandbox window 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 appears.
319

Chapter 10: Branching and Merging Revisions
Automatic
Merging on
Resync
320
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 appears. 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.
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 336.
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 330.
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 has been 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 322. For
more information on resyncing members, see “Resyncing Members” on
page 184.
To merge revisions automatically on resynchronization in the
graphical user interface
1 With a Sandbox window open, select one or more members that
contain member deltas that denote that both the working file has been
modified and a new member revision available.
u s e r g u i d e

2 Do one of the following:
Select Member > Resynchronize.
Click .
The Confirm Working File Merge dialog appears.
Merging Branched 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 336.
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 330.
The selected member is updated and merged.
321

Chapter 10: Branching and Merging Revisions
Merging Revisions
Merging
Revisions
Automatically
322
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 95.
For more information on MKS Visual Merge, see “MKS Visual Merge
Interface” on page 101.
For more information on the command line interface, see “Command Line
Interface” on page 92.
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 window, select the revisions you
want to merge.
2 Do one of the following:
From the Sandbox window, select Member > Diff/Merge > Merge.
From the Member History window, select History > Merge.
The Merge dialog box appears.
u s e r g u i d e

Merging Revisions
3 Specify the revisions you want to merge. You can specify a revision by
name from the Symbolic list, specify a particular revision from the
Revision list, or specify a revision by label from the Label list.
4 Click OK to continue.
The Merge dialog box appears (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 appears.
323

Chapter 10: Branching and Merging Revisions
Working With
MKS Visual
Difference
324
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.
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 301.
2 In Visual Difference, do one of the following:
Select File > Merge.
Click .
The Reassign Merge Roles dialog box appears.
u s e r g u i d e

Merging Revisions
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 97.
325

Chapter 10: Branching and Merging Revisions
326
5 Complete the required changes by doing one of the following:
Merging Blocks (see “Merging Blocks” on page 327)
Editing Merge Results (see “Editing Merge Results” on page 331)
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 appears.
u s e r g u i d e

Merging Revisions
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 329.
327

Chapter 10: Branching and Merging Revisions
328
Editing Merge Results
Once you are working in Merge mode in MKS Visual Difference you can
directly edit the merge result if necessary.
In MKS Visual Difference you can cut, copy, and paste text in the merge
result. MKS Visual Difference highlights the edited text and displays the
edit icon ( ) next to the line number. You can access editing functions in
the following ways:
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.
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.
u s e r g u i d e

Saving Merge Results
Merging Revisions
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 appears.
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.
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 .
329

Chapter 10: Branching and Merging Revisions
Working With
MKS Visual
Merge
330
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 322).
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.
u s e r g u i d e

Merging by Nonconflicting Blocks
Merging Revisions
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.
2 Save the merge result file to retain the changes as described in “Saving
Merge Results” on page 333.
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 333.
Editing Merge Results
While you are working in MKS Visual Merge you can directly edit the
merge result if necessary.
331

Chapter 10: Branching and Merging Revisions
332
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
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.
u s e r g u i d e

Saving Merge Results
Merging Revisions
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 appears.
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.
333

Chapter 10: Branching and Merging Revisions
334
Suspending Merges
Once you have initiated a merge, you can suspend it and then resolve it at
a later time. Suspending merges allows you to mark the working file to
indicate that merging is required. This provides time you may need to
investigate conflicts or difference blocks before finishing the merge.
You can only suspend a merge operation if there are changes since the last
time you saved the merge result.
To suspend 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 appears.
2 Click Yes to mark the revision for merging at a later time.
In your Sandbox window 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 336.
u s e r g u i d e

Merging in the
Command Line
Interface
Merging Revisions
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:
where
si merge -r value -r value member --sandbox=value
-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:
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.
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.
335

Chapter 10: Branching and Merging Revisions
Resolving Merges
336
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 have been 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 window, select a member with an unresolved merge
symbol.
2 Select Member > Diff/Merge > Resolve Merge.
The Merge dialog box appears (if your preferences are set to confirm
the action to be taken, see “Command Preferences” on page 48).
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 window,
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.
u s e r g u i d e

Resolving Merges
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 101, and “Working With MKS Visual
Merge” on page 330.
4 In the MKS Visual Merge window, click File > Save As.
The Save merge result dialog box appears.
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 window, a delta appears indicating that the merge is
complete.
337

Chapter 10: Branching and Merging Revisions
338
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” on
page 199.
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 340
“How the Integration Works” on page 340
“Creating a Change Package for an Issue” on page 343
“Adding Entries to an Issue’s Change Package” on page 345
“Viewing a Change Package’s Issue” on page 346
“Finding Change Packages Using a Query” on page 347
339

Chapter 11: The Integrity Manager Integration
Integrating With Integrity Manager
How the Integration Works
340
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 Open the Manage Change Packages window (see “Managing Change
Packages” on page 206). This is your control centre for managing your
grouping of tasks.
3 Create a change package (see “Creating a Change Package” on
page 203) 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 an open state.
You can see the change package listed in the Manage Change
Packages window.
341

Chapter 11: The Integrity Manager Integration
342
4 View the change package in the Change Package window (see
“Viewing Change Package Details and Entries” on page 211). All
operations you do to address the issue will 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 during
one of the following operations:
Check Out
Rename
Lock
Add Member
Drop Member
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 window.
6 When all of the development to address the issue is completed, submit
the change Package (see “Submitting Change Packages” on page 221).
All of the 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.
7 Close the change package to signify that the work to address the issue
has been 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 207 or “Finding Change Packages Using a Query”
on page 347).
8 In Integrity Manager, advance the issue through the workflow. At this
point, the verification phase begins. If it’s determined that more work
needs to be performed to address the issue, the technician moves the
u s e r g u i d e

Creating a Change Package for an Issue
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.
Creating a Change Package for an Issue
You can create a change package and associate it with an issue in one of the
following ways: 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 window open, select Change Package > Create.
Create a change package when performing any one of the
following operations:
“Checking Out a Member” on page 163
“Checking In a Member” on page 172
“Renaming a Member” on page 180
“Locking a Member” on page 186
“Adding Members to a Project” on page 146
“Dropping Members From a Project” on page 158
Refer to 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 window appears.
343

Chapter 11: The Integrity Manager Integration
344
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.
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, for
example, Failed install.
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.
The change package is created. To view the change package, see
“Viewing Change Package Details and Entries” on page 211.
u s e r g u i d e

Adding Entries to an Issue’s
Change Package
Adding Entries to an Issue’s Change Package
Once a change package has been created and associated with an issue, you
can add entries to that change package upon any one of the following
operations:
“Checking Out a Member” on page 163
“Checking In a Member” on page 172
“Renaming a Member” on page 180
“Locking a Member” on page 186
“Adding Members to a Project” on page 146
“Dropping Members From a Project” on page 158
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.
NOTE
You can only add a member to an issue’s change package upon a check out and
locking a member if lock tracking is enabled. For more information on lock
tracking, see your administrator.
After the operation is completed, the entry is added to the change package.
The change package’s ID appears in the member’s C.P. ID (Change Package
ID) column of a Project or Sandbox window.
The change package ID is displayed as a hyperlink that automatically
opens Integrity Manager to the specified issue. For more information on
the integration, see “The Integrity Manager Integration” on page 339.
345

Chapter 11: The Integrity Manager Integration
Viewing a Change Package’s Issue
346
As part of the Integrity Manager integration, you can launch the
Integrity Manager Web interface from Source Integrity to view issues that
are associated with change packages.
To view a change package’s issue in the graphical user interface
Do one of the following:
From the Manage Change Packages window (see “Managing Change
Packages” on page 206), select a change package. Do one of the
following:
Under the Issue column, click the number link for the issue.
Select Change Package > View Issue.
Click .
With the Change Package window open (see “Viewing Change
Package Details and Entries” on page 211) do one of the following:
Select Change Package > View Issue.
Click .
With a Project or Sandbox window open, select a member that has a
change package associated with it. Do one of the following:
Under the C.P.ID column, click the number link for the change
package.
Select Change Package > View Issue.
The Integrity Manager Web 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 in the Web interface
1 In a Project window, 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 opens.
u s e r g u i d e

3 Select Actions > View Issue.
Finding Change Packages Using a Query
The Integrity Manager Web interface opens, displaying the associated
issue. For more information on Integrity Manager, see the
Integrity Manager User Guide.
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 have been 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 appears.
2 Click the By Query tab.
The By Query panel is displayed.
347

Chapter 11: The Integrity Manager Integration
348
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 207.
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 206.
To update the search results with current data, select View > Refresh.
To create a new search from the Change Packages window, select View
> Filter.
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 350
“Using the Apply CP Command” on page 355
“Using the Resync CP Command” on page 375
“Working With a Resolution CP” on page 397
“Using the Resync By CP Command” on page 405
349

Chapter 12: Advanced Change Package Operations
Change Package Feature Overview
350
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 has been 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.
IMPORTANT
At this time, Apply CP and Resync CP do not handle change package entries
(project members) that have been renamed.
u s e r g u i d e

Change
Package
Methodology
Change
Package
Commands
Change Package Feature Overview
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
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
351

Chapter 12: Advanced Change Package Operations
352
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
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.
u s e r g u i d e

Change Package Feature Overview
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 have been 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
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.
353

Chapter 12: Advanced Change Package Operations
Resolving
Conflicts
354
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
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 330. For information on the MKS Visual Merge tool, see “MKS
Visual Merge Interface” on page 101.
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.
u s e r g u i d e

Using the Apply CP Command
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.
Apply that resolution change package 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.
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.
355

Chapter 12: Advanced Change Package Operations
356
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).
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 357
“How Apply CP Works” on page 357
Procedures for the graphical user interface
the Apply CP backfill list, (“Apply CP Backfill List” on page 359)
u s e r g u i d e

Key Apply CP
Concepts
How Apply CP
Works
Using the Apply CP Command
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 375.
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
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 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.
357

Chapter 12: Advanced Change Package Operations
358
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.
359

Chapter 12: Advanced Change Package Operations
360
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
361

Chapter 12: Advanced Change Package Operations
362
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).
u s e r g u i d e

Apply CP Backfill Options
Using the Apply CP Command
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
Back
Revisions Only
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.
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 375.
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.
363

Chapter 12: Advanced Change Package Operations
364
The developer working on the code has checked in all these changes and
associated both files with CP 22:1. Development work then continues to
include a further revision to main.c which is checked in at revision 1.3 and
associated with CP 23:1. The main project therefore contains main.c at
revision 1.3 and main.h at revision 1.1.
Aurora_Project
main.c
1.3
Archive for main.c
1.3
1.2
CP 23:1
CP 22:1
1.1 CP 21: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.
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
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.2 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
365

Chapter 12: Advanced Change Package Operations
Apply CP
Procedures
366
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 381.
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 237. For more information on restoring a project, see “Restoring a Project”
on page 240.
At this time, the Apply CP command does not handle change package
entries for rename.
To apply a change package in the graphical user interface
1 From a Sandbox or Project window, 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 207 and “Finding Change Packages Using a
Query” on page 347.
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.
367

Chapter 12: Advanced Change Package Operations
368
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 375.
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, whether open or
closed.
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. Type can be one of the following:
Update is a check in operation
Lock is a check out operation
Add is an add member operation
Drop is a drop member operation
Rename From/To is a rename operation
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.
Note: If Integrity Manager is enabled, you can link directly
to the issue in the Integrity Manager database by clicking
the C.P. ID link.
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.
369

Chapter 12: Advanced Change Package Operations
370
To view the information for a member history, select a member under
the Change Package Entries tab, 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.
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

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.
371

Chapter 12: Advanced Change Package Operations
Apply CP
General Command Option
372
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.
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.
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.
u s e r g u i d e

Apply CP
Advanced Command Options
Ignore Server in Change
Package
Function
Using the Apply CP Command
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.
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 appears.
373

Chapter 12: Advanced Change Package Operations
374
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 375.
The Confirm Change Package Application dialog box appears
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.
NOTE
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 244.
u s e r g u i d e

Using the Resync CP Command
Using the Resync CP Command
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.
NOTE
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 405.
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
375

Chapter 12: Advanced Change Package Operations
Key Resync CP
Concepts
How Resync CP
Works
376
packages that can be used for this purpose. For more information on
resolution change packages, see “Working With a Resolution CP” on
page 397.
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 376
“How Resync CP Works” on page 376
“Resync CP Backfill List” on page 377
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.
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.
u s e r g u i d e

Resync CP
Backfill List
Using the Resync CP Command
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).
--------------------
*** 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.
377

Chapter 12: Advanced Change Package Operations
378
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.
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|#...] ?
379

Chapter 12: Advanced Change Package Operations
380
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.
381

Chapter 12: Advanced Change Package Operations
382
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.
383

Chapter 12: Advanced Change Package Operations
384
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
385

Chapter 12: Advanced Change Package Operations
Resync CP
Procedures
386
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
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.
NOTE
CP 10:1
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.
At this time, the Resync CP command does not handle change package entries
for rename.
To resynchronize a change package in the graphical user interface
1 From a Sandbox window, select the project you want the Resync CP
command to operate on.
2 Select Change Package > Resynchronize Change Package.
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

Using the Resync CP Command
The Resynchronize Change Packages wizard opens, displaying the
Apply List panel.
3 To add change packages to the Apply List, click Add.
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 207 and “Finding Change Packages Using a
Query” on page 347.
The Select Change Package(s) panel appears. The Change Packages
tab is populated with the filter or query results.
387

Chapter 12: Advanced Change Package Operations
388
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.
u s e r g u i d e

Tab Table Columns
Change Package
Entries
Using the Resync CP Command
Type lists the type of operation that was used to
manipulate the listed member. Type can be one of the
following:
Update is a check in operation
Lock is a check out operation
Add is an add member operation
Drop is a drop member operation
Rename From/To is a rename operation
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.
Note: If the Integrity Manager integration is enabled, you
can link directly to the issue in the Integrity Manager
database by clicking the C.P. ID link.
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.
Once you select a change package ID, the Change Package Entries tab
is populated with information on the associated change package
entries.
389

Chapter 12: Advanced Change Package Operations
390
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.
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

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.
391

Chapter 12: Advanced Change Package Operations
Resync CP
General Command Options
392
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.)
u s e r g u i d e

Resync CP
Advanced Command Options
Function
Verbose Provides additional information to track the status of the command.
Using the Resync CP 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.
393

Chapter 12: Advanced Change Package Operations
Resync CP
Advanced Command Options
394
Function
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.
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.
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 appears.
u s e r g u i d e

Using the Resync CP Command
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 appears. Under
the Query tab, information is provided on the operations to be
performed.
395

Chapter 12: Advanced Change Package Operations
396
Under the Warnings tab, information is provided on the change
packages associated with intermediate revisions.
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.
u s e r g u i d e

NOTE
Working With a Resolution CP
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 244.
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
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.
397

Chapter 12: Advanced Change Package Operations
398
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.
u s e r g u i d e

Key Resolution
CP Concepts
Working With a Resolution CP
The process for creating a resolution change package is as follows:
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.
Once all the merge conflicts are addressed, you can check in the
changes to the newly created resolution change package.
After all the changes are checked in, you can then close the resolution
change package, just as you would do for a normal change package.
Apply the change package.
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 399)
an example (see “How Resolution CPs Work” on page 400)
procedures for the graphical user interface (“To create a resolution
change package in the graphical user interface” on page 402)
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.
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.
399

Chapter 12: Advanced Change Package Operations
How Resolution
CPs Work
400
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 newly-
released product. The main goal of this team is to produce bug fixes for
Release 2.0a. The work process for the MDT is:
A bug is reported by a customer.
A change package for the bug is created, in this case it has the
container ID 1204. 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.
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
u s e r g u i d e

Using a
Resolution CP
Working With a Resolution CP
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 changes are checked into the
resolution change package. The resolution change package is then closed.
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
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 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.
Close the resolution change package.
Apply that resolution change package 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
401

Chapter 12: Advanced Change Package Operations
Resolution CP
Procedures
402
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.
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 386).
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.
403

Chapter 12: Advanced Change Package Operations
404
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 392).
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 and check in the files and associate them with the
resolution change package ID. This resolution change package
appears by default as the selected change package.
u s e r g u i d e

Using the Resync By CP Command
9 After you have created the resolution change package, you must then
apply it to your project. To apply the resolution change package,
follow the procedures outlined under “Apply CP Procedures” on
page 366.
Using the Resync By CP Command
The Resync By CP command is primarily a tool for developers. When you
want to resynchronize files in your sandbox, you usually do so by choosing
individual files and then using the Resynchronize (si resync) command.
However, if the files you are resynchronizing have changes that are linked
to other files, the standard resync operation would not include those
related files. To resynchronize all related files, you would have to
manually search for all the changes associated with the change package on
the member you are resynchronizing.
The Resync By CP command automates this process by searching the
change package specified on the member revision you are resynchronizing
and then bringing the changes from the project to your sandbox.
While the Resync CP command searches all files related to a selected
change package, and all the change packages that may be associated with
the related files, the Resync By CP command only processes the change
packages associated with the member you are resynchronizing.
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 375.
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
405

Chapter 12: Advanced Change Package Operations
406
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.
Sandbox - Developer 1
main.c
Project
main.c
Before using Resync By CP in a development environment.
1.1
CP 21:1
1.1 CP 21:1 main.c
u s e r g u i d e
Sandbox - Developer 2
1.1 CP 21:1

Developer 1 then performs the following tasks:
checks out and locks main.c, revision 1.1
Using the Resync By CP Command
makes an update to main.c that requires the main.h file
checks in the changes to main.c and associates these changes with CP
22:1
also against CP 22:1, adds main.h as a member of the project
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
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.
407

Chapter 12: Advanced Change Package Operations
408
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 has been 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 320.
To resynchronize by CP in the graphical user interface
1 With a Sandbox window open, select one or more members that
contain member deltas.
2 Select Member > Resynchronize By CP.
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.
u s e r g u i d e

A P P E N D I X
Views, Windows, and
Dialog Boxes
A
This appendix provides additional information about the views,
windows, and dialog boxess that are available in the Source Integrity
graphical user interface and Web Interface.
409

Appendix A: Views, Windows, and Dialog Boxes
Project and
Sandbox
Windows (GUI)
410
When you open a project or sandbox, Source Integrity displays its contents
in a Project or Sandbox window.
Figure 1. Examples of Project and Sandbox windows.
The Project and Sandbox windows display project members, subprojects,
and subsandboxes in a tree structure. You can expand and collapse a
project, sandbox, subproject, and subsandbox tree using one of the
following options:
Double click the project, sandbox, subproject, or subsandbox.
Click the plus or minus icons in the directory list.
Right click the project, sandbox, subproject, or subsandbox and select
Expand All.
From a Project or Sandbox window, 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.
u s e r g u i d e

Project and Sandbox Windows (GUI)
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 Project and Sandbox windows can be resized within the
Source Integrity application window’s workspace or reduced to an icon in
the application window.
The Project and Sandbox windows also support standard shortcut menus.
Selecting and right clicking a project member in a Project or Sandbox
window displays a menu of actions you can perform on the selected items.
Dialog boxes that you may encounter while working in Project and
Sandbox windows 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.
The information in Project and Sandbox windows 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 76.
Depending on your view preferences, your Project and Sandbox window
displays may be different than the default preferences described here. For
more information on View Preferences, see “View Preferences” on page 59.
For more information on Project and Sandbox window view selections, see
“Project and Sandbox Windows (GUI)” on page 410.
The following list outlines the default column set and what they display:
Name displays the following information:
project or subprojects, for example, project.pj
sandbox or subsandboxes, for example, project.pj
project or sandbox members, for example, demoapp.c
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.
411

Appendix A: Views, Windows, and Dialog Boxes
412
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.
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. For more information on change packages, see
“Using Change Packages” on page 199.
If the Integrity Manager integration is enabled, the change package ID
is displayed as a hyperlink that automatically opens
Integrity Manager to the specified issue. For more information, see
“The Integrity Manager Integration” on page 339.
If the revision has a deferred operation or lock against it that appears
as an entry in the change package, a icon is displayed beside the
change package ID.
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.
u s e r g u i d e

Project Window
(Web)
Project Window (Web)
When you open a project using the Source Integrity Web interface,
Source Integrity displays its contents in a Project window.
The Project window 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 window displays in columns with the
following headings and icons by default:
Name displays the following information:
project or subprojects, for example, project.pj
project members, for example, demoapp.c
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.
413

Appendix A: Views, Windows, and Dialog Boxes
Project History
Window (GUI)
414
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” on page 199.
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.
When you open a project history, Source Integrity displays its contents in a
Project History window. The default view for the Project History window
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 420.
You can apply filters in the Project History window to view and
manipulate a subset of revisions. For information on applying filters in the
Project History window, see “Project History Filters” on page 232.
For information on toggling between the Graphical History view and the
List view in the Project History window, see “Changing Views (GUI)” on
page 424.
u s e r g u i d e

Project History Window (GUI)
The information in the List view of the Project History window displays in
columns with headings. For information on how to configure the column
set, see “Configuring the Source Integrity Column Set” on page 76.
Depending on your view preferences, your Project History window
displays may be different than the default preferences described here. For
more information on View Preferences, see “View Preferences” on page 59.
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.
The Project History window can be resized within the Source Integrity
application window’s workspace or reduced to an icon in the application
window.
415

Appendix A: Views, Windows, and Dialog Boxes
Project History
Window (Web)
Member History
Window (GUI)
416
The Project History window also supports standard shortcut menus.
Selecting and right clicking an archive revision in a Project History
window displays a menu of actions you can perform on the selected item.
When you open a project history, the Source Integrity Web interface
displays its contents in a Project History window.
The information in a Project History window 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.
To open a Project History window, select Project > View Project History.
When you open a member history, Source Integrity displays its contents in
a Member History window. The default view for the Member History
window 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 420.
In the Member History window 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.
u s e r g u i d e

Member History Window (GUI)
You can apply filters in the Member History window to view and
manipulate a subset of revisions. For information on applying filters in the
Member History window, see “Member History Filters” on page 281.
For information on toggling between the Graphical History view and the
List view in the Member History window, see “Changing Views (GUI)” on
page 424.
The information in the List view of the Member History window 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 76.
Depending on your view preferences, your Member History window
displays may be different than the default preferences described here. For
more information on View Preferences, see “View Preferences” on page 59.
The following outlines the default column set and what they display:
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.
417

Appendix A: Views, Windows, and Dialog Boxes
418
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” on page 199.
If the Integrity Manager integration is enabled, the change package ID
is displayed as a hyperlink that opens Integrity Manager to the
associated issue. For more information, see “The Integrity Manager
Integration” on page 339.
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.
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.
Locker Host displays the host name of the computer that locked the
member.
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.
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.
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.
The Member History window can be resized within the Source Integrity
application window’s workspace or reduced to an icon in the application
window.
u s e r g u i d e

Member History
Window (Web)
Member History Window (Web)
The Member History window also supports standard shortcut menus.
Selecting and right clicking a revision in a Member History window
displays a menu of actions you can perform on the selected revision.
When you open a member history, Source Integrity displays its contents in
a Member History window.
To view the Member History window, do one of the following:
select Member > View Member History
click the member name link in the Project window
The information in a Member History window 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.
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.
419

Appendix A: Views, Windows, and Dialog Boxes
Graphical
History View
(GUI)
420
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” on page 199.
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.
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 window. 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.
u s e r g u i d e

Graphical History View (GUI)
Figure 2. 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 windows.
For more information on Member History window filters, see “Member
History Filters” on page 281, and on Project History window filters, see
“Project History Filters” on page 232.
421

Appendix A: Views, Windows, and Dialog Boxes
422
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 has been 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 windows, including where you can find the
corresponding procedures.
Member History Operations
For Operation ... See …
Check Out “Checking Out a Member” on page 163
Check In “Checking In a Member” on page 172
Revert “Discarding Changes to a Member” on page 183
View Revision “Viewing a Member’s Working File or Revision” on
page 291
View Annotated
Revision
“Viewing an Annotated Revision” on page 286
Differences “Comparing Revisions” on page 301
Lock “Locking a Member” on page 186
Unlock “Unlocking a Member” on page 188
Add Label “Adding Labels to Members” on page 266
Delete Label “Deleting Member Labels” on page 267
Promote “Promoting Members” on page 268
Demote “Demoting Members” on page 269
Set Member Revision “Setting the Member Revision” on page 300
Archive Information “Viewing and Editing Archive Information” on
page 282
Revision Information “Viewing and Editing Revision Information” on
page 284
Delete Revision “Deleting Revisions” on page 301
u s e r g u i d e

For Operation ... See …
Merge “Merging Revisions” on page 322
Project History Operations
Graphical History View (GUI)
View Change Package “Viewing Change Package Details and Entries” on
page 211
Merge Branch “Step Two: Merge Branch” on page 313
For Operation ... See …
Add Label “Adding Project Labels” on page 233
Delete Label “Deleting Project Labels” on page 235
Promote “Promoting a Project” on page 235
Demote “Demoting a Project” on page 236
View Project Differences “Viewing Project Differences” on page 244
Open Build Project “Opening a Build Project” on page 233
Create Development Path “Creating a Development Path” on page 141
Remove Development Path “Removing a Development Path” on page 143
Dragging in the Graphical History View (GUI)
Dragging is a unique function of the graphical history view, available only
through the Member History window.
In the graphical history view of the Member History window, you can use
the drag method to merge branched revisions. For more information on
branching and merging, see “Step Two: Merge Branch” on page 313.
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 window open, select View >
Show Labels. The labels disappear from the Graphical History view.
423

Appendix A: Views, Windows, and Dialog Boxes
424
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 window 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 window 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 window 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 windows. If you prefer to view information in these
windows 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.
u s e r g u i d e

Change
Package View
(GUI)
Change Package View (GUI)
For information on setting the default view in the Member History or
Project History windows, see “View Preferences” on page 59.
To view a Member History or Project History in List view
With a Member History or Project History window 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 window 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 Change Package window displays the change package ID, person who
created the change package, description (if one was provided), summary,
date the change package was created, and the current change package
state.
By default, the Change Package window displays the following
information for each change package entry:
Type is the entry type of the change package entry. The possible types
are Add, Drop, Lock, Rename, Update, Deferred Add, Deferred
Check In, Deferred Rename.
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.
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.
425

Appendix A: Views, Windows, and Dialog Boxes
Change
Package View
(Web)
426
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.
Additional columns are available in the client preferences. To change the
displayed columns, see “View Preferences” on page 59.
The Source Integrity Web interface provides you with a Change Package
view.
The Change Package view lists the change package ID, summary, state,
creation date, and the user name of the person who created the change
package. The Change Package view also details, in tabular form, the
contents of the change package (including entry type, project name,
member name, revision number, date changed, and the name of the
Integrity Server the project resides on).
Using the Change Package view, you can also link directly to an associated
issue in the Integrity Manager Web interface. To see the associated issue,
select Actions > View Issue.
u s e r g u i d e

Change
Packages View
Change Packages View
For more information on working with change packages, see “The
Integrity Manager Integration” on page 339 and “To view a change
package’s issue in the Web interface” on page 346.
The Integrity Manager Web interface opens and displays the issue
associated with the change package. Through the Actions menu, you can
also view a revision, a member history, revision information, and member
differences.
The Change Packages 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 206), whereas the Change Packages window displays
all change packages queried (see “Finding Change Packages” on page 207).
By default, the Manage Change Packages window displays the following
information:
ID displays the change package ID.
Issue displays the issue ID if change packages are enabled.
Creator displays the username 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 59.
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 211)
View Issue that is associated with the change package (see “Viewing a
Change Package’s Issue” on page 346)
Submit the change package (see “Submitting Change Packages” on
page 221)
Close a Change Package (see “Closing a Change Package” on
page 219)
Edit an existing Change Package (see “Editing a Change Package” on
page 217)
Create a new Change Package (see “Creating a Change Package” on
page 203)
427

Appendix A: Views, Windows, and Dialog Boxes
Annotated
Revision View
Locks View
428
The Annotated Revision window 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 window, see
“View Preferences” on page 59.
Select an annotation block, then from the History menu, select one of the
following:
Revision Information, see “Viewing and Editing Revision Information”
on page 284.
View Revision, see “Viewing a Member’s Working File or Revision” on
page 291.
View Member History, see “Viewing a Member History” on page 280.
View Issue, see the Integrity Manager User Guide.
View Change Package, see “Using Change Packages” on page 199.
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.
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,
Change Package ID, Sandbox, Development Path. For more information,
see “View Preferences” on page 59.
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.
u s e r g u i d e

Registered
Projects and
Sandboxes
Dialog Boxes
(GUI)
Registered Projects and Sandboxes Dialog Boxes (GUI)
To refresh the list of locked revisions, select Locks > 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 appears.
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.
The Registered Projects and Registered Sandboxes dialog boxes allow you
to open, create, import, and drop projects or sandboxes.
When you switch views from a Registered Projects or Registered
Sandboxes dialog box to another dialog box or window, the Registered
Projects or Registered Sandboxes dialog box is no longer visible, but it is
still accessible from the taskbar.
The Registered Projects dialog box contains one tab, Regular, that displays
projects used for regular development.
The Registered Sandboxes dialog box contains three tabs that display
different types of sandboxes.
The Registered Projects and Sandboxes dialog boxes support 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.
429

Appendix A: Views, Windows, and Dialog Boxes
Registered
Projects
Window (Web)
430
NOTE
Sandboxes based on configured subprojects do not appear with a configuration
icon in the Registered Sandboxes dialog box. For more information on
configured subprojects, see “Configuring a Subproject” on page 126.
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.
The Registered Projects window allows you to view the projects and
project histories that are available on the Integrity Server.
The Registered Projects window displays all regular projects used for
development.
u s e r g u i d e

Registered Projects Window (Web)
To view the Registered Projects window, select Tools > Manage Projects or
click .
431

Appendix A: Views, Windows, and Dialog Boxes
432
u s e r g u i d e

A P P E N D I X
Glossary of Terms
Access Control List See ACL.
B
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.
author name The author name is the name you associate with revisions
upon check in. By default, your author name is your user name.
433

Appendix B: Glossary of Terms
434
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 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.
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.
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.
u s e r g u i d e

Glossary of Terms
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, 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 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 that has been 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.
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
435

Appendix B: Glossary of Terms
436
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 deferred add operation and will be added to the project at a future time
when the operation is submitted. The member is shown as a deferred add
in the sandbox, but not yet shown in the project. A pending member is also
known as a deferred member.
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 window The Project History window 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 window.
Project window The Project window 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 Windows, which list the
u s e r g u i d e

members of the project and provide access to them.
Glossary of Terms
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.
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.
437

Appendix B: Glossary of Terms
438
Sandbox window The Sandbox window 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.
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.
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.
u s e r g u i d e

Glossary of Terms
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.
439

Appendix B: Glossary of Terms
440
u s e r g u i d e

Index
A
access control list
described 31
understanding ACLs 31
access keys
graphical user interface 76
access permission 30
ACL
See access control list
adding
change package entries 205
label
to member 266
to project 233
to revision 290
member
deferred 146
to project 146
subproject 119
administrator
described 1
all members
filter 83, 91
annotated revision 286
any member delta
filter 83
application window
graphical user interface 72
web interface 89
applying change package 349
backfill list 359
backfill option 363
command option 372
GUI command 366
key concept 357
overview 351
process 357
architecture
server 13
archive
information
editing 282
viewing 282
archive description
described 148
assigning
revision description 174
revision number 173
attribute
project 228
Author keyword 197
B
backfill list
Apply CP 359
Apply CP option 363
Resync CP 377
Resync CP option 381
before starting
access control lists 31
access permission 30
Source Integrity 30
binary file 18
comparing 18
described 18
branch
described 306
ignore 384
merge on 383
merging 313
by dragging 316
on check in 311
on check out 319
on resync 320
renaming member on branch 181
starting during check in 172
branching
on check out 306
browser requirements 24
build project
opening 233
build sandbox
creating 131
441

Index
C
442
described 144
canceling deferred operation 191
change
scanning sandbox for 171
change package
adding entries 205
to an issue 345
Apply CP process 357
applying 349
command option 372
GUI command 366
key concept 357
closing 219
creating 203
for an issue 343
editing 217
entry member differences 222
explained 200
finding 207
using query 347
managing 206
methodology 351
resolution
creating 402
GUI command 402
key concepts 399
process 400
using 401
Resync CP process 376
resynchronizing 375
by CP 405
command option 392
example 406
GUI command 386
key concept 376
submitting 221
using to control development 202
viewing 211
associated issue 346
why to use 201
check in 14, 18
check out 14, 17
checking in
member 172
merging on check in 311
checking out
automatic merging on check out 319
branching 306
member 163
checkpointing 19
project 19, 237
CLI 5
described 92
using graphical user interface 93
closing
change package 219
client 70
client session 69
columns
configuring 76
command
ident 196
man 5
option
Apply CP 372
Resync CP 392
preferences 48
syntax 93
viewing 93
command line interface
See CLI
command prompts
described 93
CompanyInfo keyword 197
comparing
project 20
revision 301
working file to member revision 192
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
configuration management 14
configuration options 19
configuring
client environment variable 29
graphical user interface
main toolbar 78
Source Integrity 40
subproject 126
conflict
viewing in Visual Merge 330
connecting
u s e r g u i d e

preferences 43
to multiple servers 39
to server 37
content
reconstructing revision 18
creating
build sandbox 131
change package 203
for an issue 343
development path 141
project 110
report 277
sandbox 131
shared subproject 122
subproject 118
variant sandbox 131
customer support
getting help 8
D
Date keyword 197
deferred item
filter 85
deferred member
described 189
deferred operation 189
adding member 146
canceling 183, 191
checking in member 172
dropping member 158
renaming member 180
resynchronizing 184, 191
reverting 183, 191
submitting 190
deleting
member label 267
project label 235
revision 301
delta
described 18
storing 18
demoting
project 236
revision 293
development
integrated environment 22
object 17
path 21
creating 141
described 139
editing 230
removing 143
viewing 230
difference
project 20, 244
differencing
change package entries 222
third party differencing tool 66
tool preferences 66
Visual Difference 95
editing merge results 328
merging 324
mode 98
panes 97
preferences 99
reverting merge results 328
saving merge results 329
working with 324
discarding
change to working file 183
disconnecting
from multiple servers 40
from server 69
documentation
Integrity Manager CLI Reference
Guide 5
Integrity Manager User Guide 5
Integrity Server Administration CLI
Reference Guide 4
Integrity Server Installation and
Administration Guide 4
man pages 5
online help 5
related 3
release notes 5
Source Integrity Enterprise Edition CLI
Reference Guide 4
Source Integrity Enterprise Edition IDE
Integrations Guide 5
Using MKS Make 5
dropping
member 158
project 114
described 114
sandbox 136
described 136
subproject 129
E
editing
Index
443

Index
archive information 282
change package 217
development path information 230
member 170
attribute 259
information 257
label 262
merge results in Visual Difference 328
merge results in Visual Merge 331
project
attribute 228
information 226
revision
information 284
label 288
enhancements
this release 7
environment variable 86
UNIX client 29
F
features
new 7
file
binary 18
comparing 18
history 15
text 18
working 17
file and object history 15
filter
all members 83, 91
any member delta 83
deferred item 85
existing working files 84
frozen member 84, 91
list
graphical user interface 74
web interface 91
locked member 84, 91
member at label 84, 91
member at state 85, 91
member history
all revisions 281
branched 281
labeled 281
locked 281
member 281
member locked by me 84, 91
member on branch 85, 92
444
member with attribute 84, 92
member with label 84, 91
member with name 85
missing working file 84
modified working file 83
new member 84
new revision available 84
out of sync member 83
project history
all revisions 232
development path 232
labeled 232
using 83
web interface 91
working file on branch 84
working file size delta 84
finding
change package
using query 347
change packages 207
former member
described 158
freezing
member 270
frozen member
filter 84, 91
G
general
preferences 41
graph
Reporter 274
graphical history view 420
changing views 424
dragging and dropping 423
member history window 420
project history window 420
selecting revision 422
view options 423
graphical user interface
access keys 76
application window 72
columns
configuring 76
described 72
environment variable 86
filter list 74
graphical history view 420
member history window 416
member information pane 74
u s e r g u i d e

menu bar 72
project history window 414
project window 73, 410
registered project 429
sandbox window 73, 410
shortcut keys 76
shortcut menu 73
status bar 74
title bar 72
toolbar 73
configuring 78
using in CLI 93
workspace 74
groups
viewing 34
H
Header keyword 197
help
customer support 8
history
file 15
object 15
I
Id keyword 197
IDE
See integrated development environment
ident command 196
ignore branch 384
importing
a project 112
member 155
sandbox 135
installing
Integrity Client 24
UNIX post-install 29
integrated development environment 22
integrations
for Solution
described 340
Integrity Client
installing 24
post-installation on UNIX 29
uninstalling 29
Integrity Manager
integration 340
how works 340
issue
adding entries to a change
package 345
creating a change package for 343
viewing 346
using query 347
Integrity Manager CLI Reference Guide 5
Integrity Manager User Guide 5
Integrity Server
registering project with 14
Integrity Server Aministration CLI Reference
Guide 4
Integrity Server Installation and
Administration Guide 4
interface 71
K
keyword
Author 197
CompanyInfo 197
Date 197
Header 197
Id 197
locating 196
Locker 197
Log 197
Name 197
ProjectName 197
ProjectRevision 197
RCSfile 197
Revision 197
Setting 197
Source 197
State 197
using 194
keywords
table 196
L
label
deleting from revision 291
labeling
member 266
revision 290
launching
Source Integrity 34
line terminator 133
list, backfill
Apply CP 359
Apply CP option 363
Index
445

Index
Resync CP 377
Resync CP option 381
locating keyword 196
locked member
filter 84, 91
making locked member writable 308
managing revision locks 298
view sandbox that locked member 139
Locker keyword 197
locking
member 186
multiple revisions 296
revision 294
Log keyword 197
logging in 36
logging out 69
M
make utility 5
man command 5
manage project
graphical user interface 429
web interface 430
manage sandbox
graphical user interface 429
managing change packages 206
member
adding label to 266
adding to project 146
attribute
editing 259
viewing 259
checking in 172
checking out 163
deferring operation 189
deleting label 267
demoting 269
dropping 158
editing 170
freezing 270
history 17
reference format 18
viewing 280
importing 155
information
editing 257
viewing 257
label
editing 262
viewing 262
446
location 15
locking 186
making locked member writable 308
managing locks 298
name 15
permission 31
project 17
promoting 268
removing from project 158
renaming 180
tip revision 181
resynchronizing 184, 263
reverting 183
revision 17
number 15
setting 300
updating 263
selecting 161
thawing 272
type 15
unlocking 188
updating 184
viewing 170
member at label
filter 84, 91
member at state
filter 85, 91
member history window
filter 281
graphical history view 420
graphical user interface 416
web interface 419
member information pane
graphical user interface 74
member locked by me
filter 84, 91
member name argument
described 93
member on branch
filter 85, 92
member with attribute
filter 84, 92
member with label
filter 84, 91
member with name
filter 85
menu bar
graphical user interface 72
web interface 90
merge
automatic merging on check out 319
automatic merging on resync 320
u s e r g u i d e

on branch 383
merge results
editing in Visual Merge 331
reverting in Visual Merge 332
saving in Visual Merge 333
merging
branch 313
by dragging 316
in Visual Difference 324
on check in 311
resolving merges 336
revision 322
automatically 322
in Visual Merge 331
revision in CLI 335
revision in Visual Difference 324
revision in Visual Merge 330
suspending in Visual Merge 334
metadata 15
methodology
change package 351
missing working file
filter 84
MKS Visual Difference
See Visual Difference
MKS Visual Merge
See Visual Merge
modified working file
filter 83
N
Name keyword 197
new features 7
new member
filter 84
new revision available
filter 84
O
object
control 17
history 15
online help 5
opening
member history 280
project 115
sandbox 138
option
configuration 19
out of sync member
filter 83
P
pending member 189
permission 31
preferences
command 48
connection 43
difference tool 66
general 41
saving 67
setting 40
view 59
printing lists and views 75
process
Apply CP command 357
resolution change package 400
Resync CP command 376
project 14, 17
adding member 146
attribute 228
editing 228
viewing 228, 253
checkpointing 19, 237
comparing 20
content 15
creating 110
deleting label 235
demoting 236
difference 20, 245
comparing current to last
checkpointed 248
comparing current to specified
revision 246
comparing two specified
revisions 245
dropping 114
history
viewing 231
importing 112
information
editing 226
viewing 226
member 17
metadata 15
modification
viewing 249
opening 115
permission 31
Index
447

Index
promoting 235
registering with Integrity Server 14
removing member 158
restoring 240
in GUI 241
viewing 115
differences 244
project history window
filter 232
graphical history view 420
graphical user interface 414
web interface 416
project window
graphical user interface 73, 410
web interface 90, 413
ProjectName keyword 197
ProjectRevision keyword 197
project-specific configuration 15
promoting
a project 235
member 268
revision 292
proxy
configuring 46
Q
quick access keys
access keys 76
graphical user interface shortcut keys 76
quitting
session 69
R
RCSfile keyword 197
reconstructing revision 18
reference format
member history 18
registered project
graphical user interface 429
web interface 430
registered sandbox
described 429
web interface 430
related documentation 3
release enhancements 7
release notes 5
removing
development path 143
member 158
448
renaming
member 180
on a branch 181
tip revision 181
report
creating 277
information 273
type 274
by author 274
by author (summary) 274
member revision to label 275
member revision to revision 275
newer revision 275
project member history 276
revision locked 276
revision with label 276
revision with state 276
Reporter
described 273
graph 274
resolution change package
creating 402
GUI command 402
key concepts 399
process 400
using 401
restoring project 240
in GUI 241
resynchronizing
automatic merging on resync 320
by CP 185, 405
example 406
deferred operation 184, 191
member 184, 263
resynchronizing change package 375
backfill list 377
backfill option 381
command option 392
GUI command 386
ignore branch option 384
key concept 376
merge on branch option 383
overview 351
process 376
reverting
deferred operation 183, 191
member 183
merge results in Visual Difference 328
merge results in Visual Merge 332
revision 15
adding label to 290
annotated 286
u s e r g u i d e

comparing 301
deleting 301
deleting label 291
demoting 293
description
assigning 174
in member history 18
information
editing 284
viewing 284
label
editing 288
viewing 288
locking 294
locking multiple revisions 296
merging 322
automatically 322
in CLI 335
in Visual Difference 324
in Visual Merge 330, 331
number 15
assigning 173
valid 173
promoting 292
reconstructing 18
unlocking 295
viewing 291
viewing locks 298
Revision keyword 197
S
sandbox 14
build 144
creating 131
described 14
dropping 136
importing 135
information
general 251
project attribute 252
viewing 251
opening 138
scanning for change 171
snapshot 253
type 133
variant 21
view sandbox that locked member 139
viewing 138
sandbox window
graphical user interface 73, 410
saving
merge results in Visual Difference 329
merge results in Visual Merge 333
preferences 67
scanning sandbox
for change 171
selecting
member 161
server
configuring multiple servers 47
connecting 37
disconnecting 69
session
closing client 70
quitting 69
shutting down client 70
setting
member revision 300
preferences 40
Setting keyword 197
shared subproject
creating 122
shortcut keys
graphical user interface 76
shortcut menu
graphical user interface 73
shutting down
client 70
snapshot a sandbox 253
Solution integration 340
Source Integrity
before starting 30
concept 13
configuring 40
graphical history view 420
graphical user interface 72
integration with Integrity Manager 340
rules 340
viewing associated issue 346
starting 34
understanding 13
web interface 88
Source Integrity Enterprise Edition CLI
Reference Guide 4
Source Integrity Enterprise Edition IDE
Integrations Guide 5
Source Integrity interfaces 71
Source keyword 197
starting
a session 36
branch during check in 172
Source Integrity 34
Index
449

Index
State keyword 197
status bar
graphical user interface 74
web interface 90
storing delta 18
submit 190
change packages 221
deferred operation 190
subproject
adding 119
configuring 126
creating 118
creating shared subproject 122
dropping 129
suspending
merges in Visual Merge 334
system requirements
web browser 24
T
table
keyword 196
text file 18
thawing
member 272
third party difference tool 66
tip revision
renaming 181
title bar
graphical user interface 72
web interface 89
toolbar buttons
graphical user interface 73
web interface 90
type
report 274
sandbox 133
U
uninstalling
Integrity Client 29
UNIX
client environment variable 29
unlocking
member 188
revision 295
updating
member 184
member revision 263
450
user
described
using
1
filter 83
keyword 194
Using MKS Make guide
utility
5
CLI 5
make 5
V
variant sandbox 21
creating 131
described 139
viewing
archive information 282
change package
associated issue 346
details and entries 211
entry member differences 222
multiple 206
command 93
conflict in Visual Merge 330
development path information 230
general sandbox information 251
group membership 34
member 170
member attribute 259
member difference 222
member history 280
member information 257
member label 262
preferences 59
project 115
information 226
project attribute 228, 253
project attribute information 252
project differences 244
project history
opening 231
revision 291
revision information 284
revision label 288
sandbox 138
sandbox information 251
working file 291
Visual Difference 95
editing merge results 328
merging 324
mode 98
u s e r g u i d e

panes 97
preferences 99
reverting merge results 328
saving merge results 329
working with 324
Visual Merge 101
editing merge results 331
merging revision 331
panes 104
preferences 105
reverting merge results 332
saving merge results 333
suspending merges 334
viewing conflict 330
working with 330
W
web browser
system requirements 24
web interface 88
application window 89
filter 91
filter list 91
member history window
described 419
menu bar 90
project history window
described 416
project window 90
described 413
registered project 430
registered sandbox 430
status bar 90
title bar 89
toolbar buttons
described 90
what’s new 7
working file 17
comparing to member revision 192
discarding change 183
viewing 291
working file on branch
filter 84
working file size delta
filter 84
working file, existing
filter 84
working with project 14
workspace
graphical user interface 74
writable
making locked member writable 308
Index
451

Index
452
u s e r g u i d e