Unfortunately, there isn’t much we can do about the random changes in the APV files for procedures you did not change. The export just does it. It is one of the most frustrating parts of source control and Clarion.
I am going to see if I can code my process that breaks up the main TXA to the individual APV to recognize some of the more common random changes and eliminate them.
There are two schools of thought. One is to discard changes to any modules that the programmer knows he did not modify. Then only committing the modules with intentional changes. This is nice because the commits only contain actual work. This method also reduces potential conflicts with other developers because less superfluous changes are committed. However, it is more work for the developer because they need to remember/review modules to determine whether they want to discard or not.
The other method is to commit the noise because the IDE will often keep exporting the noise and you’ll have to confirm whether you made changes to a module many times as you export your work.
I have clients who use both methods and I adhere to which ever method they prefer when working on their code.
My personal preference falls in-between the two. If the noise is something like a new template prompt, let’s say you upgrade WinEvent and there is a new prompt. That is going to get added to every procedure in the APP. I’ll go ahead and commit these changes for all the modules, because the IDE is going to continue update the APV files with the new prompt every time it is exported.
If the noise is difference in the empty TIMES entries in some of the structures, I’ll discard these changes if I know I didn’t change the procedure. It’s a bit of a pain, but it does keep the commits cleaner and it’s likely the IDE will change the exact same thing again at another time which creates more superfluous commits.
Either way, the noise doesn’t make a difference when importing back to the APP format.
I would not recommend trying to look through the APV file and trying to only keep your modification and trying to get rid of the noise. That’s likely to create problems. Just commit the whole module or not.
Merge/conflicts are handled by the source control client you use, just like non-Clarion code. The main thing to remember is you have to re-import the APV files to the APP whenever you pull changes from another developer. Also, make sure you have exported any changes you have made before pulling and merging changes from the other developers.
I use Git for source control and SmartGit as my client.
Let me know if you have any other questions.