This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Side effects of COMPRESSDELTA and COMPRESSWORKIMAGE directives

Are there any negative side effects in the use of these directives for binary source files stored in PVCS archive files?

We've noticed problems when deleting the latest revision that that the remaining 'latest' revision is different than what was originally checked in there. Our workaround has been to instead fetch that earlier revision (tip - 1) and simply check it back in as the new 'latest revision'. iow we don't delete PVCS revisions for binary source files.

The above has led me to think that we simply don't have the correct PVCS config directives )specified per source filename extension) in place for binary source files.

Mark

Parents
  • 0

    We currently have the following set for one particular file type (.xdm):

    ARCHIVESUFFIX .xdm = zdm
    COMPRESSDELTA .xdm
    COMPRESSWORKIMAGE .xdm
    NOEXPANDKEYWORDS .xdm
    NOTRANSLATE .xdm
    NOGENERATEDELTA .xdm

  • Suggested Answer

    0   in reply to 

    Hello Mark,

    Compression is intended for source code, so I would not recommend using it on binary files.

    The COMPRESSDELTA directive should get ignored as NOGENERATEDELTA is in effect, so each revision is a complete copy of the workfile. COMPRESSWORKIMAGE should still play a role, but there should be no difference between deleting the TIP revision and then getting the new TIP versus getting TIP-1, as both end up pointing to the same revision contents (because you don't have deltas in the archive there is no need to recompute the TIP). If you can reproduce this issue, for example using a backup copy of the archive where you previously saw this behavior, please submit a case for investigation with a sample archive.

    It is important to know that the directives in a CFG file only affect the archive attributes being applied to new files. Existing archives will use the attribute that are embedded in those archives, which can be seen using Show History or the vlog command. Changing those attributes requires using one of:

    • Admin | Archive Attributes (Desktop Client GUI)
    • pcli SetArchiveAttributes
    • vcs

    (See KB doc https://knowledgebase.serena.com/InfoCenter/index?page=content&id=S122399)

    Based on that I recommend checking one of the affected archives to confirm its attributes match your current CFG file default.

    From an archives size / performance perspective, the best choice is to use split archives on a File Server with NOGENERATEDELTA (still) in effect, but not using COMPRESSWORKIMAGE. In this configuration file I/O will only every contain a single revision, and the archive will have no size limit (though individual revisions in the archive are still limited to 2GB each).

    Kind regards,

    - Richard.

  • Verified Answer

    +1 in reply to   

    Thanks for the all the details Richard!

    I'm afraid that this is with a version of PVCS that is no longer supported. (We're still trying to migrate to a cloud-based system which will include a current version of PVCS. It could be months (or more!) before we go live there.) We've gone quite some time using our 'no delete' work around, but whenever I've explored this the binary file revisions that resulted have always been different after deleting the TIP.

    The PVCS directives are in place in the archive. I had hoped that this might have been a directive-related issue.

    What I found in this particular instance was that in the scenario where the TIP is deleted, the resulting TIP revision had 3 bytes prepended to the extracted binary.

    HEX    8D  00 00
    DEC   141  00 00
    OCT   215  00 00

    Since this version of PVCS is dated, we'll move on and continue with the workaround. But if I get a free moment, I'll try the same on our 8.6.2 version of PVCS (not yet in production use). 

    Thanks again,
    Mark


  • 0   in reply to 

    Thanks, Mark!

    I'm very interested to learn whether VM 8.6.2 (or the current VM 8.6.3 + 8.6.3.2 patch) has the same issue, as we'd want to look into solving this problem if it still exists.

    Please keep me posted :-)

    Kind regards,

    - Richard.

Reply
  • 0   in reply to 

    Thanks, Mark!

    I'm very interested to learn whether VM 8.6.2 (or the current VM 8.6.3 + 8.6.3.2 patch) has the same issue, as we'd want to look into solving this problem if it still exists.

    Please keep me posted :-)

    Kind regards,

    - Richard.

Children
No Data