You can convert binary openssl output to base64 and write that to file:

cmd=$$$FormatText("openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign %1 %2 | base64 > %3",fileKey,fileMsg,file64)

base64 is available in most linux flavors, and on Windows in various GNU CoreUtils builds and in Git (usually under C:\Program Files\Git\usr\bin\).

 

Also in an a business operation filenames should be generated randomly (probably via ##clss(%File).TempFilename(ext)) to avoid conflicts.

Export relevant globals to xml file(1 file per namespace) and compare hash sums. Also there's a lot of tools to display XML diffs if hash sums would differ.

Otherwise it's per global iteration and compare. I'd write some method to calculate global hash maybe (complete iteration and hash of keys and value). So:

  • Get lists of globals in both ns
  • Iterate over lists, and calculate hashes for each global separately
  • Compare lists (iterate over one list and delete each same value from both lists, all that's left is diff)
  • Report if global is in one list and not in the other
  • Report if global hashes differ across lists
  • (Optional) Display detailed compare for globals with different hashes

There's no need to search for the /s1/s2/s3 in the second template, as the first template would send every node into the second template. So your XSLT should probably look like this:

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:output method="xml" indent="yes"/>
     
    <xsl:template match="//@* | //node()">
        <xsl:copy>
            <xsl:apply-templates select="@*"/>
            <xsl:apply-templates select="node()"/>
        </xsl:copy>
    </xsl:template>
    
    <xsl:template match="//s3" >
        <xsl:copy>
            <xsl:apply-templates select="@*"/>
            Content Replaced
        </xsl:copy>
    </xsl:template>
    
</xsl:stylesheet>

I think the most important part of source control file structure is mirroring package structure in Studio, since that is the view we spend the most time with. That said it looks something like this:

root/
    Package1/
              Class.cls
              Class2.cls
              Routine.mac
              Include.inc
     Package2/ 
              Class.cls
              Class2.cls
              Routine.mac
              Include.inc

Additionally:

  1. Web app should be stored in a separate repository.
  2. If there's docs/dictionaries/etc, then all sources should be in a /src folder instead of repository root.
  3. All libs/modules/etc should be moved into their separate repositories each and plugged in as a submodules.
  4. Builds, if any should not be stored in a repo but rather meta-managed (releases).
  5. Commit messages and granular commit history is one of the most helpful things when analysing project history, enforce commit message style (title is the most important i.e. PART/SUBPART - thing done in a commit).