Version control

[Anthony Thompson]

I’m aware that this topic has come up several times in the past; in fact I just made a summary for my team of all the previous discussions.

I also know that Infor has recently added basic versioning to the GUI (View -> Site Manager -> right-click on file and Check-In, Check-Out, Show History, etc.

However the GUI versioning only works for Cloverleaf objects and I’m investigating a version/source control system we can use for our shell scripts, cron files, etc. which are outside our Cloverleaf sites.

The other weakness of Cloverleaf’s version control is that there is no command line equivalent. I’d hoped (prayed) that I’d find that underneath the GUI there was a version of cvs, svn (subversion) or git, but alas no – it seems Cloverleaf decided to roll its own VCS with a proprietary database.

(Which is fine, but also means they’re reinventing the wheel and means their version control also lacks basic VCS features like being able to compare two prior versions, restore a prior version, allow two people to work on different parts of a file and merge changes, etc.)

We’re also very leery about the exclusive checkout aspect of Cloverleaf’s GUI-based versioning, as far as someone checking out some files and forgetting to check them all in before going on vacation, or if out sick, etc.

In the Unix world there’s CVS (early 90s; venerable), Subversion (early 2000s, an improved CVS), and Git (late 2000s, most modern).

The momentum is obviously behind Git and I wish we could use it, but unfortunately getting anything installed on our Cloverleaf server takes an Act of God (risk assessment, justification, etc.) and our server vendor (IBM/AIX) only has a prebuilt package available for CVS (see http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html)

So unfortunately that means we’ll probably have to go with CVS since it’s “vendor blessed” and the vendor supplies an installation package. I guess some version control is (much) better than no version control.

My question is, what issues have people encountered using CVS (or for that matter Subversion or Git) with Cloverleaf, and how did you (or did you) resolve them?

Previous threads have mentioned that the GUI rewrites NetConfig in a different/semi-random order, even if no changes were made, so from a source control perspective it appears the file changed even though it really didn’t.

(Vaughn Skinner wrote in 2012 at https://usspvlclovertch2.infor.com/viewtopic.php?t=5787 that he wrote a Perl script to reorder NetConfig before checkin, but I don’t think he ever posted the script, and I’m not sure how palatable that would be to my team in any case.)

Another issue that was mentioned is that CVS/svn files and/or directories in Cloverleaf’s directories can cause issues with the GUI (see Richard Hart in 2013 at https://usspvlclovertch2.infor.com/viewtopic.php?t=6729 and Lin Lue in 2006 at https://usspvlclovertch2.infor.com/viewtopic.php?t=1191 and Bill May in 2005 at https://usspvlclovertch2.infor.com/viewtopic.php?t=681)

So I’m wondering if anyone is using or tried using cvs/svn/git and experienced problems in the GUI and what the solution was, or any other problems encountered & what the solutions were.

(As a side note, it seems Cloverleaf used to come with a version of CVS called hcicvs, as it was mentioned in a 2006 post at https://usspvlclovertch2.infor.com/viewtopic.php?t=1203 but it was subsequently removed for reasons that weren’t clear, perhaps partly due to the plan to add versioning to the GUI.)

Topic

[Rob Abbott]

Hi Anthony I certainly understand why you would want to use a more robust version control but just want to respond to a couple points:

Quote:

… their version control also lacks basic VCS features like being able to compare two prior versions, restore a prior version, allow two people to work on different parts of a file and merge changes, etc.

You can do a compare between versions by looking at the history (a third-party diff tool is required, configure this under client options)

You can rollback / restore to a previous version by selecting the “Replace With…” option

No support for merge in current release

Quote:

We’re also very leery about the exclusive checkout aspect of Cloverleaf’s GUI-based versioning, as far as someone checking out some files and forgetting to check them all in before going on vacation, or if out sick, etc.

There is an administrator GUI for version control that allows an administrator to see the status of all versioned objects and release any lock that they want.

I have noted your requests for a command-line equivalent and support for non-native objects.

Rob Abbott
Cloverleaf Emeritus

[Paul Glezen]

I’m in a similar situation.  I had Cloverleaf tossed in my lap after our guru retired.  Since the guru pretty much did everything for everybody, he didn’t bother much with VC.  I learned that the Cloverleaf product offers VC and I expect to leverage it in another few months or so, once I figure it out.  But I wanted to start tracking changes immediately, so I started using what I know, and that’s Git.

My AIX admins declined my request to install Git on our TEST or PROD servers.  So I created three repositories on my local workstation: one for external programs that run outside (but interact with) Cloverleaf; one for tracking the configuration scripts (mostly shell scripts); and one for the Cloverleaf source.  I found that PROD and TEST were hopelessly out of sync.  So I only officially track PROD.  For my Cloverleaf source, I created a site directory with subdirectories for Tables, Xlate, formats, java_uccs, and tclprocs.  I also track the NetConfig files for each production site, naming them NetConfig.1, NetConfig.2, etc, to keep them apart.

This is only production.  When someone wants to start an enhancement, I copy the relevant Cloverleaf source from my Git working copy to the Cloverleaf TEST so they know they are starting from what is currently in PROD (and not some version on TEST that someone changed and then abandoned).  After development and testing has completed in TEST, and we’re ready for a PROD promotion, I copy the changed files back onto my workstation and commit them into Git.  I promote them from my workstation, not from TEST.  All NetConfig changes are done manually on PROD (not copied from TEST).  If, after a day or so, no disaster occurs in PROD, I tag the PROD promotion in Git.  Rinse and repeat.

Note that I am the only one using Git in all this.  Everyone else is oblivious.  This is all a temporary stop-gap until I get my head around the Cloverleaf development lifecycle which includes many tools such as version control and BOX for packaging/promotion.

I initially shared the concern about the Cloverleaf checkout locks.  However, as I learn more about the Cloverleaf development model, I feel that in this context the locks make more sense.  A Cloverleaf developer never has a private working copy of the code.  Rather, the client is working with code real-time fetched from a Cloverleaf TEST server.  If lack of communication leads two developers to change the same file at the same time, somebody is going to get hurt.  In this case, the lock mechanism compensates for the negligence of the technical team lead that should be communicating properly as to who should be changing what.

As Rob pointed out on a previous post, an admin can release abandoned locks.

I love Git.  I use it all the time for my open source projects.  The biggest problems I have with Git at work are that (1) none of my admins are willing to install/support it and (2) none of my colleagues are willing to effectively learn it.  The worst are my otherwise-bright colleagues with previous VC experience (baggage) who simply try to map the commands from CVS/SVN/ClearCase/whatever to Git and just make a mess that I have to fix.  Most Cloverleaf developers I’ve met that are not Tcl developers don’t possess the sophistication to make a distributed version control system (or even CVS/SVN) a regular part of their routine.  They’re terrified of command line VC.  That’s why I don’t see Git as a long term solution for Cloverleaf VC.  For most Cloverleaf developers at my work location, a GUI checkout, lock, change, check-in process makes more sense.  So once I get a grip on the Cloverleaf VC, I expect to drop Git and embrace the Cloverleaf model (at least for Cloverleaf source).  I expect to also reap the benefits of the BOX feature.

You specifically called out the challenge of tracking configuration scripts.  Unlike source code, configuration scripts often vary between TEST and PROD.  You can minimize this by externalizing these variations to property files and trying to make the TEST and PROD file systems as consistent as possible.  But fundamentally, the configuration of TEST and PROD will often be different due to different infrastructure topology if nothing else.  (IT shops have been addressing this for decades; but some in the industry have “discovered” this phenomenon under the guise of “DevOps”.)  In this vein, container-based cloud technology has garnered much attention.  (Docker containers, et al).  It would be interesting to see if Infor could offer cloud solutions with semi-private Docker repositories offering Cloverleaf Site images on which customers layer their own customizations.  Then the Docker image (or whatever container you prefer) becomes the unit of controlled deployment.

[Benjamin Rubin]

Certainly a late reply to this thread, but I wanted to mention my own solution to all this.

When I started to look into vcs support for our Cloverleaf environments, there was no such option in the GUI itself for this.  I knew that my team would be resistant to any development workflow changes. The way we do development currently is with a single test site environment that we all share.  Sure, managing locks is annoying, but not terrible.  There are only three of us total.

Anyway, what I ended up setting up was a simple script that performed a daily automated commit. I also parse out the netconfig into separate files for each thread, so looking at diffs is a lot more managable.  I know this really isn’t a real solution to version control, but it gives me a good overview of what is changing and when.  

It all gets pushed to an internal GitLab server as well.

[Greg Tataryn]

I have a question about version control in repect to using BOX to migrate interfaces.

If we have an xlate in test that is version 1.2 lets say and version 1.0 is in production. When the xlate is moved to production, does the production version update to 1.2 to match test?

Or if Box is not used for individual objects, but rather those objects are moved by copying them from test to production, how does that affect the versioning?

[Author]

Replies