Working File Changes View
Users who add, edit, and delete files directly through the file system can use the Working File Changes view to review a summary of all changes made on disk and to submit those changes to the repository. The view compares the file system against the repository and lists all of the files, folders, and subfolders that have been added, updated, or deleted.
Once you have completed your work, and you are ready to submit your work to the repository, launch the Working File Changes view. From a Sandbox, select > > to access the view.
In the view, select a Change Package by selecting an existing change package from the drop-down list.
Once you have selected a Change Package, select the change entries you want to move to that change package.
• Select entries by clicking on them or by using the cursor control keys to move the selector bar.
• Use the up and down arrows to move through the entries.
• Retain the selection of multiple or concurrent entries by selecting entry check boxes in the far left column of the view.
The Working File Changes view displays all changes on disk and filters out *.bak entries by default.
• To exclude files, folders, and subprojects based on file or directory patterns, select > , and specify the patterns that you want to exclude.
• To exclude specific entries in the view by type, select the View menu and then the exclude option to exclude from the view. For example, to exclude dropped entries from the view, select > . When dropped entries are excluded from the view, a check mark appears beside the submenu. When dropped entries are visible in the view, the check mark is cleared.
|
|
Your customized view filters and exclusions are not saved when you close the view.
|
You can also perform the following operations:
When you are ready to move selected entries to the change package, select > or click the
Move to Change Package toolbar button
.
| You can make changes to working files in build subprojects in an extendable development path. When you move these files to a change package, paths to subprojects with file changes are automatically extended. This assumes that you have extenddevpath permission and that the subproject is eligible for extension. For more information, see Extending an Extendable Development Path. |
Once all of the entries you want to submit have been moved to change packages, select > . For more information on submitting change packages, see
Submitting Change Packages.
| • The Working File Changes view respects the Integrity Lifecycle Manager client Add Members and Create Subprojects command preferences for creating subprojects and creating subprojects for empty directories. It is highly recommended that these create subproject command preference options are enabled when using this view. • Because you are not prompted for any entry types except add member operations in the Working File Changes view, Integrity Lifecycle Manager performs Add Members, Create Subprojects, Drop, Lock, and Move Change Package Entry commands using pre-configured command options. These options can be modified in the Integrity Lifecycle Manager client by selecting > . |
The information in the Working File Changes view displays in columns with headings. Depending on your view preferences, the columns displayed can be different than the default preferences described here. By default, the Working File Changes view displays the following columns.
Column | Description |
Absolute Path | Displays the absolute file path of the file, folder, or subproject on the disk. The Working File Changes view is sorted by Absolute Path by default. |
Change | Indicates the type of change entry on disk: • Additions are indicated by an add icon.  Additions include added non-members, folders, subprojects, or deferred add member entries. • Deletions are indicated by a drop icon.  Deletions include dropped members, subprojects, or deferred-drop member entries. • Updates are indicated by an update icon.  Updates include modifications made to files, files in folders, or files in subprojects. | When new directories are created on the file system, each child is listed as a separate addition entry. For example: C:/Sandbox/newDirectory/File1.txt
C:/Sandbox/newDirectory/File2.txt When adding the children, a newDirectory subproject is created automatically if the Add Member command preference option to automatically create subdirectories is enabled. If the command preference option is disabled, the children are added to the repository in a folder called newDirectory. See Command Preferences. When subprojects are deleted, the view lists a single drop entry indicating that the entire subproject has been deleted. Individual entries for each child are not displayed. For example: C:/Sandbox/Subproject/project.pj When you add a dropped subproject entry to a change package, and you submit that change package to the repository, the entire subproject and all of its contents are dropped. When folders are deleted, the view lists individual drop entries for the contents of the folder. For example: c:/Sandbox/folder/child1.txt
c:/Sandbox/folder/child2.txt
c:/Sandbox/folder/child3.txt There is no corresponding folder drop operation in Integrity Lifecycle Manager. In the Working File Changes view, you can select and drop folder contents yourself or move folder contents to a change package. |
|
CP ID | |
Notes | Additional information about entries indicating that further action needs to be taken before the entry can be moved to a change package or a change package can be submitted to the repository. The Working File Changes view can include the following notes: • Former Subproject Encountered – Changes on disk cannot be identified because the subproject has been dropped from the project. • Pending Add Member Entry – The entry is in a pending added state and does not contain working revision information. You cannot move this entry to a change package, and you cannot submit this entry as part of a change package to the repository. • Out of Sync Entry – Your changes on disk are out of sync with the repository. You can add out of sync entries to change packages but you cannot submit out of sync entries as part of a change package to the repository. Select > to resynchronize this entry, and then refresh this view before proceeding. • Change Package Conflict – Your changes on disk are out of sync with the open change package. You must discard the conflicting change package entry before you can submit the change package to the repository. |
Known Limitations
• The Working File Changes view supports using change packages for submitting source code changes to the repository, and Transactional Change Packages are recommended. Ensure that change packages are enabled on the Integrity Lifecycle Manager server. If change packages are not enabled, the view displays all changes made on disk; however, you cannot use the view to move entries to change packages nor can you submit entries to the repository.
• The view supports a single Sandbox only. Overlapping Sandboxes consisting of one or more subproject(s) having the same name as existing folders or subfolders are not supported.
• The view compares the local file system against the repository. It does not show information on incoming changes available in the Sandbox view.
• The Working File Changes view is not dynamic. It displays updates when you perform operations within the view itself. Any work performed outside of the view (such as in the Sandbox view or through the file system directly) can result in stale view results. Manually refresh the view to display an updated snapshot of the working directory by selecting > .
• Renamed files, folders, or subprojects are represented in the view as dropped and added change entries that do not include persisted history details.
Updating Sandboxes with Third-Party Software Component Source Code
Users can review changes between two versions of third-party software component source code in a specific Integrity Lifecycle Manager Sandbox using the Working File Changes view.
1. On the file system, manually remove all of the files and folders from a specific Integrity Lifecycle Manager Sandbox.
2. Using archival software, unzip the third-party component software you want to compare into that same empty Integrity Lifecycle Manager Sandbox.
3. In the Integrity Lifecycle Manager client, use the Working File Changes view to review all files that have been added, changed, or deleted, and to submit changes to the repository.
| Checksum verification must be enabled on the Integrity Lifecycle Manager server in order to use the Working File Changes view to review changes to third-party software component source code. Checksum verification is enabled by default in new Integrity 10.8 installations or later. For Integrity Lifecycle Manager installations upgraded to 10.8 or later, checksum verification is enabled as part of an internal Sandbox migration process. However, you must also manually resynchronize existing migrated Sandboxes using the --overwriteunchanged option so that checksum information is calculated correctly. For information on checksum verification, see Integrity Lifecycle Manager Client Verification of Checksums. |
