Ignition Versioning

Hi all,

Do you have any info about Ignition versioning? I found that Ignition can:

“if you change a project to be in Manual publish mode, then you can explicitly publish a project in the Designer.”

inductiveautomation.com/supp … ioning.htm

But it would be far better to have that information in a text file too (txt, xml…) in order to track all the releases via Subversion.

Could you tell me if it is possible to get these results or to track via subversion the upgrades I do?

Thank you for any feedback! :slight_smile:

Kyle Chase on this forum made a module to make the publish comments available through SQL.

cosentano, because the project is saved to an internal database in the gateway, you can’t use a VCS on the project itself without exporting the project when you want to commit a new version to the VCS.

If you do export the project, be aware that although the format is xml, much of the data inside the xml is binary. This usually means that the change saved between one commit and the next will be relatively large even for small changes to the project, so your VCS can quickly eat up some disk space for large projects with frequent commits.

Hello,

thank you very much for your replay.

It would be enough for us just put under VCS configuration files that then can be imported\copied in correct folder to restore the project.

They could be for exampe the xml files exportable for sql tags and the configuration stored in data folder.

The point is that for files in data folder, setting.data file, for example, is in some way compiled (many SOH and NUL ASCII characters inside).

There is a way to get it (and all other similar files) more readable and so comparable.

Besides when we export a project it is created a .proj file that it is not usefull for our scope because we cannot trace its changes. Or there is a way to read it?

Thank you very much for any ideas and support.

No, the project file is probably not as human-readable as you would like. :smiley: There is so much data that needs to be stored for even a single window that if we put the information in a human-readable format the files would be enormous, and the readability would benefit almost none of our customers.

That said, you can probably design a system that will do what you want, it just won’t be as automated as you would like. Exporting your project file on a regular basis would be a good idea, since that way you can recover from disaster easily, as well as revert back to a previous version if your design changes aren’t working out. Good commit messages will help here (as they do with anything you are putting under VCS.) Although much of the data inside the project file is binary, there are parts that are human-readable that can help you know what changed. For example, in the Skeleton Project Single Tab West from our website, lines 11-21 are [code]Skeleton_Project_Single_Tab_West

Skeleton Project (Single Tier Tabbed West) 1327446189176 admin 47 87a4cb81-2d09-b288-da51-f28320357ed3 <![CDATA[H4sIAAAAAAAAAGy8BVBcTdQtirsEt+DuLsHdJbg7gwVnGNzdIbhbcHd3C+7uIbiG4Pom/3ffvfXq[/code] You can easily read the name of the project, who modified it when, and can tell that the first resource is an About window. If you need a human-friendly representation of that window, you could also save annotated screen shots when major changes are made. But if your major worry is about restoring the project, the .proj file will do the trick.

Tags can be exported as xml and are very readable. An example is <Tags> <Tag name="_types_" path="" type="Folder"/> <Tag name="_Diagnostics_" path="" type="Folder"/> <Tag name="Connection State" path="_Diagnostics_" type="OPC"> <Property name="Value">Connected</Property> <Property name="DataType">7</Property> <Property name="OPCServer">Ignition OPC-UA Server</Property> <Property name="OPCItemPath">[GenericSim]_Meta:[Diagnostics]/Connection State</Property> </Tag> </Tags>

The gateway backups are not at all human readable, and probably not a great candidate for version control because they are all binary data. But you should have a good incremental backup system on computers where you have any important data, including the gateway. Remember that some data, like images, are not tied to a specific project, so you need to have a gateway backup as well as a project backup if you are worried about recovering from a complete disaster.

Anything you have in a database is not going to work well with VCS. That’s just the nature of databases. Again, incremental backup is important.

I would suggest that you make a small example project and play around with exporting things to VCS. Make some notes on what you need to put in the commit messages. You’ll probably find a work flow that meets your individual needs.

Thank you, I have got the point! :slight_smile:

A further questions, I heard the rumor that the possibility of versioning will be given with the V7.7. Is it that true?

Thanks a lot for your help!!! :slight_smile:

I discovered that in configure–> console–>advanced there is the possibility to retrieve all the data configuration that Ignition saves in the internal database. Do you know if ther’s a way to dump this database, in order to be restored in a second moment?

Really dont need to revive this. Just further details would work…
What is the unit of measure for the lastModified? Hours, Minutes, Seconds , tens, hundreds, thou etc