Version Control in Clarion?

Hi, i’m looking to get started on a legacy Clarion project and, coming from a Web Development background, was looking into how to manage my code changes. I wanted to use Git but i’ve been told it doesnt work as all Clarion code is compiled into a single file?

How do people manage their development flow, especially if there are multiple developers involved? Apparently the best practice is for each dev to create small template components and then plug it in to the main application at the end?

Any help and advice is appreciated.




Look at Rick’s UpperPark Version Control. You can buy it on and there is a webinar on ClarionLive explaining how to use it.



1 Like

Hello, Ryan

Welcome to Clarion. I think you will find the community of developer very helpful.
If you have a Skype account there are a few active Skype groups where you can ask questions and, of course, here at ClarionHub (the 'Hub :slight_smile: ).

Most Clarion developer works with APP files, which are binary files and do not work well with source control systems.
However, you can export Clarion APP files to a text format know as TXA (Text App).
What my solution does is integrate into the IDE so you can export and import your App files to text files. I break the APP into different files (.APV) for each module in the APP for better granularity. These are the files that are actually committed to source control. Since they are text you can do the normal source control functions like branching and merging.

I have done a lot of webinars on ClarionLive demonstrating and helping users.
You can get a good feel for the workflow by watching the ClarionLive webinar 375. I walk through the whole process of setting up the system.

Some other useful videos on ClarionLive:

Let me know if you have any questions.


Hello Rick,

Does your solution work with Clarion PE or only with the Enterprise Edition ?


Clarion PE is supported by my Addin.
There is no support for building from the command line for automated builds. That is because Clarion PE does not have the /ag switch on the ClarionCL utility. The /ag switch is the “generate App” option.
I have a couple of customer who use PE.

That’s good news,
Thanks Rick

Thanks Rick,

Appreciate the response. My collegue who had previous purchased UpperPark has just shown me it. It looks very promising. We’ve managed to get the application exporting / importing correctly, using Git / Bitbucket to manage our code branches. A couple of questions however:

When i change a single procedure, i get multiple APV files showing up as being changed, when really it should only be one. Do you know why this happens?

Also, how do you manage conflicts / merges? If me and my collegue make changes to the same procedure, and he pushes his code first. Obviously when i go to pull down his code, i’ll get a conflict. How do i go about merging these changes?


Hi Ryan,

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.

1 Like

Hi Rick,

I downloaded the last version from your site, hoping to have the C11 version, but the password provided for the previous version don’t work. Do we have to buy a renewal to have the last version ?


Guy, I just sent you an email with your serial number and maintenance plan.
There is an annual renewal ($40 on ClarionShop), but your subscription is still active.

I’ve just seen your email,
Thanks Rick

Hey @Rick_UpperPark
Is it possible to also use your Version Control for monitoring the Dictionary.
I saw a menu Option by accident for Create Dictionary Files but i cant figure out what it does or how to use it.
Is there a help file i have missed somewhere?

Hi Michael,

Unfortunately, there are some bugs in the dictionary export to dctx format. Specifically, user options can move from one column to another, field pictures getting corrupted, etc.
I can’t really recommend using the dctx format.
The options you found are left overs from C6.x days.

Thanks for the quick response.
Will go back to our current format for managing the Dictionary.
Appreciate the help.