Subversion - T24

Hi

Has anybody implemented Subversion version control on a JBase / Universe GLOBUS / T24 site?

What files? How?

We have been spending time for this version control. As always with t24 there are no easy answers.
You need to do a mixture of steps to get near to versioning (complete versioning will still not be possible).

1. T24 has its own versioning system for entities like versions, enquiries etc (Remember the HISTORY FILES, and the AUDIT Fields!!)
2. Changing of a parameter 'Date Time Mv' TO YES IN spf'S SYSTEM RECORD ALSO insures that with each record update iteration the change date time is also saved with the iteration. But this has it's own issues
2. The local development should then be managed by SVN but here it should be clear that user access management to repository can be a very hectic process specially if the enviroment has a development team of more than 5.
3. A process for deployment of new BCONS should be devised as per company requirements which will document and version each BCON being deployed.

Following of the above three steps will not guarantee true version control but can bring you closer to it. and this is because of the current T24 architecture which has no doubt a strong audit control but no version control which it should as afterall infobasic is their language.

Thanks for that, Saahmad!

So far we've worked out that the files that are most important are the BP file (Basic Programs) and PGM.FILE, FILE.CONTROL, and STANDARD.SELECTION, in terms of a rollback. Data itself is irrelevant to some degree.

So what we've done (or are in the process of doing) is to relocate all these files of all the accounts we have on the system into one directory structure, with a central TRUNK containing a system that is currently live. We have different teams working on different modules at any one time.

So the theory is that whoever needs a module to work on will book it out of the central repository for that client into their own copy of the live system. Once the development is complete it is merged back into the trunk. Where other teams have completed tasks in the meantime and have also merged back into the trunk and common differences dealt with immediately (before teams get re-allocated to other development work.

I guess this is a standard approach for version control.