The use cases for custom file migration and resulting backup and merge activities are described in Custom file migration use cases .

Note:

<file_name> with no extension represents a base file that is present under the BASEDIR/smarts directory of the new installation.

Table 1. Custom file migration use cases

Use case

Backup action

Merge Action

User action

Old installation

New installation: BASEDIR/smarts/.migrate.bkp.<version>

New_installation:BASEDIR/smarts/local

There is a local copy of a file, and changes were introduced by you. The file is also used in the new base installation.

Back up the base and the local copies of the file. The base copy is backed up with “base” extension, as

<file_name>.base.

The local copy will be backed up with “local” extension, as

<file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

Run sm_merge for:

  • <file_name>.base

  • <file_name>.local

  • <file_name>

Merge Outcome:

  • Changes made by you are merged into the new file and placed in <New_installation>/smarts/local/<file_name>.conf

  • If the changes made by you could not be merged without a conflict, a .conflict file is generated and placed in <New_installation>/smarts/local/<file_name>.conflict

  • Because the three-way merge utility works at a string level and not at a code level for files such as .asl, .xml, .cmd, and .sh, the merge result of these files is appended with .automerge extension. Review the files, and if the changes are acceptable, save the file without .automerge extension.

  • Files with .import and .conf extension are not appended with an automerge extension on successful merge.

  • For conflict files, review the conflict file, manually resolve the conflict, and save the file without a .conflict extension.

There is a file in old base, old local and the same file exists in new base.

No backup action.

No merge.

No user action required.

There is a file in old base and the same file exists in new base.

No backup action.

No merge.

No user action required.

The local copy of the file that was introduced by a patch and later modified by you. The file exists in the new base, but does not exist in the old base.

Back up the local copy of the file. The local copy will be backed up with “local” extension, as

<file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

sm_merge utility will compare <file_name>.local and <file_name>.

Merge Outcome:

<file_name>.conflict

Review the conflict file, manually resolve the conflict and save the file without a .conflict extension.

There is a local copy of the file, and changes were introduced by you, but the file is no longer used in the new release.

Backup the base and the local copies of the file. The base copy is backed up with “base” extension, as

<file_name>.base.

The local copy will be backed up with “local” extension, as

<file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

No merge

The files remain in the backup directory. Determine if the customization is still relevant to the new installation.

The local copy of the file was introduced by a patch, and changes were made by you. The file does not exist in either the new or old base.

Backup the local copy of the file. The local copy will be backed up with “local” extension, as <file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

No merge

Determine if the customization is still relevant to the new installation.

There is a local copy of the file, and changes were made by you. The file is also used in the new version, and there is already a local copy of the file in the new local.

Backup the local copy of the file. The local copy will be backed up with “local” extension, as <file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

No merge

The sm_merge gives precedence to the files in new_local. No changes will be made to the files that are already under new_local.

Key exceptions to the rule are covered in the “Migration of security configuration files” on page 93.

There is a local copy of the file, and custom code was introduced by you. This code does not exist in either the old or the new base.

Back up the local copy of the file. The local copy will be backed up with “custom” extension, as <file_name>.custom.

No merge.

Copy the files (without the .custom extension) from New Installation: BASEDIR/smarts/.migrate.bkp.<version> to New installation: BASEDIR/smarts/local

Determine whether these custom files are still needed in your new installation.

There is a local copy of the file, and custom code was introduced by you. This file is also used in the new base.

Back up the local copy of the file. The local copy will be backed up with “custom” extension, as <file_name>.custom.

No merge.

Copy the files (without the .custom extension) from New Installation: BASEDIR/smarts/.migrate.bkp.<version> to New installation: BASEDIR/smarts/local

The file is copied with .<old_version> extension.

Determine whether these custom files are still needed in your new installation.

There is a local copy of the file, and changes were made by you. The file is also used in the new version, and there is already a local copy of the file in the new local introduced by a patch.

Back up the base and the local copies of the file. The base copy is backed up with “base” extension, as <file_name>.base.

The local copy will be backed up with “local” extension, as <file_name>.local.

Local name will be customized name of local.

For example: <file_name>.local123.

Run sm_merge for:

  • <file_name>.base

  • <file_name>.local

  • <file_name>

Merge Outcome:

  • Changes made by you are merged into the new file and placed in <New_installation>/smarts/local/<file_name>.conf

  • If the changes made by you could not be merged without a conflict, a .conflict file is generated and placed in <New_installation>/smarts/local/<file_name>.conflict

  • Because the three-way merge utility works at a string level and not at a code level for files such as .asl, .xml, .cmd, and .sh, the merge result of these files is appended with .automerge extension. Review the files, and if the changes are acceptable, save the file without .automerge extension.

  • Files with .import and .conf extension are not appended with an automerge extension on successful merge.

  • For conflict files, review the conflict file, manually resolve the conflict, and save the file without a .conflict extension.