Version Control

I believe there is a semi-supported downloadable thing called the work area synchronisation on github. 

https://github.com/uniface/WASListener

I haven't implemented it, as we've been managing without version control for years (Since we migrated from U8 to U9) and I haven't the time to work out how to do it, but it is on my list for that far flung day when I'm not chasing after customer requests.... 

Regards, 

Iain

Interested too. We are in the process of implementing UD6 so we can use git. Doing that on U10.04.
I still think this is something that should be natively possible:  to use filebased sourcecontrol.
UD6 seems like a good option, but very expensive, and I hate that we have to rely so heavily on a third party for sourcecontrol, Uniface upgrades, etc ...
Tried WASListener also, but that's not a setup we can use with the different branches we support. Settting up multiple databases on each developers portable is just not the same a s pulling a directory with files in it :-)

Hello all,

As Sogeti Netherlands, we have been using the UD6 driver for several years. The files, which are thereby created, have been and are put into a version control system. Initially this was Subversion, but since about three years we have been using Git. For bringing the sources into the version control system, we do not use the functionality available within UD6.

Each developer has its own development environment. In addition, an environment is set up for the compilation and delivery of the components for the other environments (test, acceptance and production). The developer is responsible for keeping the sources up to date. This works adequately for our team, consisting of two active developers and a developer who can help out when needed. 

We also collaborate on maintaining an application at a client's site. Here, there is no version control. Also, there is in fact a development environment in which all developers work. A change in a component is immediately available to the other developers. This is actually not a desirable situation.

We are also looking at whether the WASListener could be a replacement for the UD6. As far as I can see, another "database" must always be present for the repository. This is not necessary with the UD6. Another disadvantage is that the software for this needs to be started separately.

We would actually like to see the functionality provided by the WASListener returned within Rocket Uniface itself, so that no separate software needs to be started, but that this is taken care of immediately when starting the IDE. This is then on top of the current working method via a "database".

Hi Knut!

Of course UD6 is still around and stores your Uniface source code in text files rather than SQLite or Oracle.  Once your source is in text files, you can version control easily.  

We've been providing this integration with Uniface for 24 years or so...

In the past we didn't provide any GUI - the old Uniface 7/8/9 had the 'additional menu' but Uniface 10 doesn't seem to have anything similar.  So for the past couple of years we've included a simple GUI.  It was a bit limited (to GitHub enterprise) and the next release of UD6 will include support for GitHub cloud - here is a quick look:

https://youtu.be/ruvsNYpa6Rc

Lots more info over on https://theu.info

Any questions please email sales@march-hare.com

Hi Arthur,

Long time no hear, no speak!!

We currently have the UF SCCI driver - which we've paid for, and continue to pay Maintenance for.

Given that UF / Rocket haven't made anything available in UF 10.03 or 10.04 (so far) lead me to believe

1) There is an absolute reason to cancel the maintenance aspect of this.
2) If UF is (still) to be considered an Enterprise Development Environment - then, surely
    it should stand to reason that a SCC interface was indeed natively offered as a part of the
    development environment.
3) Where is the "Official" statement from UF / Rocket on this?

Time to place the keyboard on the shelf for the weekend.

Regards,

Knut

Knut,

My many discussions with the Uniface team over the years can be summarised as: we think UD6 is a great tool for customers who want additional functionality beyond what Uniface provides.

Uniface is unique in the 4GL/NOCODE world in just how open it is, and how many API's they provide.  They provide these API's so customers and ISV's can use the API's to make the product more useful.  In my experience, products that provide API's for developers to extend the functionality are always more successful in the long term than products that do not.

So in short - I think you won't find an "official statement" from Rocket or Uniface or Compuware, because it's in the documentation: The Database API.  The many API's exist for a reason, and that reason is that every function you can ever imagine is NOT going to be supplied in-built, but the vendor do provide a way to add functionality for those who want it.

Here is a bit of the history of how UD6 came into being and my take on the difference between UD6 and other solutions:

I was involved in a few change management implementations pre Y2K that all failed, including Uniface SCCI and VCLink ones.  I went looking for answers as to why the projects failed.  I found research by the Configuration Management Institute (part of Berkley) back in the late 90's early 00's, that showed that for change management to be effective, it must ensure the integrity of all managed items in each development stage, and make their evolution more manageable, and their interrelationship clear.  The effectiveness can be improved by implementing automated techniques for Insulation, Security and Access Control, Lifecycle Management, Communication and Detailed Reporting. 

The VC-Link and SCCI solutions cannot ensure the integrity of all managed items, because they rely on version controlling a COPY of the source, not the actual source.  Regardless of whether you are just paranoid, or you have developers who make changes to the meta dictionary with SQL or fast forms, the developers seem to have an instinctive reaction to NOT TRUST the version control.  The only solution I found was UD6 - a database that stores your source code in text files.  The text files are literally the rows of the database.  You can make bulk changes or use the IDE, but all changes are always captured.

If you are in a large organisation, storing your source code as text files also allows you to use the same tools and processes as other development teams with traditional languages, you can use build management tools, continuous integration, etc. etc.  Whilst change management mostly represents a cost / an overhead, these other areas provide ways to improve the development/operational productivity and provide a return on investment.  But I think the biggest advantage is that it just makes Uniface more visible in the organisation, and reduces the mystery of it.  I know one customer who even wrote their own IDE (uXML) for the UD6/Uniface source XML, so that 'untrained' staff could access the source code to help in the diagnostic process/second or third level support.  Another customer converted the UD6/Uniface XML source into Microsoft help files, for the same purpose.  

There are drawbacks too of course.  There is no way text files can be as fast as a database for some queries.  Inevitably some processes need to change from fast forms to using native text file based tools instead (sed, grep etc.).  It involves change and none of us like change and often we're already quite busy just getting our jobs done.

I originally wrote UD6 because I had a team of consultants working lots of different Uniface programming jobs and I felt it was important that as an organisation we could track what we were doing, just in case a customer queried how much time was spent, or whatever.  I put it up on a web site for others to look at - I think the first person outside of my team to try UD6 used version 0.56 for Windows / Uniface 7.2.04 on 11 January 2000, and Uniface developers were buying licenses for it by April 2000.  

To create something using the API's that Uniface provides that helps developers so much they are willing to take the time out of their day to test it and for some to license it has been a real thrill for me.  I'm very happy that because of these API's I've had the opportunity to make some people's software development just a little bit easier.  That I still get to do it 24 years later is just awesome.

Unfortunately I don't get to spend as much time on Uniface and UD6 as I'd like - my company March Hare Software provide change management software for everything from SAS/SPSS (statistical analytics) to Documents to Oracle databases to C/C++ and Java and Uniface of course. I think for every Uniface customer I have about 100 non-Uniface customers.  But Uniface and UD6 still hold a very special place in my heart and I've got a lot of ideas as how UD6 can be extended this year ready for its 25th anniversary in 2025.

I ended up writing a version control system.  Being bespoke, it does everything needed.  It will take time to write but it is definately achievable .

It is based on Git/Sqlite/uniface 10.4 and uses a distributed workflow with branches, local sqlite repositories, and integrated oracle repositories.

I also ended up writing something on my own, not a version control system (I use IBM Rational Synergy) but a Uniface client for it, which is integrated into the IDE. It works fine since many years. It addresses the above mentioned problem with integrity by comparing the database contents and the copy (the export file which is stored in the versioning system) when you begin to work on an object, so that you can see differences and can choose to use them or revert them. IBM Rational Synergy is an "old" versioning system because it works like cautious locking so that only one user can work on an object (e. g. a service component) in contrast to "modern" versioning systems like Git where conflict resolution is sometimes necessary. I have not switched to such a system because in rare cases, big problems can occur when there is a conflict in the form paint (conflicts in proc code can be resolved as for other programming languages but form paints are much more difficult).

Eric,

Technically we refer to that difference as 'reserved' or 'unreserved' (cautious locking is the rational term for 'reserved') and there is nothing 'new' or 'old' about either.  CVS was the first documented modern version control system (July 1986) and was unreserved by default but had the ability to reserve as well, other later systems introduced 'reserve by default', and now systems like SVN and Git have 'unreserved only'.  

There are advantages and disadvantages to each approach, and a good engineer will choose the tool that suits the requirements.  Don't be bullied into believing that Rational Synergy is not fit for purpose, if it meets your requirements, it's good.

-Arthur

Hi Eric.... 

In reference to comparing the formpic.  

I resolve this, by comparing xml with xml.  I do not compare the database contents.  I do, an on-the-fly, xml export of the frm in question and compare that with the xml version in the version control system.