Version Control

Integrated version control would be real nice.

you know, right click on a window or script and get a commit option? Sorta like Tortoise?

Agreed, this isn’t the first time we’ve heard a request like this.

Further to this, In would be nice to commit/branch/tag version x in a development system and then later checkout version x into the production system.

This would give us the ability to rollback to version x-1 after we discover that production is different from development/test.

(Production: The best test environment)

1 Like

Yeah, that would be awesome. I can see tagging/rollback, but I think we’d just let you use basic project copying for branches.

We already use CVS and Tortoise as our method of version control for all our source code. The only anomally when dealing with Ignition is that we just export a backup of the Project to a local directory, then commit that file to the repository.
Restoring the backup simply involves going to the Ignition web console & overwrite the existing project.
Of course it would be great if this were integrated, but for now this method works for us.

Ignition can never have an integrated solution that would satisfy everyone’s requirements.

I would far rather that Ignition exposed the files somewhere so that I can use my own existing version control and backup systems (and hopefully also my own text editor, at least for editing script modules).

Still just thinking about this? Any module developers want to take a stab at creating something?

This just came up yesterday actually. Things are getting more serious, but still no concrete details.

We’re using a python script that exports scripts, expressions and SQL bindings to the filesystem where a normal version control system can be used. It’s incredibly useful to be able to see what’s changed, even if you can’t easily import changes back into Ignition.

We have also added an import/merge mode to pull changes from the filesystem back into Ignition, but it’s a very confusing process.

We have written a module which adds a new type of script module that uses the filesystem directly, but we aren’t using it at the moment. The problem is that the scripts can only be edited via the filesystem, which proved too cumbersome when trying to bugfix a live installation.

There are two major problems that prevent this from being sanely done by module developers:

  1. The module SDK does not expose individual resources, so the only way to get at the scripts is using hackery in Jython.
  2. Ignition uses its own internal storage system instead of the filesystem, even on the gateway. This means that importing or exporting is fine (depending on whether you want Ignition or the filesystem to be the master copy), but you can’t do both without a merge process, which is not straightforward to implement or use.

Also, none of this includes the layout of the windows or other properties. I did look at using an XML export, but the export is not ‘stable’ because it’s just a serialised representation of the objects in memory.

What you are doing is interesting as I have thought of trying to at least export the scripts to be able to view version differences. Some way to get property changes on controls would also be helpful since so much in Ignition can be done via changing property values.

I have been the sole Ignition developer at my site which hasn’t made version control and the lack of being able to see file differences to much of a problem, but we are looking at adding more people to the project team which will make this more of an issue. I have also been promoting the use of Ignition as a development environment for other projects, but the lack of being able to do version control on separate project components with difference/change tracking is causing other teams to not consider user Ignition.

Kyle Chase at Kymera Systems have made an version control module, we are using a beta of this.

1 Like

do yo have a copy of the Module sir?

1 Like