SVN vs GIT (Using Upper Parks in Clarion)

1

Any strong opinions here. I have only used this version control
TortoiseSVN SVN using
Thanks

2

I use SourceTree and pretty happy with it
Sourcetreeapp

1 Like
3

I never felt comfortable with SVN or similar centralized version control systems.
I literally felt less secure with them

Then along came Mercurial (Hg) where it just added a folder of information but left all of the source files alone. What’s more, I can xcopy the folder and now I have a new repository - so when I’m about to do something in the repo, that isn’t routine (and I’m little unsure of myself) then I just make a copy first.

Hg and Git are really quite similar, but I’d say that Git won.
I recommend converting Hg repo’s to Git (which can be done, retaining the full history)

So, do I have a strong opinion on the subject - yup
Just move to Git and be happy about it.

4

I need something to support multiple programmers making changes at the same time.

For years I was the only developer and make local copies every night for versioning on a daily bases - simple TXA/TXD/APP/DCT etc zip files.

5

git is appropriate along the whole spectrum from a single person, to very large groups of programmers.

1 Like
6

As far as my source control addin goes, you can use either svn or git. It supports both. Either way you still need a client for your source control system of choice. My addin is really the “interface” to get your apps back and forth to txa files that the source control system can use.

Having said that, I would go with git all the way! I used SVN back in the aughts and early teens. I’ve been using git now for about 15 years. It is superior in my opinion.

1 Like
7

For application development with multiple developers, Rick’s UpperPark VC add-in is essential — without it, managing Clarion projects under source control quickly becomes a pain. UpperPark doesn’t replace a source control system; it’s the glue that lets you export/import your Clarion app files into text (*.APV/TXA) so that any VCS (like Git or SVN) can actually diff/merge properly. (ClarionHub)

On Git vs SVN:
Like Mark said above, Git is the way to go — it’s modern, distributed, and very flexible for team collaboration, and it handles branching/merging much better than centralized systems like SVN. (ClarionHub)

I’d recommend:

  • Git as your VCS (GitHub, Bitbucket, GitLab, Azure DevOps — whatever fits your team).
  • Keep your repo private.
  • Use a good Git client (SourceTree, GitHub Desktop, SmartGit, VS Code built-in, etc.).

How I structure my workflow:

  • Ignore generated output and binaries via .gitignore/.gitattributes.
  • I redirect Clarion’s generated source to a non-root folder.
  • I put generated CLW files in their own repository so they don’t clutter the main code repo.
  • Make sure templates (including UltimateDebug) aren’t stamping timestamps on every CLW; otherwise you’ll see noise instead of real changes.
  • Export apps via UpperPark so each procedure/module and global settings come out as separate text files — this makes commits meaningful and merges possible. (ClarionHub)

Best practices:

  • Commit often.
  • Use a client like GitHub Desktop or SourceTree so you can review changes and avoid committing unrelated noise — especially with Clarion’s export quirks.
  • Every developer needs their own licensed Clarion and templates installed.

Finally, when you get to the point of setting up .gitignore/.gitattributes, ask here — there are some gotchas with Clarion folders and file types that are worth ironing out early.

2 Likes
8

Fantastic points - thanks

9

I like to see the changes in the generated CLWs; otherwise, it can be hard to understand a subtle TXA change of template parameters. It is the CLW that the compiler uses to create the EXE so very important. Also CLW changes can identify systems with different templates or IDE settings.

The templates reuse some of the same #AT Priority Numbers e.g. 3000. This can cause the generated code to change order a little, when it really does not matter. Or maybe it’s the order it appears in the TXA / APV, or both.

I’m away so maybe someone else can explain. The fix is to change the templates to use unique Priority numbers. I. E. instead of several AT Priority 3000s use 3001,3002,3003,…

One I think I recall was OF EVENT:CloseWindow would move. Since all of its embed code moved with it there was no effect on the execution.

10

Carl

I found that in a multi dev situation putting the clw’s in the same repo as the rest of the sln repo caused issues due to being pulled in from another developer and the the ide not re-generating as expected from the ide, which is why I prefer them to be separate repos.

Maybe I was doing something wrong.

Mark

11

I’m mostly saying I want to see the CLW changes.

If the generated is in the same folder the IDE should update them with new generated code.

12

If you are familiar with TortoiseSVN you may like TortoiseGit.

13

One recommendation that I have, is that if you chat with chatgpt about .gitattributes and which filetypes might be appropriately assigned as LFS ahead of time (before you commit stuff).

If you have to change from LFS to nonLFS or vice versa after stuff has already been committed the other way in the repo, it can be pretty challenging to deal with the conflicts.