We’ve been using ignition for awhile here and had a question as to its interacting with Revision Control software.
Obviously the best solution would be to embed an RCS client right into ignition itself. We use Subversion and Mercurial here, but there are others that are equally popular.
Barring that, which is a fair bit of work, another way is to make the export files readable by humans in text. Your exports are XML now, which is good, but most of the meat of the data is stored in binary blobs. These don’t work for RCS programs at all.
Example:
<resource id='34' name='' module='' modver='7.2.6.128' type='sr.global.props' ver='0' dirty='false' editcount='0' parent='' oemlocked='false' scope='7'>
<doc></doc>
<bytes><![CDATA[H4sIAAAAAAAAAIWQTWvDMAyGz+uvML43XW6DOS6F0F1K2VjLzqqjZh62VWw57OdP6WBQKOyiL149
vJJZf8egJszFU+p02zxqhcnR4NPY6eNhu3zSa7swdPpCx0XNpXKhdNpRbHwaqmM/IVSmCCyMxo/J
XwsRREmXTPNq8xLoBOE106Vou3gwtHQqdrogbyp/yvzsA+4holZCb58LZ22NRNtjYDgW8WhWc29W
snuL6PEMNXAPDIVqdvdB2/79bdf+BxHNAcYijiY/YL5L+sAQNn83z/IbqqRr+H2a/QEMCiBuZQEA
AA==]]></bytes></resource>
I recently went to cut and paste between two copies of ignition I had up, and realized that you already have a format that is human readable and would probably work with RCS, it’s just a bear to actually use. The clipboard has things more in this format.
A HMI system compatible with traditional version control systems would be a huge selling point for me. I can’t express in words how much I want to do my version control in Mercural or Git with Ignition.
We totally agree that build in support would be great. We’ve been talking for years about doing it, or hoping that someone would make it with the module sdk (though it would probably be a little more tightly integrated if we did it).
We’re about to work on the road map a bit, we’ll have to bring this up again. In regards to the different export formats, I’m not sure, as we’re actually moving away from XML in the newer version to improve speed. But, we’ll see.
I haven’t used GIT or Mercurial. Reading reviews seems to indicate that both are superior products (newer generation) compared to SVN, but neither provides the leap that SVN was over CVS.
[quote=“nathan”]I haven’t used GIT or Mercurial. Reading reviews seems to indicate that both are superior products (newer generation) compared to SVN, but neither provides the leap that SVN was over CVS.
Unlike SVN branching and merging is awesome and fast. You’ll find yourself opening a branch and committing changes for everything. If you have a new feature, idea, bug fix, etc. you can easily create a new branch quickly, do a few commits on that branch and then either merge it into the main branch or throw it away. You don’t have to mess up the main branch just to save your experimental ideas.
You have a local copy of the repo so all your changes can be commited right away. You only have to merge with yourself until your ready to commit entire features to the main repository.
Because everyone essentially has their own little version control ecosystem, data is always backed up. With SVN you have to worry about when the last time you back up the repo, but any Git or Mercurial user just needs to push their copy of the repo back out to get everyone back to business.
Its difficult to cover all the advantages, but those are the ones I’ve seen for myself. Personally I like Git over Mercurial due to the way Mercurial handles branching, but to each their own. From the perspective of Ignition, the power of a DVCS isn’t really a huge improvement over just getting version control in the first place. Where DVCS really shines is collaborative projects. Check out github.com/ for an example of DVCS enabling organizations to handle open source much easier than sourceforge ever was.
Just throwing this out there - what do you think of an internal, integrated version control system versus the ability to “hook” into an external one (SVN, GIT, or Mercurial)?
I’m guessing that an integrated one might be more tailored to the application and useful for novice users, while power users could probably do more with external version control support.
[quote=“nathan”]Just throwing this out there - what do you think of an internal, integrated version control system versus the ability to “hook” into an external one (SVN, GIT, or Mercurial)?
I’m guessing that an integrated one might be more tailored to the application and useful for novice users, while power users could probably do more with external version control support.[/quote]
I’m leaning towards a built in system within Ignition as it will be the easiest to implement and in the end will keep things simple for anyone doing maintenance not familiar with traditional version control. The very fact that we’re talking about getting version control implemented is great. At this rate Ignition will be the only SCADA package with decent version control.
I’d probably prefer the integrated one, but it would be a great deal more work. You could provide more info on exactly what changed if you integrated it, such as “this button moved from here to here” or “this script changed” when displaying the changesets.
The question is also which ones do you support. I’m leaning towards Mercurial as that’s the direction we’re headed now. We only use SVN for legacy. Git, BitKeeper, Perforce, Bazaar and a number of others exist and are fairly popular in their own circles. One reason to go to Mercurial for Ignition is that Python itself and many python projects are going from SVN to Mercurial. (Git is being used for the Linux kernel and for many Ruby projects.)
A human readable format of some sort would likely be easier to develop but harder to use, but it would have the advantage of being universal and letting the user pick their tools. The only real complications would be that things would need to be relatively stable in the export format. You wouldn’t want ID numbers changing, or the order of rows changing in the file and creating lots of spurious updates. We have that problem when we try to bring in Isagraf code into RCS.
Here’s my thoughts for the path-of-least-resistance steps to actually getting something useful done.
Come up with some sort of “exploded” project format so that it isn’t a .proj file with a bunch of gzipped, base-64’ed data, but instead a bunch of resources files. These would vary in how “human-readable” they were, but they’re better than the all-in-one file.
Write a “VCS” module that could be given a folder path that would dump the project in its exploded format into the folder path on each save.
Give the module a “post-save-hook” command which it would run after each save. This would likely be a batch file / shell script. Environment variables would be set so the script could use the Designer’s commit message string and change summary.
Give the module an “import from exploded project” command which would pull the project back from the exploded format and overwrite the project.
The advantages of this module over some sort of embedded VCS system:
Easy for us to write. Important given the fairly low-value demand. (A few people want this, but most people would scratch their heads and say “What is VCS?”)
This system could be made to work with any VCS so we don’t have to get into the Mercurial-is-best argument over and over again.
So the project encoding would become a user defined option? Ie: small (base64 encoded zipped, etc) versus XML (or whatever “exploded” format).
What about the storage of script libraries and image files? I’m thinking that either: an option to store in a directory structure or provide some sort of import/export functionality.
What about the rest of the configuration, which is contained in a gateway backup. This is: datasources, project connections, and many other settings.
I think it would work fine for a huge shotgun style export (like gateway backup) to be able to recover most things. The desirable property is that small changes or additions don’t make significant changes, so a VCS system can efficiently store the bit-wise change. Sort of like the opposite of a good hash function (diffusion).
Am I making the whole thing more complicated than it needs to be?
My idea was restricted to projects only - not the rest of the gateway. Is that a deal-killer?
And you wouldn’t choose the format of your project, this module would just mirror your project in an exploded format on the HD somewhere. The module I was envisioning would hook into the system as-is, and nothing else would change.
I’m assuming that projects are stored in an object based structure, and that should be very simple to serialize to either JSON or XML based on reflection. Nothing more should be needed for implementing a VCS.
This assumption is not quite right. At one level they are an object based structure, and are serialized to XML via reflection, but by the time they get to the gateway there's been some encapsulation and re-packaging so the XML isn't readily available.
[quote=“Carl.Gould”]Here’s my thoughts for the path-of-least-resistance steps to actually getting something useful done.
Come up with some sort of “exploded” project format so that it isn’t a .proj file with a bunch of gzipped, base-64’ed data, but instead a bunch of resources files. These would vary in how “human-readable” they were, but they’re better than the all-in-one file.
Write a “VCS” module that could be given a folder path that would dump the project in its exploded format into the folder path on each save.
Give the module a “post-save-hook” command which it would run after each save. This would likely be a batch file / shell script. Environment variables would be set so the script could use the Designer’s commit message string and change summary.
Give the module an “import from exploded project” command which would pull the project back from the exploded format and overwrite the project.
The advantages of this module over some sort of embedded VCS system:
Easy for us to write. Important given the fairly low-value demand. (A few people want this, but most people would scratch their heads and say “What is VCS?”)
This system could be made to work with any VCS so we don’t have to get into the Mercurial-is-best argument over and over again.
Thoughts?[/quote]
This sounds reasonable.
I did come up with one other issue that may come up during a merge though.
User A and B both have revision 50 of the screen.
User A renames Dropdown C to another name.
User B adds a link from Dropdown C to pull the data into Text box D.
Ignition when you rename goes through all things linked to that item and adjusts them, but when you merge A and B’s changes, Text Box D will still be referencing the old name of Dropdown C.
I did come up with one other issue that may come up during a merge though.
User A and B both have revision 50 of the screen.
User A renames Dropdown C to another name.
User B adds a link from Dropdown C to pull the data into Text box D.
Ignition when you rename goes through all things linked to that item and adjusts them, but when you merge A and B’s changes, Text Box D will still be referencing the old name of Dropdown C.[/quote]
Sounds like a pretty standard merge conflict. Normally this type of situation is flagged during the merge for manual correction.
I don’t think that it would be flagged in this case though. The edit the second user made would have been in an unrelated location from the changes the first person made, so it would have been automatically merged in.
But you’re right that this can happen in other things as well, if someone does a global search and replace. I suspect we’d just get an error that the new reference was invalid once you loaded it into ignition and you’d need to manually re-do the change.
Well, the idea behind RCS would be that you might have this window loaded in 3 separate projects. We already have a situation where we have 3 identical projects (with different database, userlist, and taglist) that need to be kept in sync. You might have multiple developers working on the same window on two separate servers then needing to sync their work together.
