Archive conversion FAQs

Here are answers to some common questions about archive conversion.

What is a brief description of the archive conversion process in Rational Synergy 7.2 and later?

  1. Run the ccm fs_check command and fix all reported errors.
  2. Use the Web Administrator User interface to start, stop, and report on the progress of archive conversion.
  3. Run the ccm clean_cache command after the conversion to clean the cache.
  4. Rerun the ccm fs_check command and fix all reported errors.
  5. Remove the database from the Web Administrator User interface.

If I performed an archive conversion in Rational Synergy 7.1, do I need to perform an archive conversion in Rational Synergy 7.1.0.1?

Yes. Rational® Synergy 7.1.0.1 contains updated archive attributes. Therefore, you must perform an archive conversion when you upgrade a Rational Synergy 7.1 database to Rational Synergy 7.1.0.1.

If I packed a database in Rational Synergy 6.5, do I need to perform an archive conversion in Rational Synergy 7.2?

Upgrading the database from Rational Synergy 6.5 to Rational Synergy 7.2 is not supported. The typical path for the archive conversion is from Rational Synergy 7.1 to Rational Synergy 7.1.0.1 to Rational Synergy 7.2. You can perform a direct archive conversion of a Rational Synergy 7.1 database in Rational Synergy 7.2.

Do I run the fs_check command to clean the cache while the archive conversion is in process?

The ccm fs_check command is responsible for checking that the metadata, cache, and archive portions of a database are consistent.

In Release 7.1 and later, the ccm fs_check command performs an extra check for existing archives and for static versioned objects.
  • If a versioned object that was recently checked in does not have an archive, the archiver has not processed the object. This behavior is normal and is not an error.
  • If an object was checked in without an archive for a longer time than specified by a user, it is a possible error because the archiver might not be running. You receive a warning message.
  • The ccm fs_check command contains a new -c|-cutoff cutoff time option. Any object versions that are checked in before the cutoff time but are not archived produce warnings. The default cutoff is two days, -2:0:0:0. You receive a warning for any files that have not been archived but were checked in earlier than the day before yesterday.
  • After the archive is checked, the check for unused archive files process uses less memory than it did in Release 7.0 and earlier.
Before you start the archive conversion, run the ccm fs_check command. Then, fix all the errors or warnings before you proceed with the archive conversion. To fix any problems, run the ccm archive_fix command. Here is one example of a warning message that displays when you run the ccm fs_check command:
-------------- 
SERIOUS: Extracted archive and cache files differ for
four_part_name_of_object
Cache file path: path_to_cache_file
Cache file size: size
Extracted file path: Extracted_file_path
Extracted file size: size
Archive path: path_to_Archive_file
Archive version: archived_object_version
Source modify time:  modify_time_of_source
---------------

In this example, the archive and cache sources are not correct. Either the archived version is correct or the cache file is corrupted or vice versa.

If the source looks correct in Rational Synergy, then the cache files contain the correct data and the archive is corrupted.

Compare the files to determine which one is correct. This type of corruption requires manual work to resolve it.

Examples:
  • Run the ccm archive_fix command in Rational 7.1 and 7.1.0.1:
    -----------------------
    
    ccm archive_fix /i input.txt /l output.out
    
    ------------------------
    
    NOTE: Input.txt has details of all the files or objects which need to be fixed. Objects specified should be in four-part name.
  • Run the ccm archive_fix command in Rational 7.2:
    ------------------------
    ccm archive_fix –ort four_part_name_of_object 
    ------------------------

After you fix the errors, convert your archived data.

How does the Rational Synergy administrator check the status and progress of the archive conversion from the command line?

On the command line, run this command to show the archive conversion status:

ccm info -f "Level=%level, total=%total, unconverted=%unconverted, errors=%bad" archive_conversion-1:admin:base

The level attribute on the admin object shows the last complete archive conversion level where:
  • 0 or non-existent: the database contains GNU/BSD archives
  • 1: the database contains 7.1 archives but does not contain GNU or BSD archives
  • 2: the archives are at version 2, with delta compression

Why does a database display on the Archive Conversion tab in the Web Administrator User interface after the archive conversion is completed?

All new archive files are created in the database_path/st_root/archive/ccm_delta directory. When the archive conversion is complete, only the ccm_delta subdirectories should be in the database_path/st_root/archive. Run the ccm fs_check command after the conversion to detect all errors.

If other subdirectories exist, manually remove them and rerun the ccm fs_check command. The command must not detect any errors.

For example, here is a warning about unused archive entries that the ccm fs_check detects:
INFO: unused archive entry
Archive file path: database_path/st_root/archive/source/project/ccm_rcs/1/36/editor,v
Revision number: 1.1

You can restart the conversion process from the Web Administrator User interface. See Converting archived data.

Do I perform an archive conversion if I unpacked a new database in Rational Synergy 7.2, Rational Synergy 7.2.1, or Rational Synergy 7.1.0.1?

No. The unpacked database contains the latest archive in these versions of Rational Synergy.

Can I speed up the archive conversion process?

In the CCM_HOME/etc/ccm.server.properties file, edit these lines to reduce the values of the asynchronous.archive.query.poll and the asynchronous.archive.startup.delay variables.

# asynchronous.archive.query.poll is the number of seconds
# to wait before performing a query for objects which
# require archiving
#asynchronous.archive.query.poll = 300

# asynchronous.archive.startup.delay is the number of seconds
# to wait before the first query for objects which require
# archiving. If not set, the value of asynchronous.archive.query.poll
# is used.
#asynchronous.archive.startup.delay = 300

There are the two processes: the converter (which is really an unarchiver) and the archiver. The converter spends most of its time waiting for the archiver to catch up. You can reduce the time for the query poll so that the archiver does not wait 5 minutes before it starts another archiving batch. Set the value to 60 seconds. Make the same changes to the startup delay. Then, the converter spends less time waiting for the archiver to catch up. When the conversion is finished, restore the delay values to 300.


Feedback