Side effects of COMPRESSDELTA and COMPRESSWORKIMAGE directives

Question

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

Mark Davis · Accepted Answer

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

Richard Gering · Answer

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.

Menu

PVCS Discussions

Verified Answers

Side effects of COMPRESSDELTA and COMPRESSWORKIMAGE directives

Top Replies

Suggested Answer

Resources