How can more than one developer work on the same app at the same time? Presumably C11EE solves part of this, but what else is needed?
I have suddenly been told that “my” project needs another 2 developers. How do I set this up?
@Rick_UpperPark sells a really nice version control addon. It works very well for multi-developers in same app. You can buy it at Clarionshop.com. Search for “Upper”
2 Likes
There is nothing “native” to Clarion that allows for this. As mentioned UpperParks has a set of templates that help. I work on several multi developer projects and we just decided that only 1 developer can work on a DLL at a time to keep things simple. But you can also TXA to procedure being worked on.
It would be great if Clarion got rid of the APP and used TXAs for everything. Or XML or some other texted based source system.
1 Like
Thanks guys. Has anyone actually used these templates for a multi-developer project? I would be interested in hearing your experience.
I’m busy watching the CIDC2017 presentation and the ClarionLive 375 presentation is busy downloading. These are mentioned in the ClarionShop entry.
I don’t know of a template that comes with it, but it’s an addon for the Clarion IDE. It exports an app to individual txa files for each procedure. When the txa (with an APV extension) are committed into a repo), individual procedures can be worked on and committed.
You kinda have to be careful not to step on each other’s toes, especially if global options are modified.
You also have to be mindful of WHICH stuff needs to be committed. But it’s not a big deal once you figure it out.
It makes something that was not possible, possible. There are quirks about the txa’s, but not bad, and no fault of Rick’s addon.
Your wish is granted.
Under Options – Clarion – Auto Export/Import: you can set the IDE to also save APP as APV which is a TXA format, and DCT as DCV in DCTX format. The APV/DCV are the primary file so at load time the APP is ignored and built from the APV … or maybe it does a date compare and only makes the APP if it appears older than the APV.
This means your APP cannot have TXA issues like a Square bracket in column 1 of embed code. One export / import TXA and compare CLWs will tell you.
The Feb 2019 Clarion 11.13371 release made it possible to configure this with a file in the folder so each developer did not need to config their IDE. I think this may work in older releases.
FEATURE: Adding a .dct.BinaryImport file into a directory will turn on automatic import/export for dct files. Similarly the existence of a .app.BinaryImport file will turn on import/export of app files. This file can be empty or contain multiple lines with each line being a file pattern to match files. If the file is empty, then all dct/app files will be imported/exported. Otherwise only files that match at least one of the file patterns will be imported/exported.
Do full APP TXA’s work well for Source Control is a separate question. Unless PRIORY is made unique in the TPLs the code can jump around. It can be ugly to understand TXA format changes. I would also check in generated CLWs. When I last did this we decided to always replace the full APV and not try to store deltas. I think that was with Source Gear.
There are some other posts here. Search for APV or Source Control or Version Control.
Donn if you can work like Kevin describes where you agree that only one person works on an APP this can work, at least to get started. Rick’s way is the best for multiple active devs.
3 Likes
@CarlBarnes Awesome!
I have a lot of catching up to do and thank you for the posts. Part of my problem being so new to Clarion is that half the time I don’t know how to phrase my questions. So I didn’t think of searching for “Version Control”. :facepalm:
Thanks Carl;
Never knew that - it it 1000% stable? 
I’ve been a single developer for so long it may be hard to change (old dog syndrome)
I used it with 4 other Devs in other locations and it worked. Search here and PTTS for APV and you will find some bugs fixed.
As a single developer it’s nice to check your code in (commit push) and have a history and backup. Also share/ sync / push / pull between desktop and laptop.
There is some coverage in the Help
http://clarion.help/doku.php?id=softvelocity_binarytotext_importexportpanel.htm&s[]=apv
From a personal standpoint. @Rick_UpperPark Tool are the way to go.
I tried the SV APV options as described by @CarlBarnes but in the end Ricks tool help a little more than that.
The only real issue is on the SV side with what gets exported to an APV (TXA) . ie. Change a procedure etc. and sometimes when you export the APV’s and go to commit your changes, so many more procedures look like they have changed, rather than the one.
As long as all the dev’s are aware to commit often and just commit the changes they made, then this will not be a problem i.e. if you know you only changed one procedure but when you use the tool to export all 300 procedures show changes, just commit the procedure you changed. This will be the same with the SV stuff @CarlBarnes described.
Once you get used to how Git works, you will wonder why you never did this before.
Note, it used to be a case that GitHub was never free for private repositories. It is now. I used to use BitBucket for private repos but now use GitHub.
Regards
Mark
I mostly agree with all of the responses.
@Rick_UpperPark Tool works like charm. I use it every day @DonnEdwards
Thanks everyone for the positive comments.
Of course, I’m biased for my solution …
I found problems and have a number of PTSS reports on the built-in auto import/export feature.
To me one of the other main differences, is with the built-in auto import/export you are still committing the entire APP as a single text file. This doesn’t give you much granularity if you have multiple developers working on the APP. You will have conflicts with just about every commit. Working with each module as a separate file committed to source control you have significantly less conflicts and chance of two developers working on the same file. My solution works on the module level.
There are teams from 2 to 17 developers using my source control addin.
2 Likes
This hasn’t been offered or spoken about, so I’ll add it.
With version control, you have to check-in and check-out modules to work on them. I did that for 7 years working on mainframe applications. It works fine but there’s another way to do the same thing.
I work as an independent developer now with Clarion, but if I worked on a team, I would set up Clarion on my development cloud server for all of the developers to access. Each developer can have their own work area and submit tested units to the common area. They can work on their local computer and/or work on the server.
I would have my applications as multi-DLL, at least as many app files as team members, because that’s the only way to split up an application.
Of course, when the dictionary needs to be changed, then only one developer does that and notifies the team. This makes it pretty easy to control and efficient for the team to develop and test the application.
Of course if the team is in the same room (all the time), you probably don’t need a cloud server. But if a team is working from their homes or in different cities, a cloud server is the way to go. (It is then real easy to move it to the production cloud server).
1 Like
Using Source Control is more than just sharing dev files. It adds a history so you can see the changes made by each developer, branching, more …
The Joel Test summaries it well:
1. Do you use source control?
I’ve used commercial source control packages, and I’ve used CVS, which is free, and let me tell you, CVS is fine . But if you don’t have source control, you’re going to stress out trying to get programmers to work together. Programmers have no way to know what other people did. Mistakes can’t be rolled back easily. The other neat thing about source control systems is that the source code itself is checked out on every programmer’s hard drive — I’ve never heard of a project using source control that lost a lot of code.
1 Like
Yes, there is that too. It will show for example which lines were changed by whom and when. Typically you would also provide references to change documents.
This is a super-necessary requirement for applications that are in most applications e.g. public utilities, banking, military, security.
1 Like